GDPR Compliance Checklist: 12 Steps and the Docs You Need
A useful GDPR compliance checklist does two things: it tells you what has to be true, and it tells you what document proves it. Most checklists do the first and skip the second, which is why teams pass their own internal review and then fail their first real regulator inquiry.
This one covers both, written for a SaaS company that processes personal data of people in the EU or UK and wants a program that survives contact with a supervisory authority.
Step 0: Confirm the GDPR Applies to You
Article 3 sets the territorial scope, and it is wider than most non-EU companies expect. You are in scope if:
- You have an establishment in the EU, and process personal data in the context of its activities — regardless of where the processing happens, or
- You are outside the EU but offer goods or services to people in the EU (paid or free), or
- You are outside the EU but monitor the behaviour of people in the EU — which includes analytics, tracking pixels, and behavioural advertising
A US SaaS company with no EU entity, an EU-language pricing page, and a tracking pixel is in scope on the second and third limbs. The UK GDPR applies in parallel for UK data subjects, with its own regulator and its own fine ceilings.
Then settle a question that determines the rest of your obligations: are you a controller, a processor, or both? A controller decides why and how personal data is processed. A processor acts on the controller's documented instructions. Most SaaS companies are controllers for their own marketing, sales, and HR data, and processors for whatever their customers put into the product.
The Seven Principles Every Step Traces Back To
Article 5 is the spine. People often ask about the "6 pillars of GDPR," and the reason the count wobbles is that there are six substantive principles plus one meta-principle:
- Lawfulness, fairness and transparency
- Purpose limitation — collect for specified purposes, do not repurpose silently
- Data minimisation — collect what you need, not what you might need
- Accuracy — keep it correct and up to date
- Storage limitation — delete it when the purpose ends
- Integrity and confidentiality — secure it
And the seventh: accountability — you must be able to demonstrate the other six. That is the principle that converts good intentions into required paperwork, and it is why the documents column below matters as much as the actions column.
The GDPR Compliance Checklist
1. Document a lawful basis for every processing activity
Before you process, you need one of six Article 6 bases: consent, contract, legal obligation, vital interests, public task, or legitimate interests.
If you process special category data (health, biometrics, race, religion, union membership, sex life or orientation, political opinions), you need a second basis under Article 9 on top of the Article 6 one.
Choosing "legitimate interests" is common and legitimate, but it obliges you to run and record a Legitimate Interests Assessment balancing your interest against the individual's rights. An unrecorded LIA is functionally the same as no lawful basis.
Document: lawful basis register, LIAs where relied upon
2. Build a Record of Processing Activities (RoPA)
Article 30 requires a written record of your processing: purposes, categories of data subjects and data, recipients, third-country transfers, retention periods, and a general description of security measures.
The under-250-employees exemption is far narrower than it reads. It falls away if processing is not occasional, is likely to result in risk to individuals, or includes special category data. Any SaaS company processing customer data continuously fails that test. Assume you need a RoPA.
Document: RoPA (controller side, Article 30(1)); processor record (Article 30(2)) if you process for customers
3. Publish Article 13 and 14 privacy notices
Tell people, at the point of collection, who you are, what you collect, why, on what lawful basis, who receives it, whether it leaves the EEA and under what safeguard, how long you keep it, their rights, and their right to complain to a supervisory authority.
Article 13 covers data collected directly from the individual. Article 14 covers data obtained from elsewhere — enriched lead data, for example — and requires notification within a month of obtaining it. Most B2B SaaS companies have an Article 13 notice and no Article 14 process at all.
Document: external privacy notice, employee privacy notice, candidate notice
4. Stand up a data subject request workflow
Individuals have the rights to access, rectification, erasure, restriction, portability, objection, and not to be subject to solely automated decisions with legal or similarly significant effects.
Operationally you need: an intake channel, an identity verification step, a way to find every copy of a person's data across every system, a redaction process for third-party data caught in the export, and a one-month clock (extendable by two months for complex requests, with notice).
The step that fails is never the legal analysis. It is discovering that nobody can enumerate where a given user's data actually lives.
Document: DSAR procedure, request log with dates and outcomes
5. Get consent right where you rely on it
Consent must be freely given, specific, informed, unambiguous, and given by a clear affirmative action. Pre-ticked boxes, bundled consent, and cookie walls that make refusal harder than acceptance all fail.
You must be able to demonstrate consent was given, and withdrawal must be as easy as giving it. Note that cookies and similar technologies are governed by the ePrivacy Directive as implemented nationally, not only by GDPR — which is why the consent bar for tracking is opt-in even when your GDPR basis for the underlying processing is something else.
Document: consent records with timestamp, scope, and version of the notice shown
6. Sign a data processing agreement with every processor
Article 28 requires a written contract with every processor covering subject matter, duration, nature and purpose, types of data, categories of data subjects, and a specific list of processor obligations.
This is the most-skipped step and the easiest to check. Every analytics tool, CRM, support desk, email platform, hosting provider, and AI vendor touching personal data needs one. So does every sub-processor beneath them.
We cover the required clauses and the common gaps in detail in our post on the GDPR data processing agreement.
Document: signed DPAs, sub-processor list, vendor due-diligence records
7. Put a valid mechanism behind every transfer out of the EEA
Chapter V restricts transfers to third countries. Your options are an adequacy decision (including the EU-US Data Privacy Framework for certified US recipients), Standard Contractual Clauses, or Binding Corporate Rules.
SCCs alone are not sufficient. Since Schrems II you must also run a Transfer Impact Assessment examining whether the destination country's laws undermine the safeguards, and apply supplementary measures where they do.
Map this against your actual infrastructure: a US-hosted database, a support tool with offshore agents, and a sub-processor in a third country are three separate transfers needing three answers.
Document: transfer register, executed SCCs, TIAs
8. Implement Article 32 security measures
Article 32 requires appropriate technical and organisational measures, explicitly naming pseudonymisation, encryption, confidentiality, integrity, availability, resilience, restoration after an incident, and regular testing of effectiveness.
If you already hold ISO 27001 or a SOC 2 report, the control work is largely done — but map your controls to Article 32 explicitly rather than assuming the certificate speaks for itself. Regulators want the mapping, not the badge.
Document: security policy set, control-to-Article-32 mapping, penetration test and review results
9. Build a 72-hour breach notification process
A personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to individuals. If the risk is high, you must also notify affected individuals without undue delay.
Seventy-two hours is not long enough to build the process after the fact. You need a defined trigger, a named decision-maker, a severity assessment method, pre-drafted notification templates, and the supervisory authority's submission route bookmarked.
You must record every breach in an internal register, including those you decide not to report, with the reasoning for that decision.
Document: breach response procedure, breach register
10. Run DPIAs for high-risk processing
Article 35 requires a Data Protection Impact Assessment before processing likely to result in high risk: large-scale special category processing, systematic monitoring of public areas, systematic and extensive automated evaluation with significant effects, and whatever else your national authority has put on its mandatory list.
Do the screening for every new feature that touches personal data. Record the "no DPIA needed" conclusions too — an empty DPIA register looks like an absent process, not a low-risk business.
Document: DPIA screening questions, DPIA register, completed DPIAs
11. Decide on a DPO and an EU/UK representative
Appoint a Data Protection Officer if you are a public authority, if your core activities require regular and systematic monitoring of data subjects on a large scale, or if your core activities involve large-scale special category or criminal-offence data.
Separately, if you are outside the EU but in scope under Article 3(2), Article 27 requires you to designate a representative in the EU — and the UK GDPR requires a UK representative on the same logic. These are two different obligations and companies routinely have neither.
Our post on DPO vs privacy officer covers where the DPO role differs from the privacy lead you may already have.
Document: DPO appointment and independence record, or documented assessment of why one is not required; representative appointment letter
12. Train your people and set retention
Article 32 obliges you to ensure anyone acting under your authority processes personal data only on your instructions. In practice that means annual training plus role-specific training for support, sales, and engineering.
And set actual retention periods per data category, then enforce them technically. "We keep it until it is no longer needed" is not a retention schedule; it is a description of not having one.
Document: retention schedule, deletion evidence, training completion records
What Documents Are Actually Needed
If a supervisory authority opens an inquiry, this is the list they ask for, roughly in order:
- Data protection policy
- External privacy notice and employee privacy notice
- Record of Processing Activities
- Lawful basis register (and LIAs)
- Retention policy and schedule
- Signed DPAs and the sub-processor list
- DSAR procedure and request log
- Breach procedure and breach register
- DPIA register and completed DPIAs
- Transfer register, SCCs, and TIAs
- Consent records
- Training records
That list is also the best self-audit you can run. Ask someone to produce all twelve within an hour. Whatever they cannot find is your actual gap, no matter what your checklist says.
A GDPR Compliance Checklist for Software Development
Article 25 requires data protection by design and by default, which means privacy work belongs in the development lifecycle rather than in a pre-launch review.
Concretely, add these to your definition of done:
- Does this feature collect a new category of personal data? If yes, update the RoPA.
- Is the default setting the most privacy-protective option? Article 25(2) requires it.
- Can this data be deleted and exported per user through an existing path, or does it create a new orphan store?
- Are test and staging environments using synthetic or pseudonymised data rather than a production dump?
- Does this feature make an automated decision with significant effects? That triggers Article 22.
- Do logs capture personal data, and are they inside your retention schedule?
Six questions on the ticket template prevent most of the retrofit work that makes GDPR feel expensive.
A GDPR Checklist for Data Processors
If you process on behalf of customers, your obligations are direct, not inherited. A processor-specific checklist:
- Process only on documented instructions — and push back in writing if an instruction looks unlawful
- Bind staff to confidentiality
- Implement Article 32 security
- Get written authorisation before adding a sub-processor, and flow equivalent terms down
- Assist the controller with data subject requests, DPIAs, and breach handling
- Notify the controller of a breach without undue delay
- Delete or return the data at end of contract, at the controller's choice
- Maintain your Article 30(2) record
- Make information available to demonstrate compliance and allow audits
You do not need a lawful basis — that belongs to the controller. You are still directly liable for the items above, and supervisory authorities have enforced against processors on exactly these points.
On Free Templates, PDFs, and Spreadsheets
Searches for a free GDPR compliance checklist, a GDPR compliance checklist PDF, or a GDPR compliance checklist xls all point at the same instinct: get a structure, then fill it in. That instinct is right, and a data protection checklist template is a fine starting artefact.
Two cautions.
First, most public templates are controller-only. If you are a processor, half the rows do not apply and the rows you actually need are missing.
Second, a spreadsheet is a tracker, not evidence. The row that says "DPAs — complete" proves nothing. The signed agreements do. Keep the tracker if it helps you manage the work, but store the underlying documents somewhere durable and versioned, because those are what get produced under inquiry.
What Non-Compliance Costs
Fines come in two tiers. The lower tier reaches €10 million or 2% of worldwide annual turnover, whichever is higher, and covers records, security, DPIA, and processor obligations. The upper tier reaches €20 million or 4% of worldwide annual turnover and covers the basic principles, lawful basis, consent, data subject rights, and international transfers.
The financial ceiling gets the headlines, but the operational powers matter more to a growing SaaS company. A supervisory authority can order you to suspend data flows or stop processing entirely. For a product built on EU customer data, a stop-processing order is an outage with no engineering fix.
For SaaS-specific implementation detail, see GDPR for SaaS and the GDPR service page. If you handle health data as well, GDPR HIPAA compliance covers running both from one control set, and GDPR and CCPA compliance does the same for US state privacy law.
Frequently Asked Questions
What is required for GDPR compliance? Confirm scope, settle controller/processor status, document a lawful basis per activity, build a RoPA, publish Article 13/14 notices, run a one-month DSAR workflow, get consent right, sign Article 28 DPAs, cover every EEA transfer, implement Article 32 security, build a 72-hour breach process, and assess DPIA, DPO, and Article 27 representative requirements.
What are the 6 pillars of GDPR? Article 5 sets out seven principles: lawfulness/fairness/transparency, purpose limitation, data minimisation, accuracy, storage limitation, and integrity and confidentiality — plus accountability, the requirement to demonstrate the other six. The "six" count usually omits accountability.
What documents are needed for GDPR compliance? Data protection policy, privacy notices (external and employee), RoPA, lawful basis register, retention schedule, signed DPAs and sub-processor list, DSAR procedure and log, breach procedure and register, DPIA register, transfer documentation with SCCs and TIAs, consent records, and training records.
How long do I have to respond to a data subject access request? One month, extendable by two further months for complex or high-volume requests provided you notify the individual within the first month. Responses are free unless the request is manifestly unfounded or excessive, and you carry the burden of proving that.
Do we need a GDPR compliance checklist if we are only a data processor? Yes, a processor-specific one. Documented instructions, staff confidentiality, Article 32 security, sub-processor authorisation and flow-down, assistance to the controller, breach notification, deletion or return at contract end, and an Article 30(2) record.
What are the fines for failing GDPR compliance? Up to €10 million or 2% of worldwide turnover for the lower tier, and up to €20 million or 4% for the upper tier, whichever is higher in each case. Authorities can also order processing to stop, which is usually the bigger operational risk.
Want This Checklist Turned Into a Plan?
ShieldKey Solutions runs GDPR readiness assessments for SaaS companies: we confirm scope, build the RoPA and lawful basis register, review every processor agreement and transfer, and hand back a gap list ranked by regulatory exposure with owners and dates attached. Where you also need CCPA or HIPAA, we build one control set and apply both lenses.