Implementation & Compliance

GDPR Compliance Checklist: 14 Steps to Readiness

A step-by-step GDPR compliance checklist covering data mapping, policies, DPIAs, and operational readiness.

calendar_today 15 Jan 2024 update Updated 16 Apr 2026 schedule 14 min read person Prova GRC

The General Data Protection Regulation sets a high bar for how organisations collect, store, and process personal data. With fines reaching up to four per cent of annual global turnover or twenty million euros—whichever is greater—the consequences of non-compliance are significant. Yet many organisations struggle to translate the regulation’s principles into concrete operational steps.

This checklist breaks GDPR compliance into 14 actionable steps across four phases: Foundation, Policies and Rights, Security and Risk, and Governance. Each step maps to specific GDPR articles, explains what is required, and provides practical guidance for implementation. Whether you are starting from scratch or strengthening an existing privacy programme, use this checklist to identify gaps, assign ownership, and track progress towards full data protection readiness.

Phase 1: Foundation

The foundation phase establishes the organisational structure and data visibility that every subsequent step depends on. Without a clear understanding of who is responsible for data protection and what personal data your organisation actually processes, later efforts around policies, security, and governance will lack the context they need to be effective. Investing thoroughly in these first four steps prevents rework and missed obligations further down the line.

Step 1: Appoint a data protection lead or DPO (Article 37)

Article 37 of the GDPR requires certain organisations to appoint a Data Protection Officer. This obligation applies to public authorities, organisations whose core activities involve large-scale systematic monitoring of individuals, and those processing special category data at scale. Even if your organisation falls outside these categories, designating a data protection lead is essential for coordinating compliance activities and serving as the point of contact for supervisory authorities and data subjects.

Your DPO or data protection lead should report to senior management and operate with sufficient independence to fulfil the role effectively. The GDPR explicitly prohibits dismissing or penalising a DPO for performing their duties. Define the role’s responsibilities clearly: overseeing the compliance programme, advising on data protection impact assessments, liaising with the supervisory authority, and monitoring adherence to internal policies. Document the appointment formally and publish the DPO’s contact details in your privacy notice and on your website.

Step 2: Create a data processing inventory / ROPA (Article 30)

Article 30 requires organisations to maintain a record of processing activities. This is not optional documentation—supervisory authorities can request your ROPA at any time, and it forms the backbone of your entire compliance programme. A comprehensive ROPA captures each processing activity along with its purpose, the categories of data subjects and personal data involved, recipients of that data, details of international transfers, and envisaged retention periods.

Start by surveying each department to identify every instance where personal data is collected, used, stored, or shared. Common processing activities include employee payroll, customer relationship management, marketing communications, website analytics, and supplier management. For each activity, record the controller and processor details, the lawful basis relied upon, and any technical or organisational safeguards in place. Store your ROPA in a centralised system—spreadsheets work for small organisations, but a GRC platform like Prova provides version control, automated reminders, and audit-ready reporting as your processing landscape grows.

Step 3: Map data flows

With your processing inventory in place, the next step is to visualise how personal data moves through your organisation. Data flow mapping reveals where data enters your environment, how it is transmitted between systems, where it is stored, who has access, and how it eventually leaves—whether through deletion, anonymisation, or transfer to third parties.

Create diagrams that trace the journey of personal data from collection point to final disposition. Pay particular attention to cross-border transfers, as these trigger additional obligations under Chapter V of the GDPR, including the need for adequacy decisions, standard contractual clauses, or binding corporate rules. Data flow mapping frequently uncovers shadow processing—data being handled in unapproved tools, personal spreadsheets, or legacy systems that sit outside formal governance. Identifying these gaps now prevents them from becoming compliance failures later. Update your data flow maps whenever you introduce new systems, change processors, or modify the purposes for which data is used.

Step 4: Identify and document the lawful basis for each processing activity

Every processing activity must rest on one of six lawful bases defined in Article 6: consent, contract, legal obligation, vital interests, public task, or legitimate interests. Selecting the correct lawful basis is not a formality—it determines what transparency obligations you have, whether data subjects can exercise certain rights, and how easily you can change the purpose of processing in future.

Review each entry in your ROPA and assign the most appropriate lawful basis. For most commercial organisations, contract and legitimate interests cover the majority of processing activities, with consent reserved for situations where genuine choice is appropriate, such as marketing communications. If you rely on legitimate interests, you must conduct and document a legitimate interests assessment that balances your interests against the rights and freedoms of the data subject. Record the lawful basis alongside each processing activity in your ROPA, and ensure your privacy notices communicate this basis clearly to data subjects.

Phase 2: Policies and Rights

With the foundation in place, this phase focuses on translating your data processing knowledge into policies that meet GDPR transparency requirements and operational processes that respect individual rights. The regulation places data subjects at the centre of its framework, granting them a suite of rights that your organisation must be prepared to fulfil within strict timeframes. Policies without supporting processes are merely documents; this phase ensures they become embedded in daily operations.

Step 5: Draft or update privacy notices (Articles 13–14)

Articles 13 and 14 set out the information you must provide to data subjects when you collect their personal data. If you collect data directly from individuals, Article 13 applies. If you obtain data from a third party, Article 14 applies. In both cases, your privacy notice must be concise, transparent, and written in plain language.

Your privacy notice should include the identity and contact details of the controller, the DPO’s contact details, the purposes and lawful basis for each type of processing, the categories of personal data processed, recipients or categories of recipients, details of international transfers and the safeguards in place, retention periods, the rights available to data subjects, and how to lodge a complaint with a supervisory authority. Avoid vague language such as “we may use your data to improve our services” without specifying what that means in practice. Publish your privacy notice prominently on your website, link to it from all data collection points, and review it whenever your processing activities change.

Where consent is the lawful basis for processing, it must meet the GDPR’s high standard: freely given, specific, informed, and unambiguous. Pre-ticked boxes, bundled consent, and consent buried in terms and conditions do not meet this threshold. Consent must also be as easy to withdraw as it is to give.

Implement granular consent mechanisms that allow individuals to agree to specific processing purposes independently. Maintain auditable records of when and how consent was obtained, including the version of the privacy notice or consent form presented at the time. Build withdrawal mechanisms that are accessible and straightforward—an unsubscribe link in emails, a preference centre in your application, or a simple request process. When consent is withdrawn, cease the relevant processing promptly and document the action. Review your consent mechanisms regularly to ensure they remain compliant as guidance from supervisory authorities evolves.

Step 7: Build a data subject request handling process

Data subjects have the right to access their personal data (Article 15), rectify inaccurate data (Article 16), erase data in certain circumstances (Article 17), restrict processing (Article 18), receive their data in a portable format (Article 20), and object to processing (Article 21). You must respond to these requests within one calendar month, with the possibility of a two-month extension for complex or voluminous requests.

Establish a clear intake channel for data subject requests—a dedicated email address, a web form, or an in-app feature. Define an internal workflow that routes requests to the appropriate team, verifies the identity of the requester, locates the relevant data across all systems, and prepares the response. Automate where possible: a GRC platform can track request deadlines, flag overdue items, and generate audit trails. Train customer-facing staff to recognise data subject requests even when they are not formally labelled as such, since a simple email asking “what data do you hold about me?” constitutes a valid access request.

Step 8: Establish a data retention policy

The GDPR’s storage limitation principle requires that personal data be kept only for as long as necessary for the purposes for which it was collected. A data retention policy translates this principle into specific, enforceable retention periods for each category of data your organisation processes.

Work through your ROPA and assign a retention period to each processing activity based on the purpose of processing, contractual obligations, and any legal requirements that mandate minimum retention. For example, employment records may need to be retained for six years after employment ends to satisfy limitation periods, while marketing consent records should be retained for as long as consent is active plus a reasonable period for audit purposes. Define what happens when the retention period expires: deletion, anonymisation, or archival under restricted access. Implement automated deletion or review triggers in your systems wherever possible, and audit adherence to retention schedules at least annually.

Phase 3: Security and Risk

This phase addresses the GDPR’s requirements for protecting personal data against unauthorised access, loss, and misuse, and for proactively assessing and mitigating risks before they materialise. Security is not an afterthought under the GDPR—Article 5(1)(f) establishes integrity and confidentiality as a core data protection principle, and Article 32 requires measures appropriate to the level of risk.

Step 9: Implement appropriate technical and organisational measures (Article 32)

Article 32 requires controllers and processors to implement measures that ensure a level of security appropriate to the risk. The regulation explicitly mentions pseudonymisation and encryption, the ability to ensure ongoing confidentiality, integrity, availability, and resilience of processing systems, the ability to restore access to personal data in a timely manner following an incident, and a process for regularly testing and evaluating the effectiveness of those measures.

Conduct a risk assessment to determine what “appropriate” means for your organisation given the nature, scope, context, and purposes of your processing. At a minimum, implement encryption at rest and in transit, strong access controls with the principle of least privilege, multi-factor authentication for all systems containing personal data, regular vulnerability scanning and patching, and logging and monitoring of access to personal data. Document every measure in a security policy and link it to the specific risks it mitigates. The key is proportionality—a small organisation processing limited personal data has different requirements from a large-scale data processor, but both must demonstrate that they considered the risks and responded appropriately.

Step 10: Conduct DPIAs for high-risk processing (Article 35)

A Data Protection Impact Assessment is mandatory when processing is likely to result in a high risk to the rights and freedoms of individuals. Article 35 identifies specific triggers: systematic and extensive profiling with significant effects, large-scale processing of special category data, and systematic monitoring of publicly accessible areas. Supervisory authorities also publish lists of processing operations that require a DPIA.

For each high-risk processing activity, your DPIA should describe the processing and its purposes, assess the necessity and proportionality of the processing in relation to its purpose, evaluate the risks to data subjects, and identify the measures you will take to mitigate those risks. Consult your DPO during the assessment and, where the DPIA indicates residual high risk that you cannot mitigate, consult your supervisory authority before proceeding. Maintain completed DPIAs as living documents and revisit them when the nature, scope, or context of the relevant processing changes. A GRC platform can template DPIA workflows, track completion status, and link assessments directly to processing activities in your ROPA.

Step 11: Review and document processor agreements (Article 28)

Whenever you engage a third party to process personal data on your behalf, Article 28 requires a written contract that sets out the subject matter and duration of processing, the nature and purpose of processing, the types of personal data and categories of data subjects, and the controller’s obligations and rights. The contract must also require the processor to process data only on documented instructions, ensure staff confidentiality, implement appropriate security measures, assist with data subject requests and breach notifications, delete or return data at the end of the engagement, and submit to audits.

Inventory all your processors and sub-processors, then review existing contracts against Article 28 requirements. Where contracts fall short, negotiate amendments or replace them with compliant data processing agreements. Pay close attention to sub-processing chains—your processors must not engage sub-processors without your prior written authorisation, and the same data protection obligations must flow down. Maintain a centralised register of all processor agreements, their review dates, and the security measures each processor commits to. This register becomes critical evidence during supervisory authority investigations.

Step 12: Establish a breach notification process (72-hour window, Articles 33–34)

Articles 33 and 34 impose strict obligations when a personal data breach occurs. You must notify your supervisory authority within 72 hours of becoming aware of a breach that is likely to result in a risk to individuals’ rights and freedoms. If the breach is likely to result in a high risk, you must also notify the affected data subjects without undue delay.

Build a breach response plan that covers detection, assessment, containment, notification, and post-incident review. Define what constitutes a breach, establish reporting channels so employees can escalate incidents immediately, and create assessment criteria to determine whether the 72-hour notification threshold is triggered. Your notification to the supervisory authority must describe the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences, and the measures taken or proposed to address it. Maintain a breach register that records every incident regardless of whether it met the notification threshold—Article 33(5) requires this. Rehearse your breach response process at least annually through tabletop exercises to ensure the team can execute it under pressure.

Phase 4: Governance

The final phase transforms compliance from a project into a sustainable programme. GDPR compliance is not a one-time achievement—it requires ongoing vigilance, regular review, and a culture where data protection is embedded in everyday decision-making. These governance steps ensure your organisation maintains compliance as regulations evolve, processing activities change, and new risks emerge.

Step 13: Deliver staff training

Human error remains one of the leading causes of data breaches. Article 39 identifies training as a core task for the DPO, and demonstrating that staff are trained is a key indicator of accountability under Article 5(2). Training should not be a tick-box exercise—it needs to be relevant, practical, and tailored to the roles and responsibilities of different teams.

Deliver baseline data protection training to all staff during onboarding and at least annually thereafter. Supplement this with role-specific training: customer support teams need to recognise and handle data subject requests, engineering teams need to understand data protection by design and by default (Article 25), marketing teams need to understand consent requirements, and HR teams need to manage employee data lawfully. Track training completion and assessment scores centrally, and maintain records as evidence of compliance. Use real-world scenarios and case studies from supervisory authority enforcement actions to make training memorable and practical rather than abstract.

Step 14: Establish ongoing monitoring and auditing

Accountability is the golden thread running through the GDPR. Article 5(2) requires that you not only comply but also demonstrate compliance. This demands ongoing monitoring of your data protection controls, regular internal audits, and a commitment to continuous improvement.

Establish a monitoring programme that tracks key indicators: data subject request response times, breach detection and notification metrics, consent withdrawal rates, training completion rates, DPIA status, and processor compliance. Conduct formal internal audits at least annually, covering the full scope of your processing activities and controls. Use audit findings to update your risk register, refine policies, and close gaps before they become regulatory issues. A GRC platform like Prova consolidates these metrics into dashboards that provide real-time visibility to your DPO and leadership team, replacing manual evidence gathering with continuous automated monitoring. As the regulatory landscape evolves—through new guidance, enforcement decisions, and legislative changes—your monitoring programme ensures your organisation adapts proactively rather than reactively.

Frequently Asked Questions

How long does GDPR compliance take? expand_more
Most organisations need between 3 and 12 months to reach initial GDPR compliance, depending on the volume and complexity of personal data processing, the number of systems in scope, and whether the organisation already has foundational privacy practices in place. Ongoing compliance is a continuous obligation that requires regular review and adaptation as processing activities change.
Do I need a DPO? expand_more
You must appoint a Data Protection Officer if you are a public authority, if your core activities require large-scale systematic monitoring of individuals, or if you process special category data on a large scale. Even when a DPO is not legally required, appointing a data protection lead is strongly recommended to coordinate compliance efforts and serve as the point of contact for supervisory authorities.
What is a record of processing activities (ROPA)? expand_more
A record of processing activities is a structured inventory required under Article 30 of the GDPR. It documents every processing activity your organisation performs, including the categories of data subjects and personal data, the purposes of processing, recipients of data, international transfers, and retention periods. Supervisory authorities can request your ROPA at any time during an investigation or audit.
What technical measures does GDPR require? expand_more
Article 32 requires organisations to implement technical and organisational measures appropriate to the risk, including encryption of personal data, the ability to ensure ongoing confidentiality and availability of processing systems, the ability to restore access to data following an incident, and regular testing and evaluation of those measures. The regulation is deliberately technology-neutral, requiring measures that are appropriate given the state of the art and the cost of implementation.
How often should I review GDPR compliance? expand_more
GDPR compliance should be reviewed at least annually through a formal audit cycle. However, reviews should also be triggered by significant changes such as launching new products, entering new markets, adopting new processing technologies, or experiencing a data breach. Continuous monitoring through a GRC platform enables real-time visibility into compliance status rather than relying solely on periodic reviews.
Can a GRC platform help with GDPR compliance? expand_more
Yes. A GRC platform like Prova centralises your processing inventory, automates evidence collection, tracks data subject requests against regulatory deadlines, manages DPIA workflows, and provides continuous monitoring of technical controls. This reduces manual effort, minimises the risk of missed obligations, and gives leadership real-time visibility into the organisation's data protection posture.

update This article was last updated on 16 Apr 2026.

Ready to automate your GDPR compliance?

Prova brings AI-powered GRC orchestration to your compliance workflows. Get audit-ready faster with continuous monitoring and automated evidence collection.