A privacy impact assessment is a documented analysis of what a processing operation will do to the people whose data it uses, and the reason most of them fail has nothing to do with writing quality. They get produced after the system is built, when no finding can still change a design decision. Article 35(1) of the General Data Protection Regulation requires the assessment before the processing begins, and Article 35(7) fixes four contents it has to carry. The steps below follow that sequence, from a recorded screening decision through risk scoring to a formal sign-off, and the template is built backwards from Article 35(7) so every field maps to a provision rather than to a vendor’s house style.<\/p>\n
This article sets out when a privacy impact assessment is required, the steps in order, and the template fields that survive scrutiny.<\/p>\n
Three failure modes account for most rejected assessments, and none of them is a drafting problem. The first is the timing above: a document written in the week before launch, describing choices locked months earlier. The second is treating the whole thing as the data protection officer’s homework, which misreads Article 35(2). That provision makes the controller responsible for ensuring the assessment happens and casts the DPO as adviser, not author.<\/p>\n
The third is subtler, and it is the mistake we see most often. The risk section scores harm to the organisation: fines, contract loss, reputational damage. But the assessment measures risk to the individual, and the Article 29 Working Party guidelines on data protection impact assessments<\/a> flag that inversion explicitly, noting that risk management in information security is focused on the organisation while this instrument takes the data subject’s perspective. Score the wrong side of the ledger and every number in the document answers a question nobody asked.<\/p>\n\n
\n\n