GDPR has been in force since 2018, but enforcement is accelerating. 2023 and 2024 saw record fines—Meta hit €1.2 billion in a single ruling, and other major tech companies faced penalties ranging from hundreds of millions to tens of millions of euros. If you handle EU residents’ data and you’re not confident in your compliance posture, the risk is real and growing. This guide covers what GDPR actually requires, who it applies to, and what you need to implement to demonstrate compliance.
What Is GDPR?
The General Data Protection Regulation is the European Union’s comprehensive data protection law, enforceable since May 2018. It establishes rules for how organizations collect, use, store, and protect personal data of EU residents. Unlike earlier privacy laws that were fragmented by country, GDPR creates a unified standard across all EU member states (and Iceland, Liechtenstein, and Norway under the EEA).
The spirit of GDPR is straightforward: individuals own their personal data, and organizations handling that data are accountable for protecting it and using it fairly. The regulation sets minimum standards for privacy, but it also gives individuals specific rights they can exercise: the right to know what data is held about them, the right to correct inaccurate data, the right to delete data in certain circumstances, the right to move their data elsewhere, and the right to opt out of certain types of processing.
Enforcement is the teeth that matters. National data protection authorities (called Supervisory Authorities) in each EU country investigate complaints, conduct audits, and issue fines when organizations violate the regulation. Fines can reach €20 million or 4% of global annual revenue (whichever is higher) for the most serious violations. Lesser violations can result in fines up to €10 million or 2% of annual revenue.
Who Does GDPR Apply To?
This is the critical question for non-EU organizations. GDPR applies if you process personal data of EU residents, regardless of where your organization is located or where the data is processed. This “extraterritorial reach” means a startup based in California, India, or Brazil is subject to GDPR if it has EU customers, users, or anyone from the EU in its customer base whose data it collects or processes.
You’re in scope if any of the following apply: you operate a website accessible to EU residents and collect their email addresses; you sell products to EU customers and store their name, address, and payment information; you offer a mobile app that’s available in EU app stores; you collect data from EU job applicants; you run analytics on EU user behavior; or you have EU employees.
The regulation doesn’t require you to be huge. A small SaaS company with 50 EU users is subject to GDPR. A freelancer collecting contact information from EU clients is subject to GDPR. If you’re unsure whether you process personal data of EU residents, the safe assumption is yes—unless your business genuinely has no interaction with the EU.
Key GDPR Concepts Every Business Must Understand
Several core concepts appear throughout the regulation and shape how you implement compliance.
Personal data is any information that relates to an identified or identifiable natural person. This is broader than you might think. Obviously it includes names, email addresses, phone numbers, and home addresses. It also includes IP addresses, device identifiers, cookie IDs, user IDs, and any other data that could identify someone directly or indirectly. Even pseudonymized data counts if someone could use the pseudonym to identify the person.
Special category data (sometimes called “sensitive” data) includes personal data revealing racial or ethnic origin, political opinions, religious or philosophical beliefs, trade union membership, genetic data, biometric data used for identification, health data, and data concerning sex life or sexual orientation. This data receives heightened protection. You generally cannot process it without explicit consent from the data subject or one of a narrow set of exceptions. If you handle any special category data, GDPR compliance becomes more stringent.
Controller vs. processor is a distinction that shapes responsibility. A controller decides the purposes and means of processing—what data to collect, why, and how. A processor processes data on the controller’s behalf, following instructions. If you’re a SaaS platform, you might be a processor for your customers (who are controllers). If you operate a marketing campaign collecting customer emails, you’re a controller. Many organizations are both controllers and processors depending on context. The distinction matters because controllers and processors have different obligations under GDPR.
Lawful basis for processing is essential. You cannot process personal data without a legal reason. GDPR lists six lawful bases—we’ll cover them in detail in the next section. Before processing any personal data, you must identify which lawful basis applies. “We need the data” isn’t a lawful basis. “The user consented” is. “We have a contract with the user” is. This distinction is central to GDPR compliance.
Data subject rights are the rights GDPR gives to individuals. The right to access means anyone can request a copy of all the data an organization holds about them, and you must provide it within 30 days. The right to erasure (sometimes called “right to be forgotten”) allows individuals to request deletion of their data in certain circumstances. The right to data portability lets people get their data in a machine-readable format so they can move it to another service. The right to rectification lets people correct inaccurate data. The right to restrict processing lets people tell you to stop using their data for certain purposes while you consider a complaint. The right to object lets people opt out of certain types of processing, like direct marketing or profiling. Honoring these rights quickly and reliably is a core compliance obligation.
A Data Protection Officer (DPO) is a person or team responsible for overseeing data protection. GDPR requires a DPO for public authorities and organizations whose core business involves large-scale systematic monitoring of individuals (like social media platforms or data brokers). Many organizations aren’t legally required to have a DPO but appoint one anyway for governance and risk management. Whether you have a DPO or not, you need someone accountable for GDPR compliance.
The Six Lawful Bases for Processing Personal Data
Before processing any personal data, you must identify which of GDPR’s six lawful bases applies. Without one, the processing is unlawful.
Consent means the individual has clearly and freely given their permission for you to process their specific data for specific purposes. Consent must be unambiguous—a pre-checked box doesn’t count. The person must actively opt in. Consent works for many use cases: email marketing (you ask people to sign up), analytics (you explain what you’re tracking), or product features (you ask users to grant permission to access their location). The downside is that people can withdraw consent at any time, and consent doesn’t work well for essential business processes. For example, you can’t ask customers to consent to using their payment information to process transactions—you need a different lawful basis.
Contract is the lawful basis when processing is necessary to perform a contract with the individual. If someone buys a product from you, you need their address to ship it and their payment information to charge them. That’s contract-based processing. You don’t need consent for these necessary steps—the contract itself is the lawful basis. This is one reason why GDPR is manageable for e-commerce and SaaS companies: much of the core data handling rests on the contract lawful basis.
Legal obligation applies when you’re required by law to process personal data. If you’re a financial institution required by anti-money laundering regulations to collect identity information, or a healthcare provider required by law to maintain patient records, legal obligation is your lawful basis. You don’t need consent because the law mandates it.
Vital interests is a narrow basis: processing is necessary to protect someone’s life or health. An emergency room hospital might use it to access a patient’s medical history in a life-threatening situation where consent can’t be obtained. For most businesses, this basis rarely applies.
Public task applies when you’re a public authority or an organization carrying out a task in the public interest. A government agency processing tax returns would use this basis. Most private businesses won’t.
Legitimate interests is the broadest and most complex basis. You can process personal data based on legitimate interests pursued by you, your organization, or a third party—unless the data subject’s rights and freedoms override those interests. Legitimate interests could be fraud prevention, security, marketing to existing customers, analytics to improve your service, or operational efficiency. The analysis requires a “balancing test”: you weigh your business need against the person’s privacy expectations and potential harm. For data processing that’s not essential to a contract and where consent would be impractical, legitimate interests is often the answer. But you must document your assessment.
Most organizations use multiple lawful bases depending on the context. An e-commerce company might use contract for transaction processing, consent for email marketing, legitimate interests for fraud detection, and legal obligation for tax record retention. The key is documenting which basis applies to each processing activity and being able to defend it if questioned.
GDPR Technical and Organisational Measures: What You Actually Need to Implement
GDPR requires organizations to implement technical and organizational measures to protect personal data. The regulation doesn’t prescribe specific technologies—it requires an appropriate level of security given the risk. What’s appropriate depends on context: processing a customer’s email list requires different measures than processing their payment card information, genetic data, or real-time location tracking.
Data encryption and pseudonymization are fundamental. Personal data at rest should be encrypted using strong encryption (AES-256 is standard). Data in transit should use TLS or equivalent. Pseudonymization—replacing identifying details with aliases—is another approach, though GDPR notes that pseudonymized data may still be personal data if you can identify someone with reasonable effort.
Access controls mean the people handling personal data have legitimate roles and appropriate access levels. Your customer service team might access customer contact information to respond to support requests. Your engineering team building the payment system might have access to test card data, but not production customer payment information. Access should be logged, and access levels should be revoked when people leave roles.
Encryption of backups and secure deletion are often overlooked. Backup copies of personal data should be encrypted like production data. When data is deleted—either because a customer requests it or because your retention period expires—deletion should be permanent and verifiable. Writing “deleted” to a database but keeping the data in backups doesn’t meet GDPR standards.
Data breach detection and response procedures are mandatory. You need ways to detect when data has been accessed, modified, or leaked. This means logging access to sensitive data, monitoring for unusual patterns, and having incident response procedures. When a breach occurs, you must notify affected individuals and the relevant supervisory authority within 72 hours if there’s a risk to rights and freedoms.
Privacy by design and by default means integrating privacy into your systems from the start, not as an afterthought. Privacy by design happens during development: you consider what personal data you need, minimize it, and build controls into the product. Privacy by default means your systems handle data safely without users having to configure privacy settings themselves. For example, if you’re building a collaboration tool, the default should be that data isn’t shared with third parties—users can opt in to sharing, not out.
Vendor and processor management is essential because if you engage third parties to process personal data on your behalf, you remain responsible for their compliance. You need Data Processing Agreements (DPAs) with all vendors specifying what data they can access, how they’ll protect it, and their obligations. Regular audits of processor security and compliance are important. If you use cloud services, SaaS tools, or data analytics platforms, they’re likely processors, and they need DPAs.
Data Protection Impact Assessments (DPIAs) are required for processing that poses higher risks. A DPIA is a documented analysis of what data you’ll collect, why, how long you’ll keep it, who’ll access it, what risks exist, and what measures you’ll implement to mitigate risks. DPIAs are particularly important for new processing involving sensitive data, large-scale processing, or use of new technologies. When a risk is identified during a DPIA, you document how you’ll mitigate it before starting the processing.
Records of Processing Activities (RoPA), sometimes called a “data inventory,” document all processing activities your organization conducts. For each processing activity, RoPA includes who’s the controller and processor, what personal data is involved, how long it’s retained, what lawful basis applies, what recipients have access, and what safeguards are in place. When a data protection authority investigates, the first thing they ask to see is RoPA. Having an up-to-date, accurate inventory is critical.
GDPR Data Breach Notification: The 72-Hour Rule
When personal data is breached—accessed, disclosed, modified, or deleted without authorization—you have specific obligations. First, you must notify the relevant supervisory authority within 72 hours of becoming aware of the breach, unless there’s no risk to rights and freedoms. If there is a risk, you must also notify affected individuals without undue delay. Notification must describe the nature of the breach, its likely consequences, and the measures you’ve taken to mitigate harm.
The 72-hour clock starts when you discover the breach. This is why incident response procedures are important. You need to detect breaches quickly. If it takes six months to discover a breach that occurred six months ago, you’re already 150+ days late.
In practice, the 72-hour rule creates operational urgency. You need to have a plan in place: who investigates breaches, who decides whether notification is required, who communicates with regulators, and how you manage media inquiries. A data protection lawyer familiar with your jurisdiction is often essential, because the line between a breach requiring notification and one that doesn’t is sometimes nuanced.
GDPR Fines and Enforcement: What’s Actually Happened
GDPR’s fine structure has teeth, and supervisory authorities are using them. Fines depend on whether the violation is less serious (up to €10 million or 2% of annual revenue) or serious (up to €20 million or 4% of annual revenue). When an authority issues a fine, it considers factors like the nature and gravity of the violation, whether it was intentional, whether the organization cooperated, and any previous violations.
Real-world examples illustrate the pattern. Meta paid €1.2 billion for violating GDPR requirements around data transfers and user consent for targeted advertising. Amazon paid €750 million for GDPR violations related to customer consent and processing. British Airways paid £20 million for a data breach affecting 429,000 passengers (now reduced to £16 million on appeal). Even smaller violations matter: a regional authority fined a healthcare provider €100,000 for inadequate access controls.
The trend is clear: enforcement is increasing, and fines are substantial. Organizations can’t treat GDPR as a nice-to-have compliance project anymore. The question isn’t whether to comply—it’s whether to comply now or face regulatory action later.
GDPR and CCPA: Key Differences
GDPR is European, but CCPA (California Consumer Privacy Act) is American. Many organizations serve both EU and California residents, so understanding how the laws differ matters.
GDPR is older (2018 vs. 2020) and more established. CCPA is newer and still evolving—it’s being supplemented by the California Privacy Rights Act (CPRA) which expands CCPA requirements. GDPR applies to any organization processing EU residents’ data. CCPA has threshold requirements—you generally need to be a for-profit business doing business in California earning $25 million+ in annual revenue, collecting data from 100,000+ people, or deriving 50% or more of revenue from selling personal information. Many small organizations aren’t subject to CCPA but are subject to GDPR.
GDPR requires a lawful basis for processing. CCPA doesn’t—it gives consumers rights to know, delete, and opt out, but doesn’t limit how businesses collect data unless they’re selling it. GDPR has strict consent requirements. CCPA doesn’t require consent for most processing, just notice and opt-out rights. GDPR’s fines are based on global revenue. CCPA’s penalties are per violation or per violation per day, which can add up.
GDPR requires a Data Protection Officer for certain organizations. CCPA doesn’t have that requirement. GDPR applies to all processing. CCPA carves out exemptions for certain types of data like employee data or b2b information.
If you serve both EU and California residents, you need to meet the stricter standard on most counts. GDPR’s requirements around consent and lawful basis are more stringent than CCPA’s. Complying with GDPR generally gets you most of the way to CCPA compliance, but not entirely. California’s emerging CPRA requirements, including a rights to correct data and limit use, are moving closer to GDPR’s approach.
GDPR Compliance Checklist: Where to Start
If you’re not confident in your GDPR compliance, start here:
Conduct a data audit. Map all the personal data your organization collects, where it comes from, where it’s stored, how long you keep it, who accesses it, and whether it includes special category data. This inventory is the foundation.
Identify your lawful bases for each processing activity. For each type of data collection or use, document which of the six lawful bases applies and your reasoning. This documentation will be important if regulators question your practices.
Audit your vendor contracts. Review all third-party vendors handling personal data—cloud providers, analytics tools, payment processors, marketing platforms. Do they have Data Processing Agreements? Are you confident they’re meeting GDPR standards? If not, update contracts.
Implement access controls. Document who has access to personal data, why, and ensure access is limited to what’s necessary. Set up access logs and review them regularly.
Develop a data breach response plan. Establish a process for detecting, investigating, and reporting breaches. Know who your legal counsel is and how you’ll meet the 72-hour notification requirement.
Create privacy notices and make them clear. Your privacy policy should explain what data you collect, why, how long you keep it, what rights people have, and how they can exercise those rights. Make it readable—dense legal language isn’t what regulators want to see.
Document consent where required. If you rely on consent, ensure it’s clear, freely given, and documented. Maintain records showing people actively opted in.
Conduct a Data Protection Impact Assessment for any processing involving sensitive data or large-scale systematic monitoring.
Get legal review from someone familiar with GDPR. The regulation is complex, and the cost of getting it wrong is high.
How Soter Advisory Can Help
GDPR compliance isn’t a one-time project—it’s ongoing. Requirements change, your business evolves, new data types are handled, and regulatory guidance updates. Having expert guidance through the initial implementation and ongoing support ensures you’re building a sustainable compliance program.
Need help with GDPR? Soter Advisory works with companies at every stage—from initial gap assessment through to certification and ongoing support.