☑ GDPR Compliance Checklist

A lawful basis is identified and documented for EVERY processing activity

💡 Create a register mapping each processing activity to one of the six lawful bases. No lawful basis = illegal processing.

For special category data, an Article 9 condition is also identified and documented

💡 Special categories (health, race, religion, etc.) need BOTH an Article 6 basis AND an Article 9 condition.

Privacy notices are provided at all data collection points

💡 Every form, app screen, or process that collects personal data needs an accessible privacy notice.

Privacy notices contain ALL required information (identity, purposes, lawful basis, recipients, transfers, retention, rights)

💡 Use the Article 13 list as a checklist — missing any element makes the notice non-compliant.

Privacy notices are written in clear, plain language appropriate to the audience

💡 Test readability with someone outside the legal/privacy team. If they cannot understand it, rewrite it.

Processing is fair — individuals would reasonably expect the processing given the context

💡 Ask yourself: if the data subject knew exactly what we do with their data, would they be surprised or concerned?

Where consent is the lawful basis, it meets all GDPR requirements (freely given, specific, informed, unambiguous)

💡 GDPR consent is a high bar. Pre-ticked boxes, passive acceptance, and bundled consent are all invalid.

Consent is obtained through a clear affirmative action (opt-in, not opt-out)

💡 The user must DO something active: check a box, click a button, toggle a switch. Silence or inactivity is never consent.

Separate consent is obtained for each distinct processing purpose

💡 One checkbox per purpose. Do not bundle email marketing consent with terms of service acceptance.

Consent can be withdrawn as easily as it was given

💡 If consent was given with one click, withdrawal must also be one click. Do not hide the unsubscribe option.

Records of consent are maintained (who, when, what, how)

💡 You must be able to demonstrate that consent was given. Keep a consent ledger with timestamps and versions.

A cookie consent mechanism is in place that blocks non-essential cookies until consent is obtained

💡 Cookie banners that only inform but do not block cookies are not compliant. Non-essential cookies must not fire until the user actively consents.

A documented process exists for handling each of the 8 data subject rights

💡 Create a Standard Operating Procedure (SOP) for each right. Test each process with a mock request before going live.

Data subject requests are responded to within one calendar month

💡 30 calendar days from receipt, not 30 business days. Weekends and holidays count.

Identity verification is performed before fulfilling rights requests

💡 Verify identity proportionately. Do not require more ID than necessary, but do not hand data to the wrong person.

A tracking system is in place with deadline alerts for all rights requests

💡 Use a ticketing system with automated reminders at 14 days and 25 days to prevent deadline breaches.

Staff who interact with data subjects are trained to recognize and escalate rights requests

💡 Customer service, reception, and HR staff should know that a request like 'show me my data' or 'delete my account' is a formal GDPR right.

Responses include all supplementary information required (purposes, recipients, retention, rights)

💡 A DSAR response is not just the data itself — you must also tell them why you have it, who you shared it with, and how long you keep it.

Personal data is encrypted at rest in databases and file storage

💡 Use AES-256 encryption for data at rest. Most modern databases and cloud storage support this natively.

Personal data is encrypted in transit using TLS 1.2 or higher

💡 All web traffic should use HTTPS. All API connections should use TLS. No exceptions for internal traffic.

Access to personal data is controlled on a need-to-know basis (least privilege)

💡 Not everyone needs access to all personal data. Implement role-based access control and review permissions quarterly.

Audit logging is enabled for access to personal data

💡 You need to know who accessed what personal data and when. This is essential for breach investigation and accountability.

Regular vulnerability scanning and penetration testing is conducted

💡 Test your defenses regularly. Annual penetration tests and monthly vulnerability scans are a good baseline.

Backup and disaster recovery procedures are in place and tested

💡 Can you restore personal data if a system fails? Test your backups regularly. Also remember: backup data is in scope for DSARs and erasure.

Pseudonymization is used where feasible to reduce risk

💡 Where you can replace direct identifiers with tokens or pseudonyms (especially in analytics and testing), do so. It reduces risk significantly.

A documented data breach response plan exists with named roles and responsibilities

💡 Do not wait for a breach to figure out what to do. Have a plan, have named people, have templates ready.

Breaches are assessed and reported to the supervisory authority within 72 hours when required

💡 The 72 hours starts when you BECOME AWARE of the breach. Have an on-call process for weekends and holidays.

High-risk breaches are communicated to affected individuals without undue delay

💡 If the breach is likely to result in high risk to individuals, you must tell them directly — not just notify the regulator.

A breach register is maintained documenting all incidents regardless of notification decision

💡 Document EVERY breach, even ones that do not require notification. The regulator may ask to see this register.

Breach response tabletop exercises are conducted at least annually

💡 Practice makes prepared. Simulate a breach scenario annually and walk through the response with all involved teams.

A complete Record of Processing Activities (ROPA) is maintained per Article 30

💡 The ROPA is your master inventory of all personal data processing. Keep it current and review it at least every 6 months.

The ROPA includes all mandatory fields: purposes, data categories, recipients, transfers, retention, security measures

💡 Article 30 lists exactly what must be in the ROPA. Use it as a column-by-column checklist.

Data Protection Impact Assessments are conducted for high-risk processing

💡 If processing involves new tech, profiling, large-scale special data, or systematic monitoring, a DPIA is mandatory BEFORE processing starts.

A Data Protection Officer is appointed where required

💡 Public authorities, large-scale monitoring, and large-scale special data processing ALL require a DPO. When in doubt, appoint one.

Policies, procedures, and compliance evidence are documented and version-controlled

💡 GDPR accountability principle means you must be able to DEMONSTRATE compliance. If it is not documented, it did not happen.

Staff training on GDPR is delivered, documented, and refreshed regularly

💡 Train all staff on GDPR basics at onboarding and refresh annually. Track completion rates as evidence of compliance.

Only personal data that is necessary for the stated purpose is collected

💡 For every data field you collect, ask: do we actually NEED this? If not, do not collect it.

A data retention schedule is defined and documented for all categories of personal data

💡 Every type of personal data should have a defined retention period with a legal or business justification.

Technical controls enforce retention periods (automated deletion or archival)

💡 A policy that says 'delete after 3 years' is useless without technical enforcement. Automate where possible.

Legacy data with no current purpose has been identified and scheduled for deletion

💡 Many organizations have years of accumulated data with no current purpose. This is a liability, not an asset. Identify and dispose of it.

Test and development environments do not contain real personal data (or it is pseudonymized)

💡 Using production personal data in test/dev is a common but risky practice. Use synthetic or pseudonymized data instead.

All cross-border data transfers are identified and documented

💡 Map every data flow that crosses EU/EEA borders — including cloud storage, remote access, vendor processing, and intra-group transfers.

A valid transfer mechanism is in place for each cross-border transfer (adequacy, SCCs, BCRs, derogation)

💡 Every transfer outside the EU/EEA needs a legal mechanism. No mechanism = illegal transfer.

Transfer Impact Assessments (TIAs) have been conducted for transfers relying on SCCs or BCRs

💡 After the Schrems II ruling, SCCs alone are not always enough. You must assess whether the laws of the destination country undermine the protections.

The privacy notice discloses international transfers and the mechanisms used

💡 Individuals have the right to know if their data goes outside the EU/EEA and what protections are in place.

All data processors are identified and recorded in a processor register

💡 Every SaaS tool, cloud provider, and outsourced service that handles personal data on your behalf is a processor.

Article 28-compliant Data Processing Agreements are in place with ALL processors

💡 No DPA = non-compliant processing. Check every vendor. Most large vendors have standard DPAs available.

Sub-processor arrangements are documented and consented to

💡 Your processors may use their own sub-processors. You need to know who they are and ensure they are also bound by appropriate terms.

New vendor onboarding includes a privacy and security assessment

💡 Assess vendor privacy practices BEFORE signing the contract and sharing data. Integrate into procurement.

Processor compliance is reviewed at least annually for high-risk processors

💡 DPAs give you audit rights. Use them — at minimum, send an annual compliance questionnaire to your key processors.