How to Conduct a DPIA: A Step-by-Step Guide for SaaS Founders

What is a DPIA and why does it matter?

A Data Protection Impact Assessment (DPIA) is a structured process for identifying and minimising privacy risks before you start processing personal data. Under GDPR Article 35, a DPIA is legally required before you begin any processing that is likely to result in a high risk to the rights and freedoms of natural persons.

DPIAs are not optional box-ticking. The European Data Protection Board (EDPB) has consistently found that failure to conduct a DPIA when required is itself a violation of GDPR — and supervisory authorities have issued fines for this alone, separate from any underlying data protection failure.

For SaaS founders, the good news is that most standard B2B SaaS processing doesn't require a DPIA. The challenging news is that as you add AI features, behavioural profiling, large-scale analytics, or process special category data, the threshold gets crossed quickly.

When is a DPIA mandatory?

Article 35(1) GDPR states that a DPIA is required when processing is "likely to result in a high risk". The EDPB has published guidance (WP248) identifying nine criteria — if you meet two or more, a DPIA is required:

Evaluation or scoring — including profiling, credit scoring, health prediction, or performance assessment
Automated decision-making with legal or similarly significant effect — any Art. 22 processing
Systematic monitoring — tracking or observing data subjects in a systematic way, including tracking via apps or analytics
Sensitive data or data of a highly personal nature — health, biometric, location, financial, children's data, criminal records
Data processed on a large scale — the EDPB considers scale by number of subjects, volume, geographic spread, and duration
Matching or combining datasets — linking data from different sources in a way subjects wouldn't expect
Data concerning vulnerable subjects — children, employees, patients, elderly
Innovative use or applying new technological or organisational solutions — AI, IoT, facial recognition, new data sources
When the processing itself prevents data subjects from exercising a right or accessing a service

Additionally, Article 35(3) identifies three types of processing that always require a DPIA: (a) systematic and extensive evaluation of natural persons based on automated processing, including profiling; (b) large-scale processing of special category data (Art. 9) or criminal data (Art. 10); and (c) systematic monitoring of a publicly accessible area on a large scale.

Supervisory authorities also publish national lists of processing types that always require a DPIA in their jurisdiction. If your DPA has published such a list, check it.

When is a DPIA NOT required?

The GDPR carves out an exception: if processing is very similar to processing for which a DPIA has already been conducted, a new DPIA is not required. Supervisory authorities may also publish lists of processing operations that do not require a DPIA.

Typical SaaS processing that generally doesn't require a DPIA:

User authentication (username/password, email verification)
Standard B2B contact management
Basic transactional email (receipts, notifications)
Aggregate analytics with no individual profiling
Standard internal HR processes with small numbers of employees

If you're genuinely unsure, err on the side of conducting one. A DPIA is also a useful internal governance tool even when not legally required — it documents your risk thinking and helps with Art. 30 Records of Processing Activities.

The eight-step DPIA process

The EDPB's guidance and ICO's code of practice define a standard DPIA process. Here's a practical version for SaaS:

Step 1: Identify the need for a DPIA

Before starting any new processing activity, feature, or integration, run through the nine EDPB criteria above. This can be a lightweight checklist — 15 minutes with the product and engineering team. Document the outcome: either "DPIA not required" with your reasoning, or "DPIA required" with which criteria triggered it.

This screening step is itself a GDPR obligation. The absence of any documented screening is a red flag for auditors.

Step 2: Describe the processing

Write a clear, factual description of the processing activity:

What data you collect, from whom, and how
What you do with it (processing operations)
Who has access to it (internal teams, third-party processors)
Where it's stored and for how long
Any international transfers and the safeguard used

This section forms the factual foundation of your DPIA. Be specific. "We use AI to analyse" is not sufficient — you need to describe what data goes in, what the AI does, what output it produces, and how that output is used.

Step 3: Assess necessity and proportionality

For each processing operation, ask:

Is this processing necessary for the stated purpose? Could you achieve the same outcome with less data or less intrusive means?
Is the lawful basis valid for this type of processing? (Consent is often the wrong basis for profiling — legitimate interests or contract are more common for SaaS.)
If processing special category data (Art. 9), what Art. 9(2) exception applies?
Is the data minimised? Are you collecting only what you actually need?
Is the retention period proportionate? Data shouldn't be kept indefinitely "just in case".

Step 4: Identify and assess risks

This is the core of the DPIA. For each identified risk, assess:

Nature of the risk: what could go wrong? (unauthorised access, excessive processing, discrimination, financial harm, etc.)
Likelihood: how probable is this risk materialising? (Low / Medium / High)
Severity: what is the impact on data subjects if it does? (Low / Medium / High / Critical)

The GDPR frames risk in terms of impact on individuals, not on the company. A data breach is a risk to data subjects (identity theft, financial loss, reputational damage), not just a business risk. Frame your risk assessment accordingly.

Typical risks for SaaS to consider:

Unauthorised access to personal data (external attacker, misconfigured access control)
Accidental disclosure to wrong recipient
Excessive data collection beyond the stated purpose ("function creep")
Discriminatory or inaccurate automated decisions
Sub-processor breach or data residency violation
Inability of data subjects to exercise their rights

Step 5: Identify safeguards and mitigating measures

For each risk, identify the technical and organisational measures (TOMs) that reduce either the likelihood of the risk materialising or the severity of the impact if it does. Examples:

Encryption at rest and in transit → reduces severity of breach
RBAC with least-privilege access → reduces likelihood of insider access
Data minimisation → reduces scope of impact if breach occurs
Human oversight of automated decisions → reduces discrimination risk
Retention enforcement → reduces ongoing exposure
Staff privacy training → reduces accidental disclosure risk

After applying safeguards, assess the residual risk — the risk that remains after mitigating measures are in place. The goal is not zero risk (impossible) but acceptable residual risk.

Step 6: Consult stakeholders

The GDPR requires you to seek the advice of your DPO (if you have one) and, where appropriate, the views of data subjects or their representatives. In practice for early-stage SaaS, this often means:

DPO / privacy consultant review of the draft DPIA
Engineering and security team review of the technical sections
Legal counsel review if the processing is novel or the risks are high

User consultation is more relevant for consumer products with vulnerable subjects — for standard B2B SaaS, internal review is usually sufficient.

Step 7: Decide whether to proceed and document the decision

Based on the residual risk assessment, the controller must decide one of three things:

Proceed: residual risks are acceptable and safeguards are in place
Proceed with additional measures: residual risks are borderline — list the additional measures required before go-live
Prior consultation required (Art. 36): residual risk is high and cannot be mitigated — you must consult your supervisory authority before proceeding

Art. 36 consultation is rare in practice. It's triggered when the DPIA shows a high risk that the controller cannot mitigate. The DPA then has 8 weeks (extendable by 6 weeks) to advise. If you find yourself here, get a lawyer involved.

Step 8: Document, sign off, and schedule a review

A completed DPIA must be:

Signed off by the project owner and DPO
Retained as part of your Art. 30 documentation
Reviewed whenever there is a material change to the processing
Reviewed periodically (annually or every two years is common)

The GDPR doesn't require you to submit DPIAs to your supervisory authority (unless Art. 36 consultation is triggered), but they must be available on request during an audit or investigation.

What a DPIA must contain (Art. 35(7))

Article 35(7) specifies the minimum content of a DPIA:

A systematic description of the envisaged processing operations and the purposes of the processing, including where applicable the legitimate interest pursued
An assessment of the necessity and proportionality of the processing in relation to the purposes
An assessment of the risks to the rights and freedoms of data subjects
The measures envisaged to address the risks, including safeguards, security measures, and mechanisms to ensure protection of personal data

Everything else — the format, section structure, level of detail — is up to you. A DPIA can be a two-page internal memo or a 40-page formal document depending on the complexity and risk of the processing.

Common DPIA mistakes that lead to enforcement action

Not doing one when required: The most common and most expensive mistake. DPAs have issued fines specifically for this.
Doing it after the fact: A DPIA must be conducted before the processing begins, not after. A retrospective DPIA has limited value for enforcement purposes.
Generic copy-paste risk lists: Risks must be specific to your actual processing. Generic templates without contextualisation are a red flag for auditors.
Not documenting the residual risk decision: The point of a DPIA is the decision. If there's no documented conclusion, there's no DPIA.
Not reviewing after material changes: A DPIA for v1 of a feature doesn't cover v3. Material changes (new data types, new processors, new purposes) trigger a review obligation.

Generate your DPIA now

A proper DPIA takes time to get right — but having a solid starting point matters. ComplyKit's DPIA Template Generator walks you through the key inputs (project description, data categories, triggers, risks, safeguards) and generates a structured DPIA document you can review with your legal team. Free, no account required.

👉 DPIA Template Generator — Art. 35 compliant, risk table included, DPA consultation check
👉 Privacy Policy Generator — your public-facing GDPR disclosure
👉 GDPR Data Processing Agreement — required before data goes to a processor
👉 DPIA Guide for SaaS Founders — when a DPIA is required and the EDPB 9-criteria test

Key takeaways

A DPIA is legally required (not optional) before any high-risk processing under GDPR Art. 35.
Meet two of the EDPB's nine criteria → DPIA is required. No documentation of screening = a compliance gap.
The DPIA must be conducted before processing begins, not retrospectively.
Art. 36 prior consultation (with your DPA) is only required when residual risk is high and cannot be mitigated — this is rare.
DPIAs must be reviewed after material changes and retained as part of Art. 30 documentation.