GDPR risk assessment is one of those obligations that exists in the documentation of almost every organisation — but in practice tends to be performed once, without updates and without any real connection to actual data processing activities. The result is a document that satisfies a formal requirement but protects neither the organisation nor the individuals whose data is processed.
GDPR does not prescribe a single specific methodology. It does, however, require that the approach to risk be adequate, documented and linked to real processing activities. This article explains how to achieve that in practice.
What is GDPR risk assessment and why is it mandatory
Risk assessment is the process of identifying, evaluating and managing threats related to the processing of personal data. Its purpose is to determine which events could violate the rights and freedoms of individuals, and to implement proportionate safeguards.
The obligation to conduct risk assessment flows directly from Article 32 GDPR, which requires controllers to implement technical and organisational measures appropriate to the level of risk. Controllers must be able to demonstrate that those measures were chosen deliberately — on the basis of risk assessment, not arbitrarily.
Additionally, the accountability principle under Article 5(2) GDPR requires controllers not only to comply with the rules but to be able to prove it. Risk assessment is one of the key pieces of evidence during supervisory authority inspections.
When to conduct a risk assessment
Risk assessment is not a one-time project — it is a continuous process. It should be conducted or updated:
- when new processing activities are introduced,
- when significant changes occur in existing processes (new IT system, new supplier, change of purpose),
- on a regular basis — as part of ongoing GDPR management,
- before commencing high-risk processing — in which case a full DPIA is required,
- after a personal data breach — as part of learning from incidents.
In practice, every processing activity in the record of processing activities should have an associated risk assessment. Without it, the record is incomplete.
Two levels of risk assessment under GDPR — PIA and DPIA
In practice, risk assessment under GDPR operates at two levels, depending on the nature of the processing:
PIA — Privacy Impact Assessment
A standard risk assessment conducted for each processing activity. Its purpose is to determine the level of risk and select appropriate safeguards. It covers identification of threats, assessment of their likelihood and impact, and definition of remedial actions. PIA also answers the question of whether the activity requires a deeper analysis — that is, a full DPIA.
DPIA — Data Protection Impact Assessment
An in-depth assessment required for high-risk processing. It is more detailed than a PIA and requires documented description of the processing operations, assessment of necessity and proportionality, detailed risk analysis, and consultation with the DPO.
When is a DPIA mandatory
A DPIA is required whenever processing is likely to result in a high risk to the rights and freedoms of individuals. Supervisory authorities identify several typical situations:
- systematic, comprehensive assessment of personal aspects based on automated processing, including profiling,
- large-scale processing of special categories of data (health, biometric, genetic),
- systematic monitoring of publicly accessible areas on a large scale (e.g. CCTV surveillance),
- new technologies whose privacy implications are not yet fully understood,
- processing of data of vulnerable individuals (children, employees, patients).
If the PIA indicates high risk — a DPIA is mandatory before processing commences. Conducting a DPIA after the fact does not satisfy GDPR requirements.
How to conduct a risk assessment step by step
Step 1 — Identify the processing activity
Define what the assessment relates to. Specify:
- the name and purpose of the processing activity,
- what personal data is processed and whose data it concerns,
- which systems, tools and individuals are involved,
- where the data originates and to whom it is transferred.
The more precise the description of the process, the more accurate the risk assessment. Errors at this step carry through to all subsequent steps.
Step 2 — Identify threats
Identify events that could negatively affect the security of processing. Typical threat categories are:
- confidentiality — unauthorised access, data leakage, phishing,
- integrity — incorrect modification, deliberate falsification of data,
- availability — data loss, system failure, ransomware attack.
For each threat, identify the possible source — human error, external attack, technical failure, or internal action.
Step 3 — Assess impact
For each identified threat, assess the potential consequences for individuals if the threat materialises:
- low impact — minor inconvenience, no lasting consequences,
- medium impact — financial damage, discrimination, restriction of rights,
- high impact — serious financial harm, threat to health or life, reputational damage.
Step 4 — Assess likelihood
Evaluate how realistic the occurrence of each threat is given the current safeguards in place:
- low — unlikely, well protected,
- medium — possible, partial safeguards in place,
- high — realistic threat, no or weak safeguards.
Step 5 — Risk matrix
Combine the impact assessment with the likelihood assessment and determine the overall risk level. A typical 3×3 matrix produces nine combinations mapping to three levels:
- low risk — acceptable given current safeguards,
- medium risk — requires remedial action within a defined timeframe,
- high risk — requires immediate action; if the risk cannot be reduced — prior consultation with the supervisory authority is required before processing commences.
Step 6 — Risk-mitigating actions
For each medium or high risk, define:
- specific technical or organisational measures (encryption, pseudonymisation, access restriction, training),
- the person responsible for implementation,
- the implementation deadline,
- the residual risk level after measures are applied.
Step 7 — Documentation and updates
The results of the risk assessment must be documented — both the assessment itself and the actions taken. Documentation must be updated whenever a significant change occurs in the processing activity.
LIA — Legitimate Interest Assessment
Where the legal basis for processing is the controller’s legitimate interest under Article 6(1)(f) GDPR, a Legitimate Interest Assessment (LIA) must be conducted before relying on that basis. The LIA is a three-step test examining whether the controller’s interest is genuine and legally justified, whether processing is necessary to pursue it, and whether the interests and rights of the data subject do not override those of the controller. The outcome must be documented.
A detailed discussion of LIA and all six legal bases is available in the article on legal bases for processing personal data.
Most common mistakes in GDPR risk assessment
One-off assessment with no updates. A risk assessment conducted at GDPR implementation and never revisited does not reflect the current state of the organisation. New systems, new suppliers, new processes all require a fresh assessment.
No link to the record of processing activities. Risk assessment conducted in isolation from the record is of limited value. Every processing activity in the record should have an associated risk assessment.
No risk matrix or subjective scoring. Without a standardised methodology, each person assesses risk differently. A risk matrix ensures consistency and comparability across activities.
Overly generic threat descriptions. “Unauthorised access” is a threat, but too general to drive concrete action. Good risk assessment identifies specific threat vectors.
DPIA conducted after the fact. A Data Protection Impact Assessment must be completed before high-risk processing commences. Conducting it after launch violates GDPR.
Risk assessment in iGDPR — how it works in practice
iGDPR includes a dedicated risk assessment module, which guides users through the entire process in a structured way. For each processing activity you can conduct a PIA, a full DPIA, and a LIA — all within one system, using predefined criteria and weightings that can be customised to your organisation.
Once approved, each assessment becomes an official document that can be downloaded as a PDF. All assessments are linked to the record of processing activities — a change in a process automatically signals the need for an updated assessment.
Summary
GDPR risk assessment is not a one-time implementation task — it is part of ongoing data protection management. Conducted properly, it protects individuals, prepares the organisation for supervisory inspections and supports informed decisions about safeguards.
Key principles:
- every processing activity requires a risk assessment linked to the record of processing activities,
- DPIA must precede high-risk processing — not follow it,
- a risk matrix ensures consistency and objectivity across assessments,
- risk assessment must be updated whenever a significant change occurs,
- assessment results must be documented and available for inspection.
Frequently asked questions about GDPR risk assessment
Yes — the obligation flows from Article 32 GDPR and applies to all data controllers, regardless of the size of the organisation. The scope and detail of the assessment should be proportionate to the scale and nature of the processing.
A PIA (Privacy Impact Assessment) is a standard risk assessment conducted for every processing activity. A DPIA (Data Protection Impact Assessment) is a more detailed assessment required only for high-risk processing — it is more comprehensive and requires consultation with the DPO.
Risk assessments should be updated whenever a significant change occurs in the processing activity — a new IT system, a new supplier, a change in purpose or scope. A periodic review, at least once a year, is also recommended.
Always before. A DPIA must be completed before the organisation commences high-risk processing. Conducting it after the fact violates GDPR and does not protect the controller from liability.
The absence of a risk assessment violates the accountability principle under Article 5 GDPR. Supervisory authorities can impose administrative fines, and during inspections the lack of risk assessment documentation is one of the first findings raised.
A LIA (Legitimate Interest Assessment) is required when the legal basis for processing is Article 6(1)(f) GDPR. It must be conducted and documented before relying on legitimate interest as the legal basis.
Conduct GDPR risk assessments in a structured system — not in spreadsheets
iGDPR includes a dedicated risk assessment module with built-in methodology for PIA, DPIA and LIA. Every assessment is linked to the record of processing activities, generates a PDF document and signals the need for updates when processes change. See how it works in practice.
START FREE TRIAL — 21 days, no commitment





