GDPR RoPA + DPA EN - records of processing (Art. 30) and processor contracts (Art. 28)

Philosophy

A RoPA is a living accountability document and a processor contract is a list of mandatory clauses - both can be checked mechanically against the article. The skill drafts/redlines; signing and filing are human acts.

Part 1 - Records of processing (Art. 30)

Controller (Art. 30(1)(a)-(g)) - content of the record per activity:

• name and contact details of the controller and, where applicable, the joint controller, the controller's representative and the DPO,
• purposes of the processing,
• categories of data subjects and categories of personal data,
• categories of recipients (incl. in third countries or international organisations),
• where applicable, transfers to a third country or international organisation, identifying it, and for Art. 49(1) second-subparagraph transfers the documentation of suitable safeguards,
• where possible, the envisaged time limits for erasure per category of data,
• where possible, a general description of the technical and organisational security measures (Art. 32(1)).

Processor (Art. 30(2)) - mandatory fields per Art. 30(2)(a)-(d): name and contact details of the processor(s) and of each controller on whose behalf it acts (plus, where applicable, representatives and the DPO), categories of processing per controller, transfers + safeguards, description of measures. Naming controllers and sub-processors alone is NOT a complete register - contact details, representatives and DPO are statutory fields.

The skill validates completeness (a missing field is a gap, not a guess) and flags activities needing a DPIA => [[gdpr-dpia-en]]. The Art. 30(5) exemption (<250 persons) is narrow - and unavailable regardless of headcount where processing is likely to result in a risk, is not occasional, includes Art. 9(1) special categories or Art. 10 criminal-convictions data (each a separate disqualifier). Rarely applies in practice.

Part 2 - Processor contract review (Art. 28(3))

The contract MUST bind the processor to:

• (a) process only on the controller's documented instructions (incl. transfers), unless Union or Member State law requires otherwise - then inform the controller before processing, unless that law forbids it on important grounds of public interest,
• (b) ensure confidentiality of authorised persons,
• (c) apply security measures (Art. 32),
• (d) respect the conditions for engaging sub-processors (authorisation + flow-down),
• (e) assist the controller in fulfilling data-subject rights (Chapter III),
• (f) assist with Art. 32-36 compliance (security, breaches, DPIA),
• (g) at the controller's choice, delete or return all the data after the end of the services, and delete existing copies unless Union or Member State law requires storage,
• (h) make available all information needed to demonstrate compliance and allow audits/ inspections - and immediately inform the controller if an instruction, in its opinion, infringes data protection law (Art. 28(3) second subparagraph).

Plus: subject-matter and duration, nature and purpose, type of personal data, categories of data subjects, and the obligations and rights of the controller (Art. 28(3) sentence 1), and Chapter V transfers (SCCs/adequacy). The skill produces a redline of missing/defective clauses (via [[clause-checklist-en]]).

Tool - Art. 28 clause check (deterministic, offline)

Find the gaps in a processor contract with the script - list the clauses present, get the missing ones (zero dependencies, offline):

python scripts/dpa_clause_check.py --present a,b,c,g

Returns missing (e.g. d, e, f, h) = the exact redline target. complete when all eight (a-h) are present.

Governance boundary

Skill: builds/validates the register, redlines the contract, maps gaps to articles. Human: approves content, negotiates, signs the contract, owns the register. Signing is never automatic.

Companion

Clause library/redline: [[clause-checklist-en]]. DPIA: [[gdpr-dpia-en]]. Polish parity: rodo-ropa-dpa-pl.

Shared rules of the data-protection plugin (Data protection)

These rules apply to every skill in this plugin, including where the skill itself is silent. They are copied into each skill, so they hold whether you install the whole plugin or a single skill.

These skills run GDPR operations for controllers, law firms and DPOs: impact assessments, breach response, data subject rights, records of processing and processor-contract review. Each ends in a draft for decision, not a finished act.

Rules

• Output is a draft for decision. A DPIA, a breach notification, a DSAR response, a register or a contract redline is a starting point for the controller / DPO. A person approves and executes it.
• Governance boundary - the outward act stays human. Filing with the supervisory authority, sending a breach notification, sending a DSAR response, erasing or exporting data, signing a contract - the skill prepares the draft, it does not perform the act.
• No guessing on risk. A risk assessment (DPIA, breach) needs inputs; a missing input is a gap to fill, not a field to guess.
• Not legal advice. The skills organise GDPR obligations and map them to articles; they do not replace legal analysis of a specific matter.
• Confidentiality. Treat the data of a real organisation and of data subjects as confidential - do not move it outside the agreed flow. These skills add no outbound channel of their own; what reaches your model is decided by your configuration (see https://github.com/matematicsolutions/awesome-matematic-skills-en/blob/main/TRUST.md).

Plugin scope

Operational GDPR tooling (DPIA, breach, DSAR, RoPA/DPA). It does not verify citations or fetch sources of law - use verification-foundation and eu-law-sources for that. The DPA redline pairs with clause-checklist-en (verification-foundation).