Article 35(7) DPIA content: requirements and evidence

What an Article 35(7) DPIA must contain and why assessors check it

When a team plans a processing activity that may be high risk, the first question is what the data protection impact assessment (DPIA) must contain at minimum. Article 35(7) sets four parts: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of the risks to data subjects, and the measures envisaged to address those risks, including safeguards and security measures. The risk in question is the risk to individuals' rights and freedoms, not the risk to the organization's own systems, so the assessment has to start from what could happen to the people whose data is processed. Assessors look for each of the four parts as a distinct, traceable piece of work, and a gap in any one of them is the usual reason a DPIA is judged incomplete.

The work is usually hard for three reasons. System knowledge is scattered across engineering, product, vendors and the business owner, so the description is often out of date before it is finished. Necessity arguments tend to restate the purpose instead of explaining why this data, in this volume, is needed and why a less intrusive design would not do. And mitigations are listed as a generic security checklist rather than linked to a specific risk, so a reader cannot tell which control reduces which harm. An illustrative fix is a risk table where each risk row points to the named control, its owner and the test that shows it works.

The GDPR requires no certificate for this work. A DPIA is not something a certification body stamps for you, so the document itself, together with the evidence behind it, is what the controller must be able to produce when a supervisory authority asks. Before work starts, confirm internally who signs off the DPIA, where the version history is kept, and how the views of data subjects or their representatives are sought where that is appropriate under Article 35(9). Those decisions shape the evidence you will need later.

The four minimum parts of the DPIA and what each must show

Article 35(7) sets a floor for every data protection impact assessment: it must contain four elements. The first is a systematic description of the processing and its purposes, which means a written account of what data flows through the system, from where, to where, for which purpose, and who operates each step. For an engineering team this is the point where the architecture diagram, data inventory and processing purposes have to agree with each other. The second is an assessment of necessity and proportionality: why the processing is needed for the stated purpose, whether a less intrusive route exists, and whether the data collected and retained is no more than the purpose requires. The third is an assessment of the risks to data subjects, meaning the harm that could follow from unauthorized access, alteration, loss or excessive use, assessed for likelihood and severity from the individual's point of view rather than the organization's. The fourth is the measures envisaged to address those risks, including safeguards and security measures, each tied to a specific risk so an assessor can follow the chain from risk to control.

Two further provisions sit around these four parts. Article 35(8) asks the controller to take due account of compliance with approved codes of conduct when assessing impact, so if a relevant code applies to the sector or service, the DPIA should say whether the processor or controller adheres to it and how that affects the risk picture. Article 35(9) says the controller should seek the views of data subjects or their representatives where appropriate, such as works councils for employee monitoring or patient representatives for health services. The DPIA should record whether views were sought, from whom, and what changed as a result, or why none were sought. Confirm with your data protection officer or legal team how these inputs are documented in your template before the assessment starts.

Publishing is the last point to settle. WP248 rev.01 states that publishing a DPIA is not a legal requirement, but it recommends that controllers consider publishing at least parts, such as a summary or conclusion. For services sold to public bodies or to customers with their own transparency duties, a short published summary can answer questions that would otherwise arrive as individual audit requests. Decide early whether a summary will be published, who approves it, and which sections must stay internal, such as detailed security measures that could help an attacker. An assessor will expect the internal version to be complete even when the public version is brief.

What an assessor tests in a DPIA and the evidence they ask for

This table shows how a supervisory authority, internal auditor or external assessor checks a DPIA against Article 35(7), the evidence they typically request, and the findings that come up most often. Read each row as a test to run against your own assessment before someone outside the team does it for you. The main takeaway is that a DPIA is judged on whether its risks, measures and review record connect, not on whether the document exists.

Test area	What the assessor checks	Evidence requested	Common finding
Systematic description	Whether the document describes the actual data flows, systems, recipients, storage locations and purposes, and matches the processing inventory	Current data flow diagrams, processing inventory entries, system and vendor lists for the processing in scope	No description of the real data flows, or a generic description that could apply to any similar system
Necessity and proportionality	Whether the stated purposes justify each category of data and whether less intrusive options were considered	Written alternatives considered, data minimization decisions, retention periods tied to purpose	Necessity argued without alternatives, or data collected beyond what the purpose requires
Risk assessment	Whether risks to data subjects are identified, described from their perspective, and rated consistently	Risk register extracts with likelihood and impact rationale, and the version in force at each decision point	Risks framed as organizational risks only, or ratings with no stated method
Mitigating measures	Whether each named risk has measures that address it, with safeguards and security measures stated	Control mapping from each risk to measure, measure owners, and test results or configuration evidence	Measures that do not map to a named risk, or measures described but never tested
Views of data subjects	Whether the controller considered seeking views of data subjects or their representatives where appropriate, and recorded the reasons	Consultation records, survey or panel summaries, or a documented decision not to consult with reasons	No record of whether consultation was considered, or consultation with no effect on the assessment
Review trigger	Whether the controller has a defined process to check that processing still follows the DPIA when risk changes	DPIA version history, change records linked to the assessment, dated review entries	No review after a material system change, new data category or new vendor
Version and approval trail	Whether the document shows who approved it, when, and which version was current for each processing decision	Version history with author, date and approver, plus records of what changed between versions	Undated drafts, unclear approval, or a DPIA that was completed after processing started

How to write an Article 35(7) DPIA step by step, including review

The sequence below takes a team from an agreed processing activity to a signed, versioned DPIA that is revisited when the risk to individuals changes.

Scope the processing and name the owner
Start by defining the processing activity you are assessing: the system or service, the business purpose, the teams involved and the boundary of what is in and out of scope. Name one accountable owner on the controller side, usually the business or product owner, and record who advises on the assessment, such as the data protection officer where one is designated. The output is a short scope statement with the owner's name and the date it was agreed. You know this step is done when a reviewer can tell from the statement exactly which processing the DPIA covers.
Build the systematic description of the processing
Describe the processing systematically, as Article 35(7) requires. Work from system architecture diagrams, data inventories, data-flow diagrams, retention settings and the list of processors and sub-processors. Cover the categories of data subjects and personal data, the recipients, where data is stored and from where it is accessed, and how long it is kept. The output is a data-flow diagram plus a written description that matches the current system. You know this step is done when an engineer who did not write it can confirm that it matches the running environment.
Document purposes, necessity and proportionality
Record each purpose the processing serves and the lawful basis that supports it, then explain why each category of data is needed for that purpose and why a less intrusive approach would not achieve it. Compare the data collected with the data strictly required, and note where minimization, pseudonymisation or shorter retention was considered. The output is a necessity and proportionality section that ties each data element to a purpose. You know this step is done when every data element in the description has a stated purpose.
Identify and rate risks to data subjects
Identify the risks the processing creates for individuals, not for the organization. Typical entries cover unauthorized access, unwanted disclosure, excessive retention, loss of control over data, discrimination or inaccurate decisions. Rate each risk for likelihood and severity using the organization's documented method, and state the source of each risk, such as an insider, a processor or a system fault. The output is a risk register extract for this processing. You know this step is done when each risk has a likelihood, a severity and a rationale a reviewer can challenge.
Select and record mitigating measures with owners
For each risk above the acceptable level, select the safeguards and security measures that reduce it, such as access control, encryption, logging, retention limits or contractual terms with processors. Assign an owner and a delivery status to each measure, and note the residual risk after it is applied. Where a control is inherited from a platform or a processor, record the evidence that shows it operates. The output is a measures table linking each risk to its controls, owners and residual rating. You know this step is done when every high risk either has a measure with an owner or is flagged for consultation under Article 36.
Decide how to seek the views of data subjects
Decide whether and how to seek the views of data subjects or their representatives, which Article 35(9) asks you to consider where appropriate. Options include a consultation with user representatives, a survey, a works council for employee data or a documented reason why consultation is not appropriate. Also take into account approved codes of conduct under Article 35(8). The output is either a consultation record with the questions asked and the responses summarized, or a documented decision not to consult with the reasons. You know this step is done when the file shows a deliberate choice rather than an omission.
Record the outcome, sign-off and publication decision
Bring the scope, description, necessity analysis, risk register, measures and consultation outcome together into one DPIA document. Record the conclusion on whether residual risk is acceptable, the named approver and the date of sign-off. Decide whether to publish a summary or conclusion, which WP248 rev.01 recommends considering even though publication is not a legal requirement. The output is a signed, versioned DPIA and, where chosen, a published summary. You know this step is done when the approver can point to the version they signed and the evidence behind each rating.
Set the review trigger and keep the version history
Set a review trigger tied to changes in the risk the processing represents, as Article 35(11) requires where necessary. Typical triggers include a new data category, a new processor or sub-processor, a change of hosting location, a security incident, or a new purpose. Keep each version in a controlled repository so that changes, dates and authors are traceable, and check the trigger against the change log at each release. The output is a review schedule with named triggers and a version history. You know this step is done when a change request can be matched against the trigger list and the outcome is recorded.

Who writes, challenges and owns the DPIA: in-house team, partner and auditor

The controller owns the DPIA. Under the GDPR, the organization that decides why and how personal data is processed is responsible for assessing its risks, and that responsibility cannot be handed to a consultant or vendor. In practice, the work is spread across several people inside the organization, each supplying the knowledge only they hold.

Business owner: States the purposes of the processing, the categories of data subjects and the legal basis, and explains why the processing is needed.
Engineering and platform team: Describes the systems, data flows, storage locations, sub-processors and access paths in enough detail that someone outside the project can follow them.
Security team: Identifies threats to the data, scores the risks to data subjects and proposes the measures that address them.
Data protection officer: Advises on the assessment where a DPO has been designated, and documents that advice. The DPO does not make the decision for the controller.
Decision maker: A named person with authority accepts or rejects residual risk and signs off the document.

Before starting, confirm who holds the risk acceptance role, where the DPIA will be stored and who must review it when the processing changes.

Evidence that passes an Article 35(7) review and how to keep it current

A DPIA is only as credible as the record behind it. The artifacts below show a reviewer what was assessed, what was decided, and whether the assessment still matches the processing. Keeping them in a versioned, role-controlled space is what lets the team prove the review cycle happened.

Dated DPIA with version history

The assessment itself, with a clear date, named author, approver and version number on every revision. A reviewer will look for a history that shows when the DPIA was first written, what changed after each review, and who signed off. Check that superseded versions are retained rather than overwritten, so the team can show what the assessment said at the time a decision was made.

System and data-flow description

The systematic description of the processing required by Article 35(7): purposes, categories of data subjects and personal data, systems involved, recipients, storage locations and retention periods. Diagrams should match the live architecture. Ask the engineering owner to confirm the description against infrastructure configuration at each review, since a stale diagram undermines every later assessment.

Risk register extract

The assessment of risks to data subjects, listing each risk, its likelihood and severity as assessed, and the residual rating after measures. Reviewers test whether risks relate to the actual processing rather than generic threats. Keep the register extract attached to the DPIA version it supports so the link between a risk and its rating is traceable.

Measures register with owners and test results

The safeguards and security measures envisaged to address each risk, each with a named owner and a test result showing the control works in practice. A measure without an owner or a test is a statement of intent, not evidence. Record the date of each test and link it to the ticket or report that holds the detail.

Consultation record for data subjects

Where the controller sought the views of data subjects or their representatives, the record of who was consulted, how, and what was changed as a result. Where consultation was judged unnecessary, the reasons should be written down. Confirm with legal counsel how this record interacts with the DPO's advice, since the regulation treats both as inputs to the assessment.

Review log and change triggers

A dated log of each review, the trigger that prompted it, such as a new purpose, a new sub-processor, a new data category or a security incident, and the outcome. Article 35(11) requires a check that processing follows the DPIA when the risk changes, so the log should show that the team compared live processing against the assessment. For keeping the record current, XWiki keeps every page version with what changed, when and by whom, and lets users compare and roll back. Confirm that a product's version history and access model meet your own retention and access requirements before relying on it.

What an Article 35(7) DPIA costs to produce and keep current

This table lists each cost component of producing and maintaining a DPIA under Article 35(7), who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to structure a written quote and to see where internal effort ends and outside help begins. No fee or duration is stated because none was supplied; ask each provider for their own basis.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up and how to keep it down
Internal staff time (controller, business owner, engineers, DPO)	Your own staff; the controller remains accountable for the assessment	Both: initial assessment is one-time, reviews recur	Up: number of processing activities, system complexity, unclear data flows. Down: maintain a current data map and reuse a standard DPIA template across similar processing
Tooling for DPIA register and document control	Software licence or hosting; self-hosted XWiki or BookStack carry no software licence fee but need hosting and administration	Recurring (hosting, administration, upgrades)	Up: number of users, integrations with other compliance tools, backup and access control requirements. Down: keep one register with version history and role-based permissions; ask what administration effort the vendor or partner estimates
External facilitation or technical risk analysis	External consultant or implementation partner, under a written scope	Usually one-time per assessment, sometimes repeated	Up: high-risk or novel processing, complex architectures, many data subject groups. Down: define scope and deliverables in writing before work starts and prepare inputs internally
Legal or DPO review	Your DPO, in-house counsel, or an external adviser	Recurring with each assessment and each material change	Up: cross-border flows, special category data, unclear lawful basis. Down: agree a review checklist and escalation threshold in advance
Recurring review when risk changes	Internal owners and reviewers, plus any external support you retain	Recurring, triggered by changes in risk under Article 35(11)	Up: frequent releases, new data sources, new third-party processors. Down: link DPIA review to change management so triggers are caught at design time
Data subject views (where sought)	Internal research or external research panels, if you commission them	Usually one-time per assessment	Up: number of data subject groups and the need for representative sampling. Down: use existing customer or employee feedback channels where appropriate. Ask any provider how they recruit and document views

Where DPIAs fall short under review and how to close each gap

Most weak DPIAs fail in the same few places: the description does not match the system, the reasoning skips alternatives, and the document is never revisited. Each card below names one gap that an assessor or supervisory authority is likely to notice under Article 35(7), with one fix a team can act on before the next review.

Description omits real data flows

The systematic description required by Article 35(7) often reflects the intended design rather than the system as built. Teams leave out analytics pipelines, backups, support tooling, logs and the sub-processors that touch the data. Walk the data from collection to deletion with an engineer, and record every system, region, processor and sub-processor that holds or accesses the personal data, then check the list against the processor contracts and the record of processing.

Necessity argued without alternatives

Article 35(7) requires an assessment of necessity and proportionality, yet many DPIAs only explain why the chosen design works. A reviewer will ask whether the same purpose could be met with less personal data, fewer recipients, shorter retention or pseudonymised data. Record at least one less intrusive option that was considered and why it was rejected, including the cost or operational reason, so the proportionality conclusion can be traced.

Risks not linked to measures

A risk register that lists threats and a separate list of controls does not show that the risks were addressed. Article 35(7) asks for the measures envisaged to address the risks, and a reviewer needs to see which measure reduces which risk to data subjects. Map each risk to a named control, an owner and the residual risk left after the control, so that any residual high risk is visible and can be escalated.

Mitigations listed but never tested

Stating that encryption, access control or logging is in place is not evidence that it works in practice. Mitigations drift as configurations change, service accounts accumulate rights and log pipelines fail silently. Assign each safeguard a test, such as a permission review, a restore test or a log alert check, and store the result with the DPIA, so the claim in the assessment can be verified on request.

No record of data subject views

Article 35(9) asks the controller to seek the views of data subjects or their representatives where appropriate. Many DPIAs say nothing on this point, and a reviewer cannot tell whether the question was considered. Record whether views were sought, from whom and how, and if they were not sought, record the reason, such as a low-risk processing context or a representative body that was consulted instead.

No review after change

Article 35(11) requires a check that processing follows the DPIA, at least when the risk changes. Systems often gain new features, new purposes or new processors without anyone reopening the assessment. Add review triggers to the change process, such as a new processor, a new data category, a new region or a new purpose, and log the date and outcome of each review, so the DPIA stays aligned with how the system actually runs.

Questions buyers ask about DPIA content, cost and outside help

How much effort does a GDPR DPIA take, and what drives it?

The effort depends on how many processing operations the assessment covers, how sensitive the data is, and how many systems, vendors and data flows sit inside each operation. Article 35(7) sets the minimum content: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to data subjects, and the measures planned to address those risks. The main cost drivers are:

Number and complexity of data flows, including sub-processors and transfers outside the EEA
Whether the processing involves special categories of data, profiling or automated decisions
How much system documentation already exists and how current it is
The number of rounds needed with the privacy, security and business owners

Most of the cost is internal staff time. Ask any outside provider for a written scope that lists the processing operations, systems and teams involved before accepting a figure.

Can our team write a DPIA without an outside partner?

Yes. The GDPR does not require a consultant, a certificate or an external author, and the controller remains responsible for the assessment. Teams that write DPIAs in-house usually need a privacy lead who understands the legal test, a security lead who can describe technical measures accurately, and a system owner who can describe the processing. The EDPB's DPIA template, adopted for public consultation on 14 April 2026, gives predefined fields that can structure the work once consultation concludes. An outside partner is most useful when the systems are complex, the internal reviewers lack time, or the organization needs an engineering team to document and implement the mitigating measures. Any partner prepares the evidence, but the controller signs off on the content.

What does the business and engineering team need to provide?

The DPIA is only as accurate as the description of the processing, so the business owner and engineers must supply facts rather than summaries. Typical inputs include:

The purpose of each processing activity and the lawful basis relied on
Categories of data subjects and personal data, with retention periods
Architecture diagrams, data stores, integrations and access paths
A list of sub-processors, hosting locations and any transfers outside the EEA
Existing security controls, such as encryption, access control, logging and backup
Known incidents, open risks and the planned changes that could affect risk

Where relevant, the team should also state whether data subjects or their representatives were consulted under Article 35(9), and what the outcome was.

How long does a DPIA take to complete?

The duration depends on scope, and no general figure applies to every organization. A single, well-documented system with few data flows can move quickly, while a platform that handles special category data across several countries needs more reviews and engineering input. The factors that extend the timeline are missing system documentation, unresolved questions about sub-processors or transfers, disagreement on risk ratings, and changes to the system during the assessment. Any duration should come from a written plan that lists the deliverables, the reviewers, the review rounds and the dependencies on engineering work. Ask any provider to commit to that plan in writing, and treat a timeline without stated assumptions as incomplete.

Does the GDPR require us to publish our DPIA?

No. The GDPR does not require publication. The Article 29 Working Party guidance (WP248 rev.01) states that publishing a DPIA is not a legal requirement, but it recommends that controllers consider publishing at least parts, such as a summary or conclusion. Publishing a summary can help customers and regulators see how risks were handled, while the full assessment may contain security details that should remain confidential. Many organizations publish a short non-technical summary and keep the full document available to the supervisory authority on request. Check your contracts, because customers may ask for the DPIA or a summary as part of due diligence.

When must a DPIA be reviewed after it is approved?

Article 35(11) requires the controller to review whether processing is performed in accordance with the DPIA, where necessary, and at least when the risk represented by the processing changes. Common triggers include a new data category, a new sub-processor or hosting location, a major software release that changes data flows, a security incident, or a change in the purpose of the processing. Build review triggers into change management so that engineering must check the DPIA before a change ships. Record each review in the same document with its date, reviewer and outcome, so the assessment shows how the processing has been kept under control over time.

Does a certificate prove our DPIA meets the GDPR?

No. The GDPR requires no audit, attestation or certificate, and no certificate proves that a DPIA is compliant. Certification under Article 42 is voluntary, issued for at most three years by accredited certification bodies or supervisory authorities, and it does not reduce the controller's responsibility. Supervisory authorities judge the quality of the assessment itself, including whether the description is accurate, the necessity test is reasoned, the risks are identified and the measures actually exist. Ask any provider to show the evidence behind each mitigating measure rather than a badge. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue reports, attestations or certificates.

How DeployOpen prepares DPIA evidence for self-hosted platforms

DeployOpen helps organizations prepare the technical evidence behind an Article 35(7) DPIA for open-source platforms run inside their own infrastructure. The controller owns the assessment and its conclusions, and DeployOpen prepares the system descriptions, safeguards and review records the assessment relies on.

How we scope

Written scope names the processing operations, platforms and data flows the DPIA will describe.
Scope lists the risk areas to assess, such as access, retention, logging and hosting location.
Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
Scope states which decisions stay with the controller and its data protection officer.

How we build

We document the processing description, purposes and data categories from the deployed systems.
We configure and test the safeguards that the DPIA lists as measures addressing identified risks.
We run security testing on in-scope applications and infrastructure to check that stated controls work.
We set up change logging so later changes to processing can be traced against the assessment.

How we hand over

Handover includes the system description, measure inventory and test results mapped to each risk.
Documentation is delivered in formats the controller can keep under its own version control.
Review triggers are written down, so the controller knows when the assessment must be revisited.
The controller signs off the final assessment, which DeployOpen does not approve or certify.

How we support

Ongoing support and continuous testing are available as retainers after the initial handover.
Retainers can cover updates to the system description when platforms change or new features are added.
Re-testing after material changes helps the controller confirm processing still matches the DPIA.
Ask any provider to confirm in writing which review tasks it performs and which the controller keeps.

Article 35(7) DPIA content and review