GDPR: The Complete Guide for Companies

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(1) sets out six principles that every single processing operation has to satisfy: lawfulness, fairness and transparency (a), purpose limitation (b), data minimization (c), accuracy (d), storage limitation (e), and integrity and confidentiality (f). Accountability sits separately in Art. 5(2), which is why the set is commonly described as seven principles. Accountability is the expensive one. It 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 and they rank equally. A basis has to be determined for each purpose before processing begins. More than one basis inside a single processing activity therefore presupposes that each basis has its own purpose, and where purposes are bundled they have to be documented separately. Naming several bases as a precaution, so that one holds if another fails, undermines the transparency obligation in Art. 13(1)(c) and the exercise of data subject rights. Switching the basis afterwards, because the one you chose no longer holds, is not permitted; the EDPB treats it as unfair as a rule in its guidelines 05/2020 and 2/2019.

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 sets a high bar for proving that consent was freely given, and Recital 43 points the same way: where there is a clear imbalance between controller and data subject, consent is not a sound basis. 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.

That contract has to cover the mandatory contents in Art. 28(3) in full: the subject matter and duration of the processing, its nature and purpose, the categories of personal data and of data subjects, the controller's obligations and rights, the security measures, and the arrangements for sub-processors. Note also that a processor relationship is not the only option; where two parties jointly determine purposes and means they are joint controllers under Art. 26 and need a different agreement.

On that contract, the first check is the most basic one and it is the one that fails most often: are all of those contents 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.

Which minimum contents under Art. 28(3) to check first, where sub-processor chains and liability caps quietly fail, and what to do when the provider will not negotiate, are covered in our guide to reviewing a data processing agreement.

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(1) BDSG, and, independently of headcount, wherever the processing is subject to a DPIA; 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. The Court of Justice reads the copy as a faithful and intelligible reproduction, and extracts from documents or whole documents may be required where that is indispensable for the person to exercise their rights effectively (C-487/21, 4 May 2023). Recipients work the same way: on request the specific recipients have to be named, unless that is impossible or the request is manifestly unfounded or excessive (C-154/21, 12 January 2023). 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 often provoke a second infringement, since many companies cannot answer completely and on time. Compensation under Art. 82 does require actual damage, though: the infringement alone is not enough (C-300/21, 4 May 2023). There is no seriousness threshold either, so even minor non-material damage is compensable. 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: when it is required, and how it is structured

Whether a DPIA is required and how one is built are two separate questions. Art. 35(3) names three standard cases: systematic and extensive evaluation of personal aspects by automated processing, including profiling, on which decisions with legal or similarly significant effect are based; large-scale processing of special-category data under Art. 9(1) or of criminal-offense data under Art. 10; and systematic large-scale monitoring of publicly accessible areas. Art. 35(4) adds the lists published by supervisory authorities. The threshold assessment records, for each processing activity, whether a high risk is likely, and a negative result has to be documented too. Only once the threshold is crossed does the full DPIA follow.

Art. 35 requires that assessment where processing is likely to result in a high risk to the rights and freedoms of natural persons. What is most often not given enough weight is the order of the check: before you assess risks, you have to describe what is processed, what purpose it serves, and whether it is necessary and proportionate in that form. Only on that basis can you judge which risks arise for the people concerned and which measures are needed against them. So the DPIA breaks into four steps that build on each other.

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. In an ISO 27001 management system you may assess a residual 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. Those risks are not yours to dispose of in the same way. That does not mean no risk at all may remain after a DPIA; the GDPR asks for a risk-appropriate assessment and suitable mitigations. But if a likely high risk remains once those are implemented, you may not simply start processing on that basis. An approval step labeled "high risk accepted" has no place in a DPIA.

What applies instead is Art. 36: consult the competent supervisory authority before processing begins, or do not go ahead. In practice the case is rare, but the provision is central to understanding the DPIA, because the alternative to effective mitigation is not unchecked continuation, it is the regulator. The consultation replaces neither the mitigation nor a normal sign-off step.

Two tools help more than any template from a blog. The EDPB adopted a draft DPIA template on 10 March 2026 and put it out for public consultation from 14 April to 9 June 2026; it sets out the sub-points per step clearly. The consultation has closed and the final version is still outstanding, so cite it as a draft. The CNIL's PIA software, free and open source, walks the structure and ships a catalog of predefined risks. 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, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. That risk threshold is part of the obligation and is routinely dropped in summaries. 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 position is not free of cost: Art. 33(1) only requires notification where there is a risk, and notifying without a duty consumes time and hands the authority a documented set of facts.

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 and only applies where the breach is likely to result in a high risk to their rights and freedoms. There is no 72-hour deadline toward those individuals, though the notification still has to be made without undue delay. The difference between the two articles is the threshold: a risk is enough to trigger notification to the authority, a high risk is what makes notifying the individuals mandatory. So notify the authority when in doubt, yes; write to every affected person when in doubt, no.

Art. 33(5) then requires you to document every personal data breach, including the ones you do not have to report. An internal breach register is a legal obligation, not a best practice. What actually makes the difference is preparation: a named escalation chain and the right authority's notification form located in advance. Both can be arranged beforehand. The 72 hours cannot.

International data transfers

Chapter V, Arts. 44 to 50, governs transfers to recipients outside the EU and EEA. It always presupposes that the processing is already lawful under Art. 6; Chapter V is the second question, not the first. Once that is settled, the first check for a US provider 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 (Commission Implementing Decision (EU) 2023/1795 of 10 July 2023), 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 Commission's standard contractual clauses under Art. 46(2)(c) (Implementing Decision (EU) 2021/914 of 4 June 2021). Point (d) covers clauses adopted by a supervisory authority and approved by the Commission, and plays close to no role in practice, so there is no real choice between the two. This is where teams skip a step. When the Court of Justice invalidated the previous adequacy decision (Schrems II, C-311/18, 16 July 2020) it required supplementary measures on top of the clauses, insofar as the clauses alone do not secure an essentially equivalent level of protection. The contract alone is not enough, and that is where the transfer impact assessment comes from.

Before any of the substantive assessment comes a formal step that is missed more often than any other: picking the right module. The clauses have four, depending on the parties' roles. Module 1 covers controller to controller, Module 2 controller to processor, Module 3 processor to processor, and Module 4 processor to controller. Processor-to-processor arrangements, which need Module 3, routinely get papered with Module 2. The wrong module makes the transfer mechanism attackable, because the obligations agreed do not match how the roles actually sit.

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. This is exactly where contract negotiations show a characteristic weakness. The controller asks the processor whether a TIA exists for the US sub-processors it uses, gets back a "yes, we have one," and treats the point as closed. What has then been documented is the assessment's existence, not its result. Whether the four questions were actually answered for that sub-processor, and what measures followed, stays open. The better move is to have the assessment itself produced, or to make it contractually demandable, rather than asking only whether it exists. Responsibility for assessing the transfer stays with the controller.

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, the appeal is pending as C-703/25 P, 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 and in force since 27 July, amends the AI Act and deferred the high-risk deadlines to 2 December 2027 and 2 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. Where the entity belongs to a group, the turnover base is the EU-law concept of an undertaking under Arts. 101 and 102 TFEU, meaning the economic unit rather than the legal entity; Recital 150 makes that reference expressly, and limits it to calculating the fine. The Court of Justice confirmed as much and made clear the concept governs only the ceiling, not who may be fined or on what conditions (C-807/21, 5 December 2023). The addressee remains the controller or processor, while the parent can be jointly liable for payment.

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.