DPIA guide for Irish organisations: templates and audit-ready workflow
If your organisation is planning processing that involves large-scale personal data, special category data, profiling, or novel technology, you almost certainly need a Data Protection Impact Assessment (DPIA) under Article 35 of the GDPR. The immediate first step is to run a short screening check against the Data Protection Commission (DPC) and EDPB criteria, then download the DPC sample DPIA template or the EDPB meta-template to begin documenting your assessment.
- Does the processing involve special category data (health, biometric, genetic)?
- Will it profile individuals or use automated decision-making with legal or similarly significant effects?
- Does it involve large-scale, systematic monitoring of a publicly accessible area?
- Does it use novel technology where the privacy risks are not yet well understood?
- Will it combine or cross-reference datasets in ways that exceed individuals' reasonable expectations?
If you answered yes to any of these, proceed to a full DPIA before the processing begins.
Pro Tip: Start the DPIA at project design stage, not at sign-off. Link it directly to your project planning documents so that mitigation actions appear as tracked tasks from day one, giving you a clear audit trail from the outset.
Key takeaways
A DPIA is mandatory under Article 35 GDPR when processing is likely to result in high risk, and it must be completed before processing begins, not after.
| Point | Details |
|---|---|
| Screening comes first | Run a five-question screening check against DPC and EDPB criteria before committing to a full DPIA. |
| Seven-stage process | Follow the DPC's workflow from screening through to sign-off and scheduled review. |
| Data flow diagram is required | Include a visual data lifecycle diagram; it surfaces hidden flows that narrative text misses. |
| DPC consultation threshold | If high risk remains after mitigations, prior consultation with the DPC is legally required before processing begins. |
| ShieldIQ for SMEs | ShieldIQ automates DPIA templates, risk registers, and audit-ready reporting for Irish SMEs without a full-time compliance team. |
Table of Contents
- What is a DPIA and why does it matter under the GDPR?
- When is a DPIA required? Triggers and Ireland-relevant examples
- How to conduct a DPIA: a step-by-step process with deliverables and roles
- Making the DPIA audit-ready: records, sign-off, and review
- When and how to consult the Data Protection Commission
- Official templates and practical DPIA materials
- Frequent DPIA mistakes and best practices for Irish organisations
- How ShieldIQ helps automate and evidence DPIAs for Irish SMEs
- ShieldIQ cuts the time from DPIA screening to audit-ready report
- Sources
What is a DPIA and why does it matter under the GDPR?
A Data Protection Impact Assessment is a structured risk-management process that identifies, analyses, and mitigates privacy risks before processing begins. Under Article 35(7) of the GDPR, a DPIA must cover at a minimum: the nature, scope, context, and purpose of the processing; an assessment of necessity and proportionality; the risks to the rights and freedoms of data subjects; and the measures envisaged to address those risks. The DPC's guidance on DPIAs frames the process as a proactive risk-management tool rather than a form-filling exercise.
A DPIA is not about eliminating all risk. It is about identifying risks early, applying proportionate mitigations, and making a documented, defensible decision about whether the residual risk is acceptable or whether prior consultation with the supervisory authority is required. The goal is accountability, not perfection.
That distinction matters in practice. A DPIA that concludes "residual risk is low and acceptable" is a valid, compliant outcome, provided the reasoning is documented and the DPO has signed off. Where high risk remains after mitigations, the GDPR requires prior consultation with the DPC before processing begins. DPIAs also support privacy by design: embedding them into project governance means privacy considerations shape technical and organisational decisions from the start, rather than being retrofitted at launch.
When is a DPIA required? Triggers and Ireland-relevant examples
The EDPB and Article 29 Working Party guidelines identify nine criteria that indicate processing is "likely to result in a high risk." A DPIA is mandatory when two or more of these criteria apply, and good practice when even one applies.
| Trigger criterion | Ireland-relevant example |
|---|---|
| Large-scale processing of special category data | National patient data sharing project across HSE systems |
| Systematic monitoring of publicly accessible areas | CCTV with facial recognition in a large retail or transport hub |
| Profiling or automated decision-making with significant effects | Automated credit-scoring using sensitive financial data |
| Use of novel or emerging technology | AI-driven diagnostic tools in a health-tech start-up |
| Processing that prevents individuals from exercising rights or using services | Biometric access control as the sole entry method in a large workplace |
| Matching or combining datasets beyond reasonable expectation | Cross-referencing loyalty card data with third-party financial records |
Three concrete Irish examples worth noting:
A national patient data sharing project linking GP records, hospital data, and pharmacy dispensing records would trigger a mandatory DPIA on at least three criteria: special category health data, large-scale processing, and data sharing across multiple controllers. A biometric access control system deployed as the sole entry method in a large Dublin employer would trigger mandatory assessment on the grounds of special category biometric data and systematic monitoring. A fintech SME implementing automated credit-scoring that factors in behavioural data would trigger assessment on profiling and automated decision-making grounds.
Quick screening questions for a project lead:
- Does the processing involve health, biometric, genetic, or other special category data?
- Will it profile individuals or make automated decisions with significant consequences?
- Does it involve large-scale processing or systematic monitoring?
- Does it use technology whose privacy implications are not yet established?
- Will it share data with third parties beyond what individuals would reasonably expect?
Two or more "yes" answers: proceed to a full DPIA. One "yes": consider a DPIA as good practice and document your reasoning either way.

How to conduct a DPIA: a step-by-step process with deliverables and roles
The DPC's sample DPIA template maps to a seven-stage process. Each stage has a tangible deliverable that becomes part of your audit record.
- Identify the need. Confirm that a DPIA is required using the screening criteria above. Deliverable: completed screening record with rationale.
- Describe the processing. Document the nature, scope, context, and purpose of the processing, including a data flow diagram covering collection, use, storage, sharing, retention, and deletion. Deliverable: processing description and data lifecycle diagram.
- Consult stakeholders. Engage the DPO, project lead, IT/security, legal, and where appropriate, data subjects or their representatives. Deliverable: consultation log with dates, participants, and outcomes.
- Assess necessity and proportionality. Confirm that the processing is lawful, that the data collected is limited to what is necessary, and that retention periods are justified. Deliverable: necessity and proportionality assessment.
- Identify and assess risks. For each identified risk, assess likelihood and severity of harm to data subjects. Use a likelihood × severity matrix to produce a risk rating. Deliverable: risk register with ratings.
- Identify mitigations and controls. For each risk, document the technical and organisational measures that will reduce it, assign an owner, and set a target completion date. Deliverable: mitigation plan with assigned owners.
- Sign-off, integrate findings, and schedule review. The DPO provides formal advice; the project lead or senior responsible owner accepts residual risk or escalates to the DPC. Link mitigation tasks to project delivery. Deliverable: signed DPIA report, integration evidence, and review schedule.
Roles matrix
| Role | Responsibility |
|---|---|
| Project lead | Owns the DPIA process; commissions and coordinates inputs |
| DPO | Provides advice, reviews the assessment, signs off |
| IT / security | Describes technical architecture and controls |
| Legal | Confirms lawful basis, contractual obligations, and processor terms |
| Vendor / processor | Provides technical and security documentation |
Pro Tip: Link each mitigation action to a project ticket or GRC task. Require evidence attachments before a ticket is closed. This turns your DPIA from a static document into a living audit trail, and it is exactly what the DPC will look for if they review your records.
A data flow diagram is not optional decoration. The DPC sample template explicitly recommends including one because narrative descriptions routinely miss hidden data flows, third-party sharing, and function creep that a visual lifecycle diagram surfaces immediately.
Making the DPIA audit-ready: records, sign-off, and review
A completed DPIA is only as useful as the evidence that supports it. The following documents should be retained as a minimum:
- Completed screening decision with rationale (even if the conclusion is that a full DPIA is not required)
- Full DPIA report covering all seven stages
- Data flow diagram(s) showing the complete data lifecycle
- Risk register with likelihood and severity ratings for each identified risk
- Mitigation plan with assigned owners, target dates, and completion evidence
- DPO written advice and formal sign-off
- Consultation records (internal and, where applicable, data subject consultation)
- Evidence of implemented controls (configuration records, policy documents, training logs)
Sign-off checklist. Before the DPIA is finalised, confirm:
- The DPO has reviewed the assessment and their advice is recorded in writing.
- Residual risks have been formally accepted by the senior responsible owner or escalated to the DPC.
- All mitigation actions have an assigned owner and a target completion date.
- A monitoring plan is in place to detect changes that would require the DPIA to be updated.
Review timetable and triggers
| Trigger | Action required |
|---|---|
| Significant change to processing scope or purpose | Re-run or substantially update the DPIA |
| New technology introduced into the processing | Update the processing description and risk register |
| New vulnerability or security incident affecting the processing | Review risk ratings and mitigation adequacy |
| Scheduled periodic review (at least annually for high-risk processing) | Full review of all sections; update sign-off log |
| Change in applicable law or DPC guidance | Reassess necessity, proportionality, and lawful basis |
Keeping the DPIA under review is not bureaucratic caution. It is a GDPR accountability obligation, and a DPIA that has never been updated since its original sign-off will draw scrutiny in any DPC audit.
When and how to consult the Data Protection Commission
Prior consultation with the DPC is required under Article 36 GDPR when a DPIA concludes that high risk to data subjects remains after all mitigations have been applied. The EDPB guidelines are clear: if you cannot reduce residual risk to an acceptable level, you must consult before processing begins.
Criteria that typically trigger prior consultation:
- The risk register shows one or more risks rated high after mitigations
- The processing involves novel technology with no established regulatory precedent
- The DPO has advised that residual risk is unacceptable and escalation is required
- The processing falls within a category the DPC has indicated requires consultation
Documents to prepare for a DPC consultation submission:
- Executive summary of the DPIA, including the processing description and purpose
- Full DPIA report with risk register and mitigation plan
- Residual risk analysis explaining why risk cannot be reduced further
- Technical and organisational documentation supporting the mitigation rationale
- Evidence of stakeholder consultations, including DPO advice
- Any relevant processor agreements or technical specifications
The DPC has up to eight weeks to respond to a prior consultation request, extendable by a further six weeks for complex cases. Record the submission date, the DPC's response, and any conditions or recommendations in your project governance log. If the DPC raises concerns, you must address them before processing begins and update the DPIA accordingly.
Official templates and practical DPIA materials
Starting from a regulator-approved template is the fastest way to produce a defensible DPIA. The following resources are the primary references for organisations operating in Ireland.
- EDPB DPIA meta-template: A downloadable template and explainer published by the European Data Protection Board for public consultation and adaptation by national authorities and organisations. Use this as your baseline structure, particularly for cross-border or multi-jurisdictional processing.
- DPC sample DPIA template: The Irish regulator's own template, mapping directly to the seven-stage process described above. This is the primary reference for organisations established or operating in Ireland.
- NHS England universal DPIA template: Designed for health and care data, this template includes a built-in preliminary screening section and guidance on when a full DPIA is required. It is a useful sector reference for Irish health-tech organisations, though it reflects UK governance structures and should be adapted accordingly.
- ICO DPIA guidance: The ICO's DPIA materials cover necessity, proportionality, sign-off, and risk assessment in practical detail. Label this as UK guidance when using it; the principles are broadly consistent with GDPR but the jurisdictional context differs.
When adapting any template, scale the depth of your responses to the complexity and risk level of the processing. A small SME running a single internal HR system needs a proportionate assessment, not a 40-page document. A health-tech company processing patient records at scale needs considerably more rigour, particularly in the risk register and mitigation sections.
A GRC platform that supports DPIAs should provide versioned templates, evidence attachment, risk-register functionality, and audit-ready reporting. These features reduce the manual burden of maintaining DPIA records and make it straightforward to demonstrate compliance during a DPC review. For a broader view of how compliance management software fits into this picture, independent reviews can help you evaluate the options.
Frequent DPIA mistakes and best practices for Irish organisations
The most damaging DPIA errors are not technical. They are process failures that leave organisations unable to demonstrate compliance when it matters.
Common mistakes:
- Treating the DPIA as a sign-off formality completed after the project is already live
- Leaving the entire assessment to the DPO without input from IT, legal, or the project team
- Omitting a data flow diagram, which means hidden data flows and third-party sharing go unidentified
- Failing to record the DPO's written advice or the senior responsible owner's acceptance of residual risk
- Documenting mitigations without assigning owners or target dates, so they never get implemented
- Never updating the DPIA after the initial sign-off, even when the processing changes significantly
Best practice checklist:
- Start the DPIA at project inception, before technical decisions are made
- Involve a multidisciplinary team: project lead, DPO, IT/security, and legal as a minimum
- Include a data lifecycle diagram covering collection through to deletion
- Tie each mitigation to a project task with an assigned owner and a completion deadline
- Record all consultations, including internal disagreements and how they were resolved
- Schedule a review date at sign-off and set calendar reminders or automated triggers in your GRC system
Residual risk rubric
| Risk level | Criteria | Acceptance |
|---|---|---|
| Low | Unlikely to occur; limited impact on data subjects | Acceptable; document rationale |
| Medium | Possible; moderate impact; mitigations in place | Acceptable with monitoring; DPO review recommended |
| High | Likely or severe impact; mitigations insufficient | Not acceptable without further action; consider DPC consultation |
Grading risks consistently across a team requires a shared rubric. Without one, two assessors will rate the same risk differently, and your risk register will be indefensible under scrutiny.
How ShieldIQ helps automate and evidence DPIAs for Irish SMEs
For SMEs without a dedicated compliance team, the documentation burden of a DPIA is often the hardest part. ShieldIQ's GRC platform addresses this directly by providing structured DPIA templates, evidence capture, a standardised risk register, task assignment for mitigation actions, and audit-ready reporting, all within a single platform.
Feature mapping to DPIA stages:
- Automated DPIA templates aligned to the DPC seven-stage process
- Data flow and evidence capture with version control
- Risk register with likelihood and severity ratings, linked to mitigation tasks
- Assignment and tracking of mitigation actions with completion evidence
- Audit-ready reporting exportable for DPC submissions or internal governance reviews
Two SME use cases:
A small Irish health-tech vendor processing patient data for a remote monitoring application used ShieldIQ to complete the DPIA screening, build the risk register, and generate a DPC-ready report in a fraction of the time a manual process would require. The platform's evidence capture meant that every mitigation had an attached configuration record before sign-off.

A fintech SME implementing automated credit-scoring used ShieldIQ's risk register to document profiling risks and link each mitigation to a development sprint ticket. When the DPC requested information during a routine review, the audit report was ready within hours rather than days.
For organisations considering AI-related processing under the EU AI Act, ShieldIQ also supports the overlapping governance requirements that arise when a DPIA intersects with AI system risk classification.
The DPIA as a project discipline, not a compliance checkbox
The organisations that handle DPIAs well share one habit: they treat the assessment as a project discipline rather than a regulatory obligation to discharge. That means the DPO is not the only person in the room. It means the data flow diagram is drawn before the architecture is finalised, not reconstructed from memory after go-live. And it means mitigation tasks appear in the project backlog with owners and deadlines, not in a document that no one revisits.
The regulator templates from the DPC and EDPB are the right starting point. They are structured, proportionate, and designed to produce defensible documentation. For small teams, the practical challenge is not understanding what to do but finding the time and coordination to do it consistently. That is where embedding the DPIA into your project governance, and using a platform that enforces collaborative inputs and tracks evidence, makes the difference between a document and a genuine risk-management record.
Start with the DPC template, assign roles before you begin, and link every mitigation to a tracked task. If you are unsure whether residual risk requires DPC consultation, document your reasoning and ask the DPO to confirm in writing.
ShieldIQ cuts the time from DPIA screening to audit-ready report
Running a compliant DPIA manually across a multidisciplinary team is time-consuming. Coordinating inputs, maintaining version control, tracking mitigation evidence, and producing a report the DPC can actually review takes significant effort, particularly for an SME without a full-time compliance function.

ShieldIQ gives Irish SMEs a faster route from screening to sign-off. The platform provides structured DPIA templates mapped to the DPC's seven-stage process, a risk register with built-in likelihood and severity ratings, task assignment for mitigation actions, and exportable audit reports. Evidence is captured and versioned within the platform, so nothing is lost between project stages. For organisations that need hands-on support, ShieldIQ's consulting services include DPIA preparation, Virtual CISO engagement, and audit-readiness reviews. Other approaches exist, including manual templates and standalone tools, but ShieldIQ is built specifically for SMEs that need audit-ready compliance without a dedicated security team. To see how it works for your organisation, request a demo or contact the team via Shieldiqcyber.
Sources
The following resources are the primary references for organisations conducting DPIAs in Ireland. Download and adapt them before starting any assessment.
- Template for Data Protection Impact Assessment | European Data Protection Board
- What is a DPIA? | ICO
- Data protection impact assessment (DPIA) - NHS England Digital
For organisations managing DPIAs alongside broader compliance frameworks such as NIS2 or ISO 27001, the controls identified in a DPIA mitigation plan will often map directly to obligations under those frameworks, making an integrated GRC approach considerably more efficient than managing each in isolation.
This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.