How to Conduct a Privacy Impact Assessment

A privacy impact assessment (PIA), often called a DPIA when it follows the GDPR's data protection impact assessment model, is a structured way of identifying and reducing privacy risk before a project goes live. Skip the paperwork framing: if you run it well, it changes what gets built, not just what gets filed.

Why this is worth doing properly

Teams that treat the assessment as a compliance form fill it in after the architecture is fixed, discover a problem nobody can now afford to fix, and either ship the risk anyway or delay the launch. Teams that run the assessment while a project is still a design document get to change the plan for free: drop a field, shorten a retention period, add encryption, or remove a vendor before any contract is signed. The operational payoff is not "we have a document" — it is fewer expensive redesigns and fewer awkward conversations with a regulator or a customer's security team after launch. If your organisation is still deciding when assessments are mandatory versus advisable, the global data privacy fundamentals course covers the legal triggers, and Article 35 of the GDPR sets out when a DPIA is required for EU-relevant processing.

When to trigger one

Not every project needs a full assessment. Reserve the full process for changes that materially alter what data you hold, who can reach it, or what gets decided about people. Concrete triggers worth writing into policy:

• A new system or vendor will hold personal data at meaningful scale.
• An existing dataset gets a new use — particularly profiling, scoring, or automated decisions with legal or similarly significant effect.
• You start processing special category data (health, biometric, criminal, etc.) or data about children.
• You introduce large-scale monitoring of a publicly accessible area or of employees.
• Two datasets get combined or matched in a way that increases what can be inferred about a person.

A short screening questionnaire — five or six yes/no questions mapped to these triggers — lets a project owner self-assess in minutes and escalates only the projects that actually need a full review.

A working method, step by step

1. Describe the processing in plain language. What data, from whom, for what purpose, held for how long, shared with whom. Vague descriptions produce vague risk assessments — insist on specifics before moving on.
2. Map the data flow. Where does data enter, where is it stored, who and what systems can access it, where does it leave the organisation (including sub-processors), and when is it deleted. A simple diagram beats a paragraph here.
3. Identify the risks to individuals, not just to the organisation. Ask what could go wrong for the person whose data this is: wrongful denial of a service, exposure of sensitive facts, discriminatory scoring, re-identification from "anonymised" data, loss of control over their own information.
4. Assess likelihood and severity for each risk, using a simple scale (low/medium/high is enough for most organisations — precision theatre with numeric risk scores rarely improves the decision).
5. Identify mitigations for anything above your risk appetite: minimise the fields collected, shorten retention, add access controls, pseudonymise, get explicit consent, add a human review step before an automated decision is acted on.
6. Decide, document, and assign an owner. Record the residual risk after mitigation and who accepted it. If residual risk remains high and the processing is GDPR-relevant, Article 36 requires prior consultation with the supervisory authority — build that lead time into the project schedule.
7. Set a review trigger. Note what would make you redo the assessment: a new sub-processor, a new use of the same data, a jurisdiction expansion.

A worked example

A 40-person SaaS company wants to add a feature that scores customer support tickets for "churn risk" using a third-party sentiment-analysis API, then flags high-risk accounts to the sales team for proactive outreach.

• Data involved: support ticket text (which may include names, health mentions from customers describing personal circumstances, and other incidental sensitive details), account metadata, usage history.
• New risk introduced: ticket text leaves the company's infrastructure and goes to a third-party API; the score influences how a person is treated (sales outreach, potentially different service); ticket text could incidentally contain special category data typed in by a frustrated customer.
• Mitigation decided: strip free-text fields down to a redacted summary before sending to the API where feasible; add a contractual clause restricting the vendor's retention and reuse of submitted text; exclude tickets flagged as containing health or financial hardship content from the scoring pipeline entirely; cap score retention at 90 days; log every automated flag so a human reviews context before sales contact is made.
• Residual risk: low, accepted by the Head of Product, reviewed again if the vendor changes or the feature expands to a new data source.

This is the kind of decision that is cheap to make on paper and expensive to unwind once the integration is live and sales teams have built workflows around it.

Making it stick across an organisation

A method only works if people outside the privacy team actually use it. Bake the screening questionnaire into whatever intake process product and engineering already use — a ticket field in the project management tool, a checkbox in the design-review template — rather than a separate form that lives on an intranet page nobody visits. Give the questionnaire a fast turnaround promise (same-day triage, full assessment within a set number of business days) so teams don't route around it to hit a launch date. And keep the templates short: a two-page assessment that gets filled in accurately beats a twelve-page one that gets copy-pasted from the last project.

It also helps to keep a running log of past assessments, searchable by system or vendor, so the next team building something similar can start from a precedent instead of a blank page. Over time this log becomes almost as useful as the RoPA itself for answering "have we thought about this risk before."

Where these assessments go wrong

• Running it too late. By the time engineering has built the feature, "redesign the data flow" is not a realistic recommendation, so the assessment becomes a rubber stamp.
• Writing it for the file, not the decision. Long documents that restate the privacy policy but never name a specific mitigation are worse than no assessment, because they create a false sense of diligence.
• No named owner for residual risk. If nobody's name is attached to "we accepted this risk," the assessment has no teeth.
• Treating it as one-and-done. Vendors change sub-processors, features get extended to new markets, and the original assessment quietly stops matching reality.
• Ignoring low-tech triggers. Assessments get associated with "new software," but a new physical access control system with cameras or a new use of an existing customer list for a marketing campaign can trigger the same obligations.

Do this next

• Write (or adopt) a short screening questionnaire so project owners can self-identify when a full assessment is needed.
• Build the assessment step into your project or change-management process, not into a separate compliance calendar nobody checks.
• Use a standard template with the seven steps above so assessments are comparable across projects and easy to audit later.
• Assign an accountable owner for every residual risk decision, by name.
• Revisit assessments when the underlying processing changes, not on an arbitrary annual cycle only.
• If you are building this process from scratch, the practical privacy program implementation course walks through embedding assessments into existing product workflows, and the assessment can help you benchmark where your current process stands.

Official sources and further reading

• GDPR Article 35 — Data protection impact assessment
• GDPR Article 36 — Prior consultation

This article explains a general operational method and does not constitute legal advice; whether a DPIA is legally required for your specific processing depends on your jurisdiction and facts, so confirm applicability with qualified counsel where it matters.