GDPR data flow mapping - an approach

Data flow mapping is the process of identifying where personal data is collected or created, how it is stored and used, where it is transferred, and how it is eventually disposed of. Under the GDPR, understanding your data flows is a foundational requirement — without it, you cannot fulfil your obligations under Article 30 (records of processing activities), assess lawful bases, conduct meaningful gap analysis, or assign controller and processor roles accurately. Organisations that already maintain data flow documentation through an Enterprise Architecture function are well-positioned. For everyone else, the practical challenge is knowing where to start.

Your organisation may already have an overview of its data flows and have robust organisational policies and controls in place to ensure ongoing compliance with legislation relevant to your industry, operations, geography and so on. The overview of data flows may be maintained by, and is an integral asset of, your EA department whose task, among many, may be to ensure maximum utility of the data to fuel your business whilst being compliant. When something like the GDPR arrives, it is a natural discipline for your organisation to understand the impacts, identify gaps and risks, and then address what needs to be done in order to maintain ongoing compliance. Your organisation is a rare breed.

For most other organisations, among the current challenges is to identify where and how personal data is collected or created, stored, used, transferred and disposed of. In this article I present a pragmatic approach that will generate a high-level overview of a data flow — and more. There are of course other approaches to achieve this.

How does a visual approach to data flow mapping work? #

A visual data flow mapping approach uses a shared graphic vocabulary so that business and IT colleagues can discuss personal data in the same language and reach a common understanding. The diagram provides the basis for dialogue between your GDPR project team and multiple stakeholders — Business, HR, Legal, Procurement, IT, Security, Compliance, vendors, B2B customers, unions — in order to understand how compliant you are against the GDPR through gap and risk assessment.

The overview is seen from the perspective of a legal entity, which means transfers to other legal entities within your enterprise can be identified clearly. Phases of the data life-cycle — collection or creation, storage, usage, sharing or transfer, and disposal — form the vertical structure. “Data subject”, “legal entity” (the internal environment within the legal entity), and “3rd Parties” (including legal entities within your enterprise) traverse the structure horizontally.

Data flow mapping template diagram — horizontal axes: data subject, legal entity, third parties; vertical axes: data lifecycle phases

The graphic language consists of simple symbols and annotations. These should match your own organisation’s setup, IT operation and infrastructure rather than being adopted wholesale from any generic template.

Graphic vocabulary for data flow mapping — example symbols and annotations for personal data flows

What does a completed data flow map look like in practice? #

With this approach, an organisation can quickly gain a high-level picture of personal data flows. In practice, multiple diagrams will be produced — ranging from tens to hundreds, or even thousands, depending on the size and nature of your organisation. A dedicated tool for maintaining the diagrams is strongly recommended, though whiteboard sketches are a reasonable starting point.

Example personal data flow diagram for a fictitious training organisation

In reality you will capture more information and more nuance than a simple example can convey. The information you capture will also serve as a sound starting point for preparing to address Article 30 — records of processing activities.

Using the completed diagram, you can begin to determine your organisation’s role — controller, processor, joint controller, sub-processor — and plan gap analysis against the GDPR principles set out in Articles 5 to 11. This will trigger specific tasks in your GDPR project.

GDPR project tasks triggered by data flow mapping — including controller/processor role identification and Articles 5–11 gap analysis

The diagram will also pinpoint areas requiring further investigation — the specific gaps and risks that cannot be identified without first understanding the flow itself.

Further investigation and risk areas identified through data flow mapping

This approach will also begin to indicate the degree of change that your GDPR project will require from a people, process, technology and information perspective. There will be plenty of foreheads being slapped by your colleagues in the Business, HR and IT functions.

The richness of the diagram depends on how much you capture. There is a balance between keeping a single diagram readable and the need to produce detailed views of specific elements — especially where complexity exists.

What techniques can you use to elicit data flow information? #

Several elicitation techniques can be used to generate the data flow diagram, and typically you will use a combination of them.

Elicitation techniques for data flow mapping — interviews, workshops, document review, physical walk-throughs

I cannot emphasise enough the power of the physical data flow walk-through. During a workshop I was facilitating, one of the participants invited me to accompany her around the building to follow the data. As we walked along the corridors, in and out of offices, up and down flights of stairs, I was made aware of a number of environmental vulnerabilities I would never have identified had we remained in front of the whiteboard.

The participant was also satisfied that she had made a contribution — she was not comfortable in the formal workshop setting with her colleagues. Sometimes you need to meet people where they are, rather than marching them into your own rigid structures. This technique is time-consuming and is not appropriate for all data flows, but it is worth considering if risky practices are suspected or if a flow is known to contain significant manual processing of personal data.

A note on this approach #

This approach was developed based on research into existing tools — including Microsoft’s Threat Modelling Tool — and various templates. It has been refined through practical use with documentation teams who apply it regularly. It is not the only approach, and I am always open to learn from others.

What approach are you using?

I help Danish leaders develop their data protection strategy and roadmap, aligned with business purpose and goals. If you would like to discuss this in more detail, book a call or explore our services.