A GDPR compliance checklist is useful only if each answer can be checked against actual processing. The Regulation does not prescribe one universal annual questionnaire. It requires lawful, fair and transparent processing; proportionate safeguards; respect for people’s rights; and evidence that the controller’s measures work. Use the questions below to find the owner, legal decision, operational control and supporting record for each activity. A “yes” without a source or sample should be marked for verification, not treated as completed compliance.
Start with one activity, such as customer support or employee payroll, and follow the data from collection to deletion. If the organisation has many activities, use a risk-based sample first and expand where it finds gaps. The data privacy principles guide explains the six principles in Article 5(1); Article 5(2) adds accountability. This checklist turns them into review prompts. It does not make every specialist obligation apply to every small business.
1. Does the GDPR apply to this activity?
Identify who determines purposes and means, where that controller or processor is established, and what activity takes place in the context of an EU establishment. Article 3 can also cover a controller or processor outside the Union when it offers goods or services to people in the Union or monitors their behaviour in the Union, in the circumstances specified there. Merely having a European person in a database does not automatically establish territorial scope. The EDPB’s final territorial-scope guidelines help test establishment, targeting and monitoring. Our non-EU applicability guide works through the practical cases.
Confirm that the information relates to an identified or identifiable natural person and that no material-scope exclusion applies. An employee email address, a customer identifier or an IP address may be personal data depending on the facts; a company name alone is not always a person. The personal-data definition guide helps avoid both overinclusive and underinclusive inventories. Record the reason for your scope conclusion, especially where an overseas group has different establishments and services.
Then assign roles by activity. A cloud host may be a processor for customer records, while a payment service may act as an independent controller for its own legal obligations. A vendor label in procurement does not settle purposes and means. The processor definition is a starting point; contracts and practice must agree. Record any joint-controller question separately rather than forcing every recipient into an Article 28 processor form.
2. Can you describe the processing accurately?
List each distinct purpose, categories of people and data, source, recipients, systems, locations, retention criteria and responsible business owner. Follow a sample record through the systems, including exports and backups. The description should be detailed enough to reveal that a CRM entry feeds marketing as well as order fulfilment. A broad “customer management” label can hide different bases and retention periods. Use the ROPA guide to structure the inventory and the purpose-limitation guide when a team proposes a secondary use.
Article 30 sets content requirements for controller and processor records. Its exception for organisations with fewer than 250 people is conditional: it does not apply where processing is nonoccasional, likely to risk rights and freedoms, or involves Article 9 special-category or Article 10 criminal data. Routine payroll or customer operations are not occasional merely because the organisation is small. If an exemption genuinely applies to a limited activity, a lightweight inventory can still help explain how other duties are met. Avoid declaring all controllers and processors exempt or all automatically bound to the same record format.
Review the inventory against procurement and technical systems. A ROPA that names only the central database but omits an email platform or outsourced support desk is not a reliable control document. Ask an owner to confirm the purpose and recipients, then inspect a real configuration or contract. The Article 30 field guide distinguishes mandatory fields from optional management metadata. Put a review trigger on the activity when a new product, processor, location or data category is introduced.
3. Is each purpose lawful and explained?
For each purpose, identify a valid Article 6 basis and the facts making it applicable. Contract necessity under Article 6(1)(b) requires objective necessity for a contract with the data subject or steps requested by that person before it; it is not a convenient basis for all internal operations. Legal obligation requires an applicable law. Legitimate interests require an identified interest, necessity and a balance against the person’s interests and rights. Consent must be free, specific, informed and unambiguous, with withdrawal as easy as giving it. The legitimate-interest guide and valid-consent guide address those different tests.
If Article 9 special-category data are involved, identify a specific Article 9(2) condition as well as the Article 6 basis. Criminal-offence data raise Article 10 conditions. Do not use an employment consent box to avoid examining power imbalance or national labour rules. For a newsletter, check ePrivacy and national electronic-marketing rules separately from the GDPR basis. A checkbox is evidence of an action, not proof that the whole processing is necessary, transparent and lawful. The EDPB consent guidelines explain conditions and withdrawal.
Compare the decision with the notice that people saw. Articles 13 and 14 require different information depending on whether data came from the person or another source. Can a reader understand the purposes, bases, recipients, retention and rights without guessing? Check the version displayed at the time of collection. If a new analytics or profiling purpose was added later, update the analysis and notice before relying on the old wording. Transparency is an operational test, not just a privacy-policy file.
4. Are data limited, accurate and retained for a reason?
Ask whether every field is necessary for its specific purpose, not merely useful to have. A delivery form may need an address but not a birth date. Restrict default access to those who need it and correct inaccurate records through a defined route. The privacy-by-design guide shows how defaults and product decisions implement minimisation. A default field can create thousands of unnecessary copies before anyone performs a later cleanup.
For retention, record a criterion or period for each data category and what event starts the clock. Contract records, marketing preferences and support transcripts need not share one deadline. Include legal holds and backups in the procedure. The storage-limitation guide explains why a fixed “seven years for everything” rule is weak; the data-storage guide provides further operational questions. Deletion, anonymisation or restricted archival must be reflected in the system, not merely the policy.
Check a small sample. If a closed account should have lost marketing data, inspect the email platform and exports. If an accounting duty justifies keeping an invoice, separate it from the live profile. Record exceptions and their review date. This is a better control than treating storage limitation as a promise that no record will ever be retained after a deletion request.
5. Can people exercise their rights in practice?
Provide a clear route for access, rectification, erasure, restriction, portability and objection, and assess Article 22 where decisions are solely automated and produce legal or similarly significant effects. Record receipt, identity-check reason, systems searched, decision, response and any follow-up. Under Article 12(3), the normal response period is one month; it may be extended by up to two further months where complexity or number of requests warrants it, provided the person is told within the first month. If refusing to act, Article 12(4) requires the reasons and information on complaint and judicial remedies. An unexplained “closed” ticket is insufficient.
Portability has cumulative conditions under Article 20: qualifying consent or contract basis, automated processing and data provided by the person, with third-party rights and technical feasibility considered. Erasure under Article 17 has exceptions such as certain legal obligations and claims. A checklist that promises universal export or deletion will fail when an invoice must be retained or a response would expose another person. Test a request using a realistic mixed record, not an empty account. The GDPR audit checklist can help sample the whole rights workflow.
Identity checks should be proportionate. Request additional information when there are reasonable doubts; do not require a scan of an identity document by default from an authenticated account holder. For processors, decide how the controller will pass instructions and receive evidence of completion. A separate controller-recipient may have its own obligations; it does not simply obey every instruction intended for a processor.
6. Are processors and transfers understood?
For each processor, check due diligence, documented instructions, appropriate safeguards, assistance, subprocessor conditions, return or deletion, and audit information under Article 28. The binding arrangement may be a contract or another legal act under Union or Member State law meeting the statutory content. Compare the agreed service with what is actually running. A new subprocessor or remote-support location can alter the risk assessment even if the procurement record is unchanged. The processor guide helps classify a service, but the agreement must reflect the specific processing.
Map access and onward transfers outside the EEA. Where Chapter V applies, record the transfer mechanism, recipient, country, legal context and supplementary measures when needed. An EU data-centre address does not prove that all access remains in the EEA; a non-EU supplier is not automatically prohibited. Assign an owner to revisit the assessment when locations or subprocessors change. Separate this question from the Article 6 basis for the underlying processing.
7. Is security proportionate, and can you recover?
Article 32 requires controllers and processors to implement security appropriate to risk, considering state of the art, cost, context and possible harm to individuals. Evaluate confidentiality, integrity, availability and resilience. Depending on the activity, access restriction, multi-factor authentication, encryption, pseudonymisation, logging, backup, restoration and testing may be suitable. The GDPR does not set one universal encryption product, annual training schedule or penetration-test cadence for every controller. The EDPB security guidance for small organisations expressly asks organisations to adapt measures to context.
Document a few plausible failure scenarios. What if a laptop with customer data is lost? What if ransomware blocks a clinical record? What if a support agent sends a file to the wrong customer? Test the controls and recovery steps that matter to those scenarios, and record what failed. A backup is only useful if it can restore required data within an acceptable time. The privacy-by-design guide connects these choices to default access and data minimisation.
Train people for the actions their roles require: reporting a suspicious message, checking a recipient, approving exports or escalating a breach. The exact frequency should reflect role, risk and changes, not an invented “GDPR annual training” rule. Review privileged access after departures and role changes. A written security policy that no one can carry out is weak evidence of a working control.
8. Can you distinguish an incident from a notifiable breach?
Prepare an intake route for loss, unauthorised access, alteration and unavailability of personal data. Article 33(5) requires documenting personal-data breaches, even where notification is not required. The controller must notify the competent supervisory authority without undue delay and, where feasible, within 72 hours after becoming aware, unless the breach is unlikely to result in risk to people’s rights and freedoms. Article 34 communication to affected people has a separate high-risk threshold and exceptions. A processor must inform its controller without undue delay after becoming aware. The breach-handling guide and Article 33 guide develop these decisions.
Record the time of awareness, affected systems, data, people, protective measures and risk reasoning. If facts are missing, notify in phases where the duty has arisen rather than waiting for a perfect final report. Do not turn 72 hours into an automatic clock for every cyber alert: first decide whether personal data were breached and whether the Article 33 threshold is met. Also do not assume encryption always removes risk without checking key protection, availability and the actual incident. Keep the Article 34 communication decision distinct.
Test a tabletop case with the controller, security, support, legal and communications teams. If the internal incident channel takes two days to reach the decision-maker, the statutory timeline may already be at risk. An internal escalation target is an operational choice, not a substitute for the legal standard. Record how the team would contact a processor and obtain the facts it needs.
9. Are high-risk activities identified before launch?
Screen new and materially changed activities for likely high risk. Article 35 requires a DPIA where that threshold is met, including the listed large-scale special-category and systematic-monitoring situations, with national supervisory-authority lists where applicable. The assessment should describe the processing, necessity, proportionality, risks to people and planned measures. It must occur before the processing. If high residual risk remains that the controller cannot mitigate, Article 36 prior consultation may be required. A completed template does not authorise a processing activity without a lawful basis.
Give the project owner a trigger to return to the assessment when scale, data or technology changes. A small pilot can become a large, high-risk operation. Record the screening rationale even when no DPIA is required. The accountability principle is served by an honest decision trail, not by producing identical impact reports for every routine form.
10. Can you demonstrate correction and ongoing ownership?
Article 24 requires the controller to implement, demonstrate, review and update appropriate measures where necessary. Keep a small set of connected evidence for each material activity: current purpose, legal basis, notice, record, processor arrangement, safeguards, retention decision and last review. Assign an owner to unresolved gaps and verify completion. The Article 24 controller-responsibility guide explains why a folder of policies cannot replace an operating control.
A review cadence is a management decision. A full periodic audit can be helpful, but the GDPR does not prescribe a universal annual checklist review. Reopen a decision when a new product, data category, vendor, country, incident or legal requirement changes the facts. Sample live records and permissions rather than relying only on questionnaire answers. The GDPR audit checklist and SME cost guide can help plan the work without inventing an enforcement statistic or a guaranteed fine avoidance.
Use the checklist as a living gap register: describe the issue, risk, owner, action, evidence and review date. Escalate a high-risk processing plan before launch; schedule less urgent documentation repairs according to risk. A person responsible for a specific activity should be able to explain the result in plain language. That is a more useful measure of progress than a single compliance percentage.
Questions commonly asked
Does every small business need a DPO and ROPA?
No universal rule follows from size alone. Article 37 sets specific DPO triggers, and Article 30(5) gives a qualified exception from record obligations for organisations with fewer than 250 people. Recurring, risky or Article 9/10 processing can remove that exception. The DPO role guide explains designation and independence, while the DPO tasks guide helps separate the DPO’s advice and monitoring from management’s decisions.
Does every breach go to the authority within 72 hours?
No. Record and assess the breach. Article 33 notification is required unless risk to rights and freedoms is unlikely; when required it is without undue delay and, where feasible, within 72 hours of awareness. Article 34 individual communication has the separate high-risk threshold.
How often must this checklist be revisited?
Revisit it when facts change and set a risk-appropriate periodic review. Article 24 says measures are reviewed and updated where necessary, not that every controller must perform an annual certification exercise.