DPIA: why GDPR analysis should start from the real system architecture

A Data Protection Impact Assessment can be thoroughly documented and still describe the system that actually processes the data imperfectly.

The problem appears when the DPIA is built mainly from functional descriptions: purpose, categories of data, data subjects, retention periods and planned security measures. These are essential, but they do not always show where the data actually travels, which applications handle it, where it is stored and which technical services the processing depends on.

In April 2026, the European Data Protection Board (EDPB) presented a common DPIA template intended to structure, harmonise and document the process. Its use is not mandatory and, as of 17 September 2026, the official page still states that the template is to be finalised after the public consultation.12

This brings a practical question back into focus: can an organisation properly analyse the risks of processing if it does not know its architecture precisely?

A DPIA is not only a legal document

Article 35 GDPR requires a DPIA where processing is likely to result in a high risk to individuals' rights and freedoms. It must include a systematic description of the processing operations, an assessment of necessity and proportionality, an assessment of risks and the measures envisaged to address them.4

CNIL separates the exercise into three components: a detailed description of the technical and operational aspects of processing, the assessment of necessity and proportionality, and a technical study of risks to confidentiality, integrity and availability.3

A statement such as “data is hosted in the cloud and accessible only to authorised users” is therefore too abstract to explain the technical exposure of a processing activity.

Move from declared processing to deployed processing

Consider an HR system using an AI service to assist candidate assessment. Functionally, the chain may look simple: Candidate → application data → analysis → result used by HR.

The deployed architecture may be longer: Candidate → recruitment portal → API → AI service → database → document storage → HR application → identity provider → logging → backup.

Several providers may be involved. Data may cross multiple environments. A backup may sit in a different region from the primary database. Technical logs may contain identifiers or information from requests. An external API may participate in processing without appearing in the initial functional description.

A DPIA therefore benefits from comparing what the processing is supposed to do with what the architecture actually does.

Architecture adds information that a processing record may not contain

Records of processing and DPIAs have different purposes. A technical map can add complementary information: applications actually involved, data flows, APIs, storage systems, identity services, technical providers, infrastructure, backups and shared dependencies.

The goal is not to turn an information-system map into a DPIA. It is to let the DPIA rely on a verifiable representation of technical reality.

Read further
GDPR: information system mapping and records of processing are different — but complementary →

A useful chain: from purpose to infrastructure

One way to structure the relationship is to move progressively towards technical components: Purpose → processing → data → application → flow → storage → infrastructure → third party → security measure.

Each level answers a different question: why is the data processed? what operations are performed? which systems handle it? where does it travel and persist? which dependencies and third parties are involved? which controls actually protect the whole chain?

This does not replace a risk-analysis methodology. It helps test the consistency of the description on which that analysis relies.

Example: an AI-assisted HR system

The organisation states in its DPIA that CVs are used to assist candidate assessment. The initial description identifies the processing, the candidates concerned and the data used.

Architecture analysis then reveals a recruitment portal, an HR application, document storage, an AI API, an identity provider, a logging platform and backup infrastructure.

The question is no longer only whether the company protects CVs. It must understand every place where information from those CVs may be present: does the API retain requests? do logs contain personal data? do backups follow the same retention rules? which administrators can access storage? how does an erasure request propagate?

Architecture does not answer all these questions by itself. It shows where to ask them.

Data flow becomes a central DPIA object

Personal data is collected, transmitted, transformed, copied, stored, backed up and eventually deleted. For some processing activities it is therefore useful to follow the path collection → transfer → processing → storage → reuse → archiving or deletion.

Data may be well protected in the main application but appear in a temporary export; encrypted in a database but copied into a log; deleted from the operational system but remain in backups.

Data-flow analysis therefore complements processing analysis.

Invisible dependencies can change risk

An application may depend on an identity provider, secrets manager, DNS service, object storage, backup service, third-party API, monitoring tool or cloud platform.

Failure or compromise of one of these components can affect confidentiality, integrity or availability even when that component is absent from the initial business description. Architecture is useful precisely because it can make dependencies visible that are not obvious from the processing activity itself.

A security measure should be connected to something concrete

“Data encryption”, “access control”, “regular backups” and “logging” may all be relevant controls, but generic wording does not always show their coverage.

Does encryption include backups? Does multi-factor authentication protect business users, administrators and technical accounts? Does logging cover access to sensitive data?

A control becomes more useful when it can be connected to what it protects: measure → component → data → risk.

Architecture change should trigger a GDPR question

CNIL describes the DPIA as useful before implementation and also for monitoring risks over time.5

Information systems continuously change: hosting provider changes, APIs are replaced, a new AI supplier is integrated, databases migrate, replication is added or an internal service moves to SaaS.

Governance can therefore work in the opposite direction: architecture change → identify affected processing activities → check GDPR impact → revise the DPIA where necessary.

Useful review triggers include adding a provider, changing hosting location, creating a new personal-data flow, adding an application or API, materially changing access mechanisms, or creating a new copy or backup of data.

These changes do not automatically require the DPIA to be rewritten. They do justify a check.

Five architecture questions before validating a DPIA

1. Can we identify every application that handles the data?
2. Do we know where the data flows and where it persists?
3. Do we know the dependencies and providers required for the processing?
4. Do the documented security measures actually cover all these components?
5. Can we detect when a technical change makes the analysis outdated?

DPIA and architecture answer complementary questions

A DPIA asks whether high-risk processing is designed and controlled in a way that protects individuals' rights and freedoms. Architecture describes how the systems required for that processing are actually organised.

Neither replaces the other. But when a DPIA relies on an overly abstract technical representation, the analysis risks describing the system the organisation thinks it has, rather than the system that actually processes the data.

The European template presented in 2026 is an opportunity to revisit that connection. One question can be added to GDPR workshops: “Now show us where the data actually goes.”