10-Point GDPR Compliance Checklist for Security and Privacy Teams
A practical GDPR checklist covering data mapping, lawful basis, records of processing, PII protection, DPIAs, processor contracts, data subject rights, international transfers and 72-hour breach notification.
The General Data Protection Regulation (GDPR) applies to organisations that process personal data of people in the EU, including many organisations based outside Europe. Security teams sit at the centre of it: Article 32 requires appropriate security for personal data, and Article 33 sets a 72-hour clock for reporting qualifying breaches.
This checklist focuses on the work security, privacy and compliance teams share. It is a practical starting point, not legal advice; confirm your obligations with your data protection officer or legal counsel. Score your current position with the free GRC Compliance Readiness Assessment.
1. Map Personal Data and Data Flows
List the personal data the organisation holds, where it lives, where it comes from, who it is shared with and how long it is kept. Include shadow copies: exports, spreadsheets, backups, test environments, logs and AI tools.
Classify the data. Identify special category data (Article 9, such as health or biometric data) and other high-risk data such as financial details or identity documents, because these need stronger protection.
2. Maintain Records of Processing Activities
Article 30 requires controllers and processors to keep records of processing activities (RoPA). A controller record includes the purposes, categories of data subjects and personal data, recipients, international transfers, retention periods and a general description of security measures.
Treat the RoPA as a living register with owners for each processing activity, and review it when systems or suppliers change.
3. Confirm a Lawful Basis for Every Purpose
Article 6 provides six lawful bases: consent, contract, legal obligation, vital interests, public task and legitimate interests. Record which basis applies to each purpose. Where you rely on legitimate interests, document the balancing test; where you rely on consent, make sure it is freely given, specific, informed and as easy to withdraw as to give.
4. Protect PII With Risk-Based Security Controls
Article 32 requires security appropriate to the risk, and names examples: pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, the ability to restore access after an incident and a process for regularly testing the controls.
- Encrypt personal data in transit and at rest, and manage keys separately from data.
- Apply least privilege and review access to systems holding personal data on a schedule.
- Use MFA for all accounts with access to personal data.
- Pseudonymise or mask data in test, analytics and support environments.
- Log access to sensitive records and alert on unusual bulk access or export.
- Apply retention rules and securely delete data that is no longer needed (storage limitation, Article 5).
- Test backups and restores, and run regular vulnerability scans and penetration tests.
NIST SP 800-122 is a useful companion for rating the confidentiality impact of PII and choosing safeguards.
5. Build Privacy by Design Into Change
Article 25 requires data protection by design and by default. Add privacy questions to architecture reviews, change requests and procurement: what personal data is involved, is all of it needed, who can access it, how long is it kept and how is it deleted.
6. Run DPIAs for High-Risk Processing
Article 35 requires a data protection impact assessment (DPIA) before processing that is likely to result in a high risk to individuals, such as large-scale processing of special category data, systematic monitoring or new technologies including many AI uses.
A DPIA describes the processing, assesses necessity and proportionality, identifies risks to individuals and records the measures that address them. Link DPIA risks to your security risk register so treatments are tracked to completion.
7. Put Processor Contracts and Vendor Reviews in Place
Article 28 requires a written contract with every processor, covering processing only on documented instructions, confidentiality, security measures, sub-processor approval, assistance with data subject rights and breaches, deletion or return of data and audit rights.
Assess each vendor's security before signing and review critical vendors periodically. Keep a list of sub-processors and how you are notified of changes.
8. Handle Data Subject Requests on Time
Individuals have rights of access, rectification, erasure, restriction, portability and objection. Article 12 requires a response without undue delay and within one month, which can be extended by two further months for complex or numerous requests.
Document the process, verify identity before releasing data, and make sure the data map from item 1 lets you find everything held about a person.
9. Control International Transfers
Chapter V restricts transfers of personal data outside the European Economic Area. Transfers need an adequacy decision or appropriate safeguards such as Standard Contractual Clauses, with a transfer risk assessment where required. Check where your cloud and SaaS providers, and their sub-processors, store and access data.
10. Be Ready to Report a Breach in 72 Hours
GDPR fines can reach EUR 20 million or 4% of worldwide annual turnover, whichever is higher, for the most serious infringements. The bigger cost is usually loss of customer trust.
Article 33 requires controllers to notify the supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to result in a risk to individuals. Article 34 requires telling affected individuals when the risk to them is high. Processors must notify the controller without undue delay.
Build these steps into the incident response plan, keep a breach log of every incident including those not reported, and rehearse the decision process in tabletop exercises.
Breach log entry
- Date/time detected and date/time the organisation became aware
- What happened and how it was discovered
- Categories and approximate number of data subjects and records
- Likely consequences for individuals
- Containment and mitigation measures taken
- Risk decision: notify authority? notify individuals? (with rationale)
- Who decided, and when the notification was sentFrequently Asked Questions
Does GDPR apply to companies outside the EU?+
Yes, when they offer goods or services to people in the EU or monitor their behaviour, even if the company has no EU establishment.
What does Article 32 of GDPR require?+
Security of processing appropriate to the risk, including measures such as encryption and pseudonymisation, ongoing confidentiality, integrity, availability and resilience, the ability to restore data after an incident, and regular testing of controls.
When is a DPIA required under GDPR?+
Before processing that is likely to result in a high risk to individuals, such as large-scale use of special category data, systematic monitoring of public areas or innovative technologies.
How long do you have to report a GDPR breach?+
Report qualifying breaches to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of them. Tell affected individuals without undue delay when the risk to them is high.