3.5 Controller & Processor Obligations + Security

From Accountability to Concrete Duties

Quick Answer: Articles 24–32 operationalise accountability. The controller must implement and demonstrate appropriate measures (Art. 24), build in data protection by design and by default (Art. 25), keep records of processing (Art. 30), bind any processor by a contract with set clauses (Art. 28), and ensure security appropriate to the risk (Art. 32).

These articles convert the abstract accountability principle of Article 5(2) into auditable obligations. Exam scenarios typically describe an organisation that is doing the right thing substantively but is missing a document or a measure — a DPA that omits a mandatory clause, a RoPA that was never built, a default setting that over-shares, or a security control absent for the level of risk. Your job is to name the missing artefact and the article that requires it.

Note also that under Article 82 both controllers and processors can be liable for damage, and under Article 83 the lower fine tier (€10m / 2% of turnover) applies to breaches of Arts. 25–39 — distinct from the higher tier for principles and rights.

Controller Accountability and Data Protection by Design (Art. 24–25)

Article 24 — the controller must implement appropriate technical and organisational measures (TOMs) to ensure and demonstrate that processing complies, taking into account the nature, scope, context, and purposes of processing and the risks to rights and freedoms. The standard is risk-based and proportionate: a hospital's measures differ from a corner shop's. Adherence to an approved code of conduct (Art. 40) or certification (Art. 42) can help demonstrate compliance.

Article 25 — Data Protection by Design and by Default (DPbDD):

• By design — integrate safeguards (e.g., pseudonymisation, minimisation) into processing at the time of determining the means and throughout the lifecycle, not bolted on afterwards.
• By default — by automatic configuration, process only the personal data necessary for each specific purpose. This covers the amount collected, the extent of processing, the storage period, and accessibility. The textbook failure: a social platform whose default profile is public — by default it should be the most privacy-protective setting, requiring the user to opt in to wider sharing.

The two limbs are distinct exam options. "We added an encryption feature users can enable" is by design; "the privacy-protective option is the out-of-the-box setting" is by default.

Records of Processing Activities (Art. 30)

Records of processing activities (RoPA) are an internal accountability document, distinct from the public privacy notice and provided to the supervisory authority on request. A controller's RoPA records: the controller's (and DPO's) identity; purposes; categories of data subjects and personal data; recipients (including in third countries); details of any international transfers and safeguards; envisaged retention periods; and a general description of Article 32 security measures. A processor keeps a narrower record: categories of processing per controller, transfers, and security measures.

The small-organisation exemption is a perennial exam point. Organisations with fewer than 250 employees are generally exempt from maintaining a RoPA — unless any of these apply:

• the processing is likely to result in a risk to the rights and freedoms of data subjects;
• the processing is not occasional; or
• it involves special category data (Art. 9) or criminal conviction/offence data (Art. 10).

Because virtually every business processes staff payroll or customer records regularly (i.e., not occasional), the exemption almost never helps in practice — the safe exam answer is that the organisation must keep a RoPA. Beware distractors claiming the threshold is 10 or 50 employees, or that the exemption is absolute regardless of the data involved.

Processor Contracts (Art. 28) and Security (Art. 32)

Article 28 — a controller may use only processors providing sufficient guarantees of compliance, governed by a binding contract (a Data Processing Agreement, DPA). The contract must require the processor to:

• process only on documented instructions (including for transfers);
• ensure persons authorised to process are bound by confidentiality;
• take all Article 32 security measures;
• engage sub-processors only with prior authorisation and flow down equivalent terms;
• assist the controller with data subject rights, breach notification, DPIAs, and prior consultation;
• at the controller's choice, delete or return all data at the end of the service; and
• make available information for, and submit to, audits and inspections.

Article 28(10) is heavily tested: if a processor determines the purposes and means of processing — acting beyond documented instructions — it is treated as a controller for that processing and assumes the corresponding obligations and liability.

Article 32 — Security of processing requires measures appropriate to the risk, considering the state of the art, costs, and the nature/scope/context/purposes of processing. It expressly lists pseudonymisation and encryption; ensuring ongoing confidentiality, integrity, availability, and resilience; the ability to restore access after an incident; and a process for regularly testing and evaluating effectiveness. Security is a shared obligation: both controllers (Art. 24/32) and processors (Art. 32) owe it directly, and a sub-standard control for the risk level is the classic Article 32 breach.

Article 32 is also the benchmark for breach severity under Articles 33–34: encrypted or pseudonymised data that is exfiltrated may render the breach unlikely to result in a high risk, narrowing the duty to notify affected individuals.