On October 28, 2025, the European Commission published the Digital Omnibus directive — a sweeping package of amendments to GDPR, the ePrivacy Directive, and several adjacent regulations. It is the most significant overhaul of EU data protection law since the original GDPR took effect on May 25, 2018. For eight years, the regulation remained essentially frozen while the technology it governs — AI systems, cross-border SaaS, real-time analytics, programmatic advertising — evolved at a pace regulators could not have anticipated.
Our team has spent the last three months dissecting the proposed text, comparing it clause by clause against the 2018 regulation, and mapping the practical implications for development teams. This is not a legal brief. This is what you actually need to change in your codebase, your consent flows, and your data architecture.
The Context: Why Now?
GDPR was designed in 2012 and finalized in 2016. The regulation predates transformer-based AI models, widespread edge computing, and the explosion of server-side analytics. By 2024, enforcement had become inconsistent — the Irish Data Protection Commission alone had a backlog of over 10,000 complaints. Small businesses across Europe were spending between 1.4% and 2.8% of annual revenue on compliance, according to a 2024 European Commission impact assessment.
The political pressure was real. SMEs lobbied aggressively for relief. AI companies argued that Article 22 (automated decision-making restrictions) was written for a world that no longer existed. And practically every web developer had questions about cookie consent banners that nobody could answer definitively.
The Digital Omnibus is the Commission's response. It does not replace GDPR — it amends it. Think of it as GDPR 1.5, not GDPR 2.0.
What Actually Changed
SME Exemptions: Records of Processing Expanded
Under the original GDPR Article 30, every data controller and processor was required to maintain records of processing activities. The exemption threshold was 250 employees — a number that excluded most mid-size companies from relief.
The Digital Omnibus raises this threshold to 750 employees. That is a significant shift. A company with 500 employees that previously needed a full Article 30 register — documenting every processing activity, its purpose, data categories, recipients, retention periods, and security measures — is now exempt from that requirement.
Here is what the hype misses: the exemption only applies to the record-keeping obligation. It does not exempt these companies from actually complying with data protection principles. You still need lawful bases for processing. You still need to honor data subject rights. You still need breach notification procedures. The paperwork burden is lighter; the substantive obligations remain.
For development teams, this means your internal data mapping tools and processing inventory systems can be simplified for clients under 750 employees, but your consent management and rights-fulfillment infrastructure stays exactly the same.
Article 22 Relaxation: Automated Decision-Making
This is the change that will affect the most codebases. Article 22 of the original GDPR gave individuals the right not to be subject to decisions based solely on automated processing that produce legal or "similarly significant" effects. In practice, this created a compliance nightmare for recommendation engines, credit scoring APIs, automated hiring tools, and fraud detection systems.
The amended Article 22 introduces a carve-out for automated decisions that do not involve sensitive data categories (Article 9 data — race, ethnicity, political opinions, religious beliefs, health data, biometric data, sexual orientation). If your automated system processes only non-sensitive data, the strict Article 22 protections no longer apply by default.
That said, the human oversight requirement still applies for decisions involving sensitive categories. And the broader transparency obligations under Articles 13 and 14 remain — you must still inform users that automated decision-making is occurring and explain the logic involved.
For AI product teams: audit your models. If any input features correlate with or proxy for sensitive categories, you are still in Article 22 territory. Proxy discrimination has not been exempted.
Recognized Legitimate Interests: A New Lawful Basis
GDPR has always had six lawful bases for processing: consent, contract, legal obligation, vital interests, public task, and legitimate interests. The legitimate interests basis (Article 6(1)(f)) required a balancing test — your interest versus the data subject's rights. In practice, the uncertainty around this test pushed many organizations toward consent as their default basis, contributing to the consent fatigue problem.
The Digital Omnibus introduces a category of "recognized legitimate interests" — pre-approved processing purposes where the balancing test is presumed to pass. These include fraud prevention, network security monitoring, employee safety in emergency situations, and certain direct marketing activities to existing customers.
The honest answer is that this codifies what most Data Protection Authorities were already approving in practice. But having it in the regulation text removes ambiguity and reduces the risk of enforcement surprises.
Cookie Consent: Finally, Some Relief
This is the change web developers have been waiting for since 2018. The amended ePrivacy provisions (bundled into the Digital Omnibus) allow certain cookies to be set without prior consent if they meet specific criteria:
- First-party analytics cookies that do not share data with third parties
- Cookies necessary for audience measurement where data is aggregated and not used for profiling
- Cookies that support fraud prevention on the same domain
The key qualifier is "low-risk." Third-party tracking cookies, cross-site identifiers, and advertising pixels still require explicit opt-in consent. The relief targets first-party analytics — think Plausible, Fathom, or a self-hosted Matomo instance.
For development teams, this means you can potentially simplify consent banners for sites that only use first-party analytics. But if you have any third-party scripts — Google Analytics 4, Meta Pixel, HubSpot tracking, Hotjar — the full consent machinery stays.
What Stays the Same
It is worth being precise about what the Digital Omnibus does not touch, because the initial media coverage has been misleading in places.
| Area | Status After Digital Omnibus |
|---|---|
| Data subject rights (access, erasure, portability) | Unchanged |
| 72-hour breach notification requirement | Unchanged |
| Data Protection Officer requirement for large-scale processors | Unchanged |
| Cross-border data transfer rules (Chapter V) | Unchanged |
| Data Protection Impact Assessments (Article 35) | Unchanged |
| Supervisory authority structure | Unchanged |
| Maximum fines (4% of global turnover) | Unchanged |
| Consent requirements for sensitive data | Unchanged |
Your DSAR (Data Subject Access Request) handling infrastructure, your breach response playbooks, your DPO appointment procedures — none of these change.
GDPR 2018 vs. GDPR 2026 Amendments: A Direct Comparison
| Provision | GDPR 2018 | Digital Omnibus 2026 |
|---|---|---|
| Records of processing exemption | Companies < 250 employees | Companies < 750 employees |
| Automated decision-making (Art. 22) | Strict restrictions on all solely automated decisions with significant effects | Relaxed for non-sensitive data; strict protections remain for Art. 9 categories |
| Legitimate interests basis | Required case-by-case balancing test | New "recognized legitimate interests" category with pre-approved purposes |
| Cookie consent (ePrivacy) | Consent required for all non-essential cookies | Low-risk first-party analytics cookies exempted from consent |
| DPA cooperation (cross-border) | Consensus-based, often slow | Streamlined lead authority procedures, binding deadlines |
| AI-related processing | No specific provisions | Must align with EU AI Act; transparency obligations cross-referenced |
| SME compliance burden | Same as large enterprises (with limited Art. 30 exemption) | Extended exemptions, simplified documentation requirements |
The US Privacy Patchwork Gets Worse
While the EU is consolidating and simplifying, the United States continues to fracture. As of January 2026, 22 states have enacted comprehensive privacy legislation. Rhode Island's data privacy act took effect on January 1, 2026. California continues to update the CPRA through rulemaking. And Connecticut became the first state to explicitly protect neural data — brain-computer interface outputs and cognitive data generated by neurotechnology devices.
For development teams building products that serve both markets, this means maintaining two entirely different compliance architectures. The EU is moving toward a single, more pragmatic framework. The US is moving toward 50 potentially different ones.
A practical consequence: your consent management platform needs state-level granularity for US users and a newly updated configuration for EU users. If you are using a tool like OneTrust, Cookiebot, or a custom solution, plan for a configuration update cycle in Q3 2026 when the Digital Omnibus provisions are expected to take effect.
The AI Act Overlap Problem
Here is the compliance headache that nobody is talking about enough. The EU AI Act entered into force in August 2024, with a phased implementation schedule running through 2027. The Digital Omnibus explicitly cross-references the AI Act in several places, creating a dual compliance requirement for AI products.
If you are building an AI system that processes personal data of EU residents, you now need to satisfy:
- GDPR requirements for lawful processing, transparency, and data subject rights
- AI Act requirements for risk classification, conformity assessment, and human oversight
- The new Digital Omnibus provisions on automated decision-making and recognized legitimate interests
These three frameworks do not always align. The AI Act's definition of "high-risk AI system" does not map cleanly to GDPR's concept of "solely automated decisions with significant effects." A system might be low-risk under the AI Act but still trigger Article 22 protections under GDPR if it processes sensitive data.
Our recommendation: build a unified compliance matrix that maps your AI features against both frameworks simultaneously. Trying to handle GDPR and AI Act compliance in separate workstreams will create gaps.
Practical Guidance: What to Update
Consent Flows
Review every consent banner and preference center. If your site only uses first-party analytics that meet the low-risk criteria, you can remove the analytics category from your consent modal. Do not remove the banner entirely — you likely still have other processing activities that require consent.
Update the granularity of your consent categories. The Digital Omnibus encourages more specific, purpose-based consent rather than broad category-based consent. "Analytics" is too vague. "First-party page view counting using aggregated, non-profiling methods" is closer to what the regulation expects.
Privacy Policies
Every privacy policy that references GDPR needs an update. Specifically:
- Update references to the lawful basis section if you plan to rely on "recognized legitimate interests" for any processing activity
- Add language about AI-related processing if you use automated decision-making systems
- Update the automated decision-making disclosure if Article 22 changes affect your products
- Reflect the new cookie consent exemptions in your cookie policy
Data Processing Records
If your organization has between 250 and 750 employees, you have the option to discontinue formal Article 30 records. Our advice: do not actually stop maintaining them. The records are valuable for your own governance regardless of the legal requirement. But you can reduce the formality and update frequency, which saves real engineering and legal time.
Technical Infrastructure
Review your data processing pipelines for any automated decision-making that newly falls outside Article 22 strict protections. You may be able to simplify human-review workflows for non-sensitive automated decisions. But document the analysis — if a regulator asks why you removed a human review step, you need to show that the processing genuinely involves only non-sensitive data.
Timeline and What Comes Next
The Digital Omnibus is a proposal, not yet law. It must pass through the European Parliament and Council, a process that historically takes 18 to 24 months. Realistically, the amendments will take effect in late 2027 or early 2028, with possible transition periods.
That said, the direction is clear. Start planning now. The organizations that waited until the last minute for GDPR in 2018 paid the highest compliance costs and had the most chaotic implementations.
To be fair, there is a reasonable chance that Parliament will modify some provisions during the legislative process. The SME threshold might shift. The cookie exemptions might get narrower or broader. But the overall trajectory — toward pragmatic reform that maintains strong rights while reducing compliance overhead — is unlikely to change.
The 2026 reforms acknowledge something the original GDPR did not: compliance cost matters, and if the regulation is too burdensome for small and mid-size companies to implement properly, the actual level of data protection suffers. A simpler rule that companies actually follow protects privacy better than a complex rule that companies ignore or implement badly.
For development teams, the message is clear. Privacy engineering remains a core competency. But the specific implementation is about to get more nuanced, more context-dependent, and — for the first time in eight years — somewhat less painful.
Building products that need to comply with GDPR, the AI Act, or US state privacy laws? CODERCOPS helps development teams implement privacy-by-design architectures that scale across jurisdictions. Get in touch with our team to discuss your compliance roadmap.
Comments