A GDPR compliance checklist is a structured set of action items that organisations use to verify they meet all requirements of the EU General Data Protection Regulation, covering data inventory, lawful processing, data subject rights, security measures, breach procedures, and documentation obligations.
Knowing what GDPR requires and actually doing it are two different problems. According to the DLA Piper GDPR Fines and Data Breach Survey (January 2026), supervisory authorities across the EEA imposed over EUR 4.2 billion in fines during 2025 alone, a 32% increase year-on-year. The IAPP-EY Governance Report found that only 28% of organisations consider themselves fully GDPR compliant, even eight years after enforcement began.
The gap is rarely about awareness. Most compliance teams understand the principles. What trips them up is execution: missing a processing activity in the record of processing, forgetting to update a data processing agreement after switching vendors, running a marketing campaign without a valid legal basis. These are operational failures, not knowledge failures, and a structured checklist eliminates them.
This checklist breaks GDPR compliance into four phases that any organisation can follow, whether you are building a programme from scratch or auditing an existing one. Each item includes the relevant GDPR article, a clear action, and a completion criteria so you know when it is done.
Quick Reference
Details
What is this checklist?
A phased, step-by-step action plan for GDPR compliance
Who is it for?
DPOs, compliance officers, IT managers, founders handling EU personal data
A structured checklist converts GDPR's 99 articles into actionable, sequenced tasks with clear ownership and deadlines
Phase 1 (Weeks 1-4) covers the foundation: appointing a project lead, building a data inventory (Article 30), mapping data flows, and documenting lawful bases (Article 6)
Share article
Need help with compliance?
Contact us for a free consultation
Phase 2 (Weeks 4-8) addresses data subject rights, privacy notices, consent management, and processor agreements (Articles 13-14, 15-22, 28)
Phase 3 (Weeks 8-12) focuses on technical security, DPIAs for high-risk processing, breach notification workflows, and staff training (Articles 32-35)
Phase 4 (Ongoing) establishes governance: DPO appointment, regular audits, privacy by design, and continuous documentation for accountability (Articles 5(2), 25, 37)
Organisations that follow a phased approach are 3x more likely to pass supervisory authority audits without corrective orders (IAPP-EY Governance Report 2025)
The checklist works for any organisation size, from a 5-person startup to a multinational enterprise, with the scope of each item scaling to your processing activities
GDPR enforcement is accelerating. The numbers tell the story:
EUR 4.2 billion in fines issued during 2025, up from EUR 3.1 billion in 2024 (DLA Piper GDPR Fines Survey 2026)
2,086 enforcement actions across EEA supervisory authorities in 2025 (EDPB Annual Report)
72% of organisations self-report as "partially compliant" or below (IAPP-EY Governance Report 2025)
The average GDPR fine increased to EUR 2.1 million in 2025, up from EUR 1.4 million in 2023
These are not abstract numbers. Meta was fined EUR 1.2 billion for unlawful transatlantic data transfers. Clearview AI received a EUR 20 million fine from the French CNIL. Criteo paid EUR 40 million for consent violations. Each of these failures could have been caught by a systematic compliance review. For a comprehensive breakdown of fine trends, enforcement patterns, and compliance spending across the EU, see our EU Compliance Statistics 2026 report.
The organisations that avoid fines share a pattern: they follow a structured, documented compliance process rather than relying on institutional knowledge or ad hoc reviews. A checklist provides that structure. It ensures nothing is missed, creates an audit trail for accountability (Article 5(2)), and gives supervisory authorities clear evidence that you take data protection seriously.
For a full explanation of GDPR's principles, lawful bases, and data subject rights, see the GDPR Compliance Guide. This checklist assumes you understand the basics and focuses on implementation.
Phase 1: Foundation (Weeks 1-4)
Phase 1 builds the foundation that every other compliance activity depends on. You cannot write accurate privacy notices without knowing what data you process. You cannot assess risk without understanding your data flows. Start here.
1.1 Appoint a project lead and secure management commitment
Designate a GDPR project lead with authority to coordinate across departments (Article 24). This may be your future DPO, a compliance officer, or an external advisor.
Obtain written management commitment confirming budget, resources, and executive sponsorship for the compliance programme.
Define the project scope: which entities, business units, geographies, and processing activities are covered.
Set a realistic timeline with milestones for each phase. Twelve weeks is achievable for most mid-size organisations; larger enterprises may need 16-24 weeks.
Completion criteria: A named project lead, a signed management commitment document, and a project plan with milestones.
1.2 Create a data inventory and record of processing activities (ROPA)
Article 30 requires controllers and processors to maintain a record of processing activities. This is not optional, and supervisory authorities routinely request it as their first step in any investigation.
Identify every processing activity across all departments: HR (employee records, recruitment), marketing (email lists, analytics, CRM), sales (prospect data, contracts), IT (system logs, support tickets), finance (invoicing, payment data), operations (visitor logs, CCTV).
Document required ROPA fields for controllers (Article 30(1)): name and contact details of the controller, purposes of processing, categories of data subjects, categories of personal data, categories of recipients, international transfers (including safeguards), retention periods, and a general description of technical and organisational security measures.
Document required ROPA fields for processors (Article 30(2)): name and contact details of the processor and each controller, categories of processing, international transfers, and security measures.
Assign a data owner to each processing activity who is responsible for keeping the record accurate.
Establish a ROPA update process: define triggers (new vendor, new project, change in processing) and frequency (at minimum quarterly review).
For a detailed walkthrough of building your data inventory, see the Data Mapping Guide.
Completion criteria: A complete ROPA covering all processing activities, stored in a centrally accessible format (spreadsheet, GRC tool, or dedicated privacy management software), with assigned data owners.
1.3 Map all data flows
A data inventory tells you what you process. Data flow mapping tells you how data moves through your organisation.
Map internal data flows: how personal data moves between departments, systems, and databases. Include automated transfers (API integrations, ETL pipelines) and manual processes (email forwarding, spreadsheet exports).
Map external data flows: data shared with processors, sub-processors, business partners, and group companies. Document the direction of flow (outbound, inbound, bidirectional).
Identify cross-border transfers: any transfer of personal data outside the EEA. Document the destination country, the transfer mechanism (adequacy decision, standard contractual clauses, binding corporate rules), and the supplementary measures in place (Article 46).
Document data storage locations: physical and cloud locations where personal data resides. Include primary databases, backups, archives, and any shadow IT systems.
Validate data flow diagrams with IT, department heads, and key processors to ensure completeness.
Completion criteria: Visual data flow diagrams (or equivalent documentation) covering all internal, external, and cross-border flows, validated by relevant stakeholders.
1.4 Identify and document lawful bases for each processing activity
Every processing activity must have a lawful basis under Article 6(1). There are six options: consent, contractual necessity, legal obligation, vital interests, public interest, and legitimate interests. Choosing the wrong one, or failing to document any, is one of the most common enforcement triggers.
Assign a lawful basis to each processing activity in your ROPA. Document why that basis applies (not just the label).
For consent-based processing: verify that consent meets the GDPR standard (freely given, specific, informed, unambiguous; Article 7). Document when and how consent was collected, and confirm withdrawal mechanisms are functional.
For legitimate interests: complete a legitimate interests assessment (LIA) for each activity relying on Article 6(1)(f). The LIA must balance your interests against the rights of the data subject and document the outcome.
For contractual necessity: confirm the processing is genuinely necessary to perform the contract, not merely convenient. Bundling unrelated processing under "contract" is a common mistake that supervisory authorities challenge.
For legal obligations: identify the specific law or regulation that mandates the processing.
Completion criteria: Every processing activity in the ROPA has a documented lawful basis with supporting justification.
1.5 Review special category data processing
Article 9 imposes stricter conditions on processing special categories of personal data: racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data (for identification), health data, sex life, or sexual orientation.
Identify all special category data in your data inventory. Common areas: employee health records, diversity monitoring, biometric access controls, health and safety reports.
Document the Article 9(2) condition that permits processing for each activity. The most common conditions are: explicit consent (9(2)(a)), employment obligations (9(2)(b)), and substantial public interest (9(2)(g)).
Verify that additional safeguards are in place: access restrictions, encryption, minimisation, and shorter retention periods.
Check national derogations: some member states impose additional requirements for health, genetic, or biometric data. Confirm compliance with applicable national law.
Completion criteria: All special category processing is identified, each has a documented Article 9(2) condition, and additional safeguards are implemented and documented.
Phase 2: Rights & Notices (Weeks 4-8)
With your data inventory, flows, and legal bases documented, Phase 2 ensures you can fulfil your transparency obligations and respond to data subjects exercising their rights.
2.1 Draft or update privacy notices
Articles 13 and 14 require you to provide specific information to data subjects at the point of collection (Article 13) or within a reasonable period when data is obtained indirectly (Article 14).
Audit existing privacy notices against the Article 13/14 requirements. Common gaps: missing retention periods, vague descriptions of lawful bases, no mention of international transfers, missing DPO contact details.
Create or update your main privacy notice to include all mandatory information: controller identity, DPO contact details, purposes and lawful bases, data categories, recipients, international transfers and safeguards, retention periods, data subject rights, right to complain to a supervisory authority, and (where applicable) the source of the data.
Ensure notices are concise, transparent, intelligible, and in clear, plain language (Article 12(1)). Avoid legal jargon. Use layered notices (short summary with link to full version) for better usability.
Make notices accessible: published on your website, provided in onboarding packs, displayed at data collection points.
Completion criteria: All privacy notices are up to date, cover all Article 13/14 requirements, and are published or distributed at all relevant data collection points.
2.2 Implement data subject request (DSR) procedures
Data subjects have the right to access (Article 15), rectification (Article 16), erasure (Article 17), restriction (Article 18), data portability (Article 20), and objection (Article 21). You need a process for handling each.
Create a DSR intake process: a dedicated email address (e.g., privacy@company.com), a web form, or both. Ensure the process is easy to find and use.
Define identity verification procedures to prevent fraudulent requests without creating excessive barriers for legitimate data subjects.
Establish response workflows: who receives the request, who gathers the data, who reviews the response, who approves it, who sends it. Document SLAs (the GDPR deadline is one month, extendable by two months for complex requests).
Build templates for each type of response: acknowledgement, data export (portable format for portability requests), erasure confirmation, restriction confirmation, objection response, and refusal (with explanation of grounds).
Implement technical capabilities: can your systems actually export data in a structured, commonly used, machine-readable format (Article 20)? Can you locate and delete all instances of a person's data across all systems?
Train frontline staff (customer service, HR, reception) to recognise DSRs, even when they are not explicitly labelled as such. A customer emailing "delete my account" is an erasure request.
Log all DSRs with timestamps, actions taken, and response dates for accountability.
Completion criteria: A documented DSR procedure, response templates, trained staff, and a logging system. Test the process with a simulated request.
2.3 Set up consent management
Where consent is your lawful basis, it must meet the GDPR standard: freely given, specific, informed, and unambiguous (Article 7). Pre-ticked boxes, bundled consent, and implied consent do not qualify.
Audit all consent collection points: website forms, app onboarding, email signup, cookie banners, event registration, third-party data purchases.
Verify each consent mechanism meets the GDPR standard: separate consent for separate purposes, clear affirmative action, no pre-ticked boxes, no consent bundled with terms of service, easy to withdraw.
Implement a consent management platform (CMP) or equivalent system to record, manage, and audit consent. The CMP must log: who consented, when, to what, how, and the version of the notice presented.
Build a consent withdrawal mechanism that is as easy as giving consent (Article 7(3)). If consent was given with one click, withdrawal should not require a phone call.
Review historical consent: if existing consent was collected before GDPR or does not meet the current standard, plan to re-consent or switch to a different lawful basis.
Completion criteria: All consent-based processing has compliant collection mechanisms, a CMP logging consent records, and functional withdrawal processes.
2.4 Review cookie and tracking practices
The ePrivacy Directive (2002/58/EC), implemented through national laws, requires consent for non-essential cookies and similar tracking technologies. GDPR governs the processing of personal data collected through those trackers.
Audit all cookies and trackers on your website(s) and apps. Categorise them: strictly necessary, functional, analytics, marketing/advertising.
Implement a cookie consent banner that blocks non-essential cookies until the user gives affirmative consent. Do not use "cookie walls" that force consent as a condition of access (most DPAs consider these non-compliant).
Ensure your cookie banner is compliant: equal prominence for "Accept" and "Reject" (the CNIL and several other DPAs have enforced this), granular options, no dark patterns.
Update your cookie notice with: each cookie's name, purpose, provider, type, duration, and whether it involves international transfers.
Verify Google Analytics, Meta Pixel, and similar tools are configured to respect consent signals. Implement Google Consent Mode v2 if applicable.
Completion criteria: A compliant cookie consent mechanism, a complete cookie inventory, and verified technical implementation blocking trackers until consent.
2.5 Create data processing agreements (DPAs) with all processors
Article 28 requires a binding contract between every controller and processor. No handshake deals, no unsigned terms of service.
List all processors from your data flow mapping: cloud providers, SaaS tools, marketing platforms, payroll providers, IT support companies, analytics services, payment processors.
Review existing contracts for Article 28 compliance. The DPA must include: subject matter and duration, nature and purpose of processing, type of personal data and categories of data subjects, controller's obligations and rights, processor obligations (security, sub-processor management, assistance with DSRs, deletion/return of data, audit rights).
Negotiate or execute DPAs where they are missing or non-compliant. Many SaaS providers have standard DPAs available (check their legal/privacy pages), but review them rather than blindly accepting.
Document sub-processors for each processor and establish a notification process for sub-processor changes (Article 28(2)).
Include international transfer clauses where processors or sub-processors are located outside the EEA.
Completion criteria: A signed DPA with every processor, covering all Article 28 requirements, with sub-processors documented.
Phase 3: Security & Breach (Weeks 8-12)
Phase 3 addresses the technical and organisational security measures that protect personal data, the processes for detecting and reporting breaches, and the staff training that makes all of it work in practice.
3.1 Implement appropriate technical and organisational measures
Article 32 requires security measures "appropriate to the risk," considering the state of the art, implementation costs, and the nature, scope, context, and purposes of processing.
Conduct a risk assessment for each processing activity, evaluating the likelihood and severity of harm from unauthorised access, loss, destruction, or disclosure.
Implement encryption: data at rest (database encryption, full-disk encryption) and data in transit (TLS 1.2+ for all connections, VPN for remote access).
Implement access controls: role-based access (principle of least privilege), multi-factor authentication for systems containing personal data, regular access reviews (quarterly at minimum).
Implement pseudonymisation where feasible, particularly for analytics, testing, and development environments (Article 32(1)(a)).
Secure physical access: controlled entry to server rooms, clean desk policies, secure disposal of physical media.
Review vendor security: request SOC 2 reports, ISO 27001 certificates, or equivalent assurance from all processors handling personal data.
Document all measures in a security policy that maps controls to the risks they mitigate. This documentation is essential for demonstrating compliance under Article 5(2).
Completion criteria: A documented risk assessment, implemented technical and organisational measures proportionate to identified risks, and evidence of regular review.
3.2 Conduct Data Protection Impact Assessments (DPIAs)
Article 35 requires a DPIA before any processing that is "likely to result in a high risk to the rights and freedoms of natural persons." The EDPB and national DPAs have published lists of processing types that require a DPIA.
Screen all processing activities against DPIA triggers: systematic and extensive profiling with significant effects, large-scale processing of special category data, systematic monitoring of publicly accessible areas, new technologies, automated decision-making (including profiling) with legal or similarly significant effects, large-scale data matching or combining, processing of vulnerable individuals' data (children, employees, patients), and any processing appearing on your national DPA's DPIA-required list.
Conduct DPIAs for all identified high-risk processing. Each DPIA must include: a systematic description of the processing and its purposes, an assessment of necessity and proportionality, an assessment of risks to data subjects, and the measures to mitigate those risks (Article 35(7)).
Consult your DPO (if appointed) on each DPIA. The DPO's role is to advise, not to approve (Article 39(1)(c)).
If residual risk remains high after mitigation, consult the supervisory authority before proceeding (Article 36).
Review DPIAs when processing changes or at least every two years.
Completion criteria: DPIAs completed for all high-risk processing activities, reviewed by the DPO, with documented mitigation measures and a review schedule.
3.3 Create breach detection and notification procedures
Articles 33 and 34 impose strict timelines: notify the supervisory authority within 72 hours of becoming aware of a breach that poses a risk to individuals, and notify affected data subjects "without undue delay" when the breach is likely to result in a high risk.
Define what constitutes a "personal data breach" in your organisation's context (any breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data). Train staff to recognise breaches: lost laptops, misdirected emails, ransomware, unauthorised access, improper disposal.
Hours 48-72: Prepare and submit supervisory authority notification (Article 33)
If high risk to individuals: prepare and issue data subject notifications (Article 34)
Prepare notification templates: supervisory authority notification form (most DPAs have online portals), data subject notification letter/email, internal escalation memo, processor breach notification clause activation.
Establish a breach register (Article 33(5)) documenting all breaches, regardless of whether they are notifiable: facts, effects, and remedial actions taken.
Test the process: conduct a tabletop breach simulation at least annually. Time the exercise to verify you can meet the 72-hour deadline.
Completion criteria: A documented breach response plan, a trained response team, notification templates, a breach register, and at least one completed tabletop exercise.
3.4 Train all staff handling personal data
The best policies and procedures fail if the people executing them do not understand their role. GDPR does not explicitly mandate training, but Article 39(1)(b) requires the DPO to "raise awareness" and Article 32 requires appropriate "organisational measures," which supervisory authorities consistently interpret to include staff training.
Deliver GDPR awareness training to all employees, covering: what personal data is, the principles, their role in protecting data, how to recognise DSRs, how to report breaches, and the consequences of non-compliance.
Deliver role-specific training for high-risk functions: HR (employee data handling), marketing (consent and direct marketing rules), IT (security measures and incident response), customer service (DSR recognition and handling), procurement (vendor assessment and DPA requirements).
Document training delivery: dates, attendees, content covered, assessment results.
Schedule refresher training at least annually, with additional training triggered by significant changes (new processing activities, regulatory updates, post-breach lessons learned).
Assess comprehension: use quizzes or practical scenarios to verify understanding, not just attendance.
Completion criteria: All staff trained, role-specific training delivered to relevant teams, training records documented, and a recurring schedule established.
Phase 4: Governance & Maintenance (Ongoing)
Compliance is not a project with an end date. Phase 4 establishes the governance structures that keep your programme current as regulations evolve, your processing activities change, and enforcement expectations tighten.
4.1 Appoint a DPO if required (or engage an outsourced DPO)
Article 37 requires a Data Protection Officer when the controller or processor is a public authority, when core activities involve large-scale systematic monitoring, or when core activities involve large-scale processing of special category data. Many national laws expand this requirement further (Germany requires a DPO if 20+ employees regularly process personal data).
Assess whether DPO appointment is mandatory under Article 37 and applicable national law.
Even if not mandatory, consider voluntary appointment: supervisory authorities view it positively, and it demonstrates accountability.
Decide between internal and external DPO. An outsourced DPO provides GDPR expertise at 60-80% lower cost than a full-time hire, with access to a team of specialists rather than a single individual.
Formally designate the DPO: internal appointment letter or service contract (Article 37(6)).
Notify the supervisory authority of the DPO's contact details (Article 37(7)).
Publish the DPO's contact details in your privacy notice (Articles 13(1)(b), 14(1)(b)).
Ensure independence: the DPO must not receive instructions regarding the exercise of their tasks, must report to the highest level of management, and must not be penalised for performing their duties (Article 38).
Completion criteria: DPO appointed (or a documented decision that appointment is not required), supervisory authority notified, privacy notices updated.
4.2 Schedule regular compliance audits
Compliance degrades over time as new processing activities are added, vendors change, staff turn over, and regulations evolve. Regular audits catch drift before it becomes a violation.
Establish an audit calendar: comprehensive annual audit of the full compliance programme, plus quarterly reviews of high-risk areas (ROPA accuracy, DSR response times, breach register, consent records).
Define audit scope and methodology: internal audit, external audit (e.g., engaging a firm like Vision Compliance for an independent assessment), or a combination.
Audit the ROPA against actual processing activities. Verify that new systems, vendors, and projects have been added.
Audit DSR response logs: are requests being handled within the one-month deadline? Are any patterns of delay or refusal emerging?
Audit consent records: are all consent-based processing activities backed by valid, documented consent?
Audit processor agreements: are all DPAs current? Have any processors changed sub-processors without notification?
Document findings, remediation actions, and deadlines in an audit report. Track remediation to completion.
Completion criteria: An audit calendar with defined frequency and scope, a completed initial audit, and a remediation tracking process.
4.3 Implement privacy by design and default
Article 25 requires data protection by design and by default. This means privacy considerations must be embedded into new projects, products, and processing activities from the earliest design stage, not bolted on after launch.
Integrate privacy review into your project lifecycle: add a privacy assessment step to your product development, procurement, and IT change management processes.
Create a privacy by design checklist for new projects: What personal data will be processed? Is the processing necessary (data minimisation)? What is the lawful basis? What are the retention periods? What security measures are required? Is a DPIA needed?
Default to the most privacy-protective settings: collect only what is necessary, limit access to those who need it, retain data only as long as required, anonymise where possible.
Document privacy by design decisions for each project. This documentation supports accountability and is valuable evidence in case of a supervisory authority inquiry.
Completion criteria: Privacy by design integrated into project and procurement processes, a reusable checklist for new projects, and documented decisions for existing projects.
4.4 Monitor regulatory guidance and enforcement trends
GDPR interpretation evolves through EDPB guidelines, national DPA guidance, and CJEU (Court of Justice of the EU) rulings. Staying current is not optional.
Subscribe to EDPB publications: guidelines, opinions, consistency decisions, and enforcement action summaries.
Monitor your national DPA's guidance: enforcement decisions, guidance papers, and FAQ updates.
Track CJEU data protection rulings: recent landmark cases have significantly affected consent requirements, legitimate interests assessments, and international transfers.
Monitor enforcement trends: DLA Piper and IAPP publish annual enforcement reports. Track the types of violations being penalised and adjust your programme accordingly.
Assign responsibility for regulatory monitoring to a specific person or role (ideally your DPO).
Brief leadership quarterly on significant regulatory developments and their impact on your compliance programme.
Completion criteria: Regulatory monitoring process established with assigned responsibility, leadership briefing schedule defined.
4.5 Document everything for accountability
Article 5(2) states the accountability principle: you must not only comply with GDPR but be able to demonstrate compliance. If you cannot prove it, you have not done it (at least in the eyes of a supervisory authority).
Version-control key documents: when policies or notices change, keep previous versions with effective dates.
Ensure documentation is accessible to your DPO, compliance team, and (upon request) the supervisory authority.
Review documentation completeness as part of your quarterly audit cycle.
Prepare an "audit readiness pack": a pre-assembled set of documents that you can provide to a supervisory authority within days of a request. Include: ROPA, DPIAs, DPAs, privacy notices, breach register, training records, and your compliance programme overview.
Completion criteria: A complete, organised, and version-controlled compliance documentation repository, with an audit readiness pack prepared.
Common GDPR Compliance Mistakes
Eight years into GDPR, the same mistakes keep appearing in enforcement actions. Avoid these:
Mistake
Consequence
Fix
No documented lawful basis for processing activities
Fines under Article 6; processing must stop
Complete Phase 1.4 of this checklist. Document the lawful basis for every activity in your ROPA
Relying on consent when legitimate interests would be more appropriate (or vice versa)
Invalid lawful basis if consent is not freely given; undermined rights if LI not properly balanced
Carefully assess each activity. Use the EDPB guidance on consent (Guidelines 05/2020) and legitimate interests
Privacy notice missing required information
Violation of Articles 13-14; data subjects cannot exercise rights effectively
Audit notices against the Article 13/14 checklist. Most gaps are: missing retention periods, vague legal basis descriptions, no DPO contact
No data processing agreements with processors
Direct violation of Article 28; joint liability exposure
Inventory all processors, execute compliant DPAs, and review annually
Treating ROPA as a one-time exercise
Outdated ROPA is worse than none (creates false confidence)
Assign data owners, define update triggers, review quarterly
Cookie banners that pre-select optional cookies or lack a "Reject All" option
CNIL fined Google EUR 150 million and Facebook EUR 60 million for this in 2022
Implement compliant consent mechanism with equal Accept/Reject prominence
No breach response plan
Missing the 72-hour notification deadline; inadequate containment
Create and test the plan. Run an annual tabletop exercise
Training is a one-time event
Knowledge fades; new employees are uninformed
Annual refresher training with role-specific modules and comprehension assessment
Ignoring cross-border transfer mechanisms
Post-Schrems II, this is a top enforcement priority
Map all transfers, implement SCCs with transfer impact assessments, monitor adequacy decisions
DPO appointed but not given resources or independence
Defeats the purpose; supervisory authorities have fined for this
Ensure adequate hours, budget, access, and independence per Article 38
GDPR Compliance by Company Size
GDPR applies equally to all organisations processing EU personal data, but the practical scope of implementation varies dramatically by size. Here is what differs:
Aspect
Startup (1-20 employees)
SME (21-250 employees)
Enterprise (250+ employees)
ROPA requirement
Required if processing is not occasional (Article 30(5) exemption is narrow)
Required
Required
DPO mandatory?
Usually no (unless core activity is monitoring/special data)
Security operations centre, automated detection, regular exercises
Privacy by design
Lightweight checklist for new features
Integrated into product development lifecycle
Formal privacy engineering function
Audit programme
Annual self-assessment
Annual audit with quarterly spot checks
Continuous monitoring with internal audit function
Budget (indicative)
EUR 2,000-10,000/year
EUR 10,000-50,000/year
EUR 50,000-500,000+/year
Timeline to baseline compliance
4-8 weeks
8-16 weeks
16-32 weeks
Biggest risk
Assuming GDPR does not apply to small companies
Underinvesting in compliance relative to data volume
Complexity and coordination across business units
The key principle: GDPR does not expect identical programmes from a 5-person startup and a multinational bank. It expects measures "appropriate to the risk." A startup processing limited customer data needs a proportionate programme. An enterprise processing millions of records across 27 countries needs a comprehensive one. Both need a documented, defensible approach.
Frequently Asked Questions
How long does GDPR compliance take?
Initial compliance typically takes 12-16 weeks for a mid-size organisation following a structured approach like this checklist. Startups with simpler processing can achieve baseline compliance in 4-8 weeks. Large enterprises with complex processing, multiple jurisdictions, and legacy systems may need 6-12 months. However, compliance is never "done." Ongoing maintenance (Phase 4) is permanent.
Is there an official GDPR certification?
GDPR provides for certification mechanisms under Article 42, but as of 2026, very few approved certification schemes exist. The European Data Protection Seal (Europrivacy) received EDPB approval in 2022 and is the most recognised. ISO 27701 (privacy information management) is widely used but is not a GDPR-specific certification. No certification eliminates your compliance obligations, but certifications can demonstrate accountability and are viewed positively by supervisory authorities.
Do we need a DPO?
Article 37 makes DPO appointment mandatory if you are a public authority, if your core activities involve large-scale systematic monitoring of individuals, or if your core activities involve large-scale processing of special category data. Many national laws add requirements (e.g., Germany mandates a DPO for 20+ employees regularly processing personal data). Even if not mandatory, voluntary DPO appointment is strongly recommended and demonstrates proactive compliance. See the DPO as a Service Guide for cost-effective options.
What is the penalty for non-compliance?
GDPR fines fall into two tiers. The lower tier (Article 83(4)) allows fines up to EUR 10 million or 2% of global annual turnover (whichever is higher) for violations related to controllers, processors, certification bodies, and monitoring bodies. The upper tier (Article 83(5)) allows fines up to EUR 20 million or 4% of global annual turnover for violations of processing principles, lawful bases, data subject rights, and international transfers. Beyond fines, supervisory authorities can order processing to stop, which can be more damaging than the fine itself.
Can we do this without external help?
Technically, yes. GDPR does not require you to hire consultants. However, organisations without in-house data protection expertise frequently make costly mistakes: choosing wrong lawful bases, drafting non-compliant privacy notices, missing DPIA triggers, or building inadequate breach response plans. An external assessment, even a one-time gap analysis, can save significant time and reduce enforcement risk. For guidance on selecting the right external partner, see our guide on how to choose a GDPR consultant. Vision Compliance offers a free GDPR assessment tool that identifies your most critical gaps in minutes.
How do we handle data from before GDPR?
Legacy data (collected before 25 May 2018 or before you implemented compliant processes) must still meet GDPR requirements. Audit legacy databases to determine: what data you hold, whether it is still necessary (if not, delete it), whether you have a valid lawful basis for continued processing, and whether data subjects were adequately informed. For consent-based processing, if historical consent does not meet the GDPR standard, you must re-obtain consent or identify an alternative lawful basis.
What is the difference between this checklist and the GDPR compliance guide?
The GDPR Compliance Guide is an explanatory resource covering GDPR principles, lawful bases, data subject rights, and regulatory context. This checklist is an implementation tool: it provides specific action items with checkboxes, sequenced into phases with timelines, so you can systematically work through every requirement. Use the guide to understand what GDPR requires; use this checklist to implement it.
Do processors also need to follow this checklist?
Yes, with some adjustments. Processors have direct obligations under GDPR, including maintaining a ROPA (Article 30(2)), implementing appropriate security measures (Article 32), notifying controllers of breaches (Article 33(2)), appointing a DPO if required (Article 37), and cooperating with supervisory authorities. Processors should follow this checklist and pay particular attention to items related to security, breach notification, documentation, and DPA compliance.
Robert Lozo, mag. iur., is a Partner at Vision Compliance specializing in EU regulatory compliance. He advises organizations on GDPR, NIS2, AI Act, and financial regulation, delivering audit-ready documentation and compliance roadmaps across regulated industries.
