What is data compliance?

• Global average data breach cost in 2026: $4.99 million, up 12% and a record, per IBM’s Cost of a Data Breach report.
• US average breach cost in 2025: $10.22 million, the highest of any country in IBM’s 2025 X-Force report.
• Erasure enforcement in 2025: 32 data protection authorities reviewed 764 controllers, per the EDPB’s February 2026 findings.
• PCI DSS v4.x in 2025: 51 of 64 new requirements became mandatory on 31 March, per the PCI Security Standards Council.
• AI Act high-risk duties: pushed to 2 December 2027 and 2 August 2028 by the Council’s 29 June 2026 approval of the AI omnibus.

What Data Compliance Means and Which Rules It Covers

Data compliance means handling personal and sensitive data so that it meets every legal, regulatory, industry and internal requirement that applies to it. That’s the whole idea in one sentence. The hard part is the phrase “every requirement,” because the rules come from several governments and industry bodies at once, and each asks for something slightly different.

IBM’s explainer on data compliance splits those requirements into four areas, and I think the split holds up well:

• Accuracy: the data you hold about a person has to be correct and kept correct.
• Transparency: people must be told what you collect, why, and what rights they have over it.
• Protection: you have to guard the data against unauthorised access and breaches.
• Lifecycle: data needs defined storage, retention and deletion rules from the day you collect it.

Two terms get mixed up constantly here. Data governance is the internal set of policies and processes a company uses to manage its data. Data compliance is about meeting the external obligations that governments and industry bodies impose. Governance is how you run your data. Compliance is whether that passes inspection. This framing is common across the industry rather than a legally fixed definition, but it’s the clearest way to keep the two apart.

Here’s what most short definitions skip. Under the GDPR, the organisation deciding how data is used (the controller) carries the legal duty for compliance and must be able to demonstrate it. The ICO’s guide to the seven data protection principles ties this to Article 5(2), the accountability principle. In plain terms, a well-configured system with no paper trail can still fail an audit. Compliance is a documentation and evidence problem as much as a technical one.

Which rules does it cover? At the headline level, five regime families come up again and again:

Most mid-size companies sit under at least two of these. A US health-tech firm with European users and a card checkout can hit four. The rules also reach beyond personal data in places (the EU Data Act is the clearest example), which is why “data compliance” is a wider term than “privacy compliance,” even though people use them interchangeably.

What Data Compliance Actually Costs?

Data compliance costs show up in three places: the price of a breach when controls fail, the regulatory fines that follow, and the recurring cost of audits and attestations the rules themselves demand.

Breaches are the biggest line. IBM’s 2026 Cost of a Data Breach edition puts the global average at $4.99 million, a 12% rise on the prior year and a record high. That reverses the dip in the 2025 IBM X-Force Cost of a Data Breach Report, which measured $4.44 million globally, down 9% from $4.88 million in 2024.

The US figure is in a different league:

• US average breach cost in 2025: $10.22 million, a record for any country IBM tracks.
• Shadow AI premium in 2025: roughly $670,000 added to the average breach where unsanctioned AI tools were involved.
• Global average in 2026: $4.99 million, up 12%.

That shadow AI number deserves a pause. Employees pasting customer records into unapproved AI tools is a compliance failure before it’s a security one, and IBM’s 2025 data shows it carries a measurable price.

Fines come next. The GDPR’s top tier allows penalties of up to 4% of a company’s annual turnover. Cumulative fine totals get quoted widely, but the published figures depend heavily on who’s counting and how, so I’d treat any single headline total with suspicion.

Then there’s the cost of staying compliant even when nothing goes wrong. California’s regulations on cybersecurity audits and risk assessments took effect on 1 January 2026, and they turn compliance into a recurring budget item. The largest businesses (over $100 million in revenue) owe their first audit certification by 1 April 2028, with smaller firms following in 2029 and 2030. Risk-assessment attestations are also due from April 2028. These are annual-style obligations with sign-off from senior leadership, which means auditor fees and staff time every year.

One figure cuts the other way. When the European Commission proposed its Digital Omnibus on 19 November 2025, it estimated that cookie-consent reform alone would save businesses over €800 million a year. Regulators know compliance is expensive. Some of the current rule changes are an attempt to lower the bill.

How Data Compliance Works in Practice: Policies, Controls and Audits

In practice, data compliance runs as a repeating cycle of six activities: inventory the data, map it to obligations, apply controls, handle rights and retention, keep evidence, and audit or attest the result. No single law hands you this list. It’s what falls out when you line up the GDPR, the HIPAA Security Rule proposal, PCI DSS v4.x and California’s audit regulations and look at what they share.

1. Inventory the data. Everything starts with knowing where data lives and how it moves. The HIPAA Security Rule overhaul proposed in January 2025 would require an asset inventory and a network map. California’s risk assessments begin from the same question. Anyone who has run one of these knows the uncomfortable part: the inventory always surfaces systems nobody listed, from export spreadsheets to analytics tools to AI assistants someone connected to the CRM. Those AI integrations belong in the inventory too, which is why an AI integration audit often doubles as a data-discovery exercise.

1. Map data to obligations. Each dataset gets tagged with the rules that apply to it, based on data type (health, payment, personal), where the people in it live, and your size or revenue. This is the step that decides whether a given database needs PCI DSS controls, HIPAA safeguards, or both.

1. Apply technical controls. The specific controls are where the regimes get prescriptive. The HIPAA proposal would mandate encryption at rest and in transit, multi-factor authentication, network segmentation, vulnerability scans every six months and penetration tests every 12 months. PCI DSS v4.x adds 12-character minimum passwords and anti-skimming controls for payment pages (requirements 6.4.3 and 11.6.1).

1. Handle individual rights and retention. People can ask what you hold, ask for it to be deleted, and expect to be told how their data is used. You need a working procedure for each request type and a retention schedule that is applied the same way everywhere, backups included.

1. Govern and keep evidence. This is the accountability layer. ISO/IEC 27701:2025, published on 14 October 2025, gives you a standalone privacy information management system to structure it. The NIST Privacy Framework offers a lighter alternative (version 1.0 from 2020 is the current final release; a 1.1 draft appeared in April 2025). Whichever you pick, the output is the same: records showing what you decided, why, and when.

1. Audit and attest. California’s cybersecurity audits and risk-assessment attestations make an independent check and an executive signature part of the law. Even where no rule requires it, an internal audit is how you find out whether steps one through five actually happened.

The cycle repeats. New systems enter the inventory, rules change, and last year’s evidence goes stale. Treat it as a loop rather than a project with an end date.

Why Data Security Compliance and Data Privacy Compliance Are Not the Same Thing

Data security compliance is about keeping data away from people who shouldn’t have it, while data privacy compliance is about whether you were allowed to collect, use and keep that data in the first place. The two overlap, and both sit under the wider heading of data compliance. But passing one tells you very little about the other.

Security compliance is the narrower discipline. IBM’s data compliance explainer describes it as a subset of the broader term, and the rules that drive it read like engineering specifications: PCI DSS controls for payment pages, the HIPAA Security Rule for health records, California’s cybersecurity audits. They all ask one question. Can an attacker get in?

Privacy compliance asks something else entirely: should you have this data at all, and does the person know? That is the territory of the GDPR’s principles and of the EDPB’s coordinated enforcement actions, which in 2025 examined the right to erasure and in 2026 turned to transparency. Neither is a breach scenario. A company can go years without a single incident and still fail both.

The argument I see most often inside companies goes like this. Security says “it’s encrypted, we’re done.” Privacy says “you shouldn’t have it.” Both are right about their half. Encryption doesn’t make an over-retained customer record lawful, and a flawless privacy notice won’t stop a credential-stuffing attack.

Some obligations need both teams at once. Deleting a person’s data on request is a privacy duty, but purging it from backups is an infrastructure job, and that handoff is precisely where the EDPB found controllers struggling in its 2025 erasure review. One without the other fails. Budget for both.

Which Data Compliance Regulations Apply to Your Business

Which data compliance regulations apply to your business depends on three triggers: the type of data you hold, where the people in that data live, and how large your company is. Work through those three and the applicable stack usually falls out in an afternoon. Keeping up with it is the longer job.

The triggers, in the order I’d check them:

• Data type: health records bring in HIPAA, card numbers bring in PCI DSS, and any personal data of EU or UK residents brings in the GDPR.
• Location of individuals: the GDPR follows the person, so a US company with European customers is in scope. California’s rules follow California consumers the same way.
• Size and revenue: California’s cybersecurity audit deadlines are tiered by revenue, with the largest firms due first.

Here is the stack as it stands in October 2026:

The EU side is wider than most people assume. The GDPR gets the attention, but the European Commission’s Data Act factpage shows a law that reaches non-personal data too: access rights to data generated by connected products, fair contract terms for business-to-business sharing, safeguards against foreign-government access, and interoperability rules for data spaces. If you ship a connected device or run an industrial data platform in Europe, you have obligations that have nothing to do with privacy.

The US has no single federal privacy law. Compliance there is sectoral (HIPAA for health) plus state by state. California leads, and the CPPA’s September 2025 announcement confirmed that its cybersecurity audit, risk assessment and automated decision-making rules took effect on 1 January 2026, with audit certifications due between 1 April 2028 and 1 April 2030 depending on revenue. Beyond California, the IAPP’s US state privacy legislation tracker is the reference most practitioners use, because the count of enacted state laws changes often enough that any number printed in an article goes stale.

Industry standards work differently. PCI DSS is enforced through card-network contracts rather than statute, and ISO 27701 and the NIST framework are voluntary. In practice, though, a large customer’s procurement questionnaire turns “voluntary” into “required” fast.

Who Is Responsible for Data Security and Compliance Inside a Company

Legally, responsibility for data security and compliance sits with the organisation itself, and under the GDPR specifically with the controller, the entity that decides why and how personal data is processed. Inside the building, that single legal duty has to be split across at least four groups. The splitting is where most of the trouble starts.

Who owns what, in most companies that get it right:

• Legal and privacy: decide the lawful basis, write the notices and retention schedules, own the rights-request procedure and the evidence trail the GDPR’s accountability principle demands. A data protection officer or compliance lead usually sits here as coordinator.
• Security: owns the controls regulators now name outright, from encryption and multi-factor authentication to the scans and penetration tests in the HIPAA proposal.
• IT and engineering: run the systems where data actually lives, including backups, and are the only people who can make a deletion real.
• Business owners: the marketing, sales and product leads who choose to collect data in the first place and who connect new tools to it.

Ownership gaps show up fast under scrutiny. When the EDPB reviewed how 764 controllers handled erasure requests in 2025, one problem it named was missing internal procedures for handling requests. I read that as an ownership failure more than a legal one. The pattern is familiar to anyone who has sat through one: the request lands with legal, legal confirms it’s valid, and nobody has told the database team which tables to purge or whether last night’s backup counts. Every group did its job. No one owned the handoff.

California’s regime adds a signature to the problem. Its cybersecurity audit certifications and risk-assessment attestations put a named person’s name on the result, which concentrates minds in a way policy documents never do.

The practical fix is dull and effective. Give every obligation a single named owner, and write down who takes over at each handoff between teams.

Where Data Compliance Programs Usually Fail

Data compliance programs usually fail on the dull operational pieces: retention schedules applied differently in every system, deletion that never reaches backups, rights requests with no procedure behind them, and controls left until the week before the deadline. Breaches get the headlines. When regulators actually go looking, they find process gaps.

The clearest evidence comes from the EDPB’s 2025 coordinated action on the right to erasure, reported in February 2026. Thirty-two data protection authorities took part and 764 controllers responded. Three problems kept coming up:

• Retention periods that varied for the same data across different systems.
• Deletion that stopped short of backups.
• No internal procedure for receiving and handling erasure requests.

None of those is a hard engineering problem. Each is a decision nobody made.

The next enforcement target is transparency. On 19 March 2026 the EDPB launched its 2026 coordinated action on transparency and information obligations, with 25 authorities participating. If your privacy notice was last reviewed before the systems behind it changed, that is where the next round of questions will land.

Three other patterns show up often enough to name.

Shadow AI. IBM’s 2025 breach report attached roughly $670,000 in extra cost to breaches that involved unsanctioned AI tools. Staff route around approved systems when the approved systems are slow or missing, which is a strong argument for giving them custom AI tooling built for your data rules instead of hoping a policy memo holds.

Technical-only thinking. A team switches on encryption and MFA and calls it done. The GDPR’s accountability principle asks for proof of decisions, so the controls exist while the evidence of compliance does not.

Deadline procrastination. PCI DSS v4.0 marked 51 of its 64 new requirements as future-dated, which gave the industry years of notice before they became mandatory on 31 March 2025. The PCI Security Standards Council was still publishing reminders in the run-up. Every phased deadline I’ve watched goes the same way: the grace period reads as “not yet” until the final quarter, and then it reads as a crisis.

What Changed in Data Compliance Rules This Year

The biggest data compliance change of 2026 is the EU’s AI omnibus, adopted on 29 June 2026, which pushed the AI Act’s high-risk data-governance duties back to December 2027 and August 2028, while the Digital Omnibus on the GDPR remains a proposal that the EU’s own privacy regulators have partly rejected. Everything else is either settled since 2025 or still waiting on a final text.

The Digital Omnibus is the one to watch. Proposed on 19 November 2025, it would amend the GDPR, the ePrivacy Directive, the Data Act and NIS2 in a single package. The EDPB and EDPS responded on 11 February 2026 with a split verdict. They backed a higher breach-notification threshold with a longer deadline, common templates for breach notices and impact assessments, a derogation for biometric authentication, and fixes for cookie fatigue. Then they “strongly urge” the co-legislators to drop the proposed narrowing of what counts as personal data, which they describe as far more than a technical tweak.

That disagreement matters. The definition of personal data decides what the entire GDPR applies to, so a narrower one would shrink the scope of every obligation at once. As of October 2026 the GDPR parts are still a proposal, with trilogues expected once the Council settles its position.

The AI side is done. The Council’s final approval of the AI omnibus on 29 June 2026 followed the 7 May provisional deal. Stand-alone high-risk systems, which carry the data-quality and governance duties, now have until 2 December 2027. High-risk systems embedded in regulated products get until 2 August 2028. The grace period for transparency solutions on AI-generated content was cut to three months, ending 2 December 2026, and the package adds a ban on “nudifier” AI practices.

Two US items stayed still. The HIPAA Security Rule overhaul proposed in January 2025 has not been finalised, so the existing rule remains in force. The NIST Privacy Framework 1.1, which ties privacy risk to the Cybersecurity Framework 2.0 and adds AI-related risk, is still the April 2025 draft.

Data Compliance FAQ

What is the difference between data compliance and data governance?

Data governance is the internal system of policies, roles and processes a company uses to manage its data. Data compliance is whether that system satisfies the external rules set by governments and industry bodies. Good governance makes compliance possible, but a company can have detailed internal policies and still breach the GDPR if those policies ignore what the law requires.

Is data compliance the same as data security compliance?

No. Data security compliance is a subset of data compliance that covers protecting data from unauthorised access, under rules such as PCI DSS and the HIPAA Security Rule. Data compliance also covers accuracy, transparency, lawful use, individual rights and retention, which no amount of encryption addresses.

What are the 7 GDPR principles?

The seven principles in Article 5 of the GDPR are lawfulness, fairness and transparency; purpose limitation; data minimisation; accuracy; storage limitation; integrity and confidentiality; and accountability. The ICO’s guide to the data protection principles treats accountability as the one that binds the rest, because Article 5(2) requires the controller to be able to show compliance with the other six. That is why documentation counts as much as controls.

Does GDPR apply to US companies?

Yes, when a US company processes personal data about people in the EU or UK. The regulation follows the individual rather than the company’s registered address, so a US SaaS firm with European customers is in scope. The top fine tier reaches 4% of annual turnover, which is why most US firms with any European footprint run a GDPR programme.

What is the GDPR breach notification deadline?

Under the current GDPR, a controller must notify the supervisory authority of a qualifying personal data breach within 72 hours of becoming aware of it. The Digital Omnibus proposed in November 2025 would raise the threshold for which breaches need reporting and extend the deadline, and the EDPB and EDPS supported that change in February 2026. Until the omnibus passes, 72 hours is the rule.

What is ISO 27701?

ISO/IEC 27701 is the international standard for a privacy information management system, or PIMS. The 2025 edition, published on 14 October 2025, made it a standalone standard for the first time; earlier versions worked only as an extension to the ISO 27001 security standard. Companies use it to structure the governance and evidence layer of a data compliance programme and to obtain a certification that customers recognise.

Where to Start With Data Compliance

Start data compliance with the two things regulators actually check: an inventory of where your data lives and a written procedure for deleting it on request. Everything else builds on those.

A first 90 days that holds up:

1. Inventory every system holding personal, health or card data, AI tools included.
2. Tag each dataset with its regimes by data type, location of individuals and revenue.
3. Fix retention and rights-request handling first, backups included, since erasure was the EDPB’s 2025 enforcement focus and transparency is its 2026 one.
4. Adopt the controls already written into PCI DSS v4.x and the HIPAA proposal, instead of waiting for a final rule to force them.
5. Name one owner per obligation and start the evidence trail the GDPR’s accountability principle requires.

Then watch four open items: the Digital Omnibus trilogues on the personal-data definition, the HIPAA Security Rule final text, NIST Privacy Framework 1.1, and California’s first attestations due 1 April 2028.

The companies that pass inspection are the ones that can show their decisions on paper. If AI tools are among the systems your inventory turned up, talk to AlphaCorp AI about building ones that keep your data within the rules you’ve just mapped.