Most organisations that fail a GDPR investigation had policies in place, but could not show the evidence behind them: no record of why a lawful basis was chosen, no DPIA for the risky system, no log of the breach they decided not to report. This checklist walks through the General Data Protection Regulation (Regulation (EU) 2016/679) article by article and, for each obligation, lists the control to have in place and the evidence a supervisory authority would ask for. It covers principles and accountability, lawful basis, transparency, data subject rights, records of processing (ROPA), DPIAs, processors, security of processing under Article 32, breach notification, DPOs and international transfers. It applies to the EU GDPR and, with the differences noted, to the UK GDPR. It is written for privacy, security and compliance teams in organisations of any size, including small businesses. For how the security obligations work in depth, read the GDPR Compliance Guide for Security Teams.
How to use this template
- Work through sections 1 to 11 in order. For each line record a status (Done, Partial, Not started, Not applicable), an owner, and where the evidence is kept. Replace [Organisation] and other bracketed text with your details.
- "Evidence" means a document or record you could hand to a regulator tomorrow. A policy that says something happens is not evidence that it happens.
- Article references are to the EU GDPR. The UK GDPR keeps the same article numbering for these obligations; the regulator is the ICO and UK transfer tools differ (see section 11). Check for national law changes, such as the UK Data (Use and Access) Act 2025, with your legal adviser.
- Re-run the checklist at least annually and whenever you launch a significant new system, supplier or use of personal data.
- This checklist summarises obligations to help you organise compliance work. It is not legal advice.
1. Scope and roles
| # | Check | Article | Evidence |
| 1.1 | Confirm whether [Organisation] is established in the EU or UK, or offers goods or services to, or monitors, people there. | Art. 3 | Scope memo |
| 1.2 | For each processing activity, decide whether [Organisation] is controller, joint controller or processor. | Art. 4(7), 4(8), 26 | Role recorded in ROPA; joint controller arrangement where relevant |
| 1.3 | If not established in the EU but in scope, appoint an EU representative in writing (and a UK representative for UK GDPR, where required). | Art. 27 | Representative contract |
| 1.4 | Identify your lead supervisory authority if you process across borders in the EU. | Art. 56 | Main establishment analysis |
2. Principles and accountability
| # | Check | Article | Evidence |
| 2.1 | Data protection policy approved by management, covering the seven principles: lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; accountability. | Art. 5, 24 | Approved policy, review date |
| 2.2 | Retention schedule per data category, with deletion actually carried out and logged. | Art. 5(1)(e) | Retention schedule; deletion logs |
| 2.3 | Data protection by design and by default in the project and change process: privacy checkpoint before go-live, minimum data collected, privacy-protective defaults. | Art. 25 | Project gate records; design reviews |
| 2.4 | Staff training on data protection at induction and refreshed [annually], with completion tracked. | Art. 24, 39(1)(b) | Training records |
See the Privacy by Design Guide for Engineering Teams and the Data Retention and Disposal Policy Template.
3. Lawful basis and special categories
| # | Check | Article | Evidence |
| 3.1 | A lawful basis chosen and recorded for each purpose: consent, contract, legal obligation, vital interests, public task or legitimate interests. | Art. 6(1) | Lawful basis column in ROPA |
| 3.2 | Where legitimate interests is relied on (common for security monitoring and fraud prevention), a documented legitimate interests assessment balancing your interest against individuals' rights. | Art. 6(1)(f) | Signed LIA per purpose |
| 3.3 | Where consent is relied on: freely given, specific, informed, unambiguous, as easy to withdraw as to give, and recorded. | Art. 4(11), 7 | Consent records with time, wording and version |
| 3.4 | For special category data (health, biometrics used for identification, ethnicity, religion and others), an Article 9 condition identified in addition to the Article 6 basis. | Art. 9 | Condition recorded in ROPA; appropriate policy document where national law requires |
| 3.5 | Criminal offence data processed only under official authority or a legal authorisation. | Art. 10 | Legal basis recorded |
| 3.6 | Parental consent mechanism for information society services offered directly to children below the national age threshold. | Art. 8 | Age assurance and consent flow |
4. Transparency
| # | Check | Article | Evidence |
| 4.1 | Privacy notices for each group of people (customers, staff, applicants, website visitors) stating identity and contact details, DPO contact, purposes and lawful bases, recipients, transfers, retention and rights. | Art. 13, 14 | Published notices with version history |
| 4.2 | Notices provided at collection, or within one month when data is obtained from a third party. | Art. 13(1), 14(3) | Collection point screenshots |
| 4.3 | Notices written in clear and plain language and easy to find. | Art. 12(1) | Readability review |
5. Data subject rights
| # | Check | Article | Evidence |
| 5.1 | Documented procedure to receive, verify identity for and answer requests for access, rectification, erasure, restriction, portability and objection. | Art. 15 to 21 | Procedure; request log |
| 5.2 | Requests answered without undue delay and within one month, extended only where allowed and with the person told why. | Art. 12(3) | Request log with dates |
| 5.3 | Ability to find a person's data across systems, including backups, logs and SaaS tools. | Art. 15 | Data map; test search results |
| 5.4 | Safeguards for solely automated decisions with legal or similarly significant effects, including human review on request. | Art. 22 (UK GDPR: see Arts. 22B and 22C, inserted by the Data (Use and Access) Act 2025) | Inventory of automated decisions; review process |
See the DSAR Guide: Handling Data Subject Requests.
6. Records of processing (ROPA) and DPIAs
| # | Check | Article | Evidence |
| 6.1 | Record of processing activities kept as controller: purposes, categories of people and data, recipients, transfers and safeguards, retention periods and, where possible, a general description of security measures. | Art. 30(1) | ROPA, with last review date |
| 6.2 | Separate record kept for processing carried out as a processor on behalf of clients. | Art. 30(2) | Processor ROPA |
| 6.3 | If relying on the exemption for organisations under 250 employees, confirm it applies: it does not apply where processing is likely to result in a risk to rights, is not occasional, or includes special category or criminal offence data. Most organisations with any regular processing of staff or customer data should keep a ROPA. | Art. 30(5) | Exemption assessment |
| 6.4 | DPIA screening for every new or changed processing activity, and a full DPIA where processing is likely to result in a high risk, including systematic and extensive profiling with significant effects, large-scale special category data, and large-scale systematic monitoring of public areas, plus your supervisory authority's published list. | Art. 35(1), 35(3), 35(4) | Screening records; completed DPIAs |
| 6.5 | Prior consultation with the supervisory authority where a DPIA shows high residual risk that cannot be mitigated. | Art. 36 | Consultation correspondence |
See the Data Mapping and ROPA Guide, the DPIA Guide and the DPIA Template.
7. Processors and suppliers
| # | Check | Article | Evidence |
| 7.1 | Only processors that provide sufficient guarantees are used, assessed before contract. | Art. 28(1) | Supplier due diligence records |
| 7.2 | A written data processing agreement with each processor covering documented instructions, confidentiality, Article 32 security, sub-processor approval, assistance with rights and breaches, deletion or return at end, and audits. | Art. 28(3) | Signed DPAs, mapped to supplier inventory |
| 7.3 | A processor breach notification window set in hours in the contract, so you can meet your own 72-hour deadline. | Art. 33(2) | DPA clause |
| 7.4 | Sub-processor list held and changes reviewed. | Art. 28(2), 28(4) | Sub-processor register |
8. Security of processing (Article 32)
Article 32 requires technical and organisational measures appropriate to the risk, taking into account the state of the art, cost, and the nature, scope, context and purposes of processing. It names pseudonymisation and encryption, ongoing confidentiality, integrity, availability and resilience, the ability to restore access after an incident, and regular testing of the measures.
| # | Check | Article | Evidence |
| 8.1 | A documented risk assessment that drives security measure choices for personal data. | Art. 32(1), 32(2) | Risk register entries |
| 8.2 | Encryption of personal data in transit and at rest on laptops, mobile devices, databases and backups; pseudonymisation where data is used for analytics or testing. | Art. 32(1)(a) | Encryption standard; device compliance reports |
| 8.3 | Access control: MFA on email, remote access and admin accounts; least privilege; joiner, mover and leaver process; periodic access reviews, including for service accounts and API keys that reach personal data. | Art. 32(1)(b) | MFA coverage report; access review sign-offs |
| 8.4 | Patching, vulnerability management, endpoint protection and logging of access to personal data. | Art. 32(1)(b) | Patch metrics; log retention settings |
| 8.5 | Backups that are tested by restore, with at least one copy protected from ransomware; business continuity plan. | Art. 32(1)(c) | Restore test records |
| 8.6 | Regular testing: penetration tests, vulnerability scans and control reviews, with findings tracked to closure. | Art. 32(1)(d) | Test reports; remediation tracker |
| 8.7 | Staff with access to personal data act only on instructions and are bound by confidentiality. | Art. 32(4) | Contracts; acceptable use policy |
Machine credentials are a common Article 32 gap: API keys and service accounts with read access to customer databases are often unowned and never rotated. See the GDPR Enforcement Decisions on Security Failures Guide for the failures regulators have fined.
9. Personal data breaches
| # | Check | Article | Evidence |
| 9.1 | Breach procedure that covers confidentiality, integrity and availability breaches (ransomware that only encrypts data is still a breach). | Art. 4(12) | Incident response plan |
| 9.2 | Notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to people; reasons given for any delay. | Art. 33(1) | Notification records with timestamps |
| 9.3 | Notification contains the nature of the breach, categories and approximate numbers, DPO contact, likely consequences and measures taken; information may be given in phases. | Art. 33(3), 33(4) | Notification template |
| 9.4 | Affected people told without undue delay where the breach is likely to result in a high risk to them. | Art. 34 | Communication templates; decision record |
| 9.5 | Every breach documented, including those not reported, with facts, effects and remedial action. | Art. 33(5) | Breach log |
| 9.6 | Breach response tested by tabletop exercise at least [annually]. | Art. 32(1)(d) | Exercise report |
See the Data Breach Notification Checklist.
10. Data protection officer
| # | Check | Article | Evidence |
| 10.1 | Decide and record whether a DPO is mandatory: public authorities, and organisations whose core activities involve large-scale regular and systematic monitoring or large-scale special category or criminal offence data. | Art. 37(1) | DPO assessment |
| 10.2 | If appointed, the DPO is involved in all data protection issues, reports to the highest management level, has resources and has no conflicting role. | Art. 38 | Appointment letter; reporting line |
| 10.3 | DPO contact details published and notified to the supervisory authority. | Art. 37(7) | Registration confirmation |
See the Privacy Engineer and DPO Career Guide.
11. International transfers
| # | Check | Article | Evidence |
| 11.1 | Inventory of transfers outside the EEA (or UK), including remote access by support staff and sub-processors. | Art. 44 | Transfer register, linked to ROPA |
| 11.2 | Each transfer relies on an adequacy decision (for the US, only to organisations certified under the EU-US Data Privacy Framework) or an appropriate safeguard such as standard contractual clauses or binding corporate rules. | Art. 45, 46, 47 | Adequacy reference; signed SCCs; BCR approval |
| 11.3 | Transfer impact assessment and supplementary measures (for example encryption with keys held in the EEA) for transfers under Article 46 tools. | Art. 46 | Completed TIAs |
| 11.4 | UK transfers use UK tools (the International Data Transfer Agreement or the UK Addendum to the EU SCCs). | UK GDPR Art. 46 | Signed IDTA or Addendum |
| 11.5 | Derogations (Art. 49) used only for occasional, necessary transfers, not routine ones. | Art. 49 | Derogation record |
See the Standard Contractual Clauses (SCCs) Guide, the Transfer Impact Assessment (TIA) Template and the EU-US Data Privacy Framework Guide.
Implementation guidance
- Start with the data map: sections 3, 5, 6 and 11 all depend on knowing what personal data you hold, where, and who receives it. Build the ROPA first.
- Prioritise by enforcement risk: regulators most often act on security failures, unlawful basis for marketing and monitoring, ignored access requests and late breach notification. Close gaps in sections 8, 9 and 5 before polishing notices.
- Small organisations: you still need a lawful basis, notices, a way to handle requests, basic security (MFA, patching, encryption, backups), processor contracts and a breach log. A short ROPA in a spreadsheet is enough to start.
- Large organisations: assign an owner per processing activity, link the ROPA to the asset inventory and supplier register, and run DPIA screening inside the change process rather than as a separate exercise.
- Keep it current: review the checklist annually, after every significant incident and when law changes.
| Measure | What it shows |
| Share of processing activities with a recorded lawful basis and owner | ROPA completeness |
| Access requests answered within one month | Rights handling works |
| New systems launched with DPIA screening completed | Privacy by design is embedded |
| Processors with a signed Article 28 agreement | Supplier control |
| Breaches assessed within 24 hours and notifiable ones reported within 72 hours | Breach readiness |
Fines under Article 83 follow two tiers: up to EUR 10 million or 2% of total worldwide annual turnover for obligations such as Articles 25 to 39 (including security, records, DPIAs and breach notification), and up to EUR 20 million or 4% for breaches of the principles, lawful basis, data subject rights and transfer rules, whichever is higher in each case. The UK GDPR uses GBP 8.7 million and GBP 17.5 million.
Standards and references
Related NHI Mgmt Group resources: GDPR Compliance Guide for Security Teams · UK GDPR and Data Protection Act 2018 Guide · DPIA Template · Data Breach Notification Checklist · International Data Transfers Map. This guide summarises the GDPR and UK GDPR and is not legal advice.