How is a DPIA different from a privacy impact assessment, a data protection by design review, and a vendor risk assessment?

The four artefacts sit at four different layers and answer four different questions. A privacy impact assessment (PIA) is the older, pre-GDPR umbrella name used in many jurisdictions for any structured privacy analysis. A DPIA is the GDPR-specific instance with the Article 35 content requirements and the Article 36 prior-consultation procedure. A data protection by design review under Article 25 is the operational design-time check that the engineering team runs as a control. A vendor risk assessment is the supplier-side review that names a processor or sub-processor; the DPIA may incorporate vendor risk assessment evidence but the DPIA covers the processing operation as a whole, not the vendor in isolation. A mature programme keeps the four in sync: PIA terminology for jurisdictions that retain it (UK ICO uses DPIA, US federal NIST SP 800-53 PT-2 references PIA, Canada PIPEDA uses PIA-equivalent), DPIA for the GDPR-specific Article 35 trigger, data protection by design review as the design-time control that operates against the privacy controls named in the DPIA, and vendor risk assessment as the supplier-side input. Treating the four as the same artefact produces a DPIA that fails the Article 35 content test or a vendor risk assessment dressed up as a DPIA that an auditor reads as procedural confusion.

What sections does a defensible DPIA contain?

Fourteen sections produce a DPIA that meets Article 35(7) content expectations, survives a supervisory authority review, and connects to the rest of the security operating record. Header, version control, and controller identity. Processing operation description and purpose. Lawful basis and condition for special-category data. Necessity and proportionality assessment. Data flow map, asset inventory, and processor list. Risk identification per data subject category. Risk evaluation (likelihood, severity, residual risk) per identified risk. Controls and safeguards applied per risk. Consultation with the data protection officer, data subjects, and other stakeholders. Prior consultation decision under Article 36. Review and monitoring schedule. Sign-off chain with named controller representative, DPO, and joint controllers. Cross-references to data classification, retention, breach notification, and vendor risk artefacts. Document control, retention, and disposal. The fourteen sections cover what the processing is, who is affected, what could go wrong, what the controller is doing about it, who agreed to the residual risk, and how the DPIA stays current as the processing evolves.

Who has to be involved in a DPIA, and who signs it off?

Article 35(2) requires the controller to seek the advice of the data protection officer (DPO) where one is designated. Article 35(9) requires the controller to seek the views of data subjects or their representatives where appropriate, unless doing so would compromise the security of the processing or be disproportionate. Beyond the regulatory minimum, a defensible DPIA involves the product owner or business owner for the processing (the person who can defend the necessity and proportionality), the data protection officer (the advisor who reads the DPIA against GDPR), the chief information security officer or head of security (the owner of the technical controls), the legal counsel (the owner of the lawful basis assessment), the engineering lead (the owner of the data flow), the procurement or vendor risk lead (the owner of any processor and sub-processor chain), and the head of HR (for processing involving workforce data). The sign-off chain is named in Section 12 of the template: the controller representative signs the final risk decision, the DPO signs the advice column, and any joint controllers named under Article 26 sign their parallel obligation. In organisations operating under federated governance, an executive sponsor signs the residual risk acceptance under the chartered authority named in the security programme charter.

How should a DPIA classify, evaluate, and treat risk to data subjects?

The risk model in a DPIA reads against the rights and freedoms of natural persons rather than against the controllers risk to revenue or reputation. Article 35(1) and Recital 75 name the harm categories (discrimination, identity theft or fraud, financial loss, damage to reputation, loss of confidentiality of personal data protected by professional secrecy, unauthorised reversal of pseudonymisation, prevention of the data subject from exercising control over their personal data, or any other significant economic or social disadvantage). The CNIL guide, the ICO sample DPIA, the EDPB Guidelines 4/2017, and the German Standard Data Protection Model all use variants of likelihood by severity for the residual-risk read. Section 7 of the template uses three likelihood bands (negligible, limited, significant, maximum per CNIL) and three severity bands (negligible, limited, significant, maximum) to produce a four-by-four matrix. Section 8 names the controls applied per risk (organisational, technical, contractual) and the residual-risk read after controls. Where the residual risk reads as high after the controls are applied, Article 36(1) requires prior consultation with the supervisory authority before processing starts. The DPIA template does not let the controller skip this step: Section 10 forces a named decision (no prior consultation required / prior consultation in progress / prior consultation completed with named outcome) before the DPIA can be signed off.

How does a DPIA handle vendor processors, sub-processors, and international data transfers?

A DPIA covers the processing operation as a whole, including the chain of processors and sub-processors that participate. Section 5 of the template names the processor list with the contractual basis (Article 28 data processing agreement reference), the role (processor, sub-processor, joint controller under Article 26), the data classes the processor sees, the processing location, the transfer mechanism for any international transfer (adequacy decision under Article 45, Standard Contractual Clauses under Article 46(2)(c) with named SCC version, Binding Corporate Rules under Article 47, derogation under Article 49, the EU-US Data Privacy Framework under the adequacy decision), and the transfer impact assessment reference where one was required following Schrems II. The DPIA does not replace the per-processor vendor security risk assessment; it consolidates the vendor risk into the processing-operation read. Where the vendor risk assessment reads as inadequate for the processing tier, the DPIA Section 8 captures the additional safeguards (encryption with key control retained by the controller, pseudonymisation, data minimisation, contractual additional terms, alternative processor selection) or escalates to Section 9 stakeholder consultation. Importing a recent Schrems II transfer impact assessment into Section 5 as an evidence reference is the durable pattern.

How does the DPIA template handle AI and automated decision-making processing?

Article 35(3)(a) names systematic and extensive automated decision-making with legal or similarly significant effects as one of the three obligatory DPIA triggers. The template handles this through three additions to Sections 2, 4, 7, and 8. In Section 2 (processing description), the template names the model class (rule-based, classical machine learning, neural network, large language model, retrieval-augmented generation, agent framework), the training data source and consent basis, the deployment surface, the human review point, and the override pathway. In Section 4 (necessity and proportionality), the template names the alternatives considered and rejected, the explainability posture, the bias-testing programme, and the data minimisation pattern. In Section 7 (risk evaluation), the template adds a row for fairness, explainability, contestability, and human oversight risks against the data subject. In Section 8 (controls), the template names the AI-specific safeguards (model cards, dataset documentation, ongoing performance monitoring, human-in-the-loop checkpoints, the Article 22 right to obtain human intervention, the ability for the data subject to contest the decision, the routine accuracy and bias re-evaluation cadence). The template also names the cross-reference to a separate AI impact assessment under the EU AI Act Article 27 fundamental rights impact assessment where the processing is also high-risk under the AI Act; the two artefacts operate alongside each other and the DPIA covers the data protection layer specifically. Pair the DPIA with a published AI use policy and a model card for every model that processes personal data.

How does the DPIA stay current as the processing evolves?

Article 35(11) requires the controller to carry out a review of the DPIA at least when there is a change of the risk represented by the processing. The template handles this through Section 11 (review and monitoring schedule), Section 13 (cross-references), and Section 14 (document control). Section 11 names a scheduled review cadence (annual minimum, biennial for low-risk processing inside the DPIA scope, quarterly for processing classified as high-risk where Article 36 prior consultation was required) and the event triggers that force an out-of-cycle review (change in the scope of processing, change in the purpose, change in the data categories, change in the data subject categories, change in the processor chain or international transfer mechanism, change in the technology including model upgrades for AI processing, security incident affecting the processing, new supervisory authority guidance affecting the processing, change in the applicable law). Section 13 names every cross-referenced artefact (data classification policy, retention schedule, vendor risk assessment, transfer impact assessment, breach notification procedure, AI policy, secrets policy, security exception register) so a change to the cross-referenced artefact flags a DPIA review. Section 14 names the document retention (DPIA retained for the life of the processing plus the longer of six years or the retention rule in the audit evidence retention policy) and the disposal procedure (DPIA destroyed under named workflow with signed destruction certificate when the processing is decommissioned). Without the review cadence and the event triggers, the DPIA freezes at first publication and the supervisory authority reads it as procedural compliance rather than an operational record.

How does the DPIA template align with ISO/IEC 27701, NIST Privacy Framework, and sector regulations?

The DPIA is the legal artefact the privacy programme produces, but it also serves as cross-framework evidence for adjacent regimes. ISO/IEC 27701:2019 (PIMS extension to ISO 27001) Clause 6.15.1.1 (privacy risk assessment) and Clause A.7.2.5 / B.8.2.1 (DPIA expectations) read the DPIA directly as the privacy impact assessment evidence. The NIST Privacy Framework Core Govern (GV.PO-P1), Identify (ID.RA-P1, ID.RA-P3, ID.RA-P4, ID.RA-P5), and Communicate (CM.PO-P3) categories read the DPIA as the formal risk-assessment artefact. NIST SP 800-53 Rev. 5 Privacy Controls PT-2 (authority to process personally identifiable information), PT-3 (PII processing purposes), and RA-8 (privacy impact assessments) read the DPIA equivalent. NIS2 Article 21(2)(c) (business continuity, including backup management and disaster recovery) and DORA Article 6 (ICT risk management framework) read the DPIA as input where the processing is also an essential service. The EU AI Act Article 27 (fundamental rights impact assessment by deployers) reads alongside the DPIA when the processing is AI-driven. The Brazil LGPD Article 38 Relatorio de Impacto, the UK GDPR Article 35, the California CPPA risk assessment, the Colorado CPA risk assessment, the Connecticut CTDPA risk assessment, the China PIPL Article 55-56 Personal Information Protection Impact Assessment, and the Korea PIPA Article 33 all read against the same fourteen-section structure with jurisdiction-specific adjustments captured as named appendices in Section 13. The compliance-tracking surface maps the DPIA evidence into each framework template with CSV export so the audit committee, the customer security review, and the regulator request all read against the same record.

What failure modes does the DPIA template design against?

Seven recognisable failure patterns weaken the privacy compliance read of the programme and the audit defensibility of the DPIA. First, no DPIA at all where Article 35 trigger conditions apply (the firm relies on the existence of a privacy notice or a vendor risk assessment as a substitute). Second, a DPIA that names the processing in vague terms (does not pass Article 35(7)(a) systematic description). Third, a DPIA that conflates inherent risk with residual risk (does not pass the post-control residual-risk read that Article 36 prior consultation is gated on). Fourth, a DPIA signed off without DPO advice where a DPO was designated (does not pass Article 35(2) and Article 39(1)(c) DPO involvement). Fifth, a DPIA frozen at first publication with no review cadence and no event triggers (does not pass Article 35(11) review requirement). Sixth, a DPIA that names controls aspirationally but does not record their operational status (the auditor asks whether the named encryption is actually deployed and the answer is missing). Seventh, a DPIA stored in a personal drive, a wiki page, or a vendor tool the audit cannot read (the supervisory authority request cannot be answered with a single artefact pull). The fourteen-section template above is designed to enforce the structural fix for each failure: explicit trigger record in Section 2, residual-risk discipline in Section 7 and 8, DPO advice column in Section 9, prior consultation decision in Section 10, review and monitoring schedule in Section 11, named controller and joint-controller sign-off in Section 12, cross-references in Section 13, and document control and retention in Section 14.

Free Tool

Data Protection Impact Assessment (DPIA) Template
fourteen sections aligned with GDPR Article 35 and 36, ISO/IEC 27701, NIST Privacy Framework, and adjacent regimes

A free, copy-ready GDPR Article 35 DPIA template. Fourteen structured sections covering controller and DPO identity, processing description with explicit Article 35(3) and WP248 trigger record, lawful basis per purpose with Article 9 and Article 10 conditions, necessity and proportionality assessment with Article 22 automated decision-making coverage, data flow map and processor list with Article 28 DPA and international transfer mechanism references, risk identification per data subject category against Recital 75 harm categories, four-by-four likelihood-by-severity risk evaluation matrix with inherent and residual columns, controls and safeguards per risk with named operational status, consultation with DPO and data subjects under Article 35(2) and 35(9), Article 36(1) prior consultation decision with forced four-state selection and sign-off lock, scheduled review cadence and event triggers under Article 35(11), named sign-off chain across controller representative, DPO, joint controllers, and stakeholders, cross-references to data classification, retention, vendor risk, and adjacent privacy and security artefacts, and document control with retention and disposal rules. Aligned with GDPR Article 35 and 36, UK GDPR with ICO mandatory list, ISO/IEC 27701:2019 Clause 6.15.1.1 and Annexes A.7.2.5 and B.8.2.1, ISO/IEC 29134:2017, NIST Privacy Framework v1.0, NIST SP 800-53 Rev. 5 PT-2 and PT-3 and RA-8, EU AI Act Article 27 fundamental rights impact assessment where applicable, Brazil LGPD Article 38, California CPPA risk assessments, China PIPL Article 55 to 56, and Korea PIPA Article 33. Built for privacy programme leads, data protection officers, GRC and compliance teams, product security teams, AppSec teams, internal security teams, cloud security teams, data security teams, CISOs and security directors, security architects, security programme managers, legal counsel, and external compliance consultants who need a defensible Article 35 artefact rather than a checkbox.

Get Started Free

No credit card required. Free plan available forever.

Fourteen sections that turn an Article 35 obligation into a defensible privacy record

A data protection impact assessment (DPIA) is the named risk-assessment artefact the controller publishes before starting a processing operation that is likely to result in a high risk to the rights and freedoms of natural persons. GDPR Article 35(1) sets the baseline trigger; Article 35(3) names three obligatory cases (systematic and extensive automated decision-making with legal or similarly significant effects, large-scale processing of special-category or criminal-conviction data, systematic monitoring of a publicly accessible area on a large scale); national supervisory authorities publish mandatory lists under Article 35(4); the WP248 rev.01 nine criteria from the Article 29 Working Party, endorsed by the European Data Protection Board, name the meeting two of nine threshold most controllers read against in practice. The DPIA is not a checkbox: it is the defensible risk-decision record the supervisory authority, the data subjects, the customer, and the controller read against.

The fourteen sections below cover the durable shape of a DPIA against GDPR Article 35 and 36, UK GDPR Article 35 with ICO mandatory list, ISO/IEC 27701:2019 Clause 6.15.1.1 and Clauses A.7.2.5 / B.8.2.1, ISO/IEC 29134:2017, the NIST Privacy Framework v1.0 Govern / Identify / Communicate categories, NIST SP 800-53 Rev. 5 PT-2 / PT-3 / RA-8, the EU AI Act Article 27 fundamental rights impact assessment where AI processing applies, Brazil LGPD Article 38, California CPPA risk assessments under CPRA, China PIPL Article 55-56, and Korea PIPA Article 33. Pair the DPIA with the data classification policy template for the per-class handling rules the controls in Section 8 read against, the vendor security risk assessment template for the per-processor evaluation Section 5 cross-references, the risk register template for the residual-risk record that feeds the wider enterprise read, the audit evidence retention policy template for the retention rule governing the DPIA itself, the security program charter template for the chartered authority the privacy programme operates under, the acceptable use policy template for the workforce-facing rules the controls in Section 8 reference, and the security control validation runbook template for the per-control validation cadence that proves the controls named in Section 8 are operational rather than aspirational. Copy the section that fits the processing and adapt the rest as the assessment matures.

Copy the full DPIA template (all fourteen sections) as one block.

1. Header, version control, and controller identity

Open the DPIA with the named controller, the version, the DPO, and the assessment owner. A reviewer reading the first lines should see who is filing the assessment, which processing operation it covers, which version is current, who advised on it, and which framework expectations the artefact evidences. GDPR Article 35(7) requires a documented assessment; ISO/IEC 27701 Clause 6.15.1.1 expects a documented privacy risk assessment. The header is the cross-reference anchor every downstream record reads against and the first artefact the supervisory authority reads in a request for information.

DPIA title: {{DPIA_TITLE}}
DPIA identifier (the workspace cross-reference for the processing operation):
- {{DPIA_IDENTIFIER}}

Processing operation reference (the named project, product feature, system, or service the DPIA covers):
- {{PROCESSING_OPERATION_REFERENCE}}

Version: {{DPIA_VERSION}}
Effective date (the date the signed version becomes the current operating record): {{EFFECTIVE_DATE}}
Last review date: {{LAST_REVIEW_DATE}}
Next scheduled review date: {{NEXT_REVIEW_DATE}}
Document classification (per the data classification policy): {{DOCUMENT_CLASSIFICATION}}
Retention period (per the audit evidence retention policy): {{RETENTION_PERIOD}}

Controller identity (the entity that determines the purposes and means of the processing):
- Controller legal name: {{CONTROLLER_LEGAL_NAME}}
- Controller registered address: {{CONTROLLER_REGISTERED_ADDRESS}}
- Controller representative under GDPR Article 27 where the controller is not established in the EEA: {{ARTICLE_27_REPRESENTATIVE}}
- Establishment for the one-stop-shop lead supervisory authority determination: {{ONE_STOP_SHOP_ESTABLISHMENT}}
- Lead supervisory authority (where applicable): {{LEAD_SUPERVISORY_AUTHORITY}}
- Other supervisory authorities concerned: {{OTHER_SUPERVISORY_AUTHORITIES_CONCERNED}}

Joint controllers under Article 26 (where two or more controllers jointly determine the purposes and means):
- Joint controller 1: {{JOINT_CONTROLLER_1_NAME_AND_ROLE}}
- Joint controller 2: {{JOINT_CONTROLLER_2_NAME_AND_ROLE}}
- Reference to the Article 26 arrangement (the contract between joint controllers naming each party respective duties): {{ARTICLE_26_ARRANGEMENT_REFERENCE}}

Data Protection Officer (where one is designated under Article 37):
- DPO name: {{DPO_NAME}}
- DPO contact: {{DPO_CONTACT}}
- DPO supervisory-authority registration reference (where the DPO is filed with the lead supervisory authority): {{DPO_REGISTRATION_REFERENCE}}

DPIA owner (the named role accountable for keeping the DPIA current):
- Role: {{DPIA_OWNER_ROLE}} (typically Privacy Programme Lead, Data Protection Officer, or Chief Privacy Officer)
- Named person at time of publication: {{DPIA_OWNER_NAME}}

Business owner of the processing operation (the role accountable for the necessity and proportionality of the processing):
- Role: {{BUSINESS_OWNER_ROLE}}
- Named person at time of publication: {{BUSINESS_OWNER_NAME}}

Technical owner of the processing operation (the role accountable for the technical controls applied):
- Role: {{TECHNICAL_OWNER_ROLE}}
- Named person at time of publication: {{TECHNICAL_OWNER_NAME}}

Framework expectations evidenced by this DPIA (map your scope into Section 13):
- GDPR Article 35 (DPIA), Article 36 (prior consultation), Article 25 (data protection by design), Article 32 (security of processing), Article 5 (principles).
- UK GDPR Article 35 and Data Protection Act 2018 with ICO DPIA list.
- ISO/IEC 27701:2019 Clause 6.15.1.1 (privacy risk assessment), Clause A.7.2.5 / B.8.2.1 (DPIA expectations).
- ISO/IEC 29134:2017 (privacy impact assessment methodology).
- NIST Privacy Framework v1.0 Govern, Identify, Communicate (PR.PO-P, ID.RA-P, CM.PO-P).
- NIST SP 800-53 Rev. 5 PT-2, PT-3, RA-8 privacy controls.
- EU AI Act Article 27 (fundamental rights impact assessment) where the processing is AI-driven and reads as high-risk.
- Brazil LGPD Article 38 Relatorio de Impacto.
- California CPPA risk assessments under CPRA regulations.
- China PIPL Article 55-56 Personal Information Protection Impact Assessment.
- Korea PIPA Article 33 Personal Information Impact Assessment.
- Internal policy: {{INTERNAL_POLICY_REFERENCES}}

Revision history (each entry: version, effective date, change summary, trigger, owner, sign-off references):
- v1.0 {{V1_EFFECTIVE_DATE}}: Initial DPIA published under sponsor {{V1_SPONSOR_NAME}}. Trigger: pre-launch DPIA for new processing.
- v{{VN_VERSION}} {{VN_EFFECTIVE_DATE}}: {{VN_CHANGE_SUMMARY}}. Trigger: {{VN_TRIGGER}}.

2. Processing operation description and purpose

Describe the processing operation in operational detail. Article 35(7)(a) requires a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller. The description has to be specific enough that a person who does not know the system can read it and reconstruct what happens to whose data. This section also names the DPIA trigger the controller is responding to so the supervisory authority can read why the DPIA exists.

Processing operation name (the common name the business uses for the operation):
- {{PROCESSING_OPERATION_NAME}}

Plain language description (one paragraph a non-technical reader can understand):
{{PLAIN_LANGUAGE_DESCRIPTION}}

DPIA trigger (the named reason the controller is conducting the DPIA; tick every condition that applies):
- [ ] Article 35(3)(a) systematic and extensive evaluation including profiling, on which decisions are based that produce legal effects or similarly significantly affect the data subject.
- [ ] Article 35(3)(b) processing on a large scale of special-category data (Article 9) or criminal-conviction data (Article 10).
- [ ] Article 35(3)(c) systematic monitoring of a publicly accessible area on a large scale.
- [ ] Article 35(4) supervisory authority mandatory list condition: {{NAMED_SUPERVISORY_AUTHORITY_CONDITION}}
- [ ] WP248 rev.01 / EDPB Guidelines 4/2017 condition (two or more of the nine criteria):
  - [ ] Evaluation or scoring
  - [ ] Automated decision-making with legal or similar effect
  - [ ] Systematic monitoring
  - [ ] Sensitive data or highly personal data
  - [ ] Data processed on a large scale
  - [ ] Matching or combining datasets
  - [ ] Data concerning vulnerable data subjects
  - [ ] Innovative use or application of new technology or organisational solutions
  - [ ] When the processing in itself prevents data subjects from exercising a right or using a service or a contract
- [ ] Internal policy trigger (the controller policy requires a DPIA below the regulatory threshold for: {{INTERNAL_TRIGGER_REASON}}).
- [ ] Customer or contractual trigger (a customer contract or sub-processor agreement requires a DPIA): {{CONTRACT_REFERENCE}}.

Purposes of the processing (each separate purpose stated explicitly; pair each purpose with its lawful basis in Section 3):
- Primary purpose: {{PRIMARY_PURPOSE}}
- Secondary purpose 1: {{SECONDARY_PURPOSE_1}}
- Secondary purpose 2: {{SECONDARY_PURPOSE_2}}
- Out-of-scope purpose (named purposes the processing is explicitly not used for; prevents purpose creep): {{OUT_OF_SCOPE_PURPOSE}}

Processing operations performed (the actions taken on the personal data):
- Collection: {{COLLECTION_DESCRIPTION}}
- Recording: {{RECORDING_DESCRIPTION}}
- Organisation, structuring, storage: {{STORAGE_DESCRIPTION}}
- Adaptation or alteration: {{ADAPTATION_DESCRIPTION}}
- Retrieval, consultation, use: {{USE_DESCRIPTION}}
- Disclosure by transmission, dissemination, or otherwise making available: {{DISCLOSURE_DESCRIPTION}}
- Alignment or combination: {{COMBINATION_DESCRIPTION}}
- Restriction, erasure, destruction: {{RESTRICTION_AND_ERASURE_DESCRIPTION}}

Technology and tooling (where the processing involves new or innovative technology, name it explicitly):
- Platform or service: {{PLATFORM_OR_SERVICE}}
- Architecture pattern (monolith, microservices, event-driven, ML pipeline, RAG system, agent framework, federated learning, edge processing): {{ARCHITECTURE_PATTERN}}
- Algorithmic processing (rule-based, classical ML, neural network, large language model, retrieval-augmented generation, agent framework with tool use): {{ALGORITHMIC_PROCESSING}}
- Where AI is involved, name the model class, the training data source and lawful basis, the deployment surface, the human review point, the override pathway, and the contestability mechanism in Section 4.

Volume estimate:
- Estimated number of data subjects: {{ESTIMATED_NUMBER_OF_DATA_SUBJECTS}}
- Estimated number of personal-data records: {{ESTIMATED_NUMBER_OF_RECORDS}}
- Estimated processing frequency (per data subject, per day): {{ESTIMATED_FREQUENCY}}
- Geographic distribution of data subjects: {{GEOGRAPHIC_DISTRIBUTION}}

Linked artefacts (named references to adjacent records the DPIA reads against):
- Record of Processing Activities entry under Article 30: {{ROPA_ENTRY_REFERENCE}}
- Data flow map reference: {{DATA_FLOW_MAP_REFERENCE}}
- Article 28 data processing agreement(s) reference: {{DPA_REFERENCES}}
- Article 26 joint-controller arrangement reference: {{JOINT_CONTROLLER_ARRANGEMENT_REFERENCE}}
- Article 30 record of processing activities: {{ROPA_REFERENCE}}
- Transfer impact assessment reference (where applicable): {{TIA_REFERENCE}}

3. Lawful basis and condition for special-category data

Name the lawful basis per purpose under Article 6, the condition for processing special-category data under Article 9 where applicable, and the condition for processing criminal-conviction data under Article 10 where applicable. Article 35(7)(b) requires an assessment of the necessity and proportionality of the processing operations in relation to the purposes; the lawful-basis selection is the gating decision that necessity reads against. A DPIA that names consent for processing the controller cannot revoke without harm to the data subject collapses on the proportionality test.

Lawful basis per purpose (Article 6):
- Purpose 1: {{PURPOSE_1_NAME}}
  - Lawful basis (one of: 6(1)(a) consent, 6(1)(b) contract, 6(1)(c) legal obligation, 6(1)(d) vital interests, 6(1)(e) public task, 6(1)(f) legitimate interests):
    - {{PURPOSE_1_LAWFUL_BASIS}}
  - Rationale for the lawful basis selection: {{PURPOSE_1_RATIONALE}}
  - Where legitimate interests under 6(1)(f), legitimate interests assessment (LIA) reference: {{PURPOSE_1_LIA_REFERENCE}}
  - Where consent under 6(1)(a), consent capture mechanism, withdrawal mechanism, age of consent verification mechanism: {{PURPOSE_1_CONSENT_MECHANISMS}}
- Purpose 2: {{PURPOSE_2_NAME}}
  - Lawful basis: {{PURPOSE_2_LAWFUL_BASIS}}
  - Rationale: {{PURPOSE_2_RATIONALE}}
- Purpose N: {{PURPOSE_N_DETAILS}}

Special-category data processing (Article 9):
- Special-category data classes processed (racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data uniquely identifying a natural person, health data, sex life or sexual orientation data):
  - {{SPECIAL_CATEGORY_DATA_CLASSES}}
- Article 9(2) condition relied on for each class (one of: explicit consent, employment law, vital interests of incapable subject, legitimate activity of a non-profit, manifestly made public by the subject, legal claims, substantial public interest, preventive or occupational medicine, public health, archiving in the public interest):
  - Class 1 condition: {{ARTICLE_9_CONDITION_CLASS_1}}
  - Class 1 rationale and Member State law reference where required: {{ARTICLE_9_RATIONALE_CLASS_1}}
- Additional Member State law conditions (where the Member State has added conditions beyond Article 9): {{MEMBER_STATE_CONDITIONS}}

Criminal-conviction data processing (Article 10):
- Criminal-conviction data classes processed: {{CRIMINAL_CONVICTION_CLASSES}}
- Authority basis (one of: under official authority, under Member State law providing appropriate safeguards): {{ARTICLE_10_BASIS}}

Children data (Article 8 where information society services are offered directly to a child):
- Age of consent applicable in the jurisdiction (per Member State or the GDPR default of 16): {{AGE_OF_CONSENT}}
- Parental authorisation verification mechanism: {{PARENTAL_VERIFICATION_MECHANISM}}
- Plain-language privacy information for children (separate notice or layered notice with child-friendly summary): {{CHILD_PRIVACY_INFORMATION_MECHANISM}}

Cross-jurisdictional lawful basis variations (where the same processing reads against different rules under multiple regimes):
- UK GDPR variations: {{UK_GDPR_VARIATIONS}}
- LGPD Article 7 / Article 11 variations: {{LGPD_VARIATIONS}}
- CPRA / state-law variations: {{US_STATE_LAW_VARIATIONS}}
- PIPL variations: {{PIPL_VARIATIONS}}
- PIPA variations: {{PIPA_VARIATIONS}}

Lawful basis change procedure:
- If the lawful basis for a purpose changes after publication, the DPIA is reopened, the new basis assessment is captured, and the data subjects are re-informed under Article 13(3) or 14(4).
- Lawful basis change is one of the named DPIA review triggers in Section 11.

4. Necessity and proportionality assessment

Article 35(7)(b) requires the controller to assess the necessity and proportionality of the processing operations in relation to the purposes. This section is where the DPIA passes the legal test: less invasive alternatives considered, data minimisation actually applied, purpose limitation enforced, retention proportionate, accuracy maintained, and transparency delivered to the data subject. An audit reading this section asks whether the processing is the minimum that achieves the purpose, not whether the processing is convenient for the controller.

Necessity assessment per purpose:
- Purpose 1: {{PURPOSE_1_NAME}}
  - Less invasive alternatives considered: {{PURPOSE_1_ALTERNATIVES_CONSIDERED}}
  - Reason the chosen processing is the minimum necessary: {{PURPOSE_1_MINIMUM_NECESSARY_REASON}}
  - Outcome if the processing were not performed: {{PURPOSE_1_OUTCOME_WITHOUT_PROCESSING}}
- Purpose 2: {{PURPOSE_2_NAME}}
  - Less invasive alternatives considered: {{PURPOSE_2_ALTERNATIVES_CONSIDERED}}
  - Reason the chosen processing is the minimum necessary: {{PURPOSE_2_MINIMUM_NECESSARY_REASON}}

Proportionality assessment per purpose:
- Purpose 1: {{PURPOSE_1_NAME}}
  - Personal data fields processed (named per the data flow in Section 5):
    - Field A: {{FIELD_A_NAME}} (mandatory: {{FIELD_A_MANDATORY}}; alternative: {{FIELD_A_ALTERNATIVE_CONSIDERED}})
    - Field B: {{FIELD_B_NAME}} (mandatory: {{FIELD_B_MANDATORY}}; alternative: {{FIELD_B_ALTERNATIVE_CONSIDERED}})
  - Data minimisation pattern applied (pseudonymisation, aggregation, sampling, differential privacy, federated learning, on-device processing, edge processing, named tokenisation scheme): {{DATA_MINIMISATION_PATTERN}}
  - Purpose limitation pattern (named technical controls preventing data reuse for non-listed purposes): {{PURPOSE_LIMITATION_PATTERN}}
  - Storage limitation (retention schedule reference): {{RETENTION_SCHEDULE_REFERENCE}}
  - Accuracy maintenance pattern (named source-of-truth, correction workflow, data quality cadence): {{ACCURACY_MAINTENANCE_PATTERN}}
  - Transparency delivered to the data subject (Article 13 or 14 privacy notice reference, layered notice references, just-in-time notice references): {{TRANSPARENCY_REFERENCES}}

Where automated decision-making under Article 22 applies (legal or similarly significant effects):
- Automated decision-making in scope: {{ARTICLE_22_IN_SCOPE}}
- Article 22(2) exemption relied on (one of: contractual necessity, Member State law, explicit consent): {{ARTICLE_22_EXEMPTION}}
- Suitable measures applied (the right to obtain human intervention, the right to express one s point of view, the right to contest the decision): {{ARTICLE_22_SUITABLE_MEASURES}}
- For AI-driven decision-making: model card reference, dataset documentation reference, bias-testing report reference, ongoing performance monitoring reference: {{AI_DOCUMENTATION_REFERENCES}}
- Where EU AI Act applies, fundamental rights impact assessment under Article 27 reference: {{AI_ACT_FRIA_REFERENCE}}

Where international transfers occur (separate from Section 5 transfer mechanism, this row covers the proportionality side):
- Adequacy or non-adequacy posture: {{ADEQUACY_POSTURE}}
- Supplementary measures rationale: {{SUPPLEMENTARY_MEASURES_RATIONALE}}
- Transfer impact assessment reference: {{TIA_REFERENCE}}

Data subject autonomy and control (Recital 7 right to control over one s personal data):
- Right of access mechanism (Article 15): {{ACCESS_MECHANISM}}
- Right to rectification mechanism (Article 16): {{RECTIFICATION_MECHANISM}}
- Right to erasure mechanism (Article 17): {{ERASURE_MECHANISM}}
- Right to restriction of processing mechanism (Article 18): {{RESTRICTION_MECHANISM}}
- Right to data portability mechanism (Article 20): {{PORTABILITY_MECHANISM}}
- Right to object mechanism (Article 21): {{OBJECTION_MECHANISM}}
- Right not to be subject to automated decision-making mechanism (Article 22): {{ARTICLE_22_MECHANISM}}

5. Data flow map, asset inventory, and processor list

Map the processing as a data flow with named sources, destinations, processors, and sub-processors. Article 35(7)(a) systematic description has to read on a data flow, not on a narrative paragraph. The audit, the supervisory authority, and the data subject access request all read against this section to reconstruct where data goes and who touches it. International transfers, the named transfer mechanism, and the transfer impact assessment evidence all land here.

Personal data categories processed (link each to the field-level data in Section 4):
- Identifier data (names, account identifiers, internal IDs, government identifiers): {{IDENTIFIER_DATA_CLASSES}}
- Contact data (email, phone, postal address): {{CONTACT_DATA_CLASSES}}
- Demographic data (age, gender, language, jurisdiction): {{DEMOGRAPHIC_DATA_CLASSES}}
- Authentication data (passwords, MFA factors, recovery factors): {{AUTHENTICATION_DATA_CLASSES}}
- Behavioural data (clickstream, application telemetry, in-product behaviour): {{BEHAVIOURAL_DATA_CLASSES}}
- Location data (IP-derived, GPS-derived, base station, beacon): {{LOCATION_DATA_CLASSES}}
- Financial data (payment card, bank account, transaction history): {{FINANCIAL_DATA_CLASSES}}
- Special-category data (per Section 3): {{SPECIAL_CATEGORY_DATA_REFERENCE}}
- Criminal-conviction data (per Section 3): {{CRIMINAL_CONVICTION_DATA_REFERENCE}}
- Inferred data (model outputs, scores, segments): {{INFERRED_DATA_CLASSES}}
- Pseudonymous identifiers and tokens: {{PSEUDONYMOUS_DATA_CLASSES}}

Data subject categories:
- Customers: {{CUSTOMER_CATEGORIES}}
- Prospects: {{PROSPECT_CATEGORIES}}
- Employees: {{EMPLOYEE_CATEGORIES}}
- Contractors and third-party staff: {{CONTRACTOR_CATEGORIES}}
- Children (where Article 8 applies): {{CHILDREN_CATEGORIES}}
- Vulnerable data subjects (patients, asylum seekers, applicants, employees in unequal position): {{VULNERABLE_CATEGORIES}}
- Public figures or public officials (where context-specific rules apply): {{PUBLIC_FIGURE_CATEGORIES}}
- Other named categories: {{OTHER_DATA_SUBJECT_CATEGORIES}}

Data sources (where the personal data enters the processing):
- Source 1 (the data subject directly): {{SOURCE_1_DESCRIPTION}}
- Source 2 (a controller transferring to the controller): {{SOURCE_2_DESCRIPTION}}
- Source 3 (a public source, data broker, or third-party feed): {{SOURCE_3_DESCRIPTION}}
- Source 4 (derived from another processing operation): {{SOURCE_4_DESCRIPTION}}

Data destinations (where the personal data goes after the processing):
- Destination 1 (the data subject themselves through product surfaces): {{DESTINATION_1_DESCRIPTION}}
- Destination 2 (downstream system inside the controller): {{DESTINATION_2_DESCRIPTION}}
- Destination 3 (recipient outside the controller): {{DESTINATION_3_DESCRIPTION}}

Internal systems processing the data (data lake, warehouse, OLTP database, message bus, search index, cache, AI feature store, ML training pipeline, ML inference pipeline, log store):
- System A: {{SYSTEM_A_NAME}} (purpose: {{SYSTEM_A_PURPOSE}}; location: {{SYSTEM_A_LOCATION}}; classification: {{SYSTEM_A_CLASSIFICATION}})
- System B: {{SYSTEM_B_NAME}} (purpose: {{SYSTEM_B_PURPOSE}}; location: {{SYSTEM_B_LOCATION}})

External processors (Article 28 data processor relationships):
- Processor 1: {{PROCESSOR_1_NAME}}
  - Role: processor / sub-processor / joint controller
  - DPA reference: {{PROCESSOR_1_DPA_REFERENCE}}
  - Data classes received: {{PROCESSOR_1_DATA_CLASSES}}
  - Processing locations: {{PROCESSOR_1_LOCATIONS}}
  - Transfer mechanism if outside the EEA (adequacy decision under Article 45 / SCC under Article 46(2)(c) with named SCC version / BCRs under Article 47 / derogation under Article 49 / EU-US Data Privacy Framework): {{PROCESSOR_1_TRANSFER_MECHANISM}}
  - Transfer impact assessment reference: {{PROCESSOR_1_TIA_REFERENCE}}
  - Vendor security risk assessment reference: {{PROCESSOR_1_VSRA_REFERENCE}}
- Processor 2: {{PROCESSOR_2_DETAILS}}

Sub-processor chain (where a processor uses a sub-processor):
- Sub-processor 1 under Processor 1: {{SUB_PROCESSOR_1_NAME}} (DPA pass-through reference: {{SUB_PROCESSOR_1_DPA_REFERENCE}})
- Sub-processor 2 under Processor 1: {{SUB_PROCESSOR_2_NAME}}
- General authorisation for sub-processors under Article 28(2): {{SUB_PROCESSOR_AUTHORISATION_REFERENCE}}

Joint controllers under Article 26 (where applicable):
- Joint controller 1: {{JOINT_CONTROLLER_1_NAME_AND_ROLE_IN_THIS_PROCESSING}}
- Article 26 arrangement reference: {{ARTICLE_26_ARRANGEMENT_REFERENCE}}

Data flow diagram reference (named diagram in the workspace document store):
- {{DATA_FLOW_DIAGRAM_REFERENCE}}

International transfer summary (single-line read of every transfer with mechanism):
- Transfer 1: {{COUNTRY_AND_PROCESSOR_AND_MECHANISM}}
- Transfer 2: {{COUNTRY_AND_PROCESSOR_AND_MECHANISM}}

6. Risk identification per data subject category

Identify the risks to the rights and freedoms of natural persons. Article 35(7)(c) requires this assessment. Recital 75 names the harm categories the assessment reads against (discrimination, identity theft or fraud, financial loss, damage to reputation, loss of confidentiality, unauthorised reversal of pseudonymisation, prevention from exercising control, other significant economic or social disadvantage). Read the risks against the data subjects, not against the controller. A DPIA that names brand damage as the top risk has missed the entire test.

Inherent risk inventory (the risks before controls are applied; controls are addressed in Section 8):
- Risk R1: {{RISK_R1_NAME}}
  - Description: {{RISK_R1_DESCRIPTION}}
  - Data subject category affected: {{RISK_R1_DATA_SUBJECT_CATEGORY}}
  - Harm category from Recital 75: {{RISK_R1_HARM_CATEGORY}}
  - Trigger event (the named change in the processing or operating environment that realises the risk): {{RISK_R1_TRIGGER}}
  - Evidence the risk applies to this processing (incident history, industry pattern, regulator finding, threat-intelligence report): {{RISK_R1_EVIDENCE}}

- Risk R2: {{RISK_R2_NAME}}
  - Description: {{RISK_R2_DESCRIPTION}}
  - Data subject category affected: {{RISK_R2_DATA_SUBJECT_CATEGORY}}
  - Harm category: {{RISK_R2_HARM_CATEGORY}}
  - Trigger event: {{RISK_R2_TRIGGER}}
  - Evidence: {{RISK_R2_EVIDENCE}}

- Risk R3: {{RISK_R3_NAME}}
  - Description: {{RISK_R3_DESCRIPTION}}
  - Data subject category affected: {{RISK_R3_DATA_SUBJECT_CATEGORY}}
  - Harm category: {{RISK_R3_HARM_CATEGORY}}
  - Trigger event: {{RISK_R3_TRIGGER}}
  - Evidence: {{RISK_R3_EVIDENCE}}

(Continue for every distinct risk identified. A typical DPIA captures between six and twenty risks. Cluster duplicates rather than expanding each into a sub-page.)

Common risk classes a DPIA captures (use as a checklist; copy the relevant rows into the inventory above):
- Confidentiality breach by unauthorised access by external attacker.
- Confidentiality breach by unauthorised access by insider.
- Confidentiality breach by misconfigured infrastructure (publicly exposed storage, misconfigured database, exposed API).
- Confidentiality breach by lost or stolen device.
- Confidentiality breach by inadvertent disclosure (mis-sent email, mis-shared link, screen exposure).
- Integrity breach by unauthorised modification (account takeover, data poisoning, model poisoning).
- Integrity breach by accidental modification (data quality regression, broken pipeline, deletion).
- Availability breach by ransomware or destructive attack.
- Availability breach by infrastructure failure with no recovery.
- Excessive collection of personal data beyond purpose.
- Use of personal data for purposes the data subject was not informed of.
- Disclosure of personal data to a recipient the data subject did not authorise.
- Retention of personal data beyond the purpose.
- Loss of accuracy producing incorrect decisions about the data subject.
- Inability of the data subject to exercise Article 15 to 22 rights.
- Loss of transparency about the processing.
- Re-identification of pseudonymised data.
- Inference of special-category data from non-special-category inputs.
- Discriminatory outcome from automated decision-making.
- Loss of contestability for automated decisions.
- International transfer to a jurisdiction without adequate protection.
- Government access request without notification.
- Vendor or sub-processor breach beyond the controller s direct control.
- Workforce surveillance beyond what the workforce was informed of (where applicable).
- Special-category processing without an Article 9 condition.
- Children data processed without parental authorisation where Article 8 applies.

Cross-reference to security findings (where a current security finding maps to a DPIA risk, capture the cross-reference):
- DPIA risk R1 mapped to finding {{FINDING_REFERENCE_1}} on findings-management.
- DPIA risk R2 mapped to finding {{FINDING_REFERENCE_2}}.

7. Risk evaluation (likelihood, severity, residual risk)

Evaluate the likelihood and severity of each risk before controls and after controls. The matrix reads against the rights and freedoms of natural persons (data subject side), not against the controller revenue (controller side). Article 36(1) prior consultation is gated on the residual-risk read after controls; this section is where the gating decision is made and recorded. CNIL guide, ICO sample DPIA, EDPB Guidelines 4/2017, and the German Standard Data Protection Model all read against a likelihood-by-severity matrix with four bands.

Evaluation scale (use the same scale per row so the matrix is comparable):
- Likelihood bands: negligible, limited, significant, maximum.
- Severity bands: negligible, limited, significant, maximum.
- Likelihood definitions:
  - Negligible: the risk requires a sequence of events that is unlikely to occur within the next twenty-four months.
  - Limited: the risk requires conditions that occur infrequently but are foreseeable within twenty-four months.
  - Significant: the risk requires conditions that are foreseeable and have occurred in adjacent operations or in published incidents.
  - Maximum: the risk is more likely than not to materialise within twelve months given the current control posture.
- Severity definitions:
  - Negligible: the data subject experiences inconvenience or minor financial impact recoverable without external assistance.
  - Limited: the data subject experiences material inconvenience, recoverable financial impact, or non-recoverable inconvenience that does not affect rights.
  - Significant: the data subject experiences material non-recoverable financial impact, non-recoverable mental distress, or temporary impairment of rights.
  - Maximum: the data subject experiences serious financial impact, lasting mental distress, discrimination, physical harm, or permanent impairment of rights.

Per-risk evaluation table:
- Risk R1: {{RISK_R1_NAME}}
  - Inherent likelihood (before controls): {{RISK_R1_INHERENT_LIKELIHOOD}}
  - Inherent severity (before controls): {{RISK_R1_INHERENT_SEVERITY}}
  - Inherent risk rating (cell from the four-by-four matrix): {{RISK_R1_INHERENT_RATING}}
  - Controls applied (named references from Section 8): {{RISK_R1_CONTROLS_APPLIED}}
  - Residual likelihood (after controls): {{RISK_R1_RESIDUAL_LIKELIHOOD}}
  - Residual severity (after controls): {{RISK_R1_RESIDUAL_SEVERITY}}
  - Residual risk rating: {{RISK_R1_RESIDUAL_RATING}}
  - Residual-risk decision (one of: accepted by named decision-maker / further controls planned with named deadline / processing scope reduced / processing not initiated): {{RISK_R1_DECISION}}
  - Named decision-maker for the residual-risk acceptance: {{RISK_R1_DECISION_MAKER}}
  - Sign-off date: {{RISK_R1_SIGNOFF_DATE}}

- Risk R2: {{RISK_R2_NAME}}
  - Inherent likelihood: {{RISK_R2_INHERENT_LIKELIHOOD}}
  - Inherent severity: {{RISK_R2_INHERENT_SEVERITY}}
  - Inherent rating: {{RISK_R2_INHERENT_RATING}}
  - Controls applied: {{RISK_R2_CONTROLS_APPLIED}}
  - Residual likelihood: {{RISK_R2_RESIDUAL_LIKELIHOOD}}
  - Residual severity: {{RISK_R2_RESIDUAL_SEVERITY}}
  - Residual rating: {{RISK_R2_RESIDUAL_RATING}}
  - Decision: {{RISK_R2_DECISION}}
  - Decision-maker: {{RISK_R2_DECISION_MAKER}}
  - Sign-off date: {{RISK_R2_SIGNOFF_DATE}}

(Repeat for every risk in Section 6.)

Residual-risk roll-up summary (counts per band across the inventory):
- Number of residual-risk maximum cells: {{COUNT_MAX_RESIDUAL}}
- Number of residual-risk significant cells: {{COUNT_SIGNIFICANT_RESIDUAL}}
- Number of residual-risk limited cells: {{COUNT_LIMITED_RESIDUAL}}
- Number of residual-risk negligible cells: {{COUNT_NEGLIGIBLE_RESIDUAL}}

Article 36(1) gate (the prior-consultation decision is forced from the residual-risk roll-up; this row binds Section 10):
- Where any residual-risk cell reads as maximum, or where two or more residual-risk cells read as significant, prior consultation under Article 36(1) is required before processing starts.
- Prior consultation decision: {{ARTICLE_36_DECISION}} (the named state from Section 10).

8. Controls and safeguards applied per risk

Name the controls applied per risk. Article 35(7)(d) requires the controller to identify the measures envisaged to address the risks. Article 25 data protection by design is the design-time mirror of this section. Read each control against the risk in Section 6 and the residual rating in Section 7. A control catalogue with no per-risk linkage reads as a control library, not as a safeguard programme.

Control taxonomy (group controls into organisational, technical, contractual):

Organisational controls (people and process):
- Named role accountability (per the security charter, the DPO, the privacy programme lead, the business owner of the processing).
- Workforce training cadence (per the acceptable use policy template, the privacy training delivery record).
- Access governance (per the access review programme, the joiner-mover-leaver workflow).
- Awareness campaigns (privacy notice updates, in-product notice updates, training refresh).
- Incident response procedure (per the security incident severity classification template and the incident response runbook template).
- Vendor governance (per the vendor security risk assessment template and the DPA library).
- Records management (per the audit evidence retention policy template).
- Change management gates that require DPIA review (per Section 11 triggers).

Technical controls (configuration and engineering):
- Encryption at rest (named algorithm, named key custodian, named rotation cadence): {{ENCRYPTION_AT_REST_DETAILS}}
- Encryption in transit (named TLS minimum, named cipher suite policy, named mTLS posture): {{ENCRYPTION_IN_TRANSIT_DETAILS}}
- Pseudonymisation (named scheme, named key custodian, named reversal control): {{PSEUDONYMISATION_DETAILS}}
- Tokenisation (named token format, named de-tokenisation control): {{TOKENISATION_DETAILS}}
- Access control (named role-based access controls, named conditional access policies, named MFA posture): {{ACCESS_CONTROL_DETAILS}}
- Logging and monitoring (named log retention, named anomaly detection, named privileged action recording): {{LOGGING_DETAILS}}
- Data loss prevention (named DLP rules, named data class detection): {{DLP_DETAILS}}
- Backup integrity and recovery (named backup cadence, named immutability posture, named recovery testing cadence): {{BACKUP_DETAILS}}
- Vulnerability management (per the vulnerability management policy template and the vulnerability remediation runbook template): {{VULNERABILITY_MANAGEMENT_REFERENCE}}
- Secrets management (per the secrets management policy template): {{SECRETS_MANAGEMENT_REFERENCE}}
- Cryptographic key management (per the cryptographic key management policy template): {{KEY_MANAGEMENT_REFERENCE}}
- Code scanning and SAST (named coverage, named gate): {{CODE_SCANNING_DETAILS}}
- Container image signing (per the container image signing operating model): {{IMAGE_SIGNING_REFERENCE}}
- Network segmentation: {{NETWORK_SEGMENTATION_DETAILS}}
- Data residency enforcement (named data residency posture, named geo-fencing): {{DATA_RESIDENCY_DETAILS}}
- Data subject rights tooling (named DSAR fulfilment workflow, named consent platform): {{DSAR_TOOLING_DETAILS}}
- AI-specific controls (model card, dataset documentation, bias-testing report, monitoring dashboard, human-in-the-loop checkpoint, contestability surface): {{AI_CONTROLS_DETAILS}}

Contractual controls:
- Article 28 data processing agreement with each processor (named coverage of audit rights, sub-processor authorisation, breach notification, deletion, technical and organisational measures, international transfer mechanism): {{DPA_TERMS_REFERENCE}}
- Article 26 joint-controller arrangement (named coverage of respective duties and the data subject point of contact): {{JOINT_CONTROLLER_ARRANGEMENT_REFERENCE}}
- Standard Contractual Clauses where transfers occur outside an adequacy area: {{SCC_REFERENCE}}
- Binding Corporate Rules where applicable: {{BCR_REFERENCE}}
- Customer-facing terms that name the processing scope, the lawful basis, the retention, the rights mechanism: {{CUSTOMER_TERMS_REFERENCE}}

Control operational status (each control row carries a named operational status; aspirational controls are flagged for residual-risk read):
- Control deployment status (one of: operational, in-flight with named deadline, designed but not deployed, not designed): {{PER_CONTROL_STATUS}}
- Control verification cadence (named in the security control validation runbook template): {{CONTROL_VERIFICATION_CADENCE}}
- Control owner: {{CONTROL_OWNER}}

Per-risk control mapping (named cross-reference from Section 6 risks to Section 8 controls):
- Risk R1 controls: {{RISK_R1_CONTROL_REFERENCES}}
- Risk R2 controls: {{RISK_R2_CONTROL_REFERENCES}}
- Risk R3 controls: {{RISK_R3_CONTROL_REFERENCES}}

9. Consultation with DPO, data subjects, and stakeholders

Article 35(2) requires the controller to seek the advice of the data protection officer where one is designated. Article 35(9) requires the controller to seek the views of data subjects or their representatives where appropriate. This section captures the formal consultation record and any divergence between the controller decision and the advice received. A DPIA that does not record the DPO advice fails the Article 35(2) test even if the DPO was informally aware of the processing.

DPO advice (Article 35(2)):
- DPO consulted (yes / no with reason): {{DPO_CONSULTED}}
- DPO consultation date(s): {{DPO_CONSULTATION_DATES}}
- DPO advice summary (the named advice the DPO provided on the proposed processing and the controls):
{{DPO_ADVICE_SUMMARY}}
- Controller response to the DPO advice (accepted in full / accepted with named modifications / rejected with named reasons): {{CONTROLLER_RESPONSE_TO_DPO}}
- DPO sign-off on the advice column (the DPO signs the advice column even where the controller diverged; Article 39(1)(c)): {{DPO_SIGNOFF}}

Stakeholder consultation (Article 35(9) views of data subjects or their representatives):
- Data subject consultation conducted (yes / no with reason; reason if no must read against Article 35(9) exemption: would compromise security or be disproportionate): {{DATA_SUBJECT_CONSULTATION_CONDUCTED}}
- Consultation method (survey, focus group, advisory board, public consultation, named representative body, works council, customer advisory board): {{CONSULTATION_METHOD}}
- Number of data subjects or representatives consulted: {{NUMBER_CONSULTED}}
- Consultation findings summary: {{CONSULTATION_FINDINGS}}
- Controller response to consultation findings: {{CONTROLLER_RESPONSE_TO_CONSULTATION}}

Internal stakeholder consultation:
- Chief Information Security Officer (technical control owner): {{CISO_CONSULTATION}}
- Legal counsel (lawful basis and contractual control owner): {{LEGAL_CONSULTATION}}
- Head of HR (workforce-data processing): {{HR_CONSULTATION}}
- Procurement or Vendor Risk Lead (processor and sub-processor chain): {{PROCUREMENT_CONSULTATION}}
- Engineering Lead (data flow and technical owner): {{ENGINEERING_CONSULTATION}}
- Audit and Risk Committee (where residual risk read requires escalation): {{AUDIT_COMMITTEE_CONSULTATION}}
- Executive sponsor (chartered authority for residual-risk acceptance): {{EXECUTIVE_SPONSOR_CONSULTATION}}

External stakeholder consultation (where applicable):
- Works council or staff representative body (EU operations, France 50+ staff, Germany 5+ staff): {{WORKS_COUNCIL_CONSULTATION}}
- Trade union (where union recognition applies): {{UNION_CONSULTATION}}
- Independent ethics board or AI ethics committee (where AI processing): {{ETHICS_BOARD_CONSULTATION}}
- Customer advisory board (where customer data is the primary processing scope): {{CUSTOMER_ADVISORY_CONSULTATION}}
- Independent privacy expert or external counsel (where the controller commissioned external review): {{INDEPENDENT_REVIEW}}

Consultation evidence:
- Each consultation row is supported by a named record on document-management (meeting notes, advice memo, survey results, written correspondence).
- The advice column outcomes feed Section 7 residual-risk read and Section 8 controls applied.
- Where the controller diverged from named advice (DPO, data subject representative, ethics board), the reason is captured in the controller-response field.

10. Prior consultation decision under Article 36

Article 36(1) requires the controller to consult the supervisory authority prior to processing where the DPIA under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk. EDPB Guidelines 4/2017 paragraph IV.D and WP248 rev.01 clarify that prior consultation is required where residual risk after controls remains high (not merely where inherent risk is high before controls). This section forces the prior-consultation decision into one of four named states and prevents sign-off until a valid state is selected.

Prior consultation status (the DPIA cannot be signed off until one of the four states is selected and supporting evidence is recorded):

State 1: No prior consultation required because residual risk after controls is not high.
- Supporting evidence: Section 7 residual-risk roll-up reads zero maximum cells and fewer than two significant cells.
- DPO advice on no-consultation decision (Article 39(1)(c)): {{DPO_ADVICE_ON_NO_CONSULTATION}}
- Decision date: {{NO_CONSULTATION_DECISION_DATE}}
- Decision-maker: {{NO_CONSULTATION_DECISION_MAKER}}

State 2: No prior consultation required because the processing is covered by Member State law that itself was subject to a DPIA under Article 35(10).
- Member State law reference: {{MEMBER_STATE_LAW_REFERENCE}}
- DPIA reference covering the law: {{LAW_DPIA_REFERENCE}}
- Lawful basis cross-reference: {{LAW_LAWFUL_BASIS_REFERENCE}}

State 3: Prior consultation in progress with the supervisory authority.
- Supervisory authority name: {{SUPERVISORY_AUTHORITY_NAME}}
- Filing reference: {{FILING_REFERENCE}}
- Submission date: {{SUBMISSION_DATE}}
- Article 36(3) information provided to the supervisory authority:
  - Respective responsibilities of the controller, joint controllers, and processors involved.
  - Purposes and means of the intended processing.
  - The measures and safeguards provided to protect the rights and freedoms of data subjects under the GDPR.
  - Contact details of the DPO.
  - The DPIA itself.
  - Any other information requested by the supervisory authority.
- Article 36(2) response deadline (eight weeks from receipt, extendable by six weeks for complex cases): {{RESPONSE_DEADLINE}}
- Status updates from the supervisory authority: {{STATUS_UPDATES}}

State 4: Prior consultation completed with named outcome.
- Outcome state (one of: no objection / advice received and incorporated / objection received and processing modified / objection received and processing not initiated): {{PRIOR_CONSULTATION_OUTCOME}}
- Outcome date: {{OUTCOME_DATE}}
- Outcome reference (the supervisory authority decision document): {{OUTCOME_REFERENCE}}
- Where advice was received: the named modifications made to the processing or to the DPIA: {{INCORPORATED_ADVICE_SUMMARY}}
- Where objection was received: the named change in scope or the decision not to initiate processing: {{OBJECTION_RESPONSE_SUMMARY}}

Multi-authority consultation (where the processing involves data subjects in multiple Member States):
- One-stop-shop lead supervisory authority: {{LEAD_AUTHORITY}}
- Concerned supervisory authorities notified under Article 60: {{CONCERNED_AUTHORITIES_NOTIFIED}}
- Cooperation procedure status: {{COOPERATION_STATUS}}

Sign-off lock:
- The DPIA cannot be signed off as final by the controller representative in Section 12 until Section 10 reads one of the four valid states above and the supporting evidence is captured. This is a structural enforcement of Article 36(1) the template carries.

11. Review and monitoring schedule

Article 35(11) requires the controller to carry out a review where there is a change of the risk represented by the processing. Without a review cadence and named event triggers the DPIA freezes at first publication and the supervisory authority reads it as procedural compliance rather than an operational record. The template forces a scheduled cadence and a list of event triggers that force out-of-cycle review.

Scheduled review cadence (set per residual-risk band):
- Default cadence: annual review.
- High-residual-risk processing (any residual rating significant or maximum): quarterly review.
- Standard-residual-risk processing (residual rating limited): biennial review.
- Low-residual-risk processing (residual rating negligible across all rows): triennial review where supervisory-authority guidance permits.

Next scheduled review date: {{NEXT_REVIEW_DATE}}
Owner of the next scheduled review: {{NEXT_REVIEW_OWNER}}

Event triggers that force an out-of-cycle review:
- [ ] Change in the scope of processing (new data classes, new data subject categories, new processing operations, new purposes).
- [ ] Change in the purpose of processing (purpose extension, purpose narrowing, purpose elimination).
- [ ] Change in the processor or sub-processor chain (new processor, removed processor, processor location change, processor merger or acquisition).
- [ ] Change in the international transfer mechanism (Schrems-equivalent decision, SCC version change, adequacy decision change, Privacy Framework status change).
- [ ] Change in technology (platform migration, vendor change, ML model upgrade for AI processing, architecture change, new feature introduction).
- [ ] Security incident affecting the processing (breach affecting the data classes covered by the DPIA, incident response under Article 33 or 34 invoked).
- [ ] New supervisory authority guidance affecting the processing (EDPB guideline, national supervisory authority decision, sector regulator decision).
- [ ] Change in the applicable law (new Member State law, new sector-specific regulation, new international transfer regime).
- [ ] Change in the residual-risk read (new threat intelligence, new vulnerability disclosure, new threat-modelling input affecting the residual-risk evaluation in Section 7).
- [ ] Change in the consultation parties (new DPO, new joint controller, new works council, new data subject representative).
- [ ] Customer or contractual trigger (a customer requests DPIA review as part of a security questionnaire or vendor risk request).
- [ ] Regulator request (the supervisory authority requests an update under Article 36(1) or under an enforcement action).
- [ ] Audit observation (the audit committee or internal audit reads a deficiency in the DPIA).

Monitoring evidence (what the DPIA monitors between scheduled reviews):
- Number of data subject access requests, rectification requests, erasure requests, restriction requests, portability requests, and objection requests received for the processing per quarter.
- Number of complaints received about the processing per quarter.
- Number of security findings opened against the systems supporting the processing per quarter (cross-referenced to findings-management).
- Number of incidents under Article 33 or 34 affecting the processing per quarter.
- Number of changes to the processor or sub-processor chain per quarter.
- Number of control deployment-status changes (Section 8 aspirational controls becoming operational, or operational controls degrading).

Review record (per review cycle):
- Review date: {{REVIEW_DATE}}
- Reviewer: {{REVIEWER_NAME_AND_ROLE}}
- Trigger (scheduled or event-driven; if event-driven, named trigger from the list above): {{REVIEW_TRIGGER}}
- Material change since last review: {{MATERIAL_CHANGE_SUMMARY}}
- Updated risk inventory entries (cross-reference to Section 6 row identifiers): {{UPDATED_RISK_ROW_REFERENCES}}
- Updated risk evaluation rows (cross-reference to Section 7 row identifiers): {{UPDATED_EVALUATION_ROW_REFERENCES}}
- Updated control rows (cross-reference to Section 8 row identifiers): {{UPDATED_CONTROL_ROW_REFERENCES}}
- Article 36(1) re-evaluation (one of the four Section 10 states): {{REVIEW_ARTICLE_36_STATE}}
- DPO sign-off on the review outcome: {{REVIEW_DPO_SIGNOFF}}
- Controller representative sign-off on the review outcome: {{REVIEW_CONTROLLER_SIGNOFF}}
- New version number triggered by review (or note that no version increment was needed): {{NEW_VERSION_NUMBER}}

12. Sign-off chain

Name the people who signed the DPIA, in which capacity, and on which date. The sign-off chain is the audit anchor that converts the DPIA from a draft to an operating record. Without a named controller representative the supervisory authority does not know who to engage. Without a DPO sign-off the Article 35(2) test fails. Without joint-controller sign-off the Article 26 arrangement is incomplete.

Controller representative sign-off (the role accountable for the DPIA decision under Article 35; typically the data controller s named senior representative for privacy matters; the Article 27 representative for non-EEA controllers):
- Role: {{CONTROLLER_REPRESENTATIVE_ROLE}}
- Name: {{CONTROLLER_REPRESENTATIVE_NAME}}
- Signature: {{CONTROLLER_REPRESENTATIVE_SIGNATURE}}
- Sign-off date: {{CONTROLLER_REPRESENTATIVE_DATE}}
- Sign-off statement: "I accept the residual-risk read in Section 7 and confirm the prior-consultation decision in Section 10. The processing operation described in Section 2 may proceed under the controls named in Section 8 with the review schedule in Section 11."

Data Protection Officer sign-off (Article 35(2) advice column; the DPO signs the advice column even where the controller diverged):
- Name: {{DPO_NAME}}
- Signature: {{DPO_SIGNATURE}}
- Sign-off date: {{DPO_SIGNATURE_DATE}}
- DPO sign-off statement: "The advice provided in Section 9 has been considered by the controller. The residual-risk read in Section 7 and the prior-consultation decision in Section 10 reflect either acceptance of my advice or a named divergence captured in Section 9. I confirm I performed the Article 35(2) advisory role."

Joint controller sign-off (under Article 26 where applicable):
- Joint controller 1 name: {{JOINT_CONTROLLER_1_REPRESENTATIVE_NAME}}
- Signature: {{JOINT_CONTROLLER_1_SIGNATURE}}
- Sign-off date: {{JOINT_CONTROLLER_1_DATE}}
- Article 26 arrangement reference (the joint-controller arrangement document where respective responsibilities are named): {{JOINT_CONTROLLER_ARRANGEMENT_REFERENCE}}

Internal stakeholder sign-offs:
- Chief Information Security Officer (technical control owner): {{CISO_SIGNATURE_AND_DATE}}
- Legal Counsel or Chief Legal Officer (lawful basis and contractual control owner): {{LEGAL_SIGNATURE_AND_DATE}}
- Business owner of the processing operation (necessity and proportionality owner): {{BUSINESS_OWNER_SIGNATURE_AND_DATE}}
- Engineering Lead (data flow and technical owner): {{ENGINEERING_LEAD_SIGNATURE_AND_DATE}}
- Executive sponsor (residual-risk acceptance under chartered authority): {{EXECUTIVE_SPONSOR_SIGNATURE_AND_DATE}}

Approval gate enforcement:
- The DPIA reads as signed off only when the controller representative sign-off, the DPO sign-off, and any joint controller sign-offs are captured.
- Stakeholder sign-offs above the regulatory minimum are tracked in the engagement record on the workspace for the audit chain and are not gating for the DPIA approval read.
- Where any signatory diverges from the consensus, the named divergence is captured in Section 9 (Consultation) before sign-off.

Version increment record:
- Sign-off in this section creates version {{DPIA_VERSION}} as the operational record.
- Prior versions remain accessible per the document control rule in Section 14.
- Out-of-cycle modifications under Section 11 review triggers do not bypass the sign-off chain; each version increment cycles through this section.

13. Cross-references to adjacent artefacts

Cross-reference every adjacent artefact the DPIA reads against and every artefact the DPIA feeds. The cross-reference list is what makes the DPIA part of an operating system rather than an isolated document. When the data classification policy, the retention schedule, the vendor risk assessment, or the breach notification procedure changes, the cross-reference triggers a DPIA review under Section 11.

Privacy programme cross-references:
- Article 30 Record of Processing Activities entry for this processing: {{ROPA_REFERENCE}}
- Privacy notice published to the data subject (Article 13 or 14): {{PRIVACY_NOTICE_REFERENCE}}
- Consent management platform record reference where applicable: {{CONSENT_PLATFORM_REFERENCE}}
- Legitimate interests assessments where applicable: {{LIA_REFERENCE_LIST}}
- Transfer impact assessments where applicable: {{TIA_REFERENCE_LIST}}
- Breach notification procedure for incidents affecting this processing: {{BREACH_NOTIFICATION_PROCEDURE_REFERENCE}}
- Data subject rights fulfilment procedure: {{DSAR_PROCEDURE_REFERENCE}}
- Children data handling addendum where Article 8 applies: {{CHILDREN_ADDENDUM_REFERENCE}}

Security programme cross-references:
- Security programme charter naming the chartered authority: {{SECURITY_CHARTER_REFERENCE}}
- Acceptable use policy naming the workforce conduct rules: {{ACCEPTABLE_USE_POLICY_REFERENCE}}
- Data classification policy naming the data classes processed and the per-class handling rules: {{DATA_CLASSIFICATION_POLICY_REFERENCE}}
- Audit evidence retention policy naming the DPIA retention rule: {{AUDIT_EVIDENCE_RETENTION_POLICY_REFERENCE}}
- Vulnerability management policy naming the finding lifecycle for the systems supporting the processing: {{VULNERABILITY_MANAGEMENT_POLICY_REFERENCE}}
- Vulnerability remediation SLA policy naming the SLA windows for findings affecting the processing: {{VULNERABILITY_SLA_POLICY_REFERENCE}}
- Vulnerability disclosure policy naming external reporting safe harbour: {{VULNERABILITY_DISCLOSURE_POLICY_REFERENCE}}
- Vulnerability management RACI naming Accountable roles: {{VULNERABILITY_MANAGEMENT_RACI_REFERENCE}}
- Secrets management policy naming credential handling: {{SECRETS_MANAGEMENT_POLICY_REFERENCE}}
- Cryptographic key management policy naming key custody for encryption controls named in Section 8: {{KEY_MANAGEMENT_POLICY_REFERENCE}}
- Security exception register naming any accepted risk: {{SECURITY_EXCEPTION_REGISTER_REFERENCE}}
- Risk register entry for residual risk: {{RISK_REGISTER_REFERENCE}}
- Security incident severity classification naming triggers for breach notification: {{SECURITY_INCIDENT_SEVERITY_CLASSIFICATION_REFERENCE}}
- Incident response runbook naming the response procedure: {{INCIDENT_RESPONSE_RUNBOOK_REFERENCE}}
- Business continuity and disaster recovery plan naming the resilience controls: {{BCDR_PLAN_REFERENCE}}
- Security control validation runbook naming the per-control validation cadence for the controls in Section 8: {{SECURITY_CONTROL_VALIDATION_RUNBOOK_REFERENCE}}

Vendor and processor cross-references:
- Vendor security risk assessment per processor named in Section 5: {{PER_PROCESSOR_VSRA_REFERENCES}}
- Data processing agreement library reference: {{DPA_LIBRARY_REFERENCE}}
- Sub-processor list reference: {{SUB_PROCESSOR_LIST_REFERENCE}}

Framework evidence cross-references:
- ISO/IEC 27001 ISMS reference where the controller maintains ISO 27001 certification: {{ISO_27001_REFERENCE}}
- ISO/IEC 27701 PIMS reference where the controller maintains ISO 27701 certification: {{ISO_27701_REFERENCE}}
- SOC 2 report reference where the controller maintains a SOC 2 attestation: {{SOC_2_REFERENCE}}
- NIST Privacy Framework profile reference: {{NIST_PRIVACY_FRAMEWORK_REFERENCE}}
- EU AI Act fundamental rights impact assessment reference where applicable: {{AI_ACT_FRIA_REFERENCE}}
- Sector regulator filings (financial, health, education, public sector): {{SECTOR_REGULATOR_FILINGS}}

Jurisdiction-specific named appendices:
- Appendix A: UK GDPR specifics where the controller offers services to UK data subjects.
- Appendix B: LGPD specifics where the controller offers services to Brazilian data subjects.
- Appendix C: CCPA, CPRA, and US state-law specifics where the controller offers services to US data subjects.
- Appendix D: PIPL specifics where the controller offers services to Chinese data subjects (including the standard contract for the cross-border transfer of personal information).
- Appendix E: PIPA specifics where the controller offers services to Korean data subjects.
- Appendix F: Sector-specific appendix (HIPAA, FERPA, GLBA, COPPA, MAS TRM, APRA CPS 234, FCA Senior Managers Regime, NIS2, DORA, sector-specific health authority guidance).

14. Document control, retention, and disposal

Name the document control, retention, and disposal rules for the DPIA itself. The supervisory authority asks for prior versions of the DPIA when investigating processing operations that pre-date a security incident or a data subject complaint. Without versioned retention and a named disposal procedure the DPIA cannot meet Article 5(1)(e) storage limitation against itself and cannot satisfy a regulator request for the historic state.

Document control:
- Document classification per the data classification policy: {{DOCUMENT_CLASSIFICATION}}
- Access control (roles permitted to read the DPIA): {{ACCESS_ROLES_READ}}
- Access control (roles permitted to propose amendments): {{ACCESS_ROLES_AMEND}}
- Access control (roles permitted to sign new versions): {{ACCESS_ROLES_SIGN}}
- Versioning rule: new version on every signed amendment; prior versions retained per the retention rule below; no in-place edit after sign-off.

Retention:
- DPIA retention period: the life of the processing operation plus the longer of (i) six years after decommissioning, (ii) the retention rule in the audit evidence retention policy template, or (iii) the regulatory minimum in any applicable sector regulation.
- Retention rationale: DPIA retention supports retrospective regulator inquiries about historical processing, supports prior-consultation references for adjacent processing, and supports data subject and class-action defensibility windows.
- Retention triggers (the retention clock starts on each named event):
  - On initial sign-off: clock starts for the original version.
  - On version increment: clock starts for the new version; prior version remains retained per the retention rule.
  - On processing decommissioning: clock starts for the closed-DPIA retention.

Disposal:
- Disposal authorisation (the named role authorised to dispose of a DPIA version): {{DISPOSAL_AUTHORISATION_ROLE}}
- Disposal procedure (the named workflow that converts a DPIA from active to disposed):
  1. Retention clock expires for the named version.
  2. Disposal proposal submitted by the records custodian with named reasons.
  3. Disposal review by the DPO (confirms no active inquiry, no active complaint, no active class action).
  4. Disposal review by legal counsel (confirms no active legal hold).
  5. Disposal review by the controller representative (final approval).
  6. Disposal action executed under named workflow.
  7. Destruction certificate signed and retained per the audit evidence retention policy.
- Disposal evidence (the named record that proves a DPIA version was disposed of): {{DISPOSAL_EVIDENCE_REFERENCE}}

Re-issuance after disposal:
- A disposed DPIA version is not re-issuable; a new DPIA covering the same processing operation requires a fresh assessment under Sections 1 to 13 with a new version identifier.

Workspace storage:
- Storage location: the workspace document-management feature with named custodian, version history, and role-gated access.
- Backup and durability: backup integrity per the audit evidence retention policy template; immutability for signed versions.
- Cross-region replication where required by data residency: per the named data residency rule in Section 8.
- Activity log captures every read, amendment proposal, version increment, sign-off, review event, and disposal event with named actor and timestamp.

Final approval row (this row binds Sections 12 and 14 and is the last action in the DPIA workflow):
- Final approval that the DPIA is operational: {{FINAL_APPROVAL_SIGNATURE_AND_DATE}}
- Operational status: {{OPERATIONAL_STATUS}} (one of: operational / suspended pending review / withdrawn pending re-assessment / closed on processing decommissioning)
- Linked engagement record on the workspace: {{ENGAGEMENT_RECORD_REFERENCE}}

Seven failure modes the DPIA template designs against

A DPIA fails the supervisory authority read, the data subject read, the customer security review read, and the audit committee read in recognisable patterns. Each failure has a structural fix the fourteen-section template enforces. Read this list before customising the DPIA so the customisation does not weaken the discipline that makes the assessment defensible.

No DPIA where Article 35 triggers apply

The processing meets Article 35(3) or a supervisory authority mandatory list condition or two or more of the WP248 nine criteria, and the controller relies on the privacy notice, the vendor risk assessment, or the data processing agreement as a substitute. The supervisory authority asks for the DPIA and the controller has no artefact to produce. The fix is the explicit DPIA trigger record in Section 2 with named conditions ticked, so the question of whether a DPIA is required is recorded rather than evaded.

Inherent risk conflated with residual risk

The DPIA names inherent risk and stops; the controller does not capture the post-control residual risk. Article 36(1) prior consultation is gated on the residual-risk read after controls; without the residual column the controller cannot prove the consultation decision was correct. The fix is the four-by-four matrix in Section 7 with inherent and residual columns per risk row, the per-row residual-risk decision-maker, and the Article 36(1) gate that binds Section 10.

DPO advice not captured

A DPO was designated under Article 37 and the controller did not formally consult the DPO before signing off the DPIA. Article 35(2) is breached even if the DPO was informally aware of the processing. The fix is the DPO advice column in Section 9 with named consultation date, named advice summary, named controller response (accepted / accepted with modifications / rejected with reasons), and the DPO sign-off in Section 12 even where the controller diverged.

DPIA frozen at first publication

The DPIA is signed off at processing launch and never reviewed. Article 35(11) requires review when the risk changes. The supervisory authority reads the unreviewed DPIA as procedural compliance rather than an operational record. The fix is the scheduled cadence and the event-trigger list in Section 11, with the review record per cycle captured on the activity log so the review cadence is observable rather than asserted.

Aspirational controls listed without operational status

Section 8 lists encryption, pseudonymisation, conditional access, and SOC 2 controls as the safeguards applied. The auditor asks whether the named encryption is actually deployed today and the answer is missing. The residual-risk read in Section 7 is invalid because it was calculated against controls that are not operational. The fix is the per-control operational status field in Section 8 with named deployment status (operational, in-flight with deadline, designed but not deployed, not designed), per-control verification cadence cross-referenced to the security control validation runbook template, and per-control owner.

Prior consultation decision not documented

The DPIA produces a high-residual-risk read in Section 7 and the controller did not file an Article 36(1) prior consultation; the DPIA is signed off and the processing starts. The supervisory authority opens an investigation later and the controller has no record of the decision not to consult. The fix is the four-state forced selection in Section 10 (no consultation required because risk is not high / no consultation required because covered by Member State law / consultation in progress with named filing / consultation completed with named outcome) and the sign-off lock that prevents Section 12 closure until Section 10 reads one of the four valid states.

DPIA stored where the audit cannot read it

The DPIA lives in a personal drive, a wiki page, a privacy management tool the audit does not have access to, or an email thread between the DPO and the legal team. The supervisory authority request cannot be answered with a single artefact pull. The fix is the workspace storage rule in Section 14 with document-management as the named location, role-gated access through team-management, MFA enforcement, activity-log capture, and the engagement record cross-reference.

Ten questions the quarterly privacy programme review has to answer

Operational privacy review keeps the DPIA portfolio current. Programme governance review answers whether the portfolio is delivering durable Article 35 compliance or accumulating gaps the supervisory authority will read as procedure-on-paper. Run these ten questions at every quarterly privacy review and capture the answers in the engagement record on the workspace.

1.Which Article 35 trigger does this processing meet, and is the trigger recorded in Section 2 with named conditions ticked.
2.For each purpose in Section 2, what is the lawful basis selected in Section 3, what is the rationale, and where the basis is consent or legitimate interests, where is the supporting evidence (consent capture, LIA reference).
3.For each row in the inherent-risk inventory in Section 6, what is the residual-risk rating in Section 7 after the controls in Section 8, and who is the named decision-maker accepting the residual risk.
4.Where the residual-risk roll-up reads as high (one or more maximum cells or two or more significant cells), what state of Article 36(1) prior consultation is recorded in Section 10 and what is the supporting evidence.
5.Where a DPO is designated under Article 37, what advice did the DPO provide in Section 9, what was the controller response, and where the controller diverged, what was the documented reason.
6.For each processor and sub-processor named in Section 5, what is the Article 28 data processing agreement reference, the data classes received, the processing location, the transfer mechanism for any international transfer, and the transfer impact assessment reference.
7.For each control named in Section 8, what is the operational status, the verification cadence, and the named owner, and where the control is not operational, how is the residual-risk read in Section 7 adjusted.
8.Where automated decision-making under Article 22 applies, what is the Article 22(2) exemption relied on, what suitable measures are in place, and where AI processing reads as high-risk under the EU AI Act, what is the fundamental rights impact assessment reference under Article 27.
9.When is the next scheduled review under Section 11, and which event triggers have fired since the last review.
10.Where is the signed DPIA stored, who has read access, who has amend access, and where is the activity log evidence for every read, amendment, and sign-off event.

How the DPIA pairs with SecPortal

The template above is copy-ready as a standalone artefact. SecPortal is not a privacy management platform like OneTrust, TrustArc, DataGrail, Securiti, Privado, Ethyca, Osano, Termly, BigID, Collibra, or Transcend; it does not run a data discovery engine, does not auto-populate ROPA entries by scanning systems, does not fulfil data subject access requests, does not orchestrate consent banners, does not maintain a cookie-tracker catalogue, and does not run the supervisory authority filing workflow. What SecPortal does is carry the security-side evidence chain the DPIA cross-references through document management for versioned storage of the DPIA itself and the supporting evidence pack, with named custodian, owner roles (DPO, controller representative, business owner, technical owner), and a complete version history.

The sign-off chain across Section 12 lives on the activity log with named actor, timestamp, and 30, 90, or 365-day retention by plan, so the audit read of the controller representative sign-off, the DPO advice sign-off, the joint controller sign-off, and the executive sponsor sign-off is the same record the supervisory authority would read in a request for information. Access to the DPIA and its sensitive supporting artefacts (data flow maps, processor inventory, transfer impact assessments, prior consultation correspondence) is gated by team management role-based access control with owner, admin, member, and viewer roles shaping who can read and amend the document, and protected by multi-factor authentication.

Security findings that derive from the controls applied under Section 8 (encryption rollout gaps, pseudonymisation defects, access control misconfigurations, vendor processor findings from external scans, code-scanning findings on the systems supporting the processing) live alongside vulnerability findings on the same workspace through findings management, each carrying a CVSS-aligned severity, a named owner, a target close date, and an evidence-of-closure requirement. The retesting workflows feature pairs the verification of a finding closure to the original DPIA Section 8 control reference so the supervisory authority reads the residual-risk decision against the live control state rather than the launch-day assertion. The finding overrides feature carries the compensating-control record where a corrective action cannot land within the SLA window, with the eight-field decision chain naming the override author, the reviewer, the rationale, the expiry date, and the re-validation requirement.

The compliance tracking feature maps the DPIA evidence to ISO/IEC 27001 (Annex A 5.34 privacy and protection of personally identifiable information), ISO/IEC 27701 (Clause 6.15.1.1 and the Annex PIMS-specific controls), SOC 2 (CC1.4, CC2.2, CC6.7, P1.0 to P8.0 Privacy criteria), PCI DSS where cardholder data overlaps with personal data, NIST SP 800-53 (PT-2, PT-3, RA-8), NIST Privacy Framework, NIS2 Article 21(2)(c), DORA Article 6, and sector overlays with CSV export, so when an auditor asks how the controller knows the encryption named in Section 8 is operational, the named owner of each technical control, the validation cadence per the control validation runbook, the security findings raised against the underlying systems, and the corrective action chain are one query against the workspace rather than a scramble across the privacy stack, the security stack, and the audit stack.

Each DPIA review under Section 11 is run as an engagement with a named reviewer, named consultation parties, named trigger, and named outcome. The notifications and alerts feature dispatches the scheduled review reminder and the event-driven trigger pages to the DPO, the DPIA owner, the controller representative, and the business owner with the same audit trail. The AI report generation workflow drafts a leadership summary of the DPIA portfolio (count by residual-risk band, overdue reviews, recent event-driven triggers, processor changes, prior consultation status) from the same engagement data so the audit committee read of the privacy programme and the operational read are the same record rather than two independently edited documents that diverge between cycles.

For the workflow side where the DPIA evidence is read into an audit fieldwork response, see the audit fieldwork evidence request fulfillment workflow. For the controllers customer-facing assurance surface where DPIA references support enterprise sales reviews, see the customer security evidence room workflow. For the named-control validation cadence the DPIA Section 8 controls operate against, see the control mapping cross-framework crosswalks workflow. For the breach-side procedure that the DPIA Section 13 cross-references, see the breach notification and regulator readiness workflow. For the regulatory framework pages the DPIA evidences against, see GDPR, HIPAA, NIS2, DORA, ISO/IEC 42001, NIST AI RMF, and ISO/IEC 27036 (supplier-side privacy and security relationship). SecPortal does not replace the dedicated privacy management platform; the privacy team runs the platform, the DPO advises the controller, the controller representative signs the residual-risk decision, and SecPortal carries the durable workspace evidence chain the supervisory authority, the audit committee, and the customer all read against.

Buyer and operator pairing

The DPIA portfolio is the privacy-evidence backbone GRC and compliance teams, data security teams, internal security teams, product security teams, cloud security teams, AppSec teams, CISOs and security leaders, security architects, and security programme managers run when a privacy programme has to survive a supervisory authority inquiry, a customer enterprise security review, a regulator audit, an investor diligence read, and a board read at the same time. External providers (compliance consultants, virtual CISOs, privacy counsel, security consultants) use the same package to give clients a DPIA procedure that meets Article 35(7) content expectations rather than a one-page checklist fragment per client.

Loading tool...

Related features

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Vulnerability management software that tracks every finding

Finding overrides that survive every scan cycle

Verify fixes and track reopens on the same finding record

Orchestrate every security engagement from start to finish

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Compliance audits

Audit fieldwork evidence request fulfillment

Audit evidence retention and disposal

Breach notification and regulator readiness

Customer security evidence room workflow

Cross-framework control mapping

Vulnerability acceptance and exception management

Hold the DPIA portfolio on the same workspace as the security findings it depends on

SecPortal pairs every DPIA review to an engagement record so the controller representative sign-off, the DPO advice, the prior consultation decision, the residual-risk read, and the controls evidence chain all live on one workspace with named-actor activity log. Free plan available.

Get Started Free

No credit card required. Free plan available forever.

Data Protection Impact Assessment (DPIA) Templatefourteen sections aligned with GDPR Article 35 and 36, ISO/IEC 27701, NIST Privacy Framework, and adjacent regimes

Fourteen sections that turn an Article 35 obligation into a defensible privacy record

1. Header, version control, and controller identity

2. Processing operation description and purpose

3. Lawful basis and condition for special-category data

4. Necessity and proportionality assessment

5. Data flow map, asset inventory, and processor list

6. Risk identification per data subject category

7. Risk evaluation (likelihood, severity, residual risk)

8. Controls and safeguards applied per risk

9. Consultation with DPO, data subjects, and stakeholders

10. Prior consultation decision under Article 36

11. Review and monitoring schedule

12. Sign-off chain

13. Cross-references to adjacent artefacts

14. Document control, retention, and disposal

Seven failure modes the DPIA template designs against

No DPIA where Article 35 triggers apply

Inherent risk conflated with residual risk

DPO advice not captured

DPIA frozen at first publication

Aspirational controls listed without operational status

Prior consultation decision not documented

DPIA stored where the audit cannot read it

Ten questions the quarterly privacy programme review has to answer

How the DPIA pairs with SecPortal

Buyer and operator pairing

Related features

Document management for every security engagement

Every action recorded across the workspace

Collaborate across your entire team

Multi-factor authentication on every workspace

Compliance tracking without a full GRC platform

Vulnerability management software that tracks every finding

Finding overrides that survive every scan cycle

Verify fixes and track reopens on the same finding record

Orchestrate every security engagement from start to finish

Notifications and alerts for the people who carry the work

AI-powered reports in seconds, not days

Compliance audits

Audit fieldwork evidence request fulfillment

Audit evidence retention and disposal

Breach notification and regulator readiness

Customer security evidence room workflow

Cross-framework control mapping

Vulnerability acceptance and exception management

Hold the DPIA portfolio on the same workspace as the security findings it depends on

Fourteen sections that turn an Article 35 obligation into a defensible privacy record

1. Header, version control, and controller identity

2. Processing operation description and purpose

3. Lawful basis and condition for special-category data

4. Necessity and proportionality assessment

5. Data flow map, asset inventory, and processor list

6. Risk identification per data subject category

7. Risk evaluation (likelihood, severity, residual risk)

8. Controls and safeguards applied per risk

9. Consultation with DPO, data subjects, and stakeholders

10. Prior consultation decision under Article 36

11. Review and monitoring schedule

12. Sign-off chain

13. Cross-references to adjacent artefacts

14. Document control, retention, and disposal

Seven failure modes the DPIA template designs against

No DPIA where Article 35 triggers apply

Inherent risk conflated with residual risk

DPO advice not captured

DPIA frozen at first publication

Aspirational controls listed without operational status

Prior consultation decision not documented

DPIA stored where the audit cannot read it

Ten questions the quarterly privacy programme review has to answer

How the DPIA pairs with SecPortal

Buyer and operator pairing

Data Protection Impact Assessment (DPIA) Template
fourteen sections aligned with GDPR Article 35 and 36, ISO/IEC 27701, NIST Privacy Framework, and adjacent regimes