Anything that is of value to you is an asset. Anything that you would like to protect is an asset.
This definition is crucial, because it will help you recognize assets in such a manner that you can fit them into your 3P framework. So, what are some of the assets you know?
- The building your office is in
- The computer you use
- The antivirus software your sysadmin installs
- The software you use to manage your business
- The code you develop
- The printer you use
If you want to list all the assets you would like to protect, it will become a laborious, complicated task. Where do you start, and how do you go about it? Two things will come to your rescue:
- Asset classification
- Its relation to the 3P framework
Asset classification
There is no single right way to classify and manage assets, and it depends on the nature of your organization. However, for aiding compliance, the method of classification below might serve you well:
Information, being the focal point of your classification, will help you make some crucial calls regarding which assets should be protected the best.
All non-information assets can be protected physically or procedurally depending on which ones are most critical. However, in terms of compliance, information assets require a more elaborate approach. But first, we must understand what personal data is.
Note: While creating the list of all assets in your company, the assets can be tagged to indicate which category they fall under. This can be done with the help of a unique symbol or a color code that indicates various categories of data.
Personal data
Article 4 of the GDPR defines personal data as "any information relating to an identified or identifiable natural person."
What we consider personal data depends on how we analyze this definition.
For example, the monetary value of a house is:
- Personal data, if it is used for tax purposes.
- Not personal data, if it is used for real estate purposes.
As you can see, data can be personal depending on the situation. To be on the safe side, it’s best to treat all data with the same importance as personal data.
Personally identifiable information (PII): Any information about an individual, maintained by a person or an organization, that can be used to distinguish or trace an individual either directly or indirectly.
PII is a subset of personal data and has more implications if it is breached since it can be used to directly identify an individual and could lead to the compromise of that individual’s rights and freedom. Here are some examples:
- Name, such as full name, maiden name, mother’s maiden name, or alias
- Personal identification number, such as Social Security Number (SSN), Aadhar number, passport number, driver’s license number, taxpayer identification number, financial account number, or credit card number
- Address information, such as street address or email address
- Personal characteristics, including photographic image (especially of face or other identifying characteristic), fingerprints, handwriting, or other biometric data (e.g. retina scan, voice signature, facial geometry)
- Information about an individual that is linked or linkable to one of the above examples
Information asset register (IAR)
The systematic recording and maintaining of all information assets is know as the IAR. This database is the single most effective tool to comply with the accountability principle of the GDPR, and it will greatly simplify your compliance with many other laws and standards.
For each activity, the accountable person should be in charge of creating and maintaining the IAR.
The are two components that form the IAR:
- Activity register and the RACI matrix
- Data flow diagrams
The activity register and RACI matrix form the base of the IAR, which is then built upon with the help of data flow diagrams.
Data flow diagrams (DFDs)
The activity register and RACI matrix should give you the list of all activities.
Each activity in that list will involve information assets.
- How is the information asset treated?
- How is it captured?
- Where does it originate from?
- Where does it get stored?
- How does it get processed?
- Whom is it shared with?
A pictorial representation of the answer to all the above questions is a DFD.
Data:
It can be one asset like an email address or phone number, or it can be a list of assets if all of them are going to receive the same treatment.
For example, Zylker's marketing team performs the activity of collecting the list of participants for a corporate event. This is what the data involved will look like:
Origin:
Where this activity acquired the data from. It can be from a customer, a database, another organization, or publicly available sources. Zylker collects this information directly from customers.
Capture:
The means through which the data was acquired.
The data could also be captured through emails, interviews, a cloud application, or any other means.
Process:
How this data is utilized in the activity.
The data could be emailed, used to run a machine learning algorithm, used for analytics, or used for any other process.
Share:
The data can be shared internally with other employees or teams, or with third parties. In this example, the data is shared with an event management company.
Purpose
Identifying the purpose of processing data is helpful for complying with most standards. In the example above, the summary of data collected was displayed. What is the purpose of that? Likewise, what is the purpose of sharing data with third parties or other internal groups?
The purpose can either be a part of the DFD, or it can be mentioned along with the RACI matrix. The latter option is recommended, as it makes it easier to compile all your information into a single document that can be submitted to the authorities when required.
Scope of an IAR: Process and product
Chapter 4 of the GDPR clearly provides the obligations of controllers and processors. More than just listing out rules, this part of the GDPR can help you derive clarity into what your IAR should look like.
There are two ways to create DFDs for your processes:
- DFD for the process
- DFD for the product
Both of these are equally important, as they are useful during different times when you're in the middle of an audit.
Process DFDs are created from the standpoint of your company's functions. This is where you are the controller—you own the information assets and can decide how they are processed. The above example of Zylker's event management DFD is a typical one for process DFDs.
Product DFDs are created from the standpoint of your product. Here, the information assets are inside your product and they belong to your customers and/or users of the product. You might still find these assets in your data center or somewhere you can access, but they do not belong to you.
This point becomes critical when you do risk analysis.
Product DFDs
If we were to create a DFD for Zylker's Think platform, it would be from the universe of the platform itself. In fact, each feature can have a DFD. Lisa Bingel's test module will have the following DFD:
Each feature for which a person is accountable should have a DFD. The collection of all such DFDs will be the product DFD.
It is preferable to maintain separate IARs for your processes and your products.
IARs and the 3P framework
In a 3P framework, the right-most entity is the product. The list of all instances of this entity will give you the list of products. The entity in the middle is the process. We have already framed this as the list of activities, and if you've been following along in this guide, you will have already mapped it to the employees in your organization.
As a result, you now have documents that will describe your process and your product. The challenge now is maintaining this documentation by capturing any changes.
Non-information assets
The most practical way to deal with these assets is the same as how you handle information assets: mapping them to the 3P framework.
In a few simple steps, you can get the list of all the assets in your organization:
- Accountable people in the RACI matrix list out the assets involved in the activities they are accountable for. They can do this by simply adding a column to the RACI matrix.
- With Illustration 8 as the reference, each asset is tagged.
If you filter out the unique elements of the Asset column, you have the list of non-information assets.
The SPA touch
When those accountable for a process need help, there's no better team to offer assistance than the SPA team. However, the SPA team should offer more than just clarification on accountable individuals’ doubts; it should also provide:
- Templates for DFDs for different kinds of activities.
- Tools to make creating the IAR easier.
- A comprehensive IAR for one team so that everyone else can use it as an example.
- Constant follow-up and review of IARs.
ZOHO STORY
Zoho's IAR: With our process spread across multiple operational and product teams, a unified procedure for IARs was a difficult idea to conceive. Each team handles different data assets in different ways. Although DFDs are simple representations of the data life cycle, they can be interpreted in many ways. We solved this problem with the divide and conquer technique: We divided the entire journey of creating the IAR into product, infrastructure, and operational teams, and approached the IAR from each perspective.
For example, a product team's process IAR for software development may not technically involve data, because they just code. So, most of their DFDs would be similar. However, their product IAR would involve data from customers. Inside the universe of the product, developers still handle customers' personal data, even though they may appear to never come in contact with customer data. Operations, on the other hand, has no such complexities. For example, recruitment and onboarding are activities that deal directly with personal data. But a suite like Zoho Finance deals with personal data throughout its products.
Such differences are bound to exist in any organization. The key to solving such problems has to come from an organization’s SPA team. The SPA should use these rules of thumb:
- Categorize functions into operations and products, or any logical way depending on how they work and what assets they handle.
- Come up with customized templates for each category.
- Lead by example; take one team in each category and create an IAR for them yourself.
Nurturing accountability
Previous Chapter
‹The “R” word that matters
Next Chapter
›
