DATA PRIVACY · GDPR
Most GDPR checklists list duties. This one lists the artifacts. Every row names the check, the article it comes from, and the thing you hand a regulator to prove it is done. Start at the gate, because a third of the list may not apply to you.
TL;DR
A GDPR item is done when a document exists, not when someone agrees it is a good idea. Article 5(2) makes you able to demonstrate compliance, so the third column is the real checklist. Work the gate first. If Article 3 does not reach you, nothing below applies.
Every table below carries the same three columns. The first is the check. The second is the article it comes from, so you can read the source rather than take our word for it. The third is the artifact that proves it, and that column is the one that matters. A team can argue for an hour about whether it has a lawful basis. Nobody argues about whether a written balancing test exists.
Work it in the order below. The gate decides whether any of this is yours at all. The foundations produce the record that every later row reads from. After that come the notice, the rights, the vendors, security and transfers. Four duties sit in their own table at the end, because they apply only on a trigger. A company that starts there tends to build something it never needed.
Source: Regulation (EU) 2016/679, Articles 3, 6(1), 15 to 22, 27, 35, 36 and 37
Gate: does any of this apply, and as what #
Four questions come before the checklist. Two of them decide whether you owe anything at all. The other two decide which duties are yours and which belong to someone else in the chain.
Getting the gate wrong is expensive in both directions. A company that assumes the GDPR reaches it, and it does not, spends a quarter on a programme nobody asked for. A company that assumes the opposite misses the two duties that catch North American firms most often. One is the representative in Article 27. The other is the transfer rules in Chapter V. Neither is obvious from the outside, and both arrive with a customer questionnaire rather than a warning.
| Check | Where it comes from | What proves it is done |
|---|---|---|
| You have settled whether the GDPR reaches you | Art 3(1) and 3(2) | A dated written analysis of both limbs, with the Recital 23 markers applied to your own site and product |
| You know which data you control and which you process | Arts 4(7) and 4(8) | A split in the record: your own staff and prospect data on one side, customer data on the other |
| You have checked for joint control | Art 26(1) | Either a written finding of none, or a joint controller arrangement with responsibilities allocated |
| The essence of any joint arrangement reaches the people in it | Art 26(2) | The summary published where a data subject can find it |
What trips people up
Joint control is the quiet one. Two firms that jointly decide why and how data gets used are joint controllers whether or not either of them likes it. Article 26(3) then lets a person exercise rights against either one. Co-marketing, shared analytics and embedded partner widgets all produce it. Most companies have never asked the question. The GDPR overview covers the reach tests in full if the gate is where you are stuck.
Foundations, which everything else reads from #
If you build nothing else, build these seven. Every later section quotes them, and a programme that skips them ends up writing the same facts down four separate times.
The centre of it is the Article 30 record. Teams read that article as a filing chore and put it off. It is the opposite. Once the record exists, four other jobs shrink. The privacy notice is a rewrite of it in plain words. The vendor list is one of its columns. The transfer register is another. Each row already names the lawful basis that row runs on. Without the record, every one of those becomes its own project.
| Check | Where it comes from | What proves it is done |
|---|---|---|
| A record of processing exists, indexed by purpose | Art 30(1) | All seven fields filled: who you are, purposes, categories, recipients, transfers, retention, security measures |
| A processor record exists too, if you act as one | Art 30(2) | Who you act for, categories of work, transfers, a summary of your measures |
| Every purpose carries a lawful basis | Art 6(1) | The basis written in the record, on the purpose row, not in a separate document |
| Special category data carries a second condition | Art 9(2) | The named Article 9(2) condition beside the Article 6 basis |
| Legitimate interests carry a balancing test | Art 6(1)(f) | A written test per purpose: the interest, why processing is necessary, why rights do not override it |
| Retention has a clock, not a hope | Art 5(1)(e) | A period or a stated criterion per data category, and a job that actually deletes |
| Data protection by design and by default is built in | Art 25(1) and 25(2) | Privacy review in your change process, and defaults that collect only what the purpose needs |
What good looks like
One row per purpose, never one row per system. A system serves several purposes and each purpose needs its own basis, so a record indexed by tool cannot produce a clean answer. The GDPR implementation guide sets out the order to build these in and why the record comes first.
Telling people #
Two articles, one notice, and a set of consent machinery most teams forget to build.
| Check | Where it comes from | What proves it is done |
|---|---|---|
| The notice covers every Article 13 item | Art 13(1) and 13(2) | Identity, DPO, purposes and basis, legitimate interests, recipients, transfers, retention, rights, the right to complain, whether data is required, automated decisions |
| Data from other sources gets its own notice | Art 14(3)(a) | A notice sent inside one month of obtaining the data, or a recorded Article 14(5) exemption |
| The notice reads plainly | Art 12(1) | Concise, transparent, intelligible, in clear and plain language |
| You can show that each consent happened | Art 7(1) | A timestamped consent record naming what the person agreed to and the wording they saw |
| The consent request stands apart from other terms | Art 7(2) | A separate, plainly worded request, not a clause buried in the terms of service |
| Withdrawal is as easy as giving | Art 7(3) | A working withdrawal path that reaches every downstream system, tested end to end |
| Service is not conditional on unnecessary consent | Art 7(4) | A check that nothing behind a consent wall is also necessary to perform the contract |
What trips people up
Consent you cannot evidence is consent you do not have. Teams build the checkbox and skip the record, so a year later nobody can say what wording a person agreed to. The withdrawal path fails the same way. It updates the CRM, and the warehouse and the email tool keep the data.
Serving the rights #
Eight rights, one clock, and a process that has to work on a bad week. This is the section a regulator tests first, because a person who complains has often complained about a request you handled badly.
The hard part is not often the policy. It is the extract. An access request asks you to pull one named person’s data out of every system on your record. That includes the ones nobody thinks of as holding personal data. The analytics stack. The support tool. The log store. The backups. Teams discover on day twenty of thirty that nobody can do it. Build the extract before you need it, and time it.
| Check | Where it comes from | What proves it is done |
|---|---|---|
| One route catches every request, however it arrives | Art 12 | A named inbox or queue, plus a rule that staff forward anything that reads like a request |
| You can answer all eight rights | Arts 15 to 22 | A written procedure per right: access, rectification, erasure, restriction, notification, portability, objection, automated decisions |
| An access request produces a copy, not a summary | Art 15(3) | A repeatable extract of one person’s data from every system on the record |
| The clock is tracked | Art 12(3) | A log with the receipt date, the one month due date, and any extension told to the person inside that month |
| Identity gets checked where doubt is reasonable | Art 12(6) | A verification step that does not itself demand excessive new data |
| Marketing objections stop immediately | Art 21(3) | A suppression list honoured across every sending system, with no balancing test applied |
| Requests are answered free of charge | Art 12(5) | A documented reason wherever you charged or refused, since the burden of proof sits with you |
Everyone who touches the data #
Column (d) of your record is a to-do list. Every recipient on it needs paper. The gap between that column and the contract folder is the most common finding in this whole checklist.
It opens without anyone noticing. Someone adds a tool on a corporate card. The vendor ships data to a sub-processor you never authorised. The record catches up months later, if at all. The fix is a reconciliation rather than a policy. List the recipients, list the signed agreements, and work the difference. Your own customers run this same check against you, so the agreement you offer as a processor deserves the same eight clauses.
| Check | Where it comes from | What proves it is done |
|---|---|---|
| Every processor has a contract with all eight clauses | Art 28(3) | Documented instructions, confidentiality, security, sub-processor conditions, help with rights, help with Arts 32 to 36, deletion or return, audit rights |
| Sub-processors need your authorisation | Art 28(2) | A written general or specific authorisation, and a route for the notices of change to reach someone |
| The contract folder matches the record | Art 30(1)(d) | A reconciliation: every recipient named in the record has a signed agreement on file |
| Your own customer contracts carry the same terms | Art 28(3) | A data processing agreement you offer as the processor, covering the same eight clauses |
Security and the breach clock #
Article 32 is the one place an existing security programme does most of the work for you. If you already run an ISMS, most of this section is a mapping exercise rather than a build.
Article 33 is different, and it is where an hour of confusion costs real money. The 72 hours run from the moment you became aware, not from the moment the incident review finishes. Teams argue about when awareness began after the clock has already expired, which is the worst possible time to have that conversation. Name the person who makes that call, name a deputy for when they are on a plane, and write both into the runbook.
| Check | Where it comes from | What proves it is done |
|---|---|---|
| Measures fit the risk | Art 32(1) | Encryption and pseudonymisation where they fit, plus confidentiality, integrity, availability and resilience |
| You can restore after an incident | Art 32(1)(c) | A restore that has been tested, with the date of the last test |
| The measures get tested on a cycle | Art 32(1)(d) | A regular testing and evaluation routine, which an ISO 27001 ISMS already produces |
| Someone owns the moment you became aware | Art 33(1) | A named decision maker and a deputy, written into the runbook |
| The 72 hour path is written down | Art 33(1) | A runbook naming the supervisory authority, the contact route, and what goes in the notice |
| Breaches get logged whether or not you notify | Art 33(5) | An internal breach register with the facts, effects and remedial action for every one |
| High risk breaches reach the people affected | Art 34(1) | A communication template in clear and plain language, ready before you need it |
Transfers out of the EU #
The step that separates a North American programme from a European one. This is a summary, and the implementation guide carries the destination table and the standard clauses problem in full.
The method behind these rows is the European Data Protection Board’s Recommendations 01/2020, adopted 18 June 2021. It runs six steps, from knowing your transfers to re-evaluating them on a cycle, and the implementation guide walks all six. The first step is already in your record, which is why this section sits near the end rather than the start.
| Check | Where it comes from | What proves it is done |
|---|---|---|
| Every transfer out of the EU is listed | Art 30(1)(e) | A transfer register naming the country, the recipient and the route relied on |
| Each one travels on a named route | Arts 45, 46 and 49 | An adequacy decision, an Article 46 safeguard, or a recorded Article 49 derogation |
| Canadian recipients are checked against PIPEDA | Art 45 | A note that the recipient falls inside PIPEDA’s scope, since the 2001 adequacy decision stops there |
| US recipients are checked against the current list | Art 45 | A dated screenshot or note of the Data Privacy Framework listing, plus the re-certification date |
| Where there is no adequacy, the route was assessed | Art 46 | A transfer assessment covering the law and practice of the destination, and any extra measures |
| The whole register gets re-read on a cycle | Art 46 | A dated review, since adequacy decisions and framework listings both move |
What trips people up
Miss the annual re-certification and a Data Privacy Framework listing lapses, with nobody telling your EU customers. Put that renewal date in the same calendar as your audit dates. On the Canadian side, adequacy covers private sector bodies under PIPEDA and nothing else, which is narrower than almost anyone assumes.
The four that apply only on a trigger #
Each of these turns on a threshold, so for many companies the honest answer is no. Write the answer down anyway. “We looked, and here is why not” is the only version that helps you later, and it takes an afternoon.
Two of the four catch North American companies more often than their teams expect. The representative under Article 27 follows from Article 3(2) in nearly every case, and the exemption is narrower than it reads. The impact assessment under Article 35 arrives with any product that scores people by machine, which now describes a great many of them.
| Check | Trigger | What proves it is done |
|---|---|---|
| EU representative appointed | Art 3(2) reaches you and Art 27(2) does not excuse you | A written appointment in a member state where your data subjects live, named in the privacy notice |
| Impact assessment carried out | High risk processing, Art 35(1) and the three Art 35(3) cases | A DPIA with the four Article 35(7) parts: description, necessity and proportion, risks, measures |
| Regulator consulted before launch | Residual high risk after measures, Art 36(1) | The consultation on file, allowing eight weeks for advice and six more for a complex case |
| Data protection officer designated | One of the three Art 37(1) cases | The appointment, the published contact details, and the notification to the regulator |
Keeping the list true #
A checklist decays the day the record stops matching the systems. Four routines hold it, and all four read from the record you built at the top.
- New system, new row. Route every new tool and every new use of data through the record before it goes live. This one control keeps the rest honest.
- Vendor reconciliation. Recipients in the record against agreements on file, plus every sub-processor notice you were sent.
- Transfer re-read. Dated, because adequacy decisions and framework listings move without telling you.
- A rights rehearsal. Run a request against your own data once a year and time it. A process nobody has tried is a plan, not an operation.
Article 31 sits behind all of it. You cooperate with the regulator on request, and cooperation goes well only when the documents already exist. If you would rather a certified system held the list than a folder of habits, that is what a privacy information management system does. Start with what ISO 27701 certification is, then how to design and implement a PIMS. It counts as evidence under Articles 24(1) and 32(1). It is not an Article 42 certificate, a difference we set out in ISO 27701 vs GDPR.
Frequently asked questions #
What is on a GDPR compliance checklist?
Nine items apply to everyone. A reach analysis under Article 3. A record of processing under Article 30. A lawful basis for every purpose under Article 6. A privacy notice under Articles 13 and 14. A process for the eight rights. Contracts with every processor under Article 28. Security and a breach runbook under Articles 32 to 34. And a transfer register under Chapter V. Four more apply only on a trigger: the EU representative, the impact assessment, prior consultation and the data protection officer.
How do we prove GDPR compliance to a regulator?
With documents. Article 5(2) makes you responsible for the principles and able to demonstrate that you meet them. The deliverable for each item is an artifact, not an intention. A regulator asks to see the record of processing and the written balancing tests. It asks for the consent records and the rights log. It asks for the signed processor contracts, the breach register and the transfer register.
Which items can a small company skip?
Fewer than most expect. Article 30(5) lifts the record duty for firms under 250 staff. The carve-out falls away in three cases. The work risks people’s rights. It happens other than now and then. It touches special category or criminal record data. Running a product all year is not occasional. The four trigger duties genuinely may not apply, which is why they sit in their own table.
Do we need a GDPR checklist if we already have SOC 2 or ISO 27001?
Yes, because those cover the security half and not the privacy half. An ISO 27001 ISMS does most of Article 32 and the testing clause, and SOC 2 evidences much the same controls. Neither picks a lawful basis, writes a privacy notice, serves an access request or answers the transfer question.
What is joint control, and why is it on the checklist?
Two or more controllers who jointly decide the purposes and means of processing are joint controllers under Article 26(1). Intent does not matter. They need an arrangement allocating responsibilities, and the essence of it has to reach the data subject. Article 26(3) then lets a person exercise rights against either party. Co-marketing, shared analytics and embedded partner widgets all produce it, and almost nobody checks.
How long do we have to answer a rights request?
One month from receipt under Article 12(3), without undue delay. A complex or high volume request buys two further months, and only if you tell the person inside the first month why. The answer costs the person nothing. Article 12(5) puts the burden on you to show a request is manifestly unfounded or excessive before you charge or refuse.
Does a GDPR checklist expire?
The items do not, but your answers do. Adequacy decisions and Data Privacy Framework listings change, new systems appear, and vendors add sub-processors. Route every new system through the record, reconcile vendors on a cycle, and re-read the transfer register with a date on it. That is the difference between a checklist you completed once and a programme.
Key takeaways #
- Work the gate first. If Article 3 does not reach you, the rest of the list is optional.
- An item is done when the artifact exists. Article 5(2) asks you to demonstrate, not to intend.
- The Article 30 record is the spine. Index it by purpose, and every other row on the list reads from it.
- Consent needs three built things: a timestamped record, a withdrawal path that reaches every system, and a rule for the data afterwards.
- Check for joint control. Co-marketing and shared analytics create it, and almost nobody asks.
- Reconcile the recipient column against the contract folder. That gap is the most common finding.
- Canada’s adequacy stops at PIPEDA, and a Data Privacy Framework listing lapses if you miss the yearly re-certification.
- Four duties apply only on a trigger. Write down the reasoning even when the answer is no.
Turn the checklist into the artifacts #
A compliance manager works this list with your team and produces the record, the notice, the contracts and the runbooks. Then they keep it all true as your systems change. The same work carries ISO 27701, ISO 27001 and SOC 2, so you evidence it once.
