A practical map of the GDPR duties most teams need to operate: scope, Article 5 principles, lawful basis, transparency, rights, security, breach handling, DPIAs, records, processors, and transfers.
Use it to check whether each processing activity has a controller or processor role, a lawful basis, a notice path, a rights workflow, a RoPA entry, security controls, incident routing, and transfer safeguards where needed.
Structured answer sets in this page tree.
Cited legal and guidance references.
The GDPR is not a single checklist. It is a set of connected duties that attach to personal-data processing: decide whether the Regulation applies, identify the controller and processor roles, apply the processing principles, choose and document a lawful basis, give transparent information, enable data-subject rights, keep required records, secure processing, handle breaches, assess high-risk processing, and control transfers outside the EU framework.
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.
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.
Article 5 is the control layer for every GDPR decision. Processing must be lawful, fair, transparent, purpose-limited, data-minimised, accurate, storage-limited, secure, and accountable. Do not treat these as labels; turn each one into a test 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 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 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.
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.
Confirm GDPR scope, assign controller and processor roles, define the purpose, choose a lawful basis, prepare Article 13 or 14 notice content, add the RoPA entry, check rights handling, assess Article 32 security, screen for DPIA need, and identify any Chapter V transfer.
Keep written evidence for lawful basis, transparency notices, RoPA entries, processor terms, security risk assessment and controls, breach assessments, DPIA screening or DPIA results, rights-request handling, retention decisions, and international-transfer safeguards.
Sorena can help convert this GDPR requirements map into scoped processing records, source-linked obligation checks, owner assignments, and evidence requests.
Ask source-linked questions about GDPR scope, lawful basis, RoPA, DPIA, breach, processor, and transfer requirements using the cited sources on this page.
Review your GDPR processing map, source gaps, owner model, and evidence plan with Sorena.
"define and describe the context"
"Standard Contractual Clauses"
"make the record available"
"Processor"