Operationalizing GDPR in Modulos

This page is the practical rollout playbook for GDPR (Regulation (EU) 2016/679) in Modulos. It assumes the organisation has already determined that GDPR applies (see Scope and applicability) and walks through the OFF-11 and MFF-12 framework templates, the recommended project structure, the manual scoping pattern for conditional duties, the sequencing, and the evidence package supervisory authorities and auditors typically expect.

Quick decision

• Stand up the GDPR programme for the first time → start with one OFF-11 organisation project (governance + RoPA + DPO + breach SOP + transfer mechanism) and one MFF-12 AI-application project per in-scope service. Add the relevant EU AI Act framework templates if the AI system is in EU AI Act scope.
• Already running a privacy programme aligned to ISO/IEC 27701 → attach OFF-11 to the organisation project; map the PIMS controls onto the OFF-11 requirements. ISO/IEC 27701 substance feeds GDPR evidence; it does not by itself discharge GDPR obligations (lawful basis, Article 13 / 14 transparency, breach notification timelines, DPIA, DPO designation are GDPR-specific).
• Building an AI system that takes Article 22-style decisions → Article 22 is a strong screening signal for the Article 35(3)(a) DPIA trigger; whether the DPIA is required depends on whether the processing is systematic and extensive and produces legal or similarly significant effects under Article 35(3)(a), or independently appears on the supervisory authority's Article 35(4) list. Where the trigger applies, run the DPIA before deployment; engage the Article 36 prior consultation if residual high risk remains. Document Article 22(3) substantive human review in the operating model.
• Engaging an ICT or AI service provider → Article 28(3)(a)–(h) governs the contract. The eight provisions are mandatory; supervisory authorities reject contracts that miss one.
• 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.

TL;DR

• Modulos models GDPR as two framework templates: OFF-11 (organisation, 31 requirements ORF-225–ORF-255) and MFF-12 (AI application, 10 requirements MRF-233–MRF-242).
• Scope is manual and explicit — no questionnaire. Article 3 territorial-scope analysis and Article 4 controller / processor characterisation are recorded as evidence on OFF-11.
• The eight operative chapters of GDPR land on OFF-11; per-AI-system execution lands on MFF-12.
• Modulos does not provide dedicated UI surfaces for the Article 30 RoPA, the Article 35 DPIA workflow, the Article 33–34 breach notification, or the Article 28 contracts — these are tracked as evidence linked to the relevant OFF-11 / MFF-12 requirements.
• The supervisory authority's evidence expectation is traceability: from the Article reference to the requirement, to the controls that implement it, to the evidence that supports each control, with reviewer and decision recorded.

Primary source

Regulation (EU) 2016/679 on EUR-Lex (CELEX 32016R0679) · EDPB Guidelines · national supervisory-authority lists under Article 35(4) (DPIA-required) and Article 35(5) (DPIA-not-required)

Project structure that works

Most GDPR rollouts use the following structure:

• One organisation project with the OFF-11 framework template attached. This holds the Article 30 RoPA, the Article 6 / 9 lawful basis decisions, the Article 13 / 14 transparency notice, the Articles 15–22 data subject rights workflow, the Article 28 contract templates, the Article 32 security baseline, the Article 33–34 breach SOP, the Article 35 DPIA methodology, the Article 36 prior-consultation correspondence, the Article 37–39 DPO designation, and the Articles 44–50 transfer mechanism.
• One AI-application project per in-scope service with the MFF-12 framework template attached. Each project holds per-AI-system execution evidence: per-purpose lawful basis, Article 22(3) substantive-review records where applicable, Article 25 by-design architecture, Article 32 system-specific security, Article 35 system-specific DPIA where high-risk processing applies, transparency notice version applicable to the service.
• A shared policy project (optional) for cross-cutting policies — privacy policy, retention schedule, security policy, vendor due-diligence policy, training records. Linked to controls under both OFF-11 and MFF-12.

For dual-regime AI systems (GDPR + EU AI Act), attach both sets of framework templates to the same organisation and application projects; evidence is recorded once and linked to controls under both regimes.

How to operationalize GDPR in Modulos

The Modulos surfaces relevant to GDPR rollout:

Surface	Use
Project dashboard Add Framework	Attach OFF-11 to the organisation project; attach MFF-12 to each AI-service project
Project → Settings → Frameworks	Manage attached frameworks — list, freeze, and update
Project → Requirements	Track the OFF-11 / MFF-12 requirements; status Not fulfilled → Fulfilled (with optional Out of scope)
Project → Controls	Document implemented measures (per-purpose lawful basis, transparency notice, rights workflow, Article 28 contract template, RoPA, security policy, breach-handling SOP, DPIA methodology, DPO charter) and map to one or more requirements; control status changes are routed through review requests
Project → Evidence	Store supporting artefacts (RoPA itself, lawful basis decisions, transparency notices, signed contracts, DPIA documents, breach notifications, DPO designation) and link to controls
Comments and logs on each requirement	Capture rationale for fulfilment attestation, scoping decisions (controller / processor / joint-controller; Article 9 exception choice; Article 37 DPO applicability; Article 35 DPIA trigger applicability), and corrective actions

Sequence that works

A pragmatic nine-step rollout sequence:

1. Scope and characterisation. The Article 1–3 scope analysis and the Article 4(7)–(8) controller / processor characterisation are recorded as evidence linked to the relevant OFF-11 baseline requirements (with the rationale in the requirement's comments and logs). Per-processing-activity — the same organisation can be controller for one purpose and processor for another.
2. Lawful basis per purpose. Fulfil ORF-226 (Article 6 lawful basis) and ORF-227 (Article 7–8 consent). For each AI-system processing purpose, document the lawful basis decision. Where Article 6(1)(f) legitimate interests is used, record the three-prong test.
3. Principles into operable controls. Build out the Article 5 principles — purpose-limitation register, retention schedule, accuracy / drift monitoring, security baseline. Record evidence on ORF-225 and on the relevant MFF-12 requirements / projects.
4. Transparency notice. Build the Article 13 / 14 transparency notice (including the Article 13(2)(f) / 14(2)(g) automated-decision disclosure where applicable). Record the current version + change history as evidence.
5. Data subject rights workflow. Operationalise Articles 15–22 — DSAR intake, identity verification, response-template library, internal SLA reflecting the Article 12(3) one-month timeline. Where Article 22 applies, build the substantive human-review process.
6. Article 25 by design + Article 32 security. On each MFF-12 AI project, document the architecture decisions implementing data minimisation, pseudonymisation, default settings, encryption, access control, monitoring, restoration, and Article 32(1)(d) testing.
7. DPIA for high-risk processing. Where Article 35(3)(a)–(c) applies — especially for AI systems performing systematic and extensive automated evaluation under Article 35(3)(a) — run the DPIA before deployment. Store the DPIA as evidence linked to the Article 35 requirement on OFF-11 and to the relevant MFF-12 project. Where residual high risk remains, engage Article 36 prior consultation.
8. Breach SOP. Operationalise Articles 33–34 — detection trigger, the 72-hour notification timeline, the Article 33(3)(a)–(d) content template, the Article 34(1) data-subject communication trigger with the Article 34(3) exceptions, the Article 33(5) documentation duty.
9. Transfers, DPO, supervisory cooperation. Address Articles 44–50 international-transfer mechanisms where personal data leaves the EEA. Designate a DPO if Article 37(1) conditions are met. Establish a supervisory-cooperation contact under the Article 56 lead-authority / Article 60 cooperation mechanism where the organisation operates in multiple Member States.

Readiness + fulfilment attestation

Requirements in Modulos use a two-step pattern, not a review:

• when all linked controls are in a final state, the requirement becomes ready for review (a signal to the requirement owner);
• the requirement owner attests fulfilment by marking the requirement Fulfilled, with rationale captured in the requirement's comments and logs.

Review requests in Modulos apply to control status changes (and other reviewable objects like assets) — not to requirements themselves.

Evidence package baseline

A defensible GDPR evidence package typically includes:

• Scope and characterisation — Article 3 territorial-scope memo; Article 4(7)–(8) controller / processor characterisation per processing activity; Article 27 representative designation where applicable.
• Article 5 + 6 + 9 — per-purpose lawful basis records; Article 6(1)(f) three-prong tests where used; Article 9(2) exception memo where applicable; principles-into-controls evidence.
• Article 13 / 14 + 15–22 — current transparency notice + change history; rights-request workflow + sample response packages; Article 22 substantive-review records.
• Article 25 — by-design architecture evidence per AI system; default-setting evidence.
• Article 28 — signed contracts with all eight Article 28(3)(a)–(h) provisions; sub-processor authorisation records.
• Article 30 — the RoPA itself (controller record + processor record where applicable).
• Article 32 — security policy implementing Article 32(1)(a)–(d); Article 32(1)(d) testing evidence.
• Articles 33–34 — breach-handling SOP; executed 72-hour notifications to supervisory authorities; data-subject communications where Article 34 applied; Article 33(5) breach log.
• Article 35 — DPIA methodology; executed DPIAs per high-risk AI system (with the Article 35(7) content).
• Article 36 — prior-consultation correspondence with supervisory authority where applicable.
• Articles 37–39 — DPO designation letter; position arrangements (independence, reporting line); DPO tasks evidence.
• Articles 44–50 — adequacy-decision reference, Article 46 safeguards (e.g. Commission SCCs Implementing Decision (EU) 2021/914), Article 47 BCRs, or Article 49 derogations.

Common evidence patterns by Article

GDPR evidence is most defensible when each Article maps to a recurring artefact pattern that the organisation produces and refreshes on a predictable cadence. The patterns most teams settle on:

• Article 5 principles — a per-purpose evidence cycle: a purpose register reviewed at least annually; a retention schedule with deletion-run logs; data-quality metrics and drift monitoring outputs; a security baseline document maintained alongside Article 32 evidence. The cycle is repeated for every distinct AI-system processing purpose; the evidence attaches to the OFF-11 Article 5 requirement and to each MFF-12 system project.
• Article 6 lawful basis — a per-purpose lawful-basis decision record. For Article 6(1)(f) legitimate interests, the three-prong test (purpose / necessity / balancing) is the operative artefact and is typically refreshed every 12 months or whenever the processing materially changes.
• Articles 12–14 transparency — a current transparency notice with a versioned change history. The Article 13(2)(f) / 14(2)(g) automated-decision disclosure (meaningful information about the logic + significance + envisaged consequences) is the AI-specific section to keep current.
• Articles 15–22 data subject rights — a DSAR intake queue with identity-verification evidence, response templates, and internal SLA tracking against the Article 12(3) one-month timeline. Where Article 22 applies, the substantive human-review records are the operative evidence — not just a rubber-stamp log.
• Article 25 by-design — architecture decision records (ADRs) per AI system documenting data minimisation, default settings, pseudonymisation choices, and the access-control model.
• Article 28 contracts — a contract repository indexed by processor; each contract checked against the eight Article 28(3)(a)–(h) provisions; sub-processor authorisation records (specific or general written authorisation).
• Article 30 RoPA — the RoPA itself as a controlled document, refreshed when the processing materially changes; the Article 30(5) exemption decision recorded only if genuinely applicable.
• Article 32 security — a security policy document mapping each Article 32(1)(a)–(d) sub-point to specific technical measures; the Article 32(1)(d) "regularly testing, assessing and evaluating" evidence is the part most often missing in audits.
• Articles 33–34 breach — a breach log (Article 33(5)) with one entry per incident; the 72-hour notification text + supervisory-authority response; the Article 34 communication where applicable, with the Article 34(3) exception rationale recorded if invoked.
• Article 35 DPIA — a DPIA per high-risk AI system with the Article 35(7)(a)–(d) content; the Article 35(9) stakeholder-consultation evidence where appropriate; Article 36 prior-consultation correspondence where residual high risk remained.
• Articles 37–39 DPO — DPO designation letter, the Article 38 independence arrangement (reporting line, no instructions clause, no conflict of interest), DPO task log evidencing Article 39 duties.

Operating cadence

A defensible GDPR programme typically follows a 12-month operating cadence anchored on the DPO and the privacy steering committee:

• Quarterly: DSAR backlog review; breach-handling drills; vendor (processor) review cycle; supervisory-authority correspondence review.
• Semi-annually: lawful-basis decisions refresh; transparency notice review; Article 32 security testing (penetration testing, vulnerability scans, restoration drills); RoPA refresh.
• Annually: full Article 5 principles cycle (purpose register, retention, accuracy); Article 30 RoPA full refresh; DPIA refresh for high-risk AI systems; Article 28 processor inventory and contract renewals; transfers mechanism review (adequacy decision updates, SCC versions, BCR scheme status); DPO annual report; supervisory-authority cooperation under the Article 60 one-stop-shop where applicable.

Material changes (new AI-system feature, new processor, new data category, new processing purpose, expansion into a new Member State, breach incident) trigger an off-cycle review of the affected requirements, controls, and evidence.

Cross-framework reuse

Most GDPR-aligned organisations also operate one or more adjacent frameworks:

• EU AI Act — for AI systems that process personal data. Article 22 GDPR / Article 14 EU AI Act distinction preserved; Article 33 GDPR / Article 73 EU AI Act distinction preserved.
• ISO/IEC 27701 (Privacy Information Management System) — provides the management-system structure for the GDPR substance.
• ISO/IEC 27001 — provides the information-security baseline supporting Article 32.
• NIS2 — for essential or important entities in scope. Article 23(10) NIS2 hook for CER critical entities; Article 21(2)(d) supply-chain measures align with Article 28 GDPR processor contracts.

The Modulos design encourages single-source evidence with multi-framework links: a control object can map to GDPR Article 32, ISO/IEC 27001 Annex A.8, ISO/IEC 27701 Annex A / B, EU AI Act Article 15, and NIS2 Article 21(2) simultaneously with a single evidence record.

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

Controller obligations and breach notification

Articles 24–32 obligations, 33–34 breach, 35 DPIA, 37 DPO

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. This operationalize page describes how Modulos maps GDPR obligations to platform surfaces; the binding obligations are in the Regulation itself, applicable national-law provisions, and supervisory-authority guidance. Commission Implementing Decision (EU) 2021/914 (international-transfer SCCs) and (EU) 2021/915 (Article 28 SCCs) are individually published on EUR-Lex.

Disclaimer

This page is for general informational purposes and does not constitute legal advice.