Key Takeaways
- The GDPR is Regulation (EU) 2016/679. It entered into force on 24 May 2016 and has applied since 25 May 2018. The two dates are routinely confused.
- The one-stop-shop is not available to everyone. It requires an establishment in the EU. A company caught only by Art. 3(2) has no lead supervisory authority, which means every authority in every member state where it targets or monitors people can act against it independently.
- Article 27 has no size threshold. If Art. 3(2) applies to you, you must appoint an EU representative in writing unless your processing is occasional, excludes large-scale special-category data, and is unlikely to create risk. All three conditions have to hold at once.
- The largest GDPR fine on record is €1.2 billion against Meta Platforms Ireland (Irish DPC, May 2023, Art. 46(1)). It has not been annulled or reduced, and Meta's challenges are unresolved.
- The €746 million against Amazon Europe Core no longer exists. Luxembourg's Cour administrative annulled it in full on 12 March 2026 and sent the file back to the regulator, because the authority never analyzed fault. Most English-language content still quotes it as the second-largest fine.
What is the GDPR, and does it apply to you?
The GDPR is the General Data Protection Regulation, formally Regulation (EU) 2016/679. It sets out when personal data may be processed, what rights the people behind that data have, and what you must be able to prove. It was adopted on 27 April 2016 by the European Parliament and the Council of the EU, not by the Commission.
One detail that shows up in due diligence: the GDPR entered into force on 24 May 2016, twenty days after publication in the Official Journal. It only became applicable two years later, on 25 May 2018, after the transition period in Art. 99. Writing that the regulation "came into force in 2018" confuses entry into force with applicability.
The question most non-EU companies actually need answered is whether the regulation reaches them, and Art. 3 answers it in two ways. Art. 3(1) catches processing in the context of an establishment in the Union. Art. 3(2) catches you wherever you are, if you offer goods or services to people in the Union or monitor their behavior. A US SaaS company with German customers and no European entity is squarely inside Art. 3(2).
That distinction has a consequence English-language guides mostly skip. If Art. 3(2) applies, Art. 27 requires you to designate a representative in the Union, in writing. There is no employee threshold and no revenue threshold anywhere in Art. 27. The only exemptions are public authorities, and processing that is simultaneously occasional, free of large-scale special-category or criminal-offense data, and unlikely to result in risk to people's rights. Those conditions are cumulative, and "occasional" does most of the work: an ongoing commercial website or app will not qualify. Two further points get misstated constantly. The representative must be established in a member state where the relevant data subjects actually are, and appointing one does not move liability off you: Art. 27(5) preserves action against the controller directly.
Throughout, the anchor is the personal datum as defined in Art. 4(1), and the concept is broader than most teams assume. An IP address, a cookie ID, and the combination of a postcode, a birth year, and a job title are all personal data once they let you single someone out. Company-level data is not, but the business contact details of an identifiable employee are.
The seven principles and the six legal bases
Art. 5 sets out seven principles that every single processing operation has to satisfy: lawfulness, fairness and transparency, purpose limitation, data minimization, accuracy, storage limitation, integrity and confidentiality, and accountability. The last one is the expensive one. Accountability means demonstrating compliance with the other six before anyone asks. A state of affairs you cannot document counts as absent.
Processing is lawful only if one of the six legal bases in Art. 6(1) applies. There are exactly six, they rank equally, and you have to commit to one per processing activity.
Which brings us to the most widespread misconception in the field. Eight years into applicability, many companies still treat consent as the safest basis, usually thinking it puts them on the cautious side. It does the opposite. Consent is the only one of the six that can be withdrawn at any moment, and withdrawal removes lawfulness going forward. You are then left without a workable basis, and you have to act on the withdrawal, which means deleting.
In the employment context there is a second and more serious problem. The subordinate relationship between employer and employee means the voluntariness of consent is treated skeptically by settled case law and by a unanimous literature. The employee is sitting opposite someone who wants something from them, wondering what happens if they refuse. If voluntariness fails, a validity condition fails, and the legal basis fails with it. So you are not only exposed to a later withdrawal, you are exposed to never having had a valid basis at all.
The textbook case is employee photographs, where consent gets signed on day one along with the rest of the onboarding paperwork, at exactly the moment when voluntariness is hardest to argue. Check all six bases first. In practice contract performance under (b) or legitimate interests under (f) carry most processing, and both hold up better.
The obligations that apply to every company
The operational weight of the GDPR is not in prohibitions. It is in obligations to prove things. Six of them apply to practically any company past a handful of people.
The record of processing activities under Art. 30 is the documentary core. Authorities ask for it first, because it reveals whether a company knows its own data processing at all. The current exemption in Art. 30(5) covers organizations with fewer than 250 employees, unless the processing is likely to result in risk, is not occasional, or includes special-category or criminal-offense data. Proposals to raise that threshold are discussed below, but they are not law. How to keep records, security measures, and DPIAs in one place instead of three parallel spreadsheets is covered on the records of processing activities page.
A terminology note for anyone working across a German-speaking organization: the German abbreviation VVT (Verzeichnis von Verarbeitungstätigkeiten) is not an English term. In English this is the record, or records, of processing activities, commonly RoPA. It matters more than it sounds, because "VVT" is currently showing up inside English-language search queries reaching this site, which suggests German terminology is leaking into how the topic gets described in English.
On the security measures in Art. 32, companies routinely overshoot, because they know the level of detail ISO 27001 expects and carry it across to privacy. Art. 32 does not ask for that. It is deliberately general and asks for measures appropriate to the risk, not a control register with implementation evidence per measure. A maintained, exportable catalog is enough, and the export is the actual point, because you have to attach those measures to every processor contract.
On that contract, the first check is the most basic one and it is the one that fails most often: are all of the mandatory contents required by Art. 28 actually present? Eight years in, frequently not. What follows from that belongs on the executive floor rather than in the compliance function. You will not always be able to conclude a fully compliant contract: a thirty-person company sending change requests to a large US provider will not get an individual amendment. The question is then not how to make the contract look better, but whether the outcome is acceptable. That decision belongs to management, not to the data protection officer, whose job is to assess and advise, in writing.
Whether you need a DPO at all follows from Art. 37(1): public authorities, large-scale regular and systematic monitoring, or large-scale processing of special-category or criminal-offense data. Note that some member states add national triggers on top. Germany requires a DPO from 20 people engaged in automated processing under § 38 BDSG, while France has no headcount threshold at all. If you operate in several member states, check each one rather than assuming the Art. 37 list is exhaustive. Where nobody internal can take the role, an external data protection officer is a recognized alternative and legally equivalent to an internal appointment.
What typically goes undocumented is whatever was introduced without the compliance function: a marketing tool on a trial plan, an AI assistant a team subscribed to itself. Finding personal data across the tools actually in use, rather than asking once a year, is the practical prerequisite for both the record and any deletion policy, and we cover it in the article on data discovery.
Data subject rights, and the deadline that creates the pressure
Arts. 15 to 22 give people seven enforceable rights: access (Art. 15), rectification (16), erasure (17), restriction (18), portability (20), objection (21), and the right not to be subject to a solely automated decision (22). Art. 12 sets the modalities and the deadline: without undue delay and in any event within one month of receipt, extendable by two further months if you notify the reasons inside the first month.
The first step is not the answer, it is entitlement. Is the person asking actually the person whose data is involved? Where there is reasonable doubt you have to verify, because releasing data to the wrong person is itself a breach.
The most commonly missed part is scope. A response under Art. 15 is not a statement that data is being processed; it includes a copy of the personal data undergoing processing. The datum itself has to appear, because the whole purpose of the right is to let the person check that the processing is lawful. A list of categories does not discharge the request. And the work compounds: a former employee of ten years asking for everything will have emails containing third parties' personal data, from people in copy to colleagues discussed in the body, and you owe those people confidentiality, so passages have to be redacted by hand.
One thing changes how you should prioritize this. Access requests are routinely filed to prepare a damages claim, because they yield two things at once. They produce information, and they provoke a second infringement, since many companies cannot answer completely and on time, and the botched answer becomes its own cause of action. The countermeasure is unglamorous: answer transparently and politely, do not play anything down, and ask what the request is actually about when it is vague. A meaningful share of requests heading toward escalation defuse that way. The full process, including identity verification, scope decisions, and deadline control, is covered in our guide to data subject access requests.
The DPIA: four steps in a fixed order
Art. 35 requires a data protection impact assessment where processing is likely to result in a high risk to the rights and freedoms of natural persons. What almost everyone gets wrong is the order. There are four steps and they run chronologically.
The most common error is starting at step 3. Putting the risk assessment before necessity and proportionality inverts the logic of the article: you end up assessing the risks of processing that has not been established as necessary in that form.
Step 2 is the one that shrinks to an empty text field, and it is where the work is. Two questions get you there. Is this volume of data necessary for the purpose, or would less do? And is the chosen means proportionate? An example: a nursery loses toys from the sandbox every week. Would video surveillance stop it? Probably. Is it proportionate, aimed at children, for the loss of sand toys? No, and gentler options exist. That balancing, written out, is step 2.
The second error is imported from information security. The GDPR has no concept of accepting a risk. In an ISO 27001 management system you may assess a risk, document it, and then knowingly carry it, because it is the company's risk. In a DPIA you are assessing risks to other people's rights and freedoms, which are not yours to dispose of. If a risk remains it must be reduced, or the processing does not happen. An approval step labeled "risk accepted" has no place in a DPIA.
If processing stays high-risk after every mitigation, Art. 36 applies: consult the supervisory authority before you start, or drop it. In practice this almost never happens, and among experienced practitioners you will struggle to find anyone who has been part of such a consultation. The rule still matters, because it explains why there is no acceptance: the alternative to mitigation is not proceeding, it is the regulator.
Two tools beat any template from a blog: the DPIA template the EDPB published in 2026, which sets out the sub-points per step, and the CNIL's PIA software, free and open source, which walks the structure and ships a catalog of predefined risks. Coming from a regulator is what makes it the most defensible freely available reference. And the DPIA is conducted before processing begins. Where it is documented after the fact you can tell, because the measures are entered as already implemented rather than following from the risk assessment.
Data breaches: the first hour, and when to notify
Art. 33(1) requires you to notify a personal data breach to the competent supervisory authority without undue delay and, where feasible, no later than 72 hours after becoming aware of it. The clock starts on awareness, not on the incident, and it runs over the weekend.
The first hour decides less about notification than about establishing the facts. The questions are always the same: who, when, how, where, which data is affected, and above all what can be established technically and demonstrably at this point, as distinct from what is assumed. The legal assessment follows.
The line between notifiable and not notifiable is rarely sharp, which is why our advisory position is to notify when in doubt. Doing so rules out an infringement of your own. If it later turns out you should have notified and did not, you have a second breach of duty stacked on top of the incident.
The reason companies hesitate is almost always the same: a fear that notifying draws the authority's attention and triggers further investigation. That fear points the wrong way. A supervisory authority is not there to make life difficult, and in this situation is closer to a technical counterpart. Notification discharges an obligation and it also opens support in planning what comes next, which matters most on larger incidents.
Art. 34 is frequently miscited, and the logic there inverts. It governs notifying the affected individuals, contains no 72-hour deadline, and only applies where the breach is likely to result in a high risk to their rights and freedoms. Notify the authority when in doubt, yes. Write to every affected person when in doubt, no. Two decisions, two different thresholds.
International data transfers
Chapter V, Arts. 44 to 50, governs transfers to recipients outside the EU and EEA. For a US provider the first check is always the same: is there a current certification under the EU-US Data Privacy Framework? Legally that is an adequacy decision under Art. 45, and it covers only companies that actually certified, not US companies generally. So verifying the specific recipient's certification and documenting the check is an obligation, not diligence.
Failing that, the second mechanism is Art. 46, in practice almost always the standard contractual clauses under Art. 46(2)(c) or (d). This is where teams skip a step. When the Court of Justice invalidated the previous adequacy decision it expressly required supplementary measures on top of the clauses. The contract alone is not enough, and that is where the transfer impact assessment comes from.
A TIA answers four questions: the legal position in the destination country, whether intelligence services can access the data, whether people have redress there, and which technical measures, encryption first, secure the processing. One of those you cannot answer yourself, since only the provider knows whether authorities have previously accessed data in its systems. Large providers at best publish a completed template; conducting and assessing it remains your responsibility. Practice is also looser than the law suggests: as soon as a reviewer sees "SCCs" during vendor assessment they ask for a TIA, and a confirming yes often ends the check, for want of capacity rather than because the question is settled.
A common misconception concerns EU hosting. The large US providers hold European subsidiaries, and you now usually contract with the subsidiary. That is a genuine advantage, but it does not close the analysis: the parent stands behind the subsidiary, and US law can permit access to data processed in the Union by that subsidiary. A European hosting location and a European counterparty are two good arguments, not the end of the assessment.
On the framework's own durability, be careful how you phrase it. The General Court dismissed the action for annulment on 3 September 2025 (Latombe v Commission, T-553/23), and the adequacy decision is valid and in force. But Latombe appealed to the Court of Justice on 31 October 2025 and that appeal is pending, and two predecessor frameworks were struck down. It has survived at first instance, which is not the same as being confirmed. Anyone relying on the framework alone, with no standard contractual clauses in reserve, is planning without a fallback.
GDPR and the EU AI Act
This is the question that comes up most often now, and it is usually framed wrongly. The GDPR and the AI Act do not overlap so much as stack. The AI Act regulates placing AI systems on the market and using them, by risk tier. The GDPR regulates the processing of personal data, including when that processing happens inside an AI system. A system can be fully AI Act compliant and unlawful under the GDPR, and the reverse.
Two consequences dominate in practice. First, the question companies actually ask, whether customer data can go into a given AI tool, is decided under the GDPR and not the AI Act. The model provider is normally a processor, which requires an Art. 28 contract, and that contract is what makes the transmission lawful. As long as the purpose of the processing does not change, no new legal basis is required. The decisive commitment is that inputs are not used to train the model, which needs verifying rather than assuming even though it has become standard in enterprise agreements. And your role changes the work: if you are yourself a processor and want to use a model as a sub-processor for customer data, you have to amend the existing contract with your own customer.
Second, the prior assessments resemble each other without being interchangeable. The Art. 35 DPIA addresses risks to the people whose data is processed. The fundamental rights impact assessment the AI Act requires for certain high-risk systems has a different object and does not discharge the DPIA. Art. 22 GDPR, on solely automated decisions, applies regardless of how a system is classified under the AI Act.
One calendar point, because it gets conflated. Regulation (EU) 2026/1744, published on 24 July 2026, amends the AI Act and deferred the high-risk deadlines to December 2027 and August 2028. It does not amend the GDPR.
How Kertos covers both frameworks on one evidence base is set out on the EU AI Act framework page.
What to tackle first is in our guide to preparing your business for the AI Act.
Who enforces the GDPR, which authority is yours, and what breaches cost
Thirty national supervisory authorities sit on the European Data Protection Board: the 27 EU member states plus Iceland, Liechtenstein, and Norway, alongside the European Data Protection Supervisor, who supervises EU institutions rather than companies. The count of individual authorities is higher, because a member state is one seat rather than one regulator. Germany alone has 18, one federal and 16 at state level, with Bavaria splitting public and private sector supervision. France, by contrast, has exactly one.
Which of them is yours depends on establishment, and this is the most consequential structural point in the regulation for a company operating across borders. Art. 56 makes the authority of your main establishment the lead supervisory authority for cross-border processing, and Art. 56(6) makes that authority your sole interlocutor. Main establishment is defined in Art. 4(16) by where decisions on the purposes and means of processing are actually taken and can be implemented, not simply where the holding company or the largest office sits.
The trap is that the one-stop-shop requires an EU establishment at all. If the GDPR reaches you only through Art. 3(2), you have no main establishment in the Union, so no lead authority is designated, and every supervisory authority in every member state where you offer services or monitor behavior can act against you independently. For a non-EU company that is a materially different exposure from the single-regulator relationship most guides describe, and it is worth factoring into where you put an EU entity.
Art. 83 sets two fine tiers: up to €10 million or 2 percent of total worldwide annual turnover for the organizational obligations (Arts. 25, 28, 30, 32, 33 and 34, 35, 37 to 39), and up to €20 million or 4 percent for the substantive ones (Arts. 5, 6, 7, 9, 12 to 22, and 44 to 49). The higher figure applies, and where the entity belongs to a group the turnover base is the group.
Now the part where most English-language content is out of date.
Three things are worth taking from that table. The first is that headline fines are less durable than headlines suggest, and the Amazon annulment is the clearest case: the appellate court found the authority had not analyzed intention or negligence, following the Court of Justice's reasoning in Deutsche Wohnen (C-807/21), and set the whole thing aside. Anyone still citing €746 million as the second-largest GDPR fine is describing something that no longer exists. You can read the Luxembourg court's own announcement of it.
The second is that transfers, not marketing, produce the largest numbers. Meta, TikTok twice, and Uber are all Chapter V cases. If you are prioritizing, the transfer file outranks the cookie banner by two orders of magnitude.
The third is procedural and new. In C-97/23 P, decided by the Grand Chamber on 10 February 2026, the Court of Justice held that an EDPB binding decision under Art. 65 is itself a challengeable act and that a controller can be directly concerned by it. That reverses the earlier position and means these disputes can now be fought at EU level rather than only through the national final decision. It is part of why the Meta litigation is unresolved.
On aggregate numbers, be careful with sourcing. There is no official EU-wide register. The CMS GDPR Enforcement Tracker Report, a law firm survey, records roughly 2,685 fines totaling about €6.11 billion at its 1 March 2026 cut-off. Cite it with the cut-off date and as a law firm figure, and treat the "€7.1 billion" number circulating in vendor content as unsourced.
One more distinction that trips up English-language coverage. The CNIL's €325 million against Google and €150 million against Shein, both from 1 September 2025, are not GDPR fines. They rest on Article 82 of the French Data Protection Act, which transposes the ePrivacy rules, which is precisely why the CNIL could act alone against companies whose lead authority sits elsewhere. Excluding those, TikTok's €530 million is the only GDPR fine above €100 million issued anywhere in the EU or EEA in 2025 or 2026.
What changes in 2026, and what has not
Plan against the law as it stands. The practical reading is that nothing in the GDPR's substance has changed in 2026, that the procedural regulation will change how cross-border cases are run from April 2027, and that the records exemption is still set at fewer than 250 employees whatever the simplification headlines say.
The GDPR also rarely arrives alone. Anyone pursuing ISO 27001 already covers a substantial part of Art. 32, because access control, encryption, and logging generate the same evidence in both frameworks. What does not transfer is the risk logic: a management system assesses risks to the company, which the company may carry, whereas the GDPR assesses risks to other people, which you may not. Running both on one evidence base without blurring that line is covered in our article on one platform for ISO 27001, GDPR, and SOC 2.
The full certification path, from scoping to the stage 2 audit, is in the guide to ISO 27001 certification.
How Kertos implements GDPR compliance
Kertos combines a data protection management platform with certified experts who take on part of the implementation. The privacy management system keeps the record of processing activities, the technical and organizational measures, and the processor contracts in one place, and derives changes from connected systems instead of asking once a year.
The area where automation pays off most clearly is data subject requests. They run through a defined process with identity verification, cross-system data collection, and deadline control against Art. 12, and more than half a million requests have been handled that way. The mechanics are on the DSAR automation page.
How scale-ups automate privacy management without growing the team, and where software reaches its limits, is set out in our article on GDPR and AI for scale-ups.
Obligation-by-obligation coverage is on the GDPR framework page.
If you want to know how much of your documentation load is automatable in your setup, book a conversation.
Frequently Asked Questions
Does the GDPR apply to companies outside the EU?
Yes, where Art. 3(2) applies, meaning you offer goods or services to people in the Union or monitor their behavior. No EU entity, office, or server is required. Companies caught this way must also designate a representative in the Union under Art. 27, and they do not get the benefit of the one-stop-shop, so every supervisory authority in every member state where they operate can act independently.
What counts as personal data under the GDPR?
Under Art. 4(1), any information relating to an identified or identifiable natural person. That covers names, addresses, and dates of birth, but also IP addresses, cookie IDs, location data, and employee reference numbers. The test is whether the data lets you single someone out using available means, including by combining several pieces.
When did the GDPR come into force?
On 24 May 2016, twenty days after publication in the Official Journal of the EU. It became applicable on 25 May 2018, after the two-year transition period in Art. 99. The commonly cited 25 May 2018 date is the start of applicability, not entry into force.
How much are GDPR fines?
Art. 83 sets two tiers: up to €10 million or 2 percent of total worldwide annual turnover for organizational and documentation obligations, and up to €20 million or 4 percent for infringements of the principles, data subject rights, or transfer rules, with the higher figure applying. The largest fine on record is €1.2 billion against Meta Platforms Ireland from May 2023, which has not been annulled or reduced.
Do we need a data protection officer?
Under Art. 37(1), yes if you are a public authority, if your core activity involves large-scale regular and systematic monitoring, or if it involves large-scale processing of special-category or criminal-offense data. Member states can add national triggers: Germany requires one from 20 people engaged in automated processing, while France applies no headcount threshold. Check each member state you operate in rather than relying on Art. 37 alone.
