GDPR implementation: how to implement GDPR in 10 steps

Most organisations searching for a GDPR implementation guide already have a privacy notice and a cookie banner. What they lack is the structure: which obligations apply to us, in what order should we tackle them, and what has to be on the table the day a supervisory authority asks?

This guide answers that. It is written for compliance leads, in-house counsel, IT managers and executives in organisations with 50 or more employees anywhere the GDPR applies, and it cites the article of the Regulation every time it says "must". Figures come from the Regulation itself, from the Court of Justice of the European Union, from the CMS Enforcement Tracker and from the UK's Data (Use and Access) Act 2025, and we say which. We end with a clearly labelled fictional worked example and a status check on the EU's amendment proposals, so you know what applies today and what is only proposed.

The short answer: what GDPR implementation actually requires

Any organisation that processes personal data about customers, employees or business contacts must be able to show that the processing is lawful, limited to its purpose and secured, and it must be able to prove it (Article 5(2) and Article 24). In practice that is ten obligations: management ownership and roles, a map of processing activities, a lawful basis for each activity, information to data subjects, procedures for their rights, a risk assessment and where needed a DPIA, appropriate security, processor agreements with oversight, a breach response plan and ongoing controls. The order matters because step 2, the mapping, is the precondition for everything after it. Start there, not with security software.

Which rules are we implementing? GDPR, national law and what is not GDPR

Searches for GDPR implementation usually mix four sets of rules that impose different duties and are enforced by different bodies. Sorting them out first saves rework later.

This article covers the first row in depth and flags where national law or the UK differs. Cookies are out of scope here, and the relationship between GDPR and the security frameworks is covered in our article on information security risk management across GDPR, NIS2, DORA and ISO 27001.

Two boundaries are worth stating. The GDPR protects people who are in the EU/EEA regardless of citizenship, and it applies to B2B organisations because contact persons at customers and suppliers are natural persons. The Regulation has no small-business exemption. A few obligations are lighter for organisations under 250 employees, and we return to that in step 2.

The foundation: seven principles and six lawful bases

All ten steps of GDPR implementation are applications of Article 5 and Article 6. Article 5(1) sets out six principles: lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, and integrity and confidentiality. Article 5(2) adds the seventh, accountability, which is why GDPR implementation is a documentation exercise and not only a behavioural one. We cover each in our article on the seven principles of GDPR.

Article 6(1) provides six lawful bases for ordinary personal data: consent, contract, legal obligation, vital interests, public task, and legitimate interests. Consent is one of six, not the default. An employer processing payroll relies on legal obligation and contract, not consent. Special categories (health, trade union membership, religion, biometrics and others) additionally need one of the conditions in Article 9(2). Health data in a healthcare setting typically relies on Article 9(2)(h). In the UK, the DUAA added Article 6(1)(ea), recognised legitimate interests, for a closed list of purposes such as crime prevention and safeguarding, with no balancing test.

GDPR implementation in 10 steps

The steps translate the Regulation into a GDPR implementation plan and appear in the order we recommend. Each names the legal source that carries the obligation, the document or process the step must end with, and the mistake we most often see.

Step 1: Anchor ownership with management and decide the DPO question

The controller is the organisation, so responsibility sits with management (Article 24(1)). The first deliverable is a written mandate: who owns the programme, what resources they get, and how they report to the executive team. Without it, GDPR implementation becomes a legal department project that the rest of the organisation waits for.

Decide at the same time whether you must appoint a Data Protection Officer. Article 37(1) makes it mandatory in three cases: you are a public authority, your core activities consist of regular and systematic monitoring of individuals on a large scale, or your core activities consist of processing special categories or criminal data on a large scale. A typical manufacturing or services company is rarely caught, but check national law: Germany's BDSG section 38 adds a DPO duty once 20 or more people are permanently engaged in automated processing. If you appoint a DPO voluntarily, all of Articles 37 to 39 apply anyway, including independence and notification to the authority. Where the duty does not apply, it is often wiser to appoint a data protection lead without the DPO title. Our article explains what a Data Protection Officer is and when one is required.

Step 2: Map your processing activities and build the record

This is the load-bearing step. A processing activity is a coherent use of personal data for a purpose, such as recruitment, payroll, customer support or newsletters. For each one you need to know which categories of people and data are involved, where the data comes from, which systems hold it, who it is shared with and when it is deleted. Our guide to processing activities shows how to draw the boundaries in practice.

The mapping is consolidated in the record of processing activities under Article 30. Paragraph 1 lists the mandatory fields for controllers and paragraph 2 the fields for processors. The record is the controller's obligation, not the DPO's, and it is the first document a supervisory authority asks for during an inspection.

The exemption in Article 30(5) is widely misread. It relieves organisations with fewer than 250 employees, but only if the processing is occasional, is unlikely to result in a risk to data subjects and does not include special categories or criminal data. Payroll and HR administration are not occasional, so in practice almost every organisation with employees must keep a record. See our article on the record of processing activities for structure and examples. The practical exercise of tracing systems and data flows is usually called data mapping, and our data mapping module is built for exactly that.

Step 3: Establish a lawful basis and purpose for each activity

With the record in hand, work through the activities one by one and select the lawful basis in Article 6(1) that fits. If you choose legitimate interests (point (f)), document the balancing test in writing, because data subjects can ask for it (Article 13(1)(d) and Article 21). If you choose consent, you must be able to demonstrate it (Article 7(1)) and it must be as easy to withdraw as to give (Article 7(3)). Our articles on the legal basis for non-sensitive personal data and the legal basis for sensitive personal data walk through the choice basis by basis.

National rules belong here too: the age of digital consent under Article 8 ranges from 13 to 16 depending on the member state, and employee data and national identification numbers are governed by national provisions under Articles 87 and 88. Set a retention period per activity at the same time. Storage limitation under Article 5(1)(e) can only be evidenced if the period is written down.

Step 4: Write privacy notices that meet the transparency duty

Article 13 applies when you collect data from the person directly and Article 14 when it comes from elsewhere. Both contain a fixed list: identity, purposes and lawful basis, recipients, any third-country transfers, retention period, rights, the right to complain to a supervisory authority and, for legitimate interests, which interest. Article 12 requires all of this in a concise, transparent and easily accessible form.

Most organisations need at least three notices: one for customers and website visitors, one for employees and one for job applicants. Each notice must mirror the record, not the other way round. Our guide to the right to be informed includes a checklist of the mandatory items. GDPR templates help here, provided you edit them against your own record rather than publishing them as downloaded. Our GDPR templates article explains what a template can and cannot do for you.

Step 5: Build a procedure for data subject rights

Articles 15 to 22 give individuals the rights of access, rectification, erasure, restriction, portability and objection, and protection against certain solely automated decisions. Article 12(3) sets the deadline: without undue delay and at the latest within one month, extendable by two further months for complex requests if you tell the person within the first month. UK controllers should note that the DUAA codified "stopping the clock" while identity or clarification is outstanding.

The procedure must answer four questions: where do requests arrive, who verifies identity, who retrieves the data from which systems, and who approves the response? Access requests are the most frequent and the most labour-intensive, so read our guide to handling data subject access requests and keep a log of every request. The log is your evidence that the deadline was met. The full set of rights is covered in our article on data subject rights.

Step 6: Assess the risk and decide whether a DPIA is required

The GDPR is risk-based. Articles 24 and 32 require measures proportionate to the risk to data subjects, and you can only show that if the risk has been assessed. The assessment starts from the record: for each activity, rate the likelihood and impact of a loss of confidentiality, integrity or availability from the data subject's perspective, not the organisation's. Our article on data privacy risk management sets out the method.

Where the risk is likely to be high, Article 35 requires a data protection impact assessment before processing starts. Article 35(3) names three cases where it is always required: systematic and extensive profiling with legal or similar effects, large-scale processing of special categories, and large-scale systematic monitoring of publicly accessible areas. The EDPB-endorsed guidelines on DPIAs (WP248 rev.01) list nine criteria and treat two met criteria as the normal trigger, and each national authority publishes its own list of processing that always needs a DPIA. If the residual risk stays high and you cannot mitigate it, you must consult the authority before starting (Article 36). Our guide to the data protection impact assessment covers the template.

Step 7: Put appropriate security and data protection by design in place

Article 32 requires appropriate technical and organisational measures taking into account the risk, the state of the art and the costs of implementation. The Regulation does not mandate specific technologies. Pseudonymisation and encryption appear as examples in Article 32(1)(a), not as requirements. What is required is that the choice of measures follows from the risk assessment in step 6 and is documented. Access control, logging, backups, multi-factor authentication and a deletion process that actually runs are what supervisory authorities most often ask about.

Article 25 imposes two obligations, and both are mandatory. Data protection by design (paragraph 1) means protection is built in when you design or procure systems and processes. Data protection by default (paragraph 2) means the system processes only the data necessary for the purpose unless someone actively chooses otherwise. Neither is a "where feasible" duty. Our article on privacy by design and privacy by default shows how to build it into procurement and development.

Step 8: Sign processor agreements and audit your processors

A processor is a supplier that processes personal data on your behalf and on your instructions, such as a payroll provider, a cloud CRM or a hosting company. Article 28(3) requires a written agreement with fixed content: instructions, confidentiality, Article 32 security, rules for sub-processors, assistance with rights and breaches, deletion or return at the end, and audit rights. The European Commission has adopted standard contractual clauses for controller-to-processor agreements under Article 28(7), and our article on data processing agreements walks through the clauses.

The most common mistake is demanding a processor agreement from everyone you share data with. The agreement is required only with processors. Your auditor, law firm, bank and public authorities are independent controllers of their own processing, and you should not sign a processor agreement with them. Conversely, the agreement alone is not enough. Article 28(1) requires you to use only processors providing sufficient guarantees, and you must follow that up with risk-based audits. See our guides to auditing data processors and vendor audits.

If the processor or its sub-processors sit outside the EU/EEA, you also need a transfer mechanism under Chapter V: an adequacy decision (Article 45), such as the EU-U.S. Data Privacy Framework for certified US companies or the UK adequacy decisions, or appropriate safeguards such as the Commission's standard contractual clauses (Article 46) with a transfer impact assessment. UK controllers use the ICO's International Data Transfer Agreement or the UK Addendum, and since 5 February 2026 apply the DUAA's "not materially lower" test for adequacy. Read more on third-country transfers of personal data.

Step 9: Prepare a personal data breach response

A breach is any incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data (Article 4(12)). An email sent to the wrong recipient is a breach. A ransomware attack is a breach. Article 33 requires notification to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware, unless the breach is unlikely to result in a risk. Article 34 requires you to inform the affected individuals without undue delay when the breach is likely to result in a high risk. The two deadlines are different and address different recipients.

Article 33(5) requires you to document every breach internally, including those you decide not to notify. That internal register is one of the documents inspectors ask for. The response plan must set out who assesses, who notifies the authority and who decides on informing individuals. For scale, Denmark's authority alone logged 9,849 breach notifications in 2025 according to its annual report, so notifying is routine, not catastrophic. Our article on security breaches includes an assessment template.

Step 10: Train your people and turn compliance into an annual cycle

The first nine steps establish compliance. The tenth keeps it alive. Accountability under Article 5(2) and Article 24(1) requires measures to be reviewed and updated where necessary, and awareness-raising and training of staff is an express task of the DPO under Article 39(1)(b). If you have no DPO, the task stays with the controller.

Set an annual wheel of fixed controls: review of the record, processor audits, testing of deletion, updates to risk assessments, awareness training and reporting to management. Our checklist of recurring GDPR tasks lists them, and our article on awareness training shows how to make training measurable. UK organisations should add the statutory complaints procedure required by the DUAA from 19 June 2026, with acknowledgement within 30 days. Every control must leave a trace: a date, an owner and an outcome.

A GDPR implementation plan: how long does it take?

There is no official timeline, and duration depends on the number of processing activities, systems and suppliers. The table below is our experience-based estimate for an organisation with 50 to 250 employees starting without structured documentation and with one person on the task part time. It is a planning tool, not a promise.

Plan for three to six months for the first nine steps. What stretches the timeline is almost always step 8: getting processor agreements back from suppliers and clarifying sub-processors in third countries. Open the supplier dialogue as soon as the record shows who the processors are.

A worked example: Harbourline Logistics implements GDPR

Harbourline Logistics Ltd and Priya Nair are fictional. We invented them for this article, and they are neither customers nor a case study.

Harbourline Logistics is a road haulage company based in Ireland with 180 employees, 95 of them drivers. Its customers are businesses, and payroll runs with an external bureau. The company uses Microsoft 365, a recruitment platform, a transport management system with GPS in every vehicle, and CCTV at the warehouse. Priya Nair is the finance director and takes on GDPR alongside her other duties. This is how her decisions fall.

Record of processing: Harbourline has fewer than 250 employees, but payroll, HR and customer management are not occasional processing, so the Article 30(5) exemption falls away. The mapping ends with 23 processing activities, 11 of them in HR. DPO: Harbourline is not a public authority and its core activity is transport, not monitoring. Priya judges GPS tracking of 95 drivers not to be "large scale" and finds no Irish rule adding a DPO duty. She appoints herself data protection lead without the DPO title and writes the reasoning down so it can be produced on request.

DPIA: GPS tracking is systematic monitoring of employees, whom the EDPB-endorsed guidelines treat as vulnerable data subjects. That is two of the nine criteria, so Priya runs a DPIA, which ends by limiting tracking to working hours and setting a 90-day retention period for location data. The CCTV is assessed separately against the Data Protection Commission's guidance on video surveillance.

Processors: of 14 suppliers receiving personal data, 9 are processors. The auditor, the bank, Revenue and the pension provider are independent controllers and get no processor agreement. Microsoft is certified under the EU-U.S. Data Privacy Framework, and the recruitment platform's US sub-processor is covered by standard contractual clauses, which Priya obtains together with the supplier's transfer impact assessment. Retention: unsuccessful applications are deleted after 12 months unless the candidate consents to longer, accounting records are kept for the statutory period under Irish company law, and location data for 90 days. The programme takes 16 weeks, and the longest wait is the three weeks the payroll bureau needs to return a signed processor agreement.

Fines and enforcement in Europe and the UK

Enforcement of GDPR implementation failures follows Article 83, which has two tiers. Breaches of the obligations in Articles 8, 11, 25 to 39, 42 and 43, including a missing record, a missing processor agreement or a missing DPO, can cost up to EUR 10 million or 2 % of total worldwide annual turnover (Article 83(4)). Breaches of the principles, lawful bases, data subject rights and transfer rules can cost up to EUR 20 million or 4 % (Article 83(5)). In both tiers the higher figure applies. The UK GDPR mirrors this with GBP 8.7 million or 2 % and GBP 17.5 million or 4 %.

The Court of Justice clarified the turnover question on 13 February 2025 in Case C-383/23 (ILVA), referred by a Danish court. "Undertaking" in Article 83 has the same meaning as in EU competition law, so the maximum fine may be calculated on the worldwide turnover of the whole group, not only the subsidiary that committed the infringement. The actual fine must still be effective, proportionate and dissuasive under the criteria in Article 83(2).

The figures are from the CMS Enforcement Tracker Report. Two things stand out for anyone planning GDPR implementation. The most frequent ground for a fine is an insufficient legal basis, which is step 3 in this guide, not a security failure. And fines are the least likely outcome of an inspection: reprimands, orders and bans under Article 58 are far more common, and a published order often costs more in customer trust than in euros.

What has changed, and what is only proposed?

The text of the Regulation has not changed since 2018. What moves is the interpretation and the national and UK supplements, and three developments from 2025 and 2026 matter for GDPR implementation.

The Court of Justice's judgment of 4 September 2025 in Case C-413/23 P (EDPS v SRB) nuances when pseudonymised data is personal data for a recipient that has no realistic means of re-identification. It does not change your duties as a controller, but it affects how you assess disclosures of pseudonymised data. The EDPB Guidelines 01/2025 on pseudonymisation, adopted in January 2025, describe how the technique works as an Article 32 safeguard.

In the UK, the Data (Use and Access) Act 2025 received Royal Assent on 19 June 2025. Most of its data protection provisions commenced on 5 February 2026, including recognised legitimate interests, the reformulated international transfer test and PECR fines raised to UK GDPR levels, and the statutory complaints procedure commenced on 19 June 2026. These are live obligations for UK controllers, not proposals.

In the EU, the Commission published the Digital Omnibus proposal (COM(2025) 837) on 19 November 2025. It would, among other things, raise the Article 30(5) threshold from 250 to 750 employees, narrow and re-time breach notification, and add an express legitimate interest rule for AI development. The EDPB and EDPS issued a critical joint opinion on 10 February 2026, and the Council was still negotiating its position in September 2026. Nothing has been adopted. Until it is, the current rules apply unchanged, and no GDPR implementation plan should be scaled back on the strength of a proposal. Even if the threshold rises, the record remains the tool that makes the other nine steps possible.

Five mistakes we see again and again

When we review how GDPR implementation has gone in practice, the same five mistakes recur. Processor agreements with every supplier, including independent controllers. Consent as the lawful basis for HR data, where contract and legal obligation are correct. Retention periods stated in the privacy notice but never configured in the systems. A record of processing built in 2018 and not updated since. And a DPO title handed to an employee who does not meet the independence requirements of Article 38, creating a duty the organisation did not previously have. All five surface in a routine inspection, and all five are cheaper to fix before than after.

How .legal supports GDPR implementation

The ten steps connect through the record of processing, and that is also how .legal supports GDPR implementation in practice. In the GDPR module you register processing activities with their lawful basis, categories, systems, recipients and retention periods, and the Article 30 record is generated from that data rather than maintained as a separate document. Risk assessments attach to individual activities, processors are registered once and reused across activities, and processor audits are planned and evidenced in the same place. Policies and notices live in policy management, so a notice can be traced back to the activities it describes.

Step 10 is the one that most often slips, which is why compliance task management lays the recurring controls out as tasks with an owner and a deadline. The platform does not replace your legal judgement, and it does not make you compliant by itself. It makes sure the documentation exists, is current and can be produced the day someone asks. Book a demo to see what the ten steps look like in practice.