EU GDPR Requirements

Start with the processing activity, not the department. GDPR scope depends on whether personal data is processed in a covered context, including material scope under Article 2 and territorial scope under Article 3. For each activity, record the data subjects, personal-data categories, purpose, entity, location, and whether the organisation is acting as controller, joint controller, processor, or both in different parts of the service.

Article 2 covers wholly or partly automated processing and structured filing-system processing. It excludes activities outside Union law, specified Member State activity under Chapter 2 of Title V TEU, processing by a natural person in a purely personal or household activity, and processing by competent authorities for the law-enforcement purposes governed by Directive (EU) 2016/680. The household exception does not automatically extend to a business or service provider that supplies the means for the processing.

Article 3 applies to processing in the context of an establishment's activities in the Union, whether or not the processing happens in the Union. It also reaches a controller or processor without a Union establishment when the relevant processing concerns offering goods or services to people in the Union or monitoring their behaviour there. Record which Article 3 route applies; EU customer access or a globally available website alone does not answer the targeting and monitoring questions.

Role classification drives the rest of the work. Controllers decide purposes and means and carry the core accountability burden. Processors process on documented controller instructions and need an Article 28 arrangement. Joint controllers must transparently allocate responsibilities for duties such as information notices and rights handling.

Apply the Article 5 principles to every processing activity. Processing must be lawful, fair, transparent, purpose-limited, data-minimised, accurate, storage-limited, secure, and accountable. Test each principle against the actual data flow.

Article 6 then requires at least one lawful basis for processing. The record should identify the basis, the purpose it supports, the evidence for that basis, and any dependency such as consent withdrawal, contract necessity, legal obligation, public task, vital interests, or legitimate-interest balancing. Special category data and criminal-offence data need additional checks under Articles 9 and 10.

Transparency starts before or at collection when Article 13 applies, and it also covers data obtained from other sources under Article 14. Notices should explain the controller, purposes, lawful bases, recipients, retention logic, transfer safeguards where relevant, rights, complaint routes, and automated decision-making information where applicable.

Rights handling needs an operational workflow, not only a policy page. Article 12 sets communication standards, Articles 15 to 22 define rights such as access, rectification, erasure, restriction, portability, objection, and safeguards around automated decision-making, and Article 34 adds communication duties for high-risk personal-data breaches.

Article 30 requires controllers and processors to maintain records of processing activities. A controller RoPA should cover purposes, categories of data subjects and personal data, recipients, transfers, retention time limits where possible, and a general description of Article 32 security measures. Processor records need the categories of processing carried out for each controller, transfer details where applicable, and security-measure descriptions where possible. The fewer-than-250-person exception is narrow: it does not apply where processing is non-occasional, likely to create risk, or includes Article 9 or Article 10 data.

The Irish DPC guidance is useful because it explains what makes a RoPA reviewable: keep mandatory Article 30 fields visible, make the record available on request, avoid substituting scattered DPIAs or policies for the RoPA, and assign process owners who maintain entries by business function.

Article 32 requires security appropriate to the risk, including measures such as pseudonymisation and encryption where appropriate, confidentiality, integrity, availability, resilience, restoration capability, and regular testing or evaluation of measures. The right security evidence is therefore risk-specific: data sensitivity, access model, retention, supplier access, backup and recovery, monitoring, and control testing.

Article 33 requires controller notification to the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware of a personal-data breach, unless the breach is unlikely to result in a risk to natural persons. Article 34 requires communication to data subjects when the breach is likely to result in high risk, subject to the GDPR's stated conditions.

Article 35 requires a data protection impact assessment where a type of processing is likely to result in a high risk to the rights and freedoms of natural persons, especially with new technologies and considering the nature, scope, context, and purposes of processing. The assessment must describe the processing and purposes, assess necessity and proportionality, assess risks to rights and freedoms, and identify measures to address those risks.

CNIL's PIA methodology grounds the practical structure: define and describe context, analyse controls for fundamental principles, assess privacy risks linked to data security, and formally document validation. Treat a DPIA as a living risk record for the processing activity, not a one-time approval attachment.

Article 25 requires the controller to build appropriate technical and organisational measures into the design of processing and to apply data-protection-friendly defaults. The decision is risk-based: consider the state of the art, implementation cost, the nature, scope, context, and purposes of processing, and the likelihood and severity of risks to people. The default should limit personal data to what is necessary for each purpose, including amount, extent, storage period, and accessibility.

Articles 37 to 39 create a separate data protection officer (DPO) decision. A controller or processor must designate a DPO where it is a public authority or body other than a court acting judicially, or where its core activities require large-scale regular and systematic monitoring, or large-scale processing of Article 9 special-category or Article 10 criminal-offence data. Union or Member State law may require a DPO in additional cases. The DPO must be involved in time, act independently, receive resources and access, report to the highest management level, and perform the monitoring, advice, DPIA, cooperation, and authority-contact tasks in Article 39.

Processor governance starts with Article 28. The controller must use processors that provide sufficient guarantees, and processing by a processor must be governed by a contract or other legal act covering documented instructions, confidentiality, Article 32 security, sub-processors, assistance with rights and breach duties, deletion or return of data, audits, and information needed to demonstrate compliance.

International transfers require a separate Chapter V analysis. Article 44 sets the general principle, Article 45 covers adequacy decisions, Article 46 covers appropriate safeguards such as standard contractual clauses, and Article 49 covers derogations for specific situations. The European Commission SCC page confirms that SCCs are pre-approved model clauses used as a ground for EU-to-third-country transfers under the GDPR.