Enforced since last 25 May 2018, the GDPR is raising many questions about data privacy concerns for organization within the scope of the regulation. Reaching compliance is necessary to enable your organization to provide strong guarantees towards the way you process the personal data concerning your clients and your employees.
To be clear, the objectives of the regulation can be summarized as following:
- Aim transparency and loyalty towards data subjects
- Accurate management of clients/employees personal data
- Be able to answer concerned persons enforced rights
Amongst all requirements to implement to demonstrate compliance (e.g. data processing registry, data breach incident response process, data subjects access rights management…) one exercise appears to be a key tool when approaching the question: where are the personal data we handle ? This step is called the data mapping and this is what we focus on in this very article. Then, it would be interesting to wonder how organization can approach it from a pragmatic perspective.
It is important to keep in mind the following points when dealing with data flow mapping:
- This task is not required for each data processing nor explicitly described in the law
- It will enable your organization to build up solid knowledge about your assets and thus ensure a better data flow control
- A data flow mapping is amongst IT Security best practices. It will help you to discover flaws that could lead to data breach event.
Data flow mapping
The purpose of such piece of work has multiple objectives:
- Regulatory : When processing data that could lead to any significant impact toward the data subject, conducting a Data Protection Impact Assessment, as required by the law, will imply to carry on a data flow mapping
- Organizational : Allow to interface business activities with the IT components supporting it
- Compliance : It is impossible to identify or investigate a data breach within the period required by the GDPR without gathering information regarding the data flows
Before talking about our approach to the data flow mapping workflow, we would like to draw your attention to the following points, which we consider to be major stakes:
- Shared/mutualized assets A particular attention should be dedicated to these data cores because the patchier the data are arranged, the more chance you have to not be able to list data flows as a whole
- Supplier and third parties relationship Be aware of the data, which is disclosed to each stakeholder within the data processing. Limit the amount of data to the strict minimum and ensure that you can effectively list and provide all data flow involved in the process Moreover, any data processing involving an application hosted in a cloud-based environment should be subject to additional analysis.
The approach
- Granularity
Depending on the following factors, you have to define the level of details that you need to achieve towards the data flow mapping exercise:
- The size of your infrastructure and its management (Is it outsourced ? Is it managed by one individual or a whole team ?)
- The nature of the data (Simple contact information or sensible data?)
- The complexity of the flows
- Bound data processing to their supporting assets
Keep in mind that the level of details should always allow your results to be usable and enable you to answer the following questions concerning one specific data processing:
- From where my data is stemming from? (Country, system, container)
- Where is it then sent?
- What system is involved in the flow?
- Who has potentially access to it?
The easiest way to carry on this piece of work is to start from a validated data processing inventory or registry. Indeed, these documents are designed to list the whole data processing occuring within your organization so by browsing them you will not forget any data flow.
Moreover, these documents should give you enough information to identify the involved supporting assets such as software components/tools or paper based documents.At this point, you should gather precise information about the previously identified assets from the individuals/teams who manage it. The use of a tool, which can track data movement, can help but is not compulsory. Good architecture schemes (hardware/software) will be enough to get the necessary details.
- Elaborate documentation
As you probably already know, concerning the GDPR, it is as important to make your data processings compliant that it is important to be able to justify and demonstrate that they are.
As said previously, according to your situation, you should create and maintain either:
- A concise but accurate flow mapping, if you are within the scope of smaller business
- An insightful and formal set of documents for larger companies
Here is a list of characteristics that will be clever to identify for each flow, where applicable:
- Data source/recipient
- Data owner
- Data subjects concerned
- Data format/container
- Data type (physical/electronic)
- Transfer method
- Person authorized to access
- Data criticity
- Retention period
- Deletion method (automatic, manual)
- Location
Conclusion
To conclude, we have seen how close the data flow mapping is related to your data processing inventory/registry and the points that should especially draw your attention. If the right choices are made, this exercise will help you out to have a better understanding of your assets and the risks related to it.
Finally, we remind you that, as almost each document designed within the GDPR approach, these documents have low utility if they are not updated and reviewed.
