From its opening recitals through to the specific obligations in Article 35, GDPR is structured around risk. It expects organisations to understand the risks their data processing creates for individuals, to demonstrate they have assessed those risks proportionately, and to make documented, defensible decisions about how to manage them. An organisation that can produce a privacy policy but cannot explain how it decided that policy was appropriate has understood the compliance surface of GDPR without the substance beneath it.
This guide covers what the risk-based approach to GDPR actually requires in practice.
Article 5(2) of GDPR contains the accountability principle: the controller is responsible for, and must be able to demonstrate compliance with, the data protection principles.
The word "demonstrate" is doing a great deal of work here. It means that compliance is not just a state the organisation must achieve. It is a position the organisation must be able to evidence, with documented reasoning showing that decisions about data processing were made deliberately and with proper consideration of the risks involved.
A generic privacy notice copied from a template does not demonstrate accountability. A data protection policy that has not been reviewed since 2018 does not demonstrate accountability. What demonstrates accountability is a documented, reasoned decision-making trail: evidence that the organisation understood what it was doing with personal data, assessed the risks involved, applied appropriate technical and organisational measures, and revisited those decisions as circumstances changed.
The practical implication is that GDPR compliance requires governance infrastructure, not just documents. The organisation needs processes for identifying new processing activities, assessing their risk implications, implementing appropriate controls, and maintaining records that substantiate the decisions made.
Article 30 requires most organisations to maintain a record of processing activities (ROPA). This is the foundational inventory through which everything else in the compliance programme connects.
The ROPA should document, for each significant processing activity: the name of the processing activity and its purpose, the categories of personal data involved, the categories of data subjects affected, any third parties to whom data is disclosed, any transfers to countries outside the UK or EU, the retention periods applied, and a description of the technical and organisational security measures in place.
Building the ROPA is genuinely substantive work. Most organisations, when they map their processing activities systematically for the first time, discover processing they were not aware of, data sharing with third parties that was never formally documented, and retention practices that vary significantly from what the policy states.
The ROPA is also not a one-time exercise. New processing activities, changes to existing ones, new suppliers, and new data sharing arrangements all require the ROPA to be updated. An accurate, current ROPA is one of the clearest signals to a regulator or auditor that an organisation is actively managing its data protection obligations rather than treating them as a historical compliance exercise.
Before any personal data is processed, there must be a lawful basis. The six lawful bases available under Article 6 are: consent, contract performance, legal obligation, vital interests, public task, and legitimate interests.
Choosing the right lawful basis is not simply a matter of selecting whichever is most convenient. The choice has real operational and rights implications. Consent, for example, must be freely given, specific, informed, and unambiguous, and can be withdrawn at any time. Relying on consent for processing that people cannot reasonably refuse is not valid consent under GDPR.
Legitimate interests, the most flexible basis, requires a three-part assessment: the legitimate interest being pursued must be identified, processing must be necessary to achieve it, and the interest must not be overridden by the rights and interests of the data subjects involved. This assessment must be documented.
A common and significant error is treating the same data under different lawful bases for different purposes, without clearly documenting which basis applies to which processing purpose, or switching basis after processing has begun because the original one is no longer convenient.
Article 35 requires a Data Protection Impact Assessment (DPIA) before beginning any processing likely to result in high risk to the rights and freedoms of individuals. The ICO's guidance makes clear this is not optional for high-risk processing: it is a legal requirement.
A DPIA is a structured risk assessment process applied to a specific processing activity. It should describe the processing and its purposes, assess necessity and proportionality, identify and assess the risks to individuals, and document the measures taken to address those risks. The outcome is not a certification that the processing is safe. It is a documented, reasoned decision about whether the residual risks after controls are proportionate and acceptable.
Three categories of processing require a DPIA automatically: systematic and extensive profiling with significant effects on individuals; processing of special category data on a large scale; and systematic monitoring of publicly accessible places on a large scale. Beyond these explicit triggers, organisations must exercise their own judgment about when the risk profile of a processing activity warrants a DPIA.
The ICO's clear advice is that when there is genuine uncertainty, the assessment should be conducted. The cost of an unnecessary DPIA is some professional time. The cost of failing to conduct one when it was required, particularly if something subsequently goes wrong and the regulator asks to see it, is considerably higher.
A robust DPIA addresses six questions in detail.
What is the processing activity and why is it being undertaken? What personal data is involved, and who are the data subjects?
Is the processing necessary for the purpose, and could the purpose be achieved with less data or less intrusive means?
What are the risks to individuals? These include physical, psychological, financial, reputational, and social risks. They should be assessed for both likelihood and severity.
What controls are in place or planned to address those risks? This should be specific: not "appropriate security measures" but the actual technical and organisational measures, with enough detail to assess whether they are adequate for the risk level identified.
What is the residual risk after controls? Is it acceptable given the purpose of the processing?
Where residual risk remains high, has the ICO been consulted? Article 36 requires prior consultation with the supervisory authority where a DPIA indicates high residual risk that cannot be mitigated.
Many organisations are required to appoint a Data Protection Officer. The obligation applies to public authorities, organisations that carry out large-scale systematic monitoring of individuals as a core activity, and organisations that process special category data on a large scale as a core activity.
The DPO role has specific characteristics that distinguish it from a conventional compliance or legal function. The DPO must be given genuine independence to perform their tasks, must be provided with resources to do so, and must not receive instructions in the exercise of their tasks. A nominal DPO with no authority or resource is not compliant with Article 37 to 39.
The DPO's responsibilities include advising on GDPR obligations, monitoring compliance, advising on DPIAs, and acting as the contact point for the supervisory authority. Whether the DPO is an internal appointment or an external appointment, the responsibilities attach to the role.
GDPR requires notification of personal data breaches to the supervisory authority within 72 hours of becoming aware, unless the breach is unlikely to result in risk to the rights and freedoms of individuals. Where the breach is likely to result in high risk, individuals must also be notified without undue delay.
The 72-hour clock runs from when the organisation becomes aware of the breach, not when the breach occurred. This means the ability to identify a breach quickly, assess its risk implications, and notify the ICO is not a process that can be improvised. It requires documented procedures, clear internal escalation paths, and people who know what to do when a potential breach is identified.
A practical readiness test: could your organisation identify a data breach today, assess its likely risk implications, escalate it to the right decision-makers, and file a notification with the ICO, all within 72 hours? For organisations that have never tested this, the honest answer is often that it would be extremely difficult.
DPIA findings should not sit in a separate data protection folder, disconnected from the organisation's broader risk management activity. A significant data protection risk identified through a DPIA is an organisational risk and deserves visibility within the same risk register, governance structures, and board reporting that any other material risk would receive.
This integration matters for several reasons. The board needs to understand material data protection risks to exercise effective governance. Management decisions about accepting high residual data protection risks should go through the same decision-making processes as other material risk acceptance decisions. And when regulators ask how an organisation decided that a particular high-risk processing activity was justified, the answer is more credible when it sits within a coherent, documented risk governance framework rather than as an isolated data protection record.
The risk function and the data protection function are addressing overlapping territory. Processing activities that create high risk to individuals often create corresponding regulatory, operational, and reputational risk to the organisation. Managing these separately, with no structural connection between the two risk pictures, produces a less complete view than either function needs.
References
