Digital Omnibus : What is Changing and Why It Matters for EU Businesses

In November 2025, the European Commission presented the Digital Omnibus Regulation proposal (COM(2025) 837) as part of a broader drive to “simplify” EU digital compliance and reduce fragmentation. The proposal is presented as a pragmatic, technical package—yet it touches multiple sensitive areas: cookie rules, GDPR enforcement practicality, AI-related processing, and cybersecurity incident reporting.

This article explains what is changing, what is being debated, and what organizations should do now.

What is the Digital Omnibus?

An “omnibus” legislative instrument is a package that amends multiple legal areas through a single proposal. The Digital Omnibus is designed to streamline the EU digital compliance environment and align certain elements across:

• GDPR (data protection)

• AI Act implementation

• Cybersecurity reporting / incident notification frameworks

• certain overlaps with the wider EU digital rulebook

The central claim is “simplification.” The central question is whether simplification is achieved by reducing unnecessary burden while maintaining safeguards—or whether some changes risk weakening rights or enforcement effectiveness.

What is changing (as proposed)

A) Cookies and terminal equipment: closer to GDPR logic

A major shift described in the proposal is moving rules around terminal equipment data (including cookies and similar identifiers) more clearly into a GDPR-style compliance and enforcement approach.

Practical meaning: cookie compliance is likely to become more explicitly tied to GDPR concepts and enforcement consequences, potentially changing how organizations design consent, records, and user controls.

B) Cookie consent redesign: fewer repeated prompts

The proposal describes a consent model intended to reduce “banner fatigue,” including:

• clearer Accept / Reject choices

• if a user rejects, the website should not ask again for at least six months

• stronger emphasis on respecting central privacy preferences (e.g., browser/device-level settings) where applicable

• a limited “whitelist” logic for certain low-impact cookies (e.g., basic aggregated measurement) under strict conditions

Practical meaning: banner UX and consent management platforms may need redesign.

Organizations should also re-check which cookies truly need consent vs. which may fall within narrowly defined low-impact categories.

C) Pseudonymised data: clearer boundaries for recipients

The proposal introduces clarification that pseudonymised data shared with third parties who cannot realistically or lawfully re-identify individuals may not be treated as personal data for those recipients.

Practical meaning: this could enable safer data sharing for analytics, research, and AI development—but it raises governance questions: who can re-identify, under what conditions, and how that is evidenced contractually and technically.

D) AI development under GDPR: more explicit use of “legitimate interests”

The proposal describes a more explicit route for processing personal data in the context of developing and operating AI systems/models using legitimate interests, with safeguards (e.g., minimisation, transparency, right to object, and impact assessments where needed).

It also references limited processing of special category data in specific contexts such as bias detection and correction, subject to strict safeguards.

Practical meaning: organizations building or deploying AI should expect intensified scrutiny of:

• legitimate interest assessments,

• transparency practices,

• objection handling,

• data minimisation and purpose limitation,

• and DPIA triggers.

E) Right of access: addressing “manifestly abusive” requests

The proposal introduces provisions allowing controllers to limit handling of access requests where there is manifest abuse (e.g., repeated, excessive, or clearly bad-faith requests).

Practical meaning: companies may gain more operational flexibility, but must apply the concept cautiously—because misuse could become a major enforcement and reputational risk.

F) Automated decision-making (GDPR Article 22): clearer conditions

The proposal clarifies/reframes the conditions under which decisions with legal or similarly significant effects may be solely automated (e.g., necessity for contract, authorization by law with safeguards, or explicit consent).

Practical meaning: organizations using scoring, profiling, or automated eligibility decisions should re-check:

• whether Article 22 applies,

• whether there is meaningful human involvement,

• and whether safeguards and transparency are adequately documented.

G) “Unified policies” across regimes

The proposal describes a direction toward integrated policies and documentation across multiple regimes (e.g., GDPR + AI Act + cybersecurity reporting), reducing parallel paperwork.

Practical meaning: good governance programs (single control frameworks, shared risk registers, unified policies) become more valuable—especially for multi-country operations.

Cybersecurity: one reporting “entry point” for incidents

Another key element is the concept of a single entry point for incident reporting to reduce duplicate notifications across frameworks. A 96-hour window is referenced for the unified submission concept, while recognizing that existing obligations under specific laws (including earlier notifications where required) remain relevant.

Practical meaning: security and privacy teams should align incident response so that:

• one internal workflow supports multiple legal notifications,

• evidence and timelines are controlled,

• and decision-making is documented.

Why this is controversial

Although the package is described as simplification, stakeholders debate whether certain changes may:

• make enforcement harder or slower through procedural shifts

• narrow practical access to remedies or complaint pathways

• create uncertainty around rights (especially in AI-related processing)

• rebalance the system more toward administrative efficiency than fundamental rights

EU-level privacy regulators have emphasized that simplification must not weaken effective protection and must preserve enforceability and rights in practice.

What businesses should do now

Even before the final text is adopted, the proposal is a strong signal: EU compliance will increasingly reward organizations that have clear governance, good records, and fast operational response.

Recommended actions:

1. Audit cookies and consent architectureMap cookies/SDKs, re-validate legal bases, and prepare for “reject = no re-ask for months” logic.

2. Re-check pseudonymisation and sharingDocument re-identification risk, control access to keys, and ensure contracts reflect technical reality.

3. Strengthen AI compliance documentationLegitimate interest assessments, DPIAs where appropriate, transparency and objection handling, model training data governance.

4. Prepare for Article 22 questionsIdentify where automated decisions have significant effects; document safeguards and human oversight.

5. Unify incident responseBuild a single internal workflow that can serve multiple notifications, with clearly assigned roles and timelines.

Conclusion

The Digital Omnibus is framed as a simplification initiative, but it introduces meaningful changes across cookies, pseudonymised data, AI-related processing, data subject rights operations, automated decision-making, and cybersecurity reporting. For organizations, the right strategy is structured readiness: strengthen governance now so you can adapt quickly once the final text is agreed.