Security of Processing: Article 32 & Vendor Management

The security principle from Article 5 gets its operational detail in Article 32, security of processing. The core duty is to implement appropriate technical and organisational measures, often abbreviated TOMs, to ensure a level of security appropriate to the risk. The phrase appropriate to the risk matters: the GDPR does not demand the same controls for a corner shop's mailing list as for a hospital's patient records.

You assess the risk to people's rights and freedoms, then match your measures to it. The exam expects you to recognise this as a risk-based standard, not a fixed checklist.

Helpfully, Article 32 gives examples, and the exam draws on them. It names the pseudonymisation and encryption of personal data; the ability to ensure ongoing confidentiality, integrity, availability, and resilience of systems and services; the ability to restore availability and access to personal data in a timely manner after a physical or technical incident, think backups and disaster recovery; and a process for regularly testing, assessing, and evaluating the effectiveness of the measures. Notice the word resilience and the restore-after-incident requirement; security under the GDPR is not only about keeping data secret, it is also about keeping it available and recoverable.

Both confidentiality and availability are part of the duty. And note that Article 32 also requires you to assess the risks presented by the processing, in particular from accidental or unlawful destruction, loss, alteration, or unauthorised disclosure, so the measures you choose must be matched to that assessed risk rather than picked off a generic checklist.

Here is a point candidates miss: Article 32 applies to both controllers and processors. The processor is not off the hook just because it acts on instructions; it has a direct, independent legal obligation to secure the personal data it handles. So if a processor's poor security causes a breach, the processor can be liable in its own right, alongside the controller.

This shared responsibility is part of why vendor management is so important, and it is why the contract between controller and processor has to spell out security expectations clearly. Always read a scenario for who actually held and secured the data, because liability can land on either party.

When a controller hands data to a processor, Article 28 governs the relationship, and it is heavily tested. First, a controller may only use processors that provide sufficient guarantees of appropriate measures. Second, the relationship must be set out in a binding written contract, commonly called a data processing agreement.

Article 28 lists what that contract must contain: the processor must process only on the controller's documented instructions; ensure persons processing the data are under confidentiality; take Article 32 security measures; assist the controller with data subject rights and with breach notification; delete or return the data at the end; and submit to audits. And crucially, a processor cannot engage a sub-processor without the controller's prior authorisation. If a scenario describes a vendor quietly subcontracting, that is an Article 28 problem.

Beyond the contract, the Body of Knowledge expects you to understand responsible vendor management as a lifecycle: due diligence before you engage a vendor, a proper contract, ongoing oversight, and the right to audit. And distinguish two kinds of sharing. Giving data to a processor who acts on your instructions is covered by Article 28.

But disclosing data to a separate organisation that will use it for its own purposes, that recipient is a controller in its own right, and the disclosure needs its own lawful basis under Article 6, plus transparency to the data subject. The exam will test whether you can tell a processor relationship from a controller-to-controller transfer; the difference is who decides the purpose.

Let's lock in security and vendors. Article 32 demands technical and organisational measures appropriate to the risk, and it names encryption, resilience, the ability to restore after an incident, and regular testing. Both controllers and processors carry that duty directly.

Article 28 requires a binding contract with any processor, spelling out instructions, confidentiality, security, assistance, deletion, and audits, and a processor needs the controller's authorisation before bringing in a sub-processor. And sharing data with a separate controller needs its own lawful basis. Next, we turn to what happens when security fails: personal data breaches and the seventy-two-hour notification clock under Articles 33 and 34.

First, go test yourself on security and vendors.