GDPR: useful analysis models

Originally published on LinkedIn, October 2017.

A COSO-inspired cube diagram combining four GDPR analysis models across its faces: organisational layers, data life cycle phases, data flow roles, and governance model

Several analysis models have proved consistently useful in my GDPR work for helping stakeholders understand complexity — whether they want a functional perspective, a holistic view, or simply need an abstract problem made concrete. This post brings together the four I return to most often.

Inspired by the (in)famous COSO cube, I have adapted it to combine these models into a single overview. There is no direct correlation between layers across the cube faces — it is a visual aide-mémoire rather than a precise mapping.

Model 1: the three-layer organisation model #

The first is a simple organisational model. It shows that data flows through three layers and is helpful for identifying processing elements and their relationships, stakeholders, purposes of processing, and third parties. It is also a useful way of representing the scope of assessments and investigations to be carried out.

In many organisations, very few people can describe the full picture in detail. To fully understand a processing activity it typically requires assembling a group of people with responsibilities and insight from each layer. Conceptually it looks like this:

Diagram showing the three-layer organisation model with business activity layer at top, business application layer in the middle, and IT infrastructure layer at the bottom, with elements and relationships mapped across layers

The three layers are:

Business activity layer — processes, procedures, activities, work, “getting stuff done”. These are automated, manual, or a combination of both, in-house or third party. In data protection terms, these are the processing activities carried out for one or more purposes.
Business application layer — software and applications that provide automated processing to support business activities. In-house or third party, or combinations.
IT infrastructure layer — IT processes, hardware components, IT applications, and IT services. In-house or third party, or combinations.

As an example, for the HR processing activity “Recruitment”, the purpose of the processing might be “to assess an individual’s qualifications and suitability for a position” — as discussed in my earlier article on why purpose is a great starting point. Analysis reveals that for this activity a number of elements from each layer support the processing. The diagrams are conceptual and in reality would be more complex, particularly at the IT infrastructure layer.

Three-layer model applied to the HR Recruitment processing activity, showing HR processes, business applications, and IT infrastructure components mapped across the three layers

On the question of tools: there are a growing number of options emerging, particularly those supporting Article 30 requirements. For organisations that need to move forward while scanning the market, it is possible to use existing in-house tools such as SharePoint as a stop gap. SharePoint has its limitations — it is not possible to link and easily maintain all elements within the three-layer model across all layers, and managing the registry alongside separate document libraries is cumbersome. Unless you are a small organisation or comfortable tinkering behind the scenes, you will need to seek alternatives.

SharePoint setup diagram showing the Registry of Processing Activities list linking to the Documentation library and the Gap and Risk Log list

Model 2: the data life cycle phase model with data flow roles #

The Data Life Cycle Phase Model coupled with Data Flow Roles is covered in an earlier article of mine on a structured and visual approach to data flow mapping. It is a visual and structured approach to mapping data flows per purpose that can be used to align stakeholders, identify where in a flow to test processing activities against GDPR principles, and pinpoint areas requiring further investigation. I will not go into detail here — see the earlier article — but here is an example:

Data life cycle phase model showing data flow across collection, storage, use, sharing/transfer, and disposal phases, with data subjects, legal entity, and third parties mapped as rows

Similar functionality to this diagram is now incorporated in the OneTrust privacy management tool, in the Data Lineage function.

Model 3: the governance model (POTI) #

The last model is what I loosely call the Governance Model, though I appreciate that label could provoke considerable discussion — especially as the elements are often seen as “enablers”. It is borrowed from MSP (the UK programme management methodology) where it is known as the POTI model: Processes, Organisation, Technology, Information.

POTI governance model diagram showing GDPR Impacts at the top with arrows flowing down to four elements: Processes, Organisation, Technology, and Information

When addressing new legislation such as the GDPR, I have used POTI to pinpoint first-cut impacts per high-level GDPR requirement — or related groupings — leading to identifying first-cut project scope. Asking the right questions for each element elicits a number of tasks requiring investigation. Affinity mapping can then be performed on the answers to identify specific deliverables and work packages. Here is a sample set of questions:

Table of POTI questions across four columns: Policies and procedures, People/organisation/culture, Technology and tools, and Information/agreements/reports — each with a set of diagnostic questions

A more in-depth version of the Governance Model involves assessing impacts against seven perspectives, based on the old COBIT 5 enablers. This extended model is particularly valuable when new requirements are expected to heavily impact people, organisation, and culture. The seven perspectives are:

Seven COBIT 5 enabler perspectives: Policies, processes and procedures; Organisational structures; Technology; Information; Culture; Insights; Competences

Risk Telling #

I have also used the POTI model to articulate the complexity of gap closing and risk treatment. The complexity can be overwhelming for executive management, and I have used the model as the basis for what I call “Risk Telling” — making risk narratives comprehensible by structuring them through the POTI elements. Conceptually it looks like this:

The key is to link and articulate the gaps and risks identified to either a privacy impact — harm to an individual — or a business impact such as compliance risk or reputational risk, while also making clear the underlying causes that must be addressed. By categorising risks and issues using the POTI elements, it becomes possible to demonstrate that it is not simply a case of “fix the IT system” or “get legal to fix the data processor agreement”.

Combining POTI with the Swiss Cheese Model #

The POTI model can be combined with the Swiss Cheese Model — which is more commonly used in accident investigation to understand what, how, and why things went wrong — to articulate what could go wrong, or is going wrong, in a GDPR context and why. Here is a simplified example:

Swiss Cheese Model applied to GDPR risk, showing slices labelled Processes/procedures, Organisation/people, Technology, and Information, with threat actor arrows passing through the holes in each slice to reach a data breach outcome

Frequently Asked Questions #

What is the POTI model and why is it useful for GDPR? POTI stands for Processes, Organisation, Technology, and Information. Borrowed from the MSP programme management methodology, it provides a structured way to identify the full scope of GDPR impacts — ensuring that compliance work is not reduced to just legal or IT fixes. Asking diagnostic questions across each element surfaces the people, culture, and process dimensions that are often underestimated.

What is the three-layer organisation model used for in GDPR? It maps processing activities across three layers: business activities, business applications, and IT infrastructure. This makes it easier to identify the full set of elements involved in any given processing activity, scope assessments accurately, and assemble the right people in the room — since in most organisations no single person has a complete view across all three layers.

How does the Swiss Cheese Model apply to data protection risk? In GDPR terms, each slice of cheese represents a POTI layer — Processes, Organisation, Technology, Information. The holes represent control gaps. When the holes align across layers, a threat actor (a malicious employee, an external attacker, or even a well-meaning mistake) can pass straight through to a data breach. The model is useful for making systemic risk visible to executive audiences who are accustomed to seeing risk treated in isolation.

If you found this useful, the Purpose and Means newsletter covers GDPR, data governance, and privacy strategy — fortnightly, in plain language.

Purpose and Means works with organisations on data protection strategy, governance, and compliance - going beyond the legal text to focus on how things actually get done. If you’d like to discuss what this means for your organisation, book a call or explore our services.