GDPR DPIA Template: A Data Protection Impact Assessment an SMB Can Fill
GDPR DPIA Template: A Data Protection Impact Assessment an SMB Can Fill
A DPIA is the document that forces you to think through a high-risk processing operation before you switch it on, not after a data subject complains. Under GDPR Article 35 it is mandatory for a defined set of processing — and the trigger list is broader than most SMBs assume. Skip it for a processing operation that needed one and the operation is non-compliant regardless of how well it runs.
A Data Protection Impact Assessment (DPIA) is a structured assessment of the impact of a envisaged processing operation on the protection of personal data, performed before the processing begins. Where the Article 30 RoPA records what you process, the DPIA assesses whether a specific high-risk activity is necessary, proportionate, and adequately safeguarded. It is the GDPR analog of a security risk assessment — narrower in scope (personal-data impact only) and required at a defined trigger threshold.
The required-content elements below reflect the public text of GDPR Article 35 (in particular Article 35(7)) and the canon’s summary of the triggers. Confirm against the official EUR-Lex text and the Article 29 Working Party / EDPB DPIA guidelines before relying on a specific point operationally.
When a DPIA is required
Article 35 mandates a DPIA where processing is likely to result in a high risk to the rights and freedoms of data subjects, in particular when using new technologies. The canon names the trigger cases explicitly:
- **Systematic and extensive profiling** with significant effects on the data subject.
- **Large-scale processing of special categories of data** (Article 9) or data relating to criminal convictions and offences (Article 10).
- **Systematic monitoring of publicly accessible places** on a large scale.
- The national supervisory authority’s published list of processing operations that require a DPIA — check your local DPA’s list.
- The canon’s worked examples: **geo-tracking of employees**, **processing employee trade-union membership**, and generally introducing new technologies or software that process employees’ personal data.
The “high risk” threshold is lower than it reads. An SMB running customer profiling for churn prediction, deploying an AI model on customer data (see GDPR and AI training data), introducing employee monitoring, or processing health-adjacent data likely crosses the line. The default is to run the DPIA; the cost of an unnecessary DPIA is a few hours, the cost of a missing one is a non-compliant operation.
The Article 30(5) documentation exemption does not apply to the DPIA — a small organisation processing high-risk data still needs one.
What a DPIA must contain (Article 35(7))
The regulation specifies the required content. A compliant DPIA includes:
1. A systematic description of the envisaged processing operations and the scope of the processing — what data, whose, where, how, the flows. 2. An assessment of the necessity and proportionality of the processing in relation to the purposes — why this processing, why this much data, why this retention, whether a less intrusive approach achieves the purpose. 3. An assessment of the risks to the rights and freedoms of data subjects — what could go wrong for the people whose data is processed. 4. The measures envisaged to address the risks — safeguards, security measures, and mechanisms to ensure the protection of personal data and to demonstrate compliance, taking into account the rights and legitimate interests of data subjects and others.
Two procedural elements complete it: seeking the views of data subjects or their representatives where appropriate (the canon is explicit that works councils and staff representatives may have a role), and the DPO’s advice on how to reduce the risks. The DPO’s advice is recorded; the DPO does not decide, the controller does.
The trigger: consult the authority on residual high risk
If, after the DPIA, the controller identifies high risk that cannot be mitigated, Article 36 requires prior consultation with the supervisory authority before starting the processing. The DPIA is the document the authority consults. Most SMB DPIAs identify mitigatable risk and stop at the DPIA; the unmitigatable high-risk path is rare but is the reason the DPIA exists as a gate.
The template
One DPIA per high-risk processing operation. Use the structure below.
| Section | What goes in it |
|---|---|
| 1. Processing description | The activity, data categories, data subjects, sources, recipients, transfers, retention, tech used. (Pull from the RoPA row.) |
| 2. Purpose & lawful basis | The specific purpose; the Article 6 basis (and Article 9 condition if special-category); the legitimate interest pursued if applicable. |
| 3. Necessity & proportionality | Why this processing achieves the purpose; why these data categories; why this retention; what less-intrusive alternatives were considered and rejected. |
| 4. Risks to data subjects | The identified risks — re-identification, discrimination, unauthorised access, excessive retention, function creep, loss of autonomy. Each with likelihood + severity. |
| 5. Mitigations | Per risk: the safeguard, security measure, or mechanism that addresses it. Residual risk after mitigation. |
| 6. Data subject views | How data subjects (or their representatives) were consulted, or the justification for not consulting. |
| 7. DPO advice | The DPO’s recommendation on risk reduction, recorded. |
| 8. Decision & date | Controller’s decision to proceed / proceed with mitigations / not proceed; date; owner; review date. |
A worked example: SMB employee geolocation
An SMB wants to enable GPS tracking on company phones to verify field-staff time sheets. The DPIA:
| Section | Entry |
|---|---|
| 1. Processing description | Continuous GPS collection from company-issued phones of 12 field technicians, during working hours only. Data: location, timestamp, device ID. Stored in the MDM console, 90-day retention. No off-hours collection. Recipients: operations manager. No third-country transfer. |
| 2. Purpose & lawful basis | Purpose: verify time-sheet accuracy for billing. Basis: legitimate interests (Article 6(1)(f)) — accurate billing; balanced against employee privacy. Not special-category unless location reveals health/religion sites (assessed below). |
| 3. Necessity & proportionality | Necessity: billing disputes cost ~4h/week; GPS verification reduces this. Alternatives considered: self-reported time sheets with spot-checks (less intrusive, kept as fallback for low-dispute accounts); clock-in app at job sites (rejected — no site hardware). Proportionality: working-hours-only window, 90-day retention, no off-hours data, no behaviour analysis. |
| 4. Risks | Re-identification of home/location patterns (M, low-med severity — mitigated by working-hours-only); function creep — manager using data for performance monitoring beyond billing (M, severity med — mitigated by purpose-binding in policy); secondary inference — location revealing health/religious visits (L-M, severity high — mitigated by working-hours-only + no off-hours data + no inference features). |
| 5. Mitigations | Working-hours-only collection enforced at MDM policy level; 90-day auto-deletion; access restricted to operations manager for billing purpose only; purpose-binding policy signed by manager; no analytics or inference features enabled; documented prohibition on cross-referencing with HR data. Residual: low. |
| 6. Data subject views | Consulted staff at team meeting; concern raised about off-hours tracking — addressed by working-hours-only policy; concern about manager over-reach — addressed by purpose-binding. Works council (if applicable) consulted. |
| 7. DPO advice | DPO advises adding a monthly access-log review for the MDM console and an annual policy review. Recorded. |
| 8. Decision & date | Proceed with mitigations. Owner: Operations Manager. Review date: 12 months or on change of scope. Date: [date]. |
The entry is a few pages. It describes the processing, justifies it against less-intrusive alternatives, names the risks and the mitigations, records the staff consultation and the DPO advice, and sets a review date. An authority reading it sees the controller thought through the operation before switching it on.
Three mistakes to avoid
- **DPIA after go-live.** The assessment is "before any processing" — the canon is explicit. A post-hoc DPIA is a non-compliance record, not a compliance document.
- **DPIA as risk-register copy-paste.** The DPIA is about impact on data subjects’ rights, not the organisation’s risk. "Risk of fines" is not a DPIA risk; "risk of re-identification of health-adjacent location data" is.
- **No data-subject views, no DPO advice.** Both are procedural requirements. Document the consultation (or the justification for not consulting) and record the DPO advice even if it is "no further mitigation recommended."
The link to the rest of the GDPR program
The DPIA starts from the RoPA — the processing description (section 1) is the RoPA row expanded. It feeds the data subject rights and 72-hour breach clock — the risks section 4 identifies are the breach scenarios the 72-hour runbook should cover. It overlaps the AI cluster: an AI training or deployment operation that triggers Article 22 needs both this DPIA and the GDPR + AI training data analysis. If you run ISO 27001, the DPIA’s security measures (section 5) are the GDPR-facing view of the ISMS controls — see the ISO 27001 joint implementation. If you run ISO 42001, the DPIA folds into the AI system impact assessment — one analysis, two reports.
How this fits the series
This is the use-case companion to the GDPR pillar, the third artifact after the RoPA and the data subject rights / 72-hour clock. It is the operational endpoint the AI training data article sends you to. The ISO 27001 joint implementation is the cross-pillar thread.
What to do next
Walk your RoPA and flag any activity that clears a trigger (profiling, large-scale special-category, systematic monitoring, employee tracking, AI on personal data). For each flagged activity, fill the eight-section template above — pull section 1 from the RoPA row, work necessity and proportionality honestly, name the risks to data subjects, document the mitigations, consult the affected people, record the DPO advice, and set a review date. A DPIA you write before go-live is a few hours; a DPIA you write after an authority asks is the operation suspended.
Want a review of your DPIA against the Article 35(7) elements? Book a 30-minute **GDPR applicability assessment** — we check your trigger flagging against your RoPA, pressure-test the necessity/proportionality reasoning, and confirm the residual-risk mitigations will hold. Bilingual EN/FR, no obligation.
→ /contact · download the GDPR for SMBs readiness guide
Get Your Free Security Readiness Assessment
Map your controls, identify compliance gaps, and secure your systems before the audit.