Appearance
Controller obligations and breach notification — GDPR Articles 24–37
This page covers the controller and processor obligations that follow once GDPR scope is established and the substantive principles, lawful basis, and data-subject rights have been addressed. Article 24 sets the controller's general responsibility; Article 25 the data protection by design and by default duty; Article 26 joint controllers; Article 28 the processor relationship; Article 30 the records of processing activities (RoPA); Article 32 security; Articles 33–34 the breach-notification regime; Article 35 the DPIA; Article 36 prior consultation; Articles 37–39 the DPO.
Article 22 (automated decision-making, including profiling) is the most legally consequential provision for AI; Article 35 DPIA, Article 33 72-hour breach notification, and Article 32 security are the operationally densest controller-side obligations.
Quick decision
- Building or deploying an AI system that processes personal data → Article 24 controller responsibility + Article 25 data protection by design and by default apply at the design phase. Document the design decisions and the safeguards as evidence under the relevant requirement.
- Engaging an ICT or AI service provider → Article 28 governs the controller / processor contract. The Article 28(3)(a)–(h) provisions are mandatory; supervisory authorities have refused to accept generic supplier templates that miss one of the eight provisions.
- Maintaining a record of processing activities → Article 30 applies to most controllers and processors. The Article 30(5) exemption (organisations of fewer than 250 persons, with limited carve-outs) is narrower than it looks — it does not apply where the processing is not occasional, includes special categories, or is likely to result in a risk to rights and freedoms of data subjects.
- High-risk processing — large-scale special categories, systematic and extensive profiling, public monitoring → Article 35 DPIA is required. The Article 35(3)(a)–(c) trigger list is the operative test; the supervisory authority's Article 35(4) list is also binding.
- Detected a personal-data breach → start the Article 33(1) 72-hour clock at the moment of becoming aware. Article 34 communication to data subjects applies if the breach is likely to result in a high risk; Article 34(3) lists three exceptions.
- In one of the Article 37(1) cases → appoint a DPO; observe the Article 38 position rules (no instructions, no conflict of interest, direct reporting to the highest management level).
TL;DR
- Article 24 controller responsibility — implement appropriate technical and organisational measures to ensure and demonstrate compliance.
- Article 25 data protection by design and by default — pseudonymisation, minimisation, default settings limited to what is necessary.
- Article 26 joint controllers — arrangement determining respective responsibilities; the essence of the arrangement made available to the data subject.
- Article 28 processor — controller must use only sufficiently-guaranteed processors; contract with the eight Article 28(3)(a)–(h) provisions; sub-processor authorisation (Article 28(2) and (4)).
- Article 30 RoPA — records of processing activities maintained by each controller and (separately) each processor. Article 30(5) narrow exemption.
- Article 32 security of processing — appropriate technical and organisational measures including, as appropriate, the four sub-points (a) pseudonymisation and encryption; (b) ongoing confidentiality, integrity, availability, resilience; (c) timely restoration; (d) regular testing.
- Article 33 72-hour controller breach notification to supervisory authority.
- Article 34 data subject communication where high risk.
- Article 35 DPIA — Article 35(3)(a)–(c) triggers + Article 35(4) supervisory-authority list.
- Article 36 prior consultation where DPIA indicates high residual risk.
- Articles 37–39 DPO — designation conditions, position, tasks.
Primary source
Regulation (EU) 2016/679 on EUR-Lex (CELEX 32016R0679) — Articles 24–39 · EDPB Guidelines on DPIA (replaces WP29 17/EN WP248rev.01) · EDPB Guidelines 9/2022 on personal data breach notification under GDPR · EDPB Guidelines on data protection by design and by default
Article 24 — responsibility of the controller
Article 24(1) is the meta-obligation:
Taking into account the nature, scope, context and purposes of processing as well as the risks of varying likelihood and severity for the rights and freedoms of natural persons, the controller shall implement appropriate technical and organisational measures to ensure and to be able to demonstrate that processing is performed in accordance with this Regulation. Those measures shall be reviewed and updated where necessary.
Article 24(2) makes data-protection policies a baseline expectation where proportionate to the processing. Article 24(3) recognises adherence to approved codes of conduct (Article 40) and approved certification mechanisms (Article 42) as evidence of compliance.
Article 25 — data protection by design and by default
Article 25(1) sets the by-design obligation: at the time of the determination of the means for processing and at the time of the processing itself, the controller shall implement appropriate technical and organisational measures, such as pseudonymisation, designed to implement data-protection principles in an effective manner and to integrate the necessary safeguards.
Article 25(2) sets the by-default obligation: appropriate technical and organisational measures to ensure that, by default, only personal data which are necessary for each specific purpose of the processing are processed. Applies to (i) the amount of personal data collected, (ii) the extent of their processing, (iii) the period of their storage, and (iv) their accessibility. In particular, default settings must not make the personal data accessible without the individual's intervention to an indefinite number of natural persons.
For AI systems, Article 25 typically lands on the system architecture: training-data sampling, retention defaults, default log levels, default UI privacy settings, and the choice of pseudonymisation in the training and inference pipeline.
Article 26 — joint controllers
Article 26(1) requires joint controllers (two or more controllers jointly determining purposes and means) to determine in a transparent manner their respective responsibilities, by means of an arrangement, unless the responsibilities are determined by Union or Member State law. The arrangement must reflect the respective roles and relationships of the joint controllers vis-à-vis the data subjects.
Article 26(2) requires the essence of the arrangement to be made available to the data subject. Article 26(3) preserves the data subject's right to exercise rights under the Regulation against each of the joint controllers.
Article 28 — processor
Article 28(1) requires the controller to use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation and ensure the protection of the rights of the data subject.
Article 28(2) requires the processor not to engage another processor (sub-processor) without prior specific or general written authorisation of the controller. In the case of general written authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object.
Article 28(3) requires the controller / processor relationship to be governed by a contract or other legal act under Union or Member State law that is binding on the processor with regard to the controller and that sets out the subject-matter and duration of the processing, the nature and purpose of the processing, the type of personal data and categories of data subjects, and the obligations and rights of the controller. Article 28(3)(a)–(h) lists eight mandatory provisions the contract must include — in summary:
- (a) the processor processes the personal data only on documented instructions from the controller, including with regard to transfers to a third country or an international organisation, unless required by Union or Member State law (with notification duties for legal requirements);
- (b) ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality;
- (c) takes all measures required pursuant to Article 32;
- (d) respects the conditions in Article 28(2) and Article 28(4) for engaging another processor;
- (e) taking into account the nature of the processing, assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights laid down in Chapter III;
- (f) assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36, taking into account the nature of the processing and the information available to the processor;
- (g) at the choice of the controller, deletes or returns all the personal data to the controller after the end of the provision of services relating to processing, and deletes existing copies (subject to Union or Member State law requiring storage of the personal data);
- (h) makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in Article 28 and allows for and contributes to audits, including inspections, conducted by the controller or another auditor mandated by the controller.
Article 28(3) also requires the processor to immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions. The above list summarises the OJ text; consult the EUR-Lex CELEX for the binding wording.
Article 28(4) requires the same contractual obligations to be imposed on sub-processors. Article 28(7) authorises the Commission to lay down standard contractual clauses (the Article 28 SCCs, published by Commission Implementing Decision (EU) 2021/915, complement the international-transfer SCCs in Implementing Decision (EU) 2021/914).
Article 30 — records of processing activities
Article 30(1) requires each controller and, where applicable, the controller's representative, to maintain a record of processing activities under its responsibility. The record contains:
- (a) the name and contact details of the controller and, where applicable, the joint controller, the controller's representative, and the data protection officer;
- (b) the purposes of the processing;
- (c) a description of the categories of data subjects and of the categories of personal data;
- (d) the categories of recipients to whom the personal data have been or will be disclosed, including recipients in third countries or international organisations;
- (e) where applicable, transfers of personal data to a third country or an international organisation, including the identification of that third country or international organisation and the documentation of suitable safeguards;
- (f) where possible, the envisaged time limits for erasure of the different categories of data;
- (g) where possible, a general description of the technical and organisational security measures referred to in Article 32(1).
Article 30(2) sets the equivalent obligation for each processor and, where applicable, the processor's representative.
Article 30(3) requires the records to be in writing, including in electronic form. Article 30(4) requires the records to be made available to the supervisory authority on request.
Article 30(5) sets a narrow exemption for organisations of fewer than 250 persons — but the exemption does not apply where the processing is not occasional, includes special categories of data under Article 9 or criminal-conviction data under Article 10, or is likely to result in a risk to the rights and freedoms of data subjects. In practice, most AI-deploying organisations fall outside the exemption.
Article 32 — security of processing
Article 32(1) is the security cornerstone:
Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including inter alia as appropriate:
(a) the pseudonymisation and encryption of personal data;
(b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services;
(c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident;
(d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.
Article 32(2) sets the risk-assessment factors. Article 32(3) recognises adherence to approved codes of conduct and approved certification mechanisms as evidence. Article 32(4) requires controllers and processors to ensure that any natural person acting under their authority with access to personal data does not process them except on instructions from the controller.
Article 33 — controller breach notification
Article 33(1) sets the 72-hour rule:
In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority competent in accordance with Article 55, unless the personal data breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification to the supervisory authority is not made within 72 hours, it shall be accompanied by reasons for the delay.
Article 33(2) sets the processor's parallel duty:
The processor shall notify the controller without undue delay after becoming aware of a personal data breach.
Article 33(3) sets the minimum content of the notification:
The notification referred to in paragraph 1 shall at least:
(a) describe the nature of the personal data breach including where possible, the categories and approximate number of data subjects concerned and the categories and approximate number of personal data records concerned;
(b) communicate the name and contact details of the data protection officer or other contact point where more information can be obtained;
(c) describe the likely consequences of the personal data breach;
(d) describe the measures taken or proposed to be taken by the controller to address the personal data breach, including, where appropriate, measures to mitigate its possible adverse effects.
Article 33(4) permits the information to be provided in phases without undue further delay where it is not possible to provide everything at the same time. Article 33(5) requires the controller to document any personal data breaches.
Article 34 — communication to the data subject
Article 34(1) triggers the data subject communication duty:
When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.
Article 34(2) sets the content (mirroring Article 33(3)(b)–(d)). Article 34(3) sets three exceptions to the communication duty:
- (a) the controller has implemented appropriate technical and organisational protection measures, and those measures were applied to the personal data affected by the personal data breach, in particular those that render the personal data unintelligible to any person who is not authorised to access it, such as encryption;
- (b) the controller has taken subsequent measures which ensure that the high risk to the rights and freedoms of data subjects referred to in paragraph 1 is no longer likely to materialise;
- (c) it would involve disproportionate effort. In such a case, there shall instead be a public communication or similar measure whereby the data subjects are informed in an equally effective manner.
Article 34(4) gives the supervisory authority the power to require the communication if the controller has not done so.
Article 35 — data protection impact assessment
Article 35(1) sets the DPIA trigger:
Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data. A single assessment may address a set of similar processing operations that present similar high risks.
Article 35(3) sets the three required-DPIA cases:
A data protection impact assessment referred to in paragraph 1 shall in particular be required in the case of:
(a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person;
(b) processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10; or
(c) a systematic monitoring of a publicly accessible area on a large scale.
Article 35(4) requires the supervisory authority to establish and make public a list of the kind of processing operations subject to the requirement for a DPIA. Article 35(5) allows the supervisory authority also to establish a list of operations for which no DPIA is required.
Article 35(7) sets the minimum DPIA content:
- (a) a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller;
- (b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes;
- (c) an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1;
- (d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned.
Article 35(9) requires the controller to seek the views of data subjects or their representatives on the intended processing, where appropriate, without prejudice to the protection of commercial or public interests or the security of processing operations.
For AI use cases, the Article 35(3)(a) trigger (systematic and extensive evaluation by automated processing, including profiling, with legal or similarly significant effects) catches many decision-making AI applications. The supervisory authority's Article 35(4) list often adds further AI-related triggers (use of biometrics, large-scale profiling, public-monitoring AI).
Article 36 — prior consultation
Article 36(1) requires the controller to consult the supervisory authority prior to processing where a DPIA under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk.
Article 36(2) requires the supervisory authority, where it is of the opinion that the intended processing would infringe this Regulation, in particular where the controller has insufficiently identified or mitigated the risk, to provide written advice to the controller within a period of up to eight weeks of receipt of the request for consultation (extendable by six further weeks, with notice to the controller within one month, taking into account the complexity of the intended processing).
Article 36(3) sets the information the controller must provide. Article 36(5) preserves Member State law requiring controllers to consult, and obtain prior authorisation from, the supervisory authority in relation to processing for a task in the public interest.
Articles 37–39 — data protection officer
Article 37(1) requires designation of a DPO where:
- (a) the processing is carried out by a public authority or body, except for courts acting in their judicial capacity;
- (b) the core activities of the controller or the processor consist of processing operations which, by virtue of their nature, their scope and/or their purposes, require regular and systematic monitoring of data subjects on a large scale;
- (c) the core activities of the controller or the processor consist of processing on a large scale of special categories of data pursuant to Article 9 and personal data relating to criminal convictions and offences referred to in Article 10.
Article 37(2) addresses group-level DPO designation. Article 37(3) addresses public authorities. Article 37(4) preserves the right of Member States or Union law to require designation in additional cases. Article 37(5) requires the DPO to be designated on the basis of professional qualities and expert knowledge of data protection law and practices. Article 37(6) allows the DPO to be a staff member or to fulfil the tasks on the basis of a service contract. Article 37(7) requires publication of the DPO's contact details and communication to the supervisory authority.
Article 38 sets the DPO's position — involvement in all issues relating to data protection, support and resources, no instructions from the controller or processor on the exercise of the DPO's tasks, no dismissal or penalty for performing the tasks, direct reporting to the highest management level, no conflict of interest, the controller and processor must ensure data subjects may contact the DPO.
Article 39 lists the DPO's tasks — informing and advising the controller / processor and employees, monitoring compliance, providing advice as regards the DPIA, cooperating with the supervisory authority, acting as the contact point for the supervisory authority.
How to operationalize Articles 24–37 in Modulos
| Layer | Modulos surface | Coverage |
|---|---|---|
| Art 24 controller responsibility | OFF-11 governance requirements | Documented design, periodic review |
| Art 25 by design and by default | MFF-12 per-AI-system requirements | Architecture evidence, default-setting evidence |
| Art 26 joint controllers | OFF-11 requirement(s) covering Art 26 arrangement | Joint-controller arrangement records |
| Art 28 processor | OFF-11 requirement(s) covering processor relationships | Contracts with the 8 Art 28(3) provisions; sub-processor records |
| Art 30 RoPA | OFF-11 RoPA requirement | RoPA itself stored as evidence; no dedicated UI surface |
| Art 32 security | OFF-11 + MFF-12 security requirements | Security measures + Art 32(1)(a)–(d) evidence |
| Art 33–34 breach | OFF-11 breach-handling requirement | Breach-notification artefacts (72h notification, content under Art 33(3), data subject communication where applicable); no dedicated breach-reporting UI surface |
| Art 35 DPIA | OFF-11 DPIA requirement linked per MFF-12 high-risk AI | DPIA documents stored as evidence; no dedicated DPIA workflow UI |
| Art 36 prior consultation | OFF-11 prior-consultation requirement | Supervisory-authority correspondence + advice |
| Arts 37–39 DPO | OFF-11 DPO requirement | DPO designation letter, position arrangements, task evidence |
A typical setup:
- Requirements — each Article 24–37 obligation is recorded as a requirement. Fulfilment tracks through
Not fulfilled→Fulfilled(with optionalOut of scopewhere the obligation does not apply — e.g. DPO where Article 37(1) conditions are not met). - Controls — implemented arrangements (joint-controller arrangement template, Article 28 contract template with all 8 provisions, RoPA template, security policy implementing Article 32(1)(a)–(d), breach-handling SOP, DPIA methodology, DPO charter) are documented as named controls.
- Evidence — joint-controller arrangements, signed Article 28 contracts, RoPA itself, security policies, breach-notification artefacts, DPIA documents, prior-consultation correspondence, DPO designations are recorded as evidence and linked to one or more controls.
- Readiness + fulfilment attestation — when controls are in a final state, the requirement becomes ready for review; the requirement owner attests fulfilment.
- Modulos does not provide dedicated UI surfaces for the Article 30 RoPA, the Article 35 DPIA workflow, or the Article 33–34 breach notification. These are evidence-attached patterns tracked against the relevant requirement.
Cross-framework mapping (preview)
| GDPR area | EU AI Act (Regulation (EU) 2024/1689) | ISO/IEC 27001:2022 | NIS2 (Directive (EU) 2022/2555) |
|---|---|---|---|
| Art 24 controller responsibility | Article 17 quality management system | Clause 5 leadership, Clause 9 evaluation | Article 20 management body |
| Art 25 by design / by default | Article 9 risk-management system; Article 14 human oversight design | Clause 6.1 risk treatment | Article 21(2)(e) secure acquisition / development / maintenance |
| Art 28 processor contracts | Article 25 value-chain responsibility + Article 50 transparency contractual terms | A.5.20 information security in supplier agreements | Article 21(2)(d) supply chain |
| Art 30 RoPA | Article 11 + Annex IV technical documentation; Article 12 record-keeping | A.5.34 records of activities | (no direct equivalent) |
| Art 32 security | Article 15 cybersecurity for high-risk AI | Annex A.8 technological controls | Article 21(2)(a)–(j) cybersecurity measures |
| Art 33 breach notification (72h) | Article 73 serious incident reporting (high-risk AI) | A.5.24, A.5.25, A.5.26 incident management | Article 23(4) staged reporting (24h / 72h / 1 month) |
| Art 35 DPIA | Article 27 fundamental rights impact assessment (FRIA — narrow trigger, distinct duty) | (no direct equivalent) | (no direct equivalent) |
| Arts 37–39 DPO | (no direct equivalent — AI Act has no equivalent of the DPO role) | (no direct equivalent — different scope) | (no direct equivalent) |
For the pairwise treatment with the EU AI Act see EU AI Act vs GDPR.
Related pages
GDPR overview
Framework structure, dates, OFF-11 / MFF-12 split
Scope and applicability
Article 2 material scope, Article 3 territorial scope, Article 4 key definitions
Key principles and obligations
Article 5 principles, Article 6 lawful basis, Article 9 special categories, Articles 12–22 rights
Operationalizing in Modulos
Practical rollout sequence for OFF-11 and MFF-12
EU AI Act vs GDPR
How the two binding EU Regulations interact for AI systems processing personal data
Source attribution
Regulation (EU) 2016/679 (GDPR) is published in the Official Journal of the European Union L 119, 4.5.2016, pp. 1–88; corrigendum in OJ L 127, 23.5.2018, pp. 2–5. Articles 24(1), 32(1) including (a)–(d), 33(1), 33(3)(a)–(d), 34(1), 34(3)(a)–(c), 35(1), and 35(3)(a)–(c) on this page are quoted from the OJ text (verifiable against the EUR-Lex CELEX). Articles 28(3)(a)–(h), 34(2), 35(7)(a)–(d), and the Article 36 paragraphs are summarised rather than quoted verbatim — consult EUR-Lex for the binding wording. The Article 28 Standard Contractual Clauses are laid down in Commission Implementing Decision (EU) 2021/915; international-transfer SCCs in Commission Implementing Decision (EU) 2021/914.
Disclaimer
This page is for general informational purposes and does not constitute legal advice.