Category: Impact Assessments & Documentation

Data Protection Impact Assessment Register

Also known as: DPIA Register, DPIA Register, DPIA Log, DPIA Inventory

Simply put

A Data Protection Impact Assessment (DPIA) Register is an organisation's central record of the DPIAs it has carried out or is required to carry out for processing activities that may pose a high risk to individuals' privacy. It typically tracks each assessment, the risks identified, and how those risks were addressed, helping an organisation demonstrate that it has considered privacy risks before processing personal data. A DPIA itself is an assessment of the impact of planned processing operations on the protection of personal data.

Formal definition

A DPIA Register is an accountability and governance tool used by a controller to maintain a structured inventory of DPIAs relevant to its processing operations. A DPIA is the structured process required, under the GDPR (the obligation is generally located in Article 35), where processing is likely to result in a high risk to the rights and freedoms of natural persons; the register documents matters such as the processing described, the assessment of necessity and proportionality, identified risks, mitigating measures, residual risk, and the outcome or review status. The register is not itself mandated as a discrete deliverable by the express text of the Regulation in the way the record of processing activities (commonly associated with Article 30) is, but it is widely used to support the accountability principle and to evidence that DPIAs have been conducted where triggered. It is closely related to, but distinct from, a data protection risk register, which some regulators (for example, the Irish Data Protection Commission) describe as a master document recording identified data protection risks more broadly. Practitioners should note that a processor has a duty to assist the controller in ensuring compliance with DPIA obligations (this assistance duty is generally located in Article 28(3)(f)), so processor input may feed into register entries. Scope and content expectations can vary between the EU GDPR, the UK GDPR, and national implementing or sector-specific regimes (such as law enforcement processing), and readers should verify specific requirements against the current official text and applicable regulator guidance.

Why it matters

The accountability principle under the GDPR requires a controller not only to comply with data protection obligations but to be able to demonstrate that compliance. A DPIA Register supports this by providing a central, structured record of the assessments an organisation has carried out or is required to carry out. Where processing is likely to result in a high risk to the rights and freedoms of natural persons, a DPIA is generally required under Article 35, and a register helps an organisation evidence that it has identified those high-risk activities, considered privacy risks before processing, and tracked how those risks were addressed.

Beyond compliance evidence, a register serves an operational function: it gives data protection teams and senior stakeholders visibility over the organisation's high-risk processing, the mitigations applied, residual risk, and review status. This can help avoid situations where a DPIA is overlooked for a triggering activity, or where a completed assessment is not revisited when the processing changes. It should be distinguished from a data protection risk register, which some regulators (for example, the Irish Data Protection Commission) describe as a master document recording identified data protection risks more broadly.

Readers should note the boundaries of this tool. Unlike the record of processing activities commonly associated with Article 30, a DPIA Register is not itself expressly mandated as a discrete deliverable by the text of the Regulation; it is a widely used practice to support accountability rather than a standalone statutory obligation. Scope and content expectations can vary between the EU GDPR, the UK GDPR, and national implementing or sector-specific regimes, such as law enforcement processing, so specific requirements should be verified against the current official text and applicable regulator guidance.

Who it's relevant to

Data Protection Officers and privacy leads

DPOs and privacy teams typically own the register as a core accountability tool, using it to track which high-risk processing activities have been assessed, monitor residual risk, and schedule reviews. It helps them evidence, to management and potentially to a supervisory authority, that DPIAs have been carried out where the Article 35 threshold is met.

Controllers and their governance functions

As the party generally responsible for the DPIA obligation under Article 35, a controller uses the register to demonstrate compliance with the accountability principle. Governance and risk functions rely on it for visibility over high-risk processing and the mitigations in place, subject to verifying specific expectations against applicable regulator guidance.

Processors

Processors have a duty to assist the controller with DPIA compliance, generally located in Article 28(3)(f). While the register is the controller's tool, processor-supplied information about processing operations and safeguards may feed into individual entries, making processors relevant contributors to the assessment record.

Compliance and legal teams

Compliance leads and lawyers use the register to confirm that assessments exist for triggering activities and to distinguish it from related instruments, such as the record of processing activities associated with Article 30 or a broader data protection risk register. They should note that content expectations can differ across the EU GDPR, the UK GDPR, and sector-specific regimes.

Inside DPIA Register

Record of DPIAs undertaken

An organized inventory listing each Data Protection Impact Assessment the organization has carried out, typically capturing the processing operation assessed, a reference identifier, and its current status (for example draft, completed, or under review). The DPIA obligation itself derives from Article 35 of the GDPR, which requires a controller to conduct an assessment where processing is likely to result in a high risk to the rights and freedoms of individuals.

Trigger and screening outcomes

A record of why a DPIA was or was not required for a given processing activity, including the screening or threshold assessment. This generally reflects the Article 35 high-risk criteria and any supervisory authority list of processing operations subject to a mandatory DPIA, which can vary between member states.

Description of processing and purposes

For each entry, a summary of the nature, scope, context, and purposes of the processing, and typically the identified legal basis under Article 6 (and, where special category data is involved, the additional Article 9 condition).

Risk assessment and mitigation measures

An account of the risks to individuals identified during the DPIA and the measures envisaged to address them, so the register reflects the residual risk position after mitigations are applied.

Consultation records

Where relevant, evidence of any consultation, including the advice of the data protection officer and, where residual high risk cannot be mitigated, any prior consultation with the supervisory authority.

Processor assistance references

Links to input received from processors. Under Article 28(3)(f), processors are generally required to assist the controller in ensuring compliance with its DPIA obligations, and the register may note where such assistance was relied upon.

Review and version history

Dates of completion and scheduled or actual reviews, with version control, reflecting that a DPIA is generally treated as a living document to be revisited when the processing or its risk profile changes.

Common questions

Answers to the questions practitioners most commonly ask about DPIA Register.

Is maintaining a DPIA register a mandatory requirement under the GDPR?

The GDPR does not expressly mandate a standalone 'DPIA register' as a named instrument. The underlying obligation to carry out a Data Protection Impact Assessment arises under Article 35 where processing is likely to result in a high risk to the rights and freedoms of individuals. Keeping a register is generally treated as a practical accountability tool that helps a controller demonstrate compliance with that obligation, rather than a distinct statutory document. Some supervisory authorities recommend such record-keeping in guidance, so you should verify expectations with your relevant regulator.

Does every processing activity need to be entered in the DPIA register?

No. A DPIA is required under Article 35 only where processing is likely to result in a high risk, and supervisory authorities typically publish lists of processing types that require one. A DPIA register therefore generally records assessments actually carried out (and, in some approaches, the reasoned decisions that a DPIA was not required), rather than cataloguing every processing operation. The broader inventory of all processing activities is a separate accountability record and should not be conflated with the DPIA register.

What information is typically recorded in a DPIA register?

Practice varies, but a register commonly captures identifying details of each assessment: the processing activity assessed, the date, the responsible owner, a summary of identified risks and mitigations, the outcome, any residual high risk requiring prior consultation with the supervisory authority, and review dates. Because the register is an accountability tool rather than a prescribed form, controllers should tailor its fields to their own risk profile and to any format their supervisory authority recommends.

How does a controller keep the register current?

A DPIA should generally be reviewed when the nature, scope, context, or purposes of processing change, or when the associated risk changes, and the register should reflect those reviews. Many organisations set periodic review cycles and trigger-based reviews (for example, on new technologies or vendors). The register should be updated to log review dates and any revised outcomes so that it continues to evidence ongoing, rather than one-off, compliance.

What is a processor's role in relation to the register?

The DPIA obligation under Article 35 rests with the controller. However, under Article 28(3)(f) a processor generally has a contractual duty to assist the controller in ensuring compliance with the DPIA obligations, taking into account the nature of processing and the information available to it. In practice, information a processor supplies (for example, about technical and organisational measures) may feed into an assessment recorded in the controller's register, but responsibility for maintaining the register typically remains with the controller.

How does the register relate to prior consultation with a supervisory authority?

Where a DPIA indicates that processing would result in a high residual risk that the controller cannot sufficiently mitigate, the controller is generally required to consult the supervisory authority before processing. The register can help identify and track such cases, recording whether prior consultation was triggered and its outcome. This links the register to the escalation pathway rather than making it a substitute for that consultation; specific procedures should be confirmed against current official guidance.

Common misconceptions

Maintaining a DPIA register is an explicit standalone requirement of the GDPR text.

The GDPR does not, in its wording, mandate a distinct 'DPIA register' by that name. The DPIA obligation arises from Article 35, and a register is generally adopted as a practical accountability and documentation tool that helps demonstrate compliance. Practitioners should verify how their supervisory authority and internal governance frameworks treat such records.

Every processing activity requires a DPIA and therefore a register entry.

A DPIA is generally required under Article 35 only where processing is likely to result in a high risk to individuals, subject to assessment against the relevant criteria and any supervisory authority lists. Many activities will not meet that threshold; some organizations still record screening outcomes to evidence the decision, but this is a practice choice rather than a universal legal mandate.

The register is the sole responsibility of the controller and processors have no role.

While the DPIA obligation rests with the controller, processors have a duty under Article 28(3)(f) to assist the controller with its DPIA obligations. Entries may therefore rely on processor input, and this division of roles should not be conflated.

Best practices

Link each register entry to the underlying Article 35 DPIA and record the screening or threshold assessment that shows why a DPIA was or was not required, so the accountability rationale is traceable.

Capture the identified legal basis under Article 6 for each assessed processing operation, and flag where an additional Article 9 condition is engaged for special category data.

Record the involvement and advice of the data protection officer, and note any prior consultation with the supervisory authority where residual high risk could not be mitigated.

Document processor assistance received under Article 28(3)(f) and reference the relevant contractual arrangements, keeping controller and processor roles clearly distinguished.

Treat entries as living records with version control and scheduled reviews, updating them when the processing, context, or risk profile changes.

Check current supervisory authority guidance and any national lists of mandatory-DPIA processing, since these can vary between member states and evolve over time.