What is GDPR compliance? Requirements, meaning and how to prove it
GDPR compliance is not a certificate. It is the ongoing duty to process personal data lawfully and to be able to demonstrate that you do. Here are the requirements with article numbers, the enforcement figures for 2025 and 2026, and an eight-step plan.
Most people who search for what GDPR compliance is already know roughly what the GDPR is. What they lack is a clear answer to what it actually requires of their organisation, where each requirement is written down, and what counts as enough. Eight years after the regulation started to apply, that is still the question we hear most often from compliance managers, DPOs, lawyers and IT leads.
The question has become harder, not easier. Supervisory authorities across Europe had issued 3,275 fines totalling around EUR 7.16 billion by September 2026. The Court of Justice has refined when pseudonymised data counts as personal data. A new procedural regulation for cross-border cases applies from April 2027. And the EU is negotiating amendments to the GDPR itself that have not been adopted.
This article gives you the requirements with article numbers, a table of the obligations that apply to almost every organisation, the enforcement picture, an eight-step plan and a worked example. The sources are the regulation text, the European Data Protection Board (EDPB), the Court of Justice and the enforcement statistics, and we say which is which.
The short answer: what is GDPR compliance?
GDPR compliance means your organisation processes personal data in line with the General Data Protection Regulation and can demonstrate that it does. The second half is not optional. The accountability principle in Article 5(2), together with Article 24, makes it the controller's duty to be able to show compliance. An organisation that follows the rules but cannot prove it is not compliant in the regulation's own terms.
In practice, GDPR compliance has three layers. A lawful basis and correct information for every processing activity. Technical and organisational measures appropriate to the risk. And documentation that evidences both: the record of processing, data processing agreements, risk assessments, impact assessments and procedures for rights requests and breaches. There is no GDPR certification for organisations, and compliance is a state you maintain, not a project you finish.
What is the GDPR? A law, not a standard and not a certificate
GDPR stands for General Data Protection Regulation, formally Regulation (EU) 2016/679. It was adopted on 27 April 2016, entered into force on 24 May 2016 and has applied since 25 May 2018. As a regulation it applies directly in every EU and EEA country without national transposition, although member states have some room to supplement it, for example on employment data, national identifiers and the age of consent for online services.
The United Kingdom kept the regulation in domestic law after Brexit as the UK GDPR, amended most recently by the Data (Use and Access) Act 2025. The European Commission renewed its adequacy decisions for the UK on 19 December 2025, so transfers from the EU to the UK continue without additional safeguards until at least 27 December 2031. UK organisations that serve people in the EU are subject to both regimes.
Searches for GDPR compliance meaning often mix concepts from different categories. Sorting them is the most useful place to start.
| What people compare | What it is | Can you be certified? |
|---|---|---|
| GDPR | EU regulation. Binding law in all EU and EEA states. | Not as an organisation. Article 42 allows certification of specific processing operations under approved schemes. |
| UK GDPR and Data Protection Act 2018 | The UK's retained and amended version, supervised by the ICO. | No. |
| ISO/IEC 27701 | International standard for a privacy information management system, an extension of ISO 27001. | Yes, but it certifies your management system, not your GDPR compliance. |
| Europrivacy | European Data Protection Seal approved by the EDPB in 2022 under Article 42(5). | Yes, for specific processing operations, not for the organisation as a whole. |
| National seals such as Denmark's D-seal | Voluntary labelling schemes for IT security and responsible data use. | Yes, but the seal is not a GDPR approval. See our comparison of the D-seal and ISO 27001. |
The consequence is simple. No external party can declare your organisation GDPR compliant. Only your own documentation can, and it is tested when a supervisory authority audits you, a data subject complains, or a customer asks to see it during procurement.
Who has to comply with the GDPR?
The regulation's scope turns on two things: what you do, and where you or the individuals are. Citizenship is not one of them, despite how often the phrase "EU citizens" appears in guides on this topic.
Article 2 sets the material scope. The regulation applies to processing of personal data wholly or partly by automated means, and to manual processing of data that forms part of a filing system. Purely personal or household activity is excluded. Everything else, from a customer database to an HR folder, is in.
Article 3 sets the territorial scope. The regulation applies to any controller or processor established in the EU, regardless of where the processing takes place. It also applies to organisations outside the EU when they offer goods or services to people in the EU or monitor their behaviour there. That is why a US retailer selling to customers in Germany is covered, while a French national living in Texas who buys from a local shop is not protected by the regulation in that transaction. Organisations outside the EU that fall under Article 3(2) must also appoint a representative in the EU under Article 27.
Size does not exempt you. The only significant size-related relief is Article 30(5), which concerns the record of processing activities. Organisations employing fewer than 250 persons are exempt from keeping the record, but the exemption falls away if the processing is not occasional, is likely to result in a risk to data subjects, or includes special categories of data. Since almost every employer processes staff data continuously, the record is required in practice for nearly everyone. The threshold is about headcount, not about the number of data subjects.
Public authorities, charities and associations are covered on the same terms as companies. The difference is that public authorities must always appoint a data protection officer under Article 37(1)(a), and that several member states cap or exclude administrative fines for public bodies.
GDPR requirements start with the seven principles in Article 5
Every other requirement in the regulation traces back to the seven principles in Article 5. Many guides list six and forget accountability, which sits in paragraph 2 and is the principle that turns documentation into a legal duty. We cover the seven principles of the GDPR in detail elsewhere, so here is the short version with what each one demands of you in practice.
| Principle | Legal source | What it requires in practice |
|---|---|---|
| Lawfulness, fairness and transparency | Art. 5(1)(a) | A lawful basis under Art. 6 (and Art. 9 for special categories) and privacy information that meets Arts. 13 and 14. |
| Purpose limitation | Art. 5(1)(b) | An explicit purpose per processing activity. Reuse for a new purpose needs a compatibility assessment under Art. 6(4). |
| Data minimisation | Art. 5(1)(c) | Only the data necessary for the purpose. Every field in a form or system should be justifiable. |
| Accuracy | Art. 5(1)(d) | Procedures to keep data up to date and to correct it on request under Art. 16. |
| Storage limitation | Art. 5(1)(e) | Retention periods per activity and evidence that they are enforced. |
| Integrity and confidentiality | Art. 5(1)(f) | Appropriate security, made concrete in Art. 32. Encryption and pseudonymisation are examples, not requirements in themselves. |
| Accountability | Art. 5(2) | The controller must be able to demonstrate compliance with the other six. This is where documentation becomes mandatory. |
GDPR compliance requirements in practice: the obligations that apply to almost everyone
The regulation has 99 articles, but the requirements a typical organisation with 50 or more employees needs to master come down to twelve. The table shows the legal source, what each one means, and which document proves you meet it. The third column is what a supervisory authority asks for first.
| Requirement | Legal source | What it means | Documentation that proves it |
|---|---|---|---|
| Lawful basis | Arts. 6, 9, 10 | One of six bases per processing activity. Consent is only one of them. Special categories also need a condition under Art. 9(2). | The record of processing with a basis per activity, legitimate interest assessments where relied on. |
| Transparency | Arts. 12, 13, 14 | Clear information at the point of collection (Art. 13) and when data comes from elsewhere (Art. 14). | Privacy notices for customers, employees, applicants and supplier contacts. |
| Data subject rights | Arts. 15 to 22 | Access, rectification, erasure, restriction, portability, objection and rights around automated decisions. Respond without undue delay and within one month (Art. 12(3)). | A procedure and a log of requests received and response times. |
| Accountability and policies | Art. 24 | Appropriate measures, including policies that are implemented and reviewed. | Data protection policy, compliance calendar, management reporting. |
| Data protection by design and by default | Art. 25 | Both are mandatory. Protection must be built in when systems are chosen and designed, and default settings must be the most protective. | Requirements in procurement and development processes, documented design choices. |
| Data processing agreements | Art. 28(3) | A written contract with every processor containing the terms paragraph 3 lists. Not with every third party, only with those processing on your behalf. | Signed agreements, a register of processors and sub-processors, an audit plan. |
| Record of processing activities | Art. 30 | The controller's (and processor's) own record with the content paragraphs 1 and 2 require. Must be made available to the supervisory authority on request. | The record itself, kept current with version history. |
| Security of processing | Art. 32 | Appropriate technical and organisational measures assessed against the risk to data subjects. | A risk assessment per processing activity or system, and a register of measures. |
| Personal data breaches | Arts. 33, 34 | Notify the supervisory authority without undue delay and where feasible within 72 hours (Art. 33), unless the breach is unlikely to result in a risk. Inform data subjects without undue delay where the risk is high (Art. 34). | An internal breach register covering all breaches, including those not notified (Art. 33(5)), and a response procedure. |
| Data protection impact assessment | Arts. 35, 36 | Required where processing is likely to result in a high risk. Prior consultation with the authority where high residual risk remains. | Screening of all activities, completed DPIAs. |
| Data protection officer | Arts. 37 to 39 | Mandatory for public authorities and for organisations whose core activities involve large-scale systematic monitoring or large-scale processing of special categories. | Appointment and notification to the authority, or a documented assessment of why you are not required to appoint one. |
| International transfers | Chapter V, Arts. 44 to 49 | Transfers outside the EU/EEA need an adequacy decision, appropriate safeguards such as standard contractual clauses, or a derogation under Art. 49. | A transfer mechanism per recipient, transfer impact assessments where relevant. |
Two rows deserve a closer look because they are the most often misunderstood. Data processing agreements under Article 28 are only required with processors, meaning suppliers that process personal data on your behalf and on your instructions. An accountant, a law firm or a bank processing data for its own purposes is an independent controller, and a processing agreement there is the wrong instrument. And the 72-hour deadline in Article 33 applies to notifying the supervisory authority. Data subjects must be informed under Article 34 when the breach is likely to result in a high risk to them, and the standard there is without undue delay, not 72 hours.
Go deeper on individual requirements in our articles on lawful bases for non-sensitive personal data, the right to be informed, the record of processing activities, data protection impact assessments and third-country transfers.
Enforcement and fines: what is at stake
The fining framework is in Article 83. It has two tiers, and the tier depends on which provision was infringed, not on how serious the individual case feels.
| Tier | Maximum | Examples of infringements |
|---|---|---|
| Art. 83(4) | EUR 10 million or 2% of total worldwide annual turnover, whichever is higher | Missing processing agreement (Art. 28), missing record (Art. 30), inadequate security (Art. 32), late breach notification (Art. 33), missing DPIA (Art. 35), failure to appoint a DPO (Arts. 37 to 39). |
| Art. 83(5) | EUR 20 million or 4% of total worldwide annual turnover, whichever is higher | Breach of the principles (Art. 5), no lawful basis (Arts. 6, 9), data subject rights (Arts. 12 to 22), unlawful international transfers (Arts. 44 to 49). |
The numbers show how those tiers are used. The CMS GDPR Enforcement Tracker recorded 3,275 fines totalling around EUR 7.16 billion across 32 countries as of September 2026. The three largest remain Meta Platforms Ireland at EUR 1.2 billion (2023, Irish Data Protection Commission, international transfers), Uber at EUR 290 million plus earlier fines from the Dutch authority, and TikTok at EUR 530 million (2025, Ireland). The long tail is more instructive than the headlines: most fines are far smaller and concern insufficient legal basis, inadequate security and failures to honour data subject rights.
Enforcement models differ by country, and that matters for how you assess your exposure. Most authorities issue administrative fines directly. In Denmark, the authority refers cases to the police and recommends a fine, which the courts then set. In the UK, the ICO issues penalty notices under the UK GDPR with the same GBP 17.5 million or 4% ceiling. In every model, the fine is rarely the largest cost. Article 58(2) gives authorities the power to order you to stop processing, and an order to shut down a system or delete a data set typically hurts more than the fine. Read more on handling a security breach.
Cross-border cases are about to speed up. Regulation (EU) 2025/2518, the GDPR procedural regulation, was published in the Official Journal on 12 December 2025 and applies from 2 April 2027. It harmonises how authorities handle complaints that involve more than one member state, with fixed deadlines for admissibility decisions and transfers between authorities, and an escalation route to the EDPB. For organisations serving customers in several EU countries, it means complaints will be processed faster and more consistently.
How to become GDPR compliant: eight steps
Sequence matters. Most organisations that stall have started with policies or a privacy notice and discovered afterwards that they do not know which processing activities the policy covers. Start with the mapping.
Step 1: Assign roles and ownership
Decide who owns GDPR compliance at management level and who runs it day to day. Assess under Article 37 whether you are required to appoint a data protection officer, and document the assessment whatever the answer. The record and the rest of the documentation are the controller's responsibility, not the DPO's.
Step 2: Map your processing activities
Go department by department and register each processing activity: purpose, categories of data subjects and data, recipients, systems, retention period and any transfers outside the EU/EEA. That is the content of the Article 30 record, and it is also the foundation for everything that follows. An organisation with 50 to 250 employees typically finds 30 to 60 activities.
Step 3: Assign lawful bases and retention periods
Attach a basis under Article 6 to each activity, and a condition under Article 9(2) where special categories are involved. Write down the balancing test wherever you rely on legitimate interests. Set a retention period per activity, and check that your systems can actually delete.
Step 4: Get your processors under control
List every supplier that processes personal data on your behalf. Sign or update processing agreements under Article 28(3), map sub-processors, and establish a transfer mechanism for those outside the EU/EEA. Plan a risk-based audit programme. Authorities expect you to follow up, not just to sign.
Step 5: Assess risk and decide on security
Carry out a risk assessment of your processing from the data subject's point of view, and decide on measures under Article 32 based on it. Screen every activity for whether it needs a DPIA under Article 35, and complete those that do. If you already run information security risk management, the method can be reused. Our guide to information security risk management across GDPR, NIS2 and ISO 27001 shows how.
Step 6: Deliver transparency and rights
Write privacy notices for each group of data subjects from the record, so they describe what you actually do. Set up a procedure for requests under Articles 15 to 22 with a single entry point, an owner and a one-month deadline. Test it with a fictitious data subject access request before the first real one arrives.
Step 7: Build breach response and awareness
Describe who assesses a breach, who decides on notification within 72 hours, and how all breaches are logged under Article 33(5). Train staff, because misdirected emails and other human errors account for a large share of notified breaches across Europe, and because awareness is an organisational measure under Article 32.
Step 8: Put it in a compliance calendar and report to management
GDPR compliance falls due continuously: processor audits, record reviews, deletion runs, policy updates, breach drills and awareness training. Put the tasks in a calendar with owners and deadlines, and report status to management at least annually. Our checklist of recurring GDPR tasks is a starting point.
A worked example: from mapping to a prioritised plan
Harbourline Logistics Ltd and Priya Shah are fictional. We invented them for this article, and they are neither customers nor a case study.
Harbourline Logistics is a transport and warehousing company with 180 employees, headquartered in Rotterdam with a depot in Manchester, and annual revenue of EUR 28 million. Its customers are online retailers and manufacturers in the Netherlands, Germany and the UK. Priya Shah is the finance director and has picked up GDPR compliance after a customer asked to see the company's record of processing and processor agreements during a tender.
The mapping takes Priya and a colleague from IT three weeks. The result is 42 processing activities across HR (14), sales and customer service (11), operations and fleet management (9), finance (5) and IT (3). Eleven suppliers are processors, including payroll, an HR system, a CRM, fleet management with GPS and a cloud platform. Three of them transfer data to the United States. Two activities, GPS tracking of drivers and CCTV at the warehouse, involve systematic monitoring of employees. The Manchester depot means the company is also subject to the UK GDPR for its UK staff and customers.
The mapping determines the priorities. With 180 employees Harbourline is below the 250 threshold in Article 30(5), but because payroll and HR processing is not occasional and includes health data on sickness absence, the record is required anyway. Priya does not have to appoint a DPO under Article 37, because monitoring its own staff is not the company's core activity, but she writes the assessment down and names herself as the contact point. She screens GPS tracking and CCTV as activities likely to result in a high risk and completes two DPIAs under Article 35. The three US transfers need a transfer mechanism per supplier. Two turn out to be certified under the EU-US Data Privacy Framework, while the third needs standard contractual clauses and a transfer impact assessment. Transfers to the Manchester depot are covered by the UK adequacy decision.
The plan then falls into place. The first three months go on the record, the eleven processing agreements and the three transfer mechanisms, because that is what the customer and any supervisory authority will ask for first. Months four to six go on the two DPIAs, the Article 32 risk assessment and an employee privacy notice covering GPS and CCTV. The rest of the year covers breach response, awareness training and a compliance calendar with quarterly reviews of the three largest processors. Had Harbourline been a public body or had monitoring as its core activity, the DPO would have come first. The point of the example is that the priorities follow from the mapping, not the other way round.
What GDPR compliance is not
Many misunderstandings about GDPR requirements come from confusing the regulation with something else. Five boundaries are worth knowing.
GDPR compliance is not a certification. No organisation can be GDPR certified, and an ISO 27001 or ISO 27701 certificate evidences a management system, not that every processing activity has a lawful basis. Nor is GDPR compliance encryption or any particular security product. Article 32 requires measures appropriate to the risk and names encryption and pseudonymisation as examples.
Cookies and tracking are governed by the ePrivacy Directive and its national implementations, such as the UK's PECR, alongside the GDPR where personal data is processed. A compliant cookie banner is not GDPR compliance, and the reverse is also true. NIS2 is a separate law with separate obligations. If you are in scope, your GDPR work does not discharge your NIS2 duties, even though the security measures overlap. See our introduction to NIS2.
And GDPR compliance is not a project with an end date. Every new supplier, system and category of staff changes the record. That is why the calendar in step 8 is a requirement, not a recommendation.
What is changing in 2026 and 2027
The text of the regulation has not changed since 2016, but the framework around it is moving. Five developments are worth knowing as of September 2026.
| Development | Status as of September 2026 | What it means for you |
|---|---|---|
| GDPR procedural regulation, Regulation (EU) 2025/2518 | Published in the Official Journal on 12 December 2025, applies from 2 April 2027. | Harmonised rules and deadlines for cross-border complaints. Complaints against you from data subjects in other EU countries will be handled faster. |
| Digital Omnibus (Commission proposal of 19 November 2025) | Under negotiation. The Council is working on a compromise text and trilogue with Parliament has not started. Not adopted. | Proposes, among other things, a changed breach notification deadline, a clarification on pseudonymised data and legitimate interests for AI training. Until adoption, the current rules apply unchanged. |
| Court of Justice, C-413/23 P (EDPS v SRB), 4 September 2025 | Decided. | Pseudonymised data is not necessarily personal data for a recipient with no realistic means of re-identification. The assessment is made from the recipient's perspective. Together with EDPB Guidelines 01/2025 on pseudonymisation, this changes how you assess sharing pseudonymised data sets. |
| EU-US Data Privacy Framework | Upheld by the General Court on 3 September 2025 (Latombe v Commission). Appeal to the Court of Justice lodged 31 October 2025, pending. | Transfers to certified US recipients remain lawful. Keep a fallback of standard contractual clauses in case the Court decides otherwise. |
| UK adequacy decisions | Renewed by the Commission on 19 December 2025, valid until 27 December 2031. | EU to UK transfers continue without standard contractual clauses. The ICO confirms the position for UK recipients. |
The most important thing to take from the table is that nothing under negotiation changes your obligations today. Organisations that postpone the record or their processing agreements with reference to the Digital Omnibus are waiting for something that is neither adopted nor certain to pass in its proposed form.
How .legal supports your GDPR compliance
The practical problem in GDPR compliance is not understanding the requirements. It is keeping the documentation current when the record, the processing agreements, the risk assessments and the task calendar each live in their own spreadsheet. Our GDPR module brings them together. You map processing activities once in Data Mapping, and the Article 30 record, the processor register and the transfer mechanisms are generated from that same registration, so they cannot drift apart.
Risk assessments under Article 32 and DPIAs under Article 35 are linked to the activities they cover. Processor audits are planned and documented alongside the agreements, and the recurring tasks from step 8 sit in compliance task management with owners, deadlines and a history you can show a supervisory authority or a customer. The platform does not make you GDPR compliant by itself. It makes sure the work you do can be evidenced.
See how other organisations use the platform in our customer cases, or book a demo to see the record, the risk assessment and the calendar working together.
.legal compliance platform
Start your GDPR compliance journey
-
Free compliance platform
-
Guided implementation workflows
-
Complete documentation management
-
Ongoing compliance monitoring
.jpeg?width=131&height=26&name=right_people_logo%20(1).jpeg){kind=small}
.jpg?width=58&height=26&name=Praktiserende%20L%C3%A6gers%20Organisation%20(1).jpg){kind=small}
.jpg?width=108&height=26&name=finans%20danmark%20(1).jpg){kind=small}
.jpg?width=89&height=26&name=klasselotteri%20(1).jpg){kind=small}
-1.png?width=34&height=26&name=bws_shipping_rgb%20-%20Kopi%20(2)-1.png){kind=small}
.jpeg?width=135&height=26&name=AH%20industries%20(1).jpeg){kind=small}
.jpg?width=225&height=26&name=KAUFMANN%20(1).jpg){kind=small}
