What Is GDPR Compliance? Requirements and How to Meet Them
Most teams can describe their GDPR obligations. Far fewer can produce the records that prove they met them.
That gap is where GDPR compliance gets hard. The regulation reads as legal text, so it usually gets treated as legal work. About a third of it lands on the IT team instead: records of what you process, security controls that have to hold up, and deadlines measured in hours.
Nobody asks for that evidence on a quiet week. An audit log written after the fact convinces nobody, and the questions tend to arrive after a breach or alongside a complaint.
We have watched teams pass a privacy review on paper and then miss the breach deadline. The security was fine. Nobody could say when the compromise was detected.
In this guide, you will learn:
GDPR reaches US companies: Article 3 applies it to any organization offering goods or services to people in the EU, wherever that organization sits.
The fines have two tiers: Up to 20 million euros or 4 percent of global turnover for serious breaches, and half that for lesser ones.
Four articles create most of the IT work: Article 30 records, Article 32 security, and Articles 33 and 34 breach notification.
The 72-hour clock is a detection problem: It starts when you become aware of a breach, so the timestamp matters as much as the fix.
Evidence beats policy: Article 5 makes you demonstrate compliance, not just achieve it.
By the end you will know whether GDPR applies to you. You will also know which articles your team owns, and what records prove you met them.
Note: This guide and the checklist are published for general information, not as legal advice. Your GDPR obligations depend on what personal data you process, whether you act as a controller or a processor, and where the people whose data you hold are located. Have a qualified data protection professional confirm how any of it applies to your organization before you rely on it.
What Is GDPR Compliance?
GDPR compliance means meeting the obligations in the General Data Protection Regulation. That is the EU law governing how personal data is collected, used, stored, and protected. It covers the personal data of people in the EU, whoever processes it.
The regulation is formally Regulation (EU) 2016/679. It took effect on 25 May 2018. It replaced a patchwork of national laws with one rulebook across every member state.
Two roles run through the whole text. Knowing which one you are changes what you owe.
Controller: You decide why and how personal data gets processed. A bank collecting customer records is a controller.
Processor: You process data on a controller's instructions. A SaaS platform running that bank's data is a processor.
Controllers carry the heavier obligations. Processors are directly liable too, which was new in GDPR. If you sell software that touches EU personal data, you are almost certainly a processor.
One more thing catches people out. There is no such thing as GDPR certification, because no regulator issues one. Compliance is a state you have to demonstrate on request. That is why the record-keeping matters so much.
Does GDPR Apply to US Companies?
Yes, GDPR applies to many US companies. Having no office or servers in Europe does not exempt you. Article 3 sets the territorial scope, and it turns on where the people are, not where the company is.
Three tests decide it. Meeting any one of them puts you in scope.
Test | What Triggers It | Example |
Establishment in the EU | You have a branch, office, or subsidiary in the EU, wherever the processing happens | A US firm with a Dublin sales office |
Offering goods or services | You target people in the EU, even for free | Pricing shown in euros, or a site translated into German |
Monitoring behavior | You track what people in the EU do online | Analytics, cookies, or ad retargeting on EU visitors |
The second test is where we see US companies get caught. Having EU visitors is not enough on its own. Deliberately targeting them is. Accepting euros, shipping to EU addresses, or running ads aimed at an EU country all point toward targeting.
Two obligations then follow that surprise almost every US company we talk to.
An EU representative under Article 27: Most in-scope organizations outside the EU have to appoint one in writing and publish who it is. It is a named contact for regulators and data subjects, not a lawyer on retainer.
A separate UK regime: Since Brexit, Britain runs its own UK GDPR alongside the Data Protection Act 2018. Serving both markets means a representative in each, answering to two different regulators.
Neither depends on how good your security is. They are paperwork obligations, and they are the ones we see missed most often.
What Are the Seven Principles of GDPR?
The seven principles sit in Article 5 and govern every processing activity you run. Every other obligation traces back to one of them. Here is what each one requires.
Principle | What It Requires |
Lawfulness, fairness, transparency | Have a valid legal basis, and tell people plainly what you do with their data |
Purpose limitation | Collect for a specific stated purpose, and do not quietly reuse it for another |
Data minimization | Collect only what the purpose actually needs |
Accuracy | Keep data correct and current, and fix or delete what is wrong |
Storage limitation | Keep it only as long as the purpose requires, then delete or anonymize |
Integrity and confidentiality | Protect data with appropriate technical and organizational security |
Accountability | Be able to demonstrate all six of the above |
The first principle needs one more layer. Lawful processing means picking one of six legal bases in Article 6, then documenting which one covers which activity.
Consent: Freely given and specific, and as easy to withdraw as it was to give.
Contract: Processing is needed to deliver what the person signed up for.
Legal obligation: Another law requires you to process it.
Vital interests: Someone's life or safety is at stake.
Public task: You are carrying out an official function.
Legitimate interests: You have a real business need that does not override the person's rights.
Consent gets the most attention and is often the weakest choice, because it can be withdrawn at any moment. We would reach for contract or legitimate interests wherever either genuinely fits.
Accountability is the principle that turns the other six into work. Being compliant is not enough. Article 5(2) makes you responsible for showing it.
That single word changes the job. The evidence has to already exist when someone asks, and in our experience that is where good security programs still come apart.
Integrity and confidentiality is the principle your IT team owns outright. Article 32 spells out what it means in practice, and we get to that shortly.
What Are the Eight Data Subject Rights?
The eight rights let people see, correct, move, and delete the data you hold on them. They sit in Articles 13 to 22, and any one of them can arrive in your inbox on any given morning.
Right | Article | What the Person Can Ask For |
To be informed | 13 and 14 | To be told what you collect and why, at the point you collect it |
Access | 15 | A copy of their data, plus how and why you process it |
Rectification | 16 | Inaccurate or incomplete data corrected |
Erasure | 17 | Their data deleted, often called the right to be forgotten |
Restriction | 18 | Processing paused while a dispute is worked out |
Portability | 20 | Their data in a machine-readable format, or sent to another provider |
To object | 21 | Processing stopped where it rests on legitimate interests or direct marketing |
Automated decisions | 22 | Not to be subject to solely automated decisions with legal or similar effects |
The access right generates the most work by a wide margin. Someone asks for everything you hold, and you have one month to produce it.
That deadline can be extended by two further months for complex or numerous requests. You have to tell the person inside the first month, so the extension is not a quiet fallback.
Here is where these requests actually get lost. Personal data sits in your ticketing system, your logs, your CRM, your backups, and your email, so answering means searching all of them. Teams that treat a request as an email someone remembers will miss the window eventually.
The teams we see handle it well treat it as a tracked service request. It gets an SLA and a named owner, like any other ticket with a clock on it.
Which GDPR Articles Create Actual Work for IT?
Four articles generate most of the technical workload. They are Article 30, Article 32, Article 33, and Article 34. The rest of the regulation is largely legal and privacy work, so this is where an IT team should spend its attention.
1. Article 30: Records of Processing Activities
Article 30 requires a written record of what you process. It covers why you process it, who you share it with, where it goes, and how long you keep it. Controllers and processors both need one.
In practice this is a data inventory. It is usually the first thing a supervisory authority asks for.
It is also the thing we see fail first. Personal data does not sit in one system. It is in your ticketing tool, your asset records, your log files, and your email. Mapping it honestly takes longer than anyone budgets.
2. Article 32: Security of Processing
Article 32 is the security article. It names four capabilities you have to provide, which is unusually specific for GDPR.
Pseudonymization and encryption: Named directly in the text as appropriate measures.
Confidentiality, integrity, availability, and resilience: Your systems have to keep providing all four, on an ongoing basis.
Restore availability after an incident: You must be able to bring data and access back in a timely manner.
Regular testing: A process for routinely testing whether the measures actually work, usually built on scheduled vulnerability assessment.
Notice that two of those four are availability obligations, not confidentiality ones. Most teams read Article 32 as an encryption requirement. Backup, recovery, and uptime sit inside the same article.
That has a consequence worth spelling out. A ransomware incident that locks you out of personal data is an Article 32 failure, even when nothing leaked.
The testing point catches people too. A control you have never tested is a control you cannot evidence. The article asks for a process, not a one-time assessment.
3. Article 33: Breach Notification Within 72 Hours
Article 33 gives you 72 hours to notify the supervisory authority after becoming aware of a personal data breach. Miss it, and the notification has to explain the delay.
The phrase that matters is becoming aware. Three details decide how that plays out:
The clock starts at reasonable certainty: Not when the breach happened, and not when the investigation wraps up.
Processors get no 72 hours: You notify your controller without undue delay, so their clock can start.
Not every breach is reportable: The test is whether it is unlikely to risk people's rights and freedoms. A decision not to report still has to be documented.
That first point makes detection speed and a defensible timestamp the whole game. Both come out of log management, and we have seen teams lose the deadline while arguing about when they officially knew.
4. Article 34: Telling the Affected People
Article 34 covers the second notification. This one goes to the individuals whose data was exposed. It applies when the breach is likely to result in a high risk to their rights and freedoms.
There is no fixed clock here, only without undue delay. Encryption can excuse you from this one. If the exposed data was unintelligible to whoever accessed it, you may not need to notify individuals at all.
That is a concrete reason encryption pays for itself, and we would put it near the top of any Article 32 plan.
What Evidence Proves You Meet Article 32?
Article 32 evidence is the dated record showing a control was operating. It is not the policy saying it should. Accountability under Article 5(2) means a regulator can ask you to demonstrate it.
The demand works differently from an audit. There is no scheduled fieldwork and no sampling window. A supervisory authority asks after a breach or a complaint.
So the records have to already exist, and they have to reach back far enough to cover whatever gets asked about. Here is what each obligation calls for, and where the artifact usually comes from.
Article | What You Must Show | Evidence Normally Requested | Usual System of Record |
Art 30 | A written record of processing activities | Data inventory naming systems, purposes, categories, recipients, transfers, and retention periods | CMDB, asset register |
Art 32(1)(a) | Pseudonymization and encryption | Encryption standards at rest and in transit, TLS configuration, key management records | Infrastructure config |
Art 32(1)(b) | Ongoing confidentiality | Access listings per system, approval records, periodic access reviews, leaver de-provisioning timestamps | IAM or SSO, service desk |
Art 32(1)(b) | Ongoing integrity | Change records with approver and test evidence, configuration baselines, drift reports | Service desk, config management |
Art 32(1)(b) | Ongoing availability and resilience | Uptime and capacity reports, redundancy design, monitoring alert history | Monitoring platform |
Art 32(1)(c) | Restore availability after an incident | Backup job logs with success and failure rates, dated restore test results with sign-off | Backup tooling |
Art 32(1)(d) | Regular testing of the measures | Vulnerability scan history, penetration test reports, control test records across the period | Security tooling |
Art 33 | You detected and reported inside 72 hours | Incident ticket with detection timestamp, severity, owner, actions, and the notification itself | Service desk, log management |
Art 33(5) | Every breach documented, reported or not | Internal breach register covering facts, effects, remedial action, and the reasoning where you did not report | Breach register |
Art 34 | Affected people were told, or lawfully were not | Communication records, or the encryption evidence that excused notification | Comms records |
Read down that table and a pattern shows up. Most of these artifacts are output from systems your team already runs, as long as those systems are set to keep them.
The service desk: Access approvals, leaver records, and the incident timeline Article 33 depends on, provided requests go through tickets rather than direct messages.
Change management: The approver, the test result, and the deployment record behind every change to a system holding personal data.
The monitoring platform: Detection timestamps, alert history, and the retention window that decides how far back your evidence reaches.
Backup tooling: Job logs and dated restore tests, which are the only proof that Article 32(1)(c) is more than an intention.
Those two halves usually live in separate tools. Put them on one unified observability and ITSM platform and the breach timeline stays attached to the evidence behind it.
None of that makes a platform a compliance product, and no tool makes you GDPR compliant. What it decides is whether a regulator's question takes an afternoon or three weeks.
We have sat on both sides of that, and the difference is rarely the security work itself.
GDPR Compliance Checklist: 10 Steps
Knowing the obligations is one thing, and sequencing them is another. Here is the order we see work best, starting with the two steps everything else depends on.
Confirm whether you are in scope: Run the three Article 3 tests. Write down the answer and the reasoning, because you may need to show it.
Decide if you are controller or processor: It can be both, for different activities. Your obligations and your contracts change either way.
Build the Article 30 record: Map where personal data actually lives across tickets, assets, logs, backups, and email. Nothing else works without this.
Establish a lawful basis for each activity: Consent is one of six, and often the weakest. Document which basis covers which processing.
Appoint the roles you need: A Data Protection Officer if Article 37 requires one, and an Article 27 EU representative if you sit outside the EU.
Close the Article 32 gaps: Encryption, access control, backup and restore testing, and a routine schedule for testing all of it.
Turn on continuous evidence collection: Access reviews, change approvals, alerting, backup logs, and retention settings that keep records long enough to matter.
Write and rehearse the breach procedure: Who declares a breach, who starts the 72-hour clock, who notifies, and where the register lives.
Build the data subject request workflow: You get one month to respond, extendable by two more. Treat it as a tracked service request, not an email someone remembers.
Review vendors and transfers: Processor agreements under Article 28, and a lawful transfer mechanism for anything leaving the EU.
Steps three and seven decide how painful the rest becomes. Both are easier to track in a spreadsheet than a document, and the downloadable checklist carries these ten steps on their own sheet.
Have a qualified data protection professional review how it applies to you. Motadata offers it as a helpful resource and is not responsible for how it is used, or for any loss, finding, or penalty that results from using it.
What Do GDPR Fines and Compliance Actually Cost?
GDPR fines run in two tiers. Which tier you land in depends on which article you broke. Both cap as a share of worldwide annual turnover, not local revenue.
Tier | Maximum | Covers |
Lower | 10 million euros, or 2 percent of global annual turnover, whichever is higher | Article 30 records, Article 32 security, Articles 33 and 34 breach notification |
Higher | 20 million euros, or 4 percent of global annual turnover, whichever is higher | The Article 5 principles, lawful basis, data subject rights, international transfers |
Notice where the IT articles sit. All four fall in the lower tier, which sounds like good news.
It rarely works out that way. A security failure usually drags a principles failure with it, because a breach tends to prove the integrity and confidentiality principle was not met either.
Fines are also not the worst outcome available to a regulator. Article 58 gives supervisory authorities corrective powers that bite harder than money.
A ban on processing: An authority can order you to stop processing personal data, temporarily or permanently. For a business built on that data, this is worse than any fine.
Suspension of data transfers: Flows to a third country can be halted, which can break a product that runs on US infrastructure.
Compensation claims: Article 82 gives anyone who suffered damage the right to claim from you directly, separately from the fine.
The reputational cost sits on top of all of that, and it lands whether or not a penalty is ever issued.
The cost of compliance itself is harder to pin down. Published estimates vary by an order of magnitude, and they depend almost entirely on your starting point. Here are the factors that move the number:
Data sprawl: The more systems hold personal data, the longer the Article 30 mapping takes.
Whether you need a DPO: Article 37 makes it mandatory for some organizations and optional for others.
Article 27 representative: A recurring cost for any in-scope company outside the EU.
Existing security maturity: If encryption, access reviews, and backup testing already run, Article 32 is mostly documentation.
Vendor count: Every processor needs an Article 28 agreement and a transfer mechanism.
Our rule of thumb is that the mapping work in step three costs more than anything else on that list. It is also the step teams consistently underestimate.
GDPR vs CCPA, DPDPA, and POPIA
GDPR is the template most modern privacy laws copied. If you already meet it, the others get easier. The differences that matter are scope, whether consent is needed upfront, and how fast you report a breach.
GDPR | CCPA and CPRA | DPDPA | POPIA | |
Applies to | People in the EU | California residents | People in India | People in South Africa |
Consent model | Opt in before processing | Opt out of sale or sharing | Opt in, with notice | Opt in, with defined exceptions |
Breach clock | 72 hours to the authority | Without unreasonable delay | As prescribed by the Board | As soon as reasonably possible |
Maximum penalty | 20 million euros or 4 percent of turnover | Per-violation civil penalties | Up to 250 crore rupees | Up to 10 million rand |
Covers companies too | No, individuals only | No, consumers only | No, individuals only | Yes, juristic persons included |
The practical takeaway is that one control set can serve several of these at once. Access control, encryption, breach detection, and retention limits appear in all four.
Most teams we work with map one set of controls to multiple frameworks rather than running separate programs. Teams with obligations in India will find the same structure in DPDPA compliance, which was drafted with GDPR as its reference point.
South Africa works the same way. The one real difference is that POPIA compliance protects companies as well as individuals, so its definition of personal information is wider than any of the other three.
Why Is GDPR Compliance So Hard to Maintain?
GDPR is hard to maintain because nothing forces you to check. There is no annual audit and no certificate to renew. A program can go stale for two years, and nobody notices until a request or a breach arrives.
Four problems come up again and again in the teams we work with.
Personal data spreads faster than the record: Every new tool, integration, and export creates a copy. The Article 30 record is accurate the day it is written and drifting by the end of the month.
Nobody owns it end to end: Legal owns lawful basis, IT owns Article 32, HR owns employee data, and the gaps between them are where obligations get dropped.
Retention is set once and forgotten: Storage limitation asks you to delete data you no longer need. Default settings keep everything forever, which quietly breaks a principle every day.
The breach clock assumes detection works: A 72-hour deadline is meaningless if the compromise sits unnoticed for six weeks. Most missed deadlines start as missed detections, which makes this an incident management problem before it is a legal one.
The pattern underneath all four is the same. GDPR asks for an ongoing state, and most teams implement it as a one-off project.
How Do You Get Started With GDPR Compliance?
Start with the Article 3 scope test, then the Article 30 record. Everything downstream depends on knowing you are in scope and knowing where the data sits.
Then split what you find into two piles. One holds obligations you genuinely do not meet, like a missing EU representative or untested backups. The other holds things you do correctly but cannot prove.
The second pile is almost always larger, and it is the cheaper one to fix. Fixing it means routing work that already happens through systems that timestamp it.
Access requests move out of direct messages and into tickets with an approver.
Breach declarations get a defined trigger and a recorded detection time.
Backup restores get tested on a schedule, with the result written down.
Log retention gets set long enough that last quarter's evidence still exists.
None of that is a privacy project. It is ordinary operational discipline, which is why teams already running solid incident management clear the Article 33 bar without much extra work.
Retention settings are the one thing we would check today. They quietly decide whether next quarter's evidence exists at all.
Build Data Protection Into How You Already Work
GDPR rewards teams whose systems keep a record of what they did. The privacy policies and lawful bases matter. But the four articles that generate real operational work come down to one question: can you show what happened, and when.
The part nobody enjoys is that this discipline slows you down at first. Approval gates add friction. Restore tests eat a day. Mapping personal data across a decade-old estate is tedious work with no visible reward.
What it buys is a 72-hour clock you can meet, a data subject request answered in days instead of weeks, and a regulator conversation where the answer already exists.
The teams we see handle this best stopped treating privacy as a project with an end date. For them it became a property of how they already run.
FAQs
Is there such a thing as GDPR certification?
No official GDPR certificate exists. Article 42 allows for approved certification schemes, but no regulator issues a general GDPR certification. Any vendor selling one is describing their own audit, not an official status.
What happens if you miss the 72-hour breach deadline?
You still notify, and you must include a reasoned explanation for the delay. Missing the deadline is a lower-tier infringement on its own. Regulators treat a late but honest report more favorably than a quiet one.
Does GDPR apply to employee data?
GDPR does apply to employee data. Personal data covers your own staff as well as customers, so HR records, access logs, and monitoring data on EU-based employees all fall in scope. Employee monitoring in particular needs a documented lawful basis.
How long do you have to answer a data subject request?
One month from receipt, extendable by a further two months for complex or numerous requests. You have to tell the person about any extension within that first month. Tracking these as service requests is what keeps teams inside the window.
Do US companies really get fined under GDPR?
US companies do get fined. Supervisory authorities have issued substantial penalties to US-headquartered organizations. Enforcement reaches companies with no EU establishment through the Article 27 representative and cooperation between regulators.
Author
Ramya Shah
Technical Writer
Ramya Shah is a technical content writer with a computer engineering background and roots in automotive journalism. He covers IT Service Management, observability, IT operations, and AI-driven automation. An early adopter of AI-assisted writing workflows, he turns complex IT processes into clear, engaging content optimized for search and answer engines (AEO), lifting content output and organic visibility.
