Risk Management and Impact Assessment in the Processing of Personal Data

Published by

Agencia Española de Protección de Datos (AEPD) — the Spanish supervisory authority

Named by the EDPB

This is Spain's entry in Annex 1 of the EDPB DPIA template Explainer — the method the AEPD points to, listed in both Spanish and English.

Type

Guidance — final (June 2021), 160 pages, 50 tables. English edition. Updates and unifies the AEPD's two March 2018 guides on risk analysis and impact assessments. Creative Commons BY-NC-SA 4.0.

Jurisdiction

Spain (AEPD) — not binding in the UK; ICO guidance remains the UK reference. The methodology is portable: it is built on GDPR Articles 24, 25, 32, 35 and 36, which the UK GDPR carries across in substantially the same form. Spain-specific content is minimal — a one-page subsection on Spain's National Security Framework, plus inline LOPDGDD citations.

Primary audience

DPOs, controllers and processors — anyone who owns DPIA quality and has to defend it

Topic tags

DPIA · risk management · accountability · privacy by design · prior consultation

Availability

Free, aepd.es (English and Spanish). Companion tools free and browser-local: Evalúa-Riesgo RGPD and Gestiona RGPD / Manage GDPR. All 50 tables are also published as a separate editable file (.odt, Spanish only).

Why it matters

DPIAs, in our experience, rarely fail on risk identification. They fail in the mitigations column — and this guide is the most explicit regulator statement of that we have found. Its Table 2 rules that an Article 28 processor contract is “a regulatory compliance obligation, not risk management”, and that an insurance policy “involves risk management of compliance, but not with regard to rights and freedoms” — citing the WP248 Guidelines: “controllers cannot escape their responsibility by covering risks under insurance policies”. It holds that transparency and information obligations under Chapter III of the GDPR, and the servicing of data subject rights, are the compliance floor, not mitigations: “These obligations are part of the controller's compliance requirements and are not measures to mitigate the risk of the processing.” Only measures going beyond what you already owed reduce risk. And it subordinates the security function: “security risk management is one of the activities for the management of risks to rights and freedoms and has to be subordinated to the latter” — the citable answer wherever a DPIA process has been colonised by an ISMS and a likelihood-times-impact spreadsheet scoped to the organisation's own losses. Three moves it makes more sharply than most: very-high-impact, low-likelihood risk must be managed anyway (the illustrations include the CLOUD Act, quantum computing and Brexit); breach likelihood is treated as a function of retention — “when the period of time in which the processing will be active (processing lifecycle) tends to be infinite, a personal data breach is only a matter of time”; and impact must be assessed across entities, because a confidentiality loss at you can enable impersonation at someone else. The commercial point is straightforward. A DPIA is the first artefact a regulator asks for when high-risk processing goes wrong, and its evidential quality decides whether Article 35 reads as a defence or as an admission. Rebuilding the mitigations column against this method costs an afternoon; the guide is free, the tools are free, and the risk-factor catalogue supplies the completeness check — what have we not thought of? — that no template gives you. One porting note: the catalogue draws partly on the AEPD's own Article 35(4) list, so a UK practitioner should substitute the ICO's, or work from the EDPB's register of national lists if the processing is cross-border. Use it alongside the ICO's DPIA guidance, not instead of it — the ICO sets the UK yardstick and the process; the AEPD adds the catalogue, and a rule for what counts as a mitigation. Its control catalogue is built around the privacy-by-design strategies, so it pairs naturally with Norway's privacy-by-design guidance for software development.