TL;DR: The Digital Omnibus proposal could narrow what counts as personal data, consolidate breach reporting, expand legitimate-interest processing for AI, and simplify consent and DSAR handling, according to Osano, while leaving the GDPR as the anchor for broader privacy change. For practitioners, the real issue is not whether the proposal passes unchanged, but how quickly governance models would need to adapt if EU privacy obligations become more conditional and less duplicative.
At a glance
What this is: The Digital Omnibus proposal would streamline parts of EU digital regulation by narrowing some GDPR scope, simplifying breach reporting, and changing consent and AI processing rules.
Why it matters: Privacy, IAM, and AI governance teams need to understand the proposal now because it could alter consent operations, data classification, breach workflows, and compliance evidence across EU-facing programmes.
Context
The Digital Omnibus proposal is best understood as a governance simplification exercise, not a wholesale replacement for EU privacy law. It would consolidate overlapping obligations across privacy, breach reporting, AI processing, and data governance, which matters because many programmes now depend on layered controls rather than a single legal baseline. For identity teams, that creates a practical question about when identity data, consent signals, and access records fall inside or outside regulatory scope.
The proposal is especially relevant where privacy controls intersect with IAM, NHI, and AI governance. Consent management, DSAR handling, breach notification, and AI training data treatment all depend on identity-linked records and access decisions, so changes to scope or timing would affect downstream control design. The current starting position in many organisations is a patchwork of regional interpretations and duplicated workflows, which makes simplification attractive but also operationally disruptive.
Key questions
Q: How should organisations respond if GDPR scope is narrowed for some data types?
A: They should not treat narrower scope as permission to weaken governance. Organisations need to document why specific datasets are outside personal-data treatment, who approved that conclusion, and what re-identification paths still exist. The safest approach is to align privacy classification, access control, and retention decisions so scope changes do not create uncontrolled exceptions.
Q: Why do simplified breach reporting rules still require strong incident governance?
A: Because simplification changes the reporting path, not the need for evidence. Teams still have to decide whether an incident is reportable, whether individuals face high risk, and whether legal, security, and privacy records align. Without disciplined triage and documentation, a single portal can become a single point of confusion rather than a reduction in burden.
Q: What breaks when consent management is treated only as a banner problem?
A: Teams miss the operational requirement to honour consent state across browsers, apps, and fallback journeys. If consent signals are not synchronised, the organisation can end up with conflicting records, poor user experience, and processing that cannot be defended. Consent management has to function as a governed preference state, not a front-end overlay.
Q: How do privacy teams govern AI training data when sensitive data is accidentally included?
A: They need a documented decision path for minimisation, removal feasibility, and output suppression when data cannot be fully excised. The key is to define who decides that removal is disproportionately burdensome, what evidence supports that call, and how objections are handled. That makes the process auditable even when the dataset itself is imperfect.
Technical breakdown
How the proposal narrows personal data scope
The proposal would narrow GDPR coverage by tying personal data more tightly to reasonable identifiability. That means pseudonymised information may fall outside the regime unless the controller can realistically re-identify it, but the classification would still require a risk assessment. Operationally, this shifts privacy governance from blanket treatment to evidence-based scoping, which can reduce compliance burden while increasing the importance of classification decisions and re-identification controls.
Practical implication: reassess data inventories and re-identification pathways so personal-data determinations are defensible, not assumed.
What changes in breach reporting and notice workflows
The proposal would reduce duplicate reporting by moving toward a single incident-reporting portal and would also raise the notification threshold for individuals to high-risk cases. It would extend the reporting window from 72 hours to 96 hours, which changes the operational cadence for triage, legal review, and evidence collection. The underlying control problem is not just speed, but the number of handoffs that exist before a report is finalised.
Practical implication: redesign incident workflows so breach classification, legal review, and notification decisions can happen in one controlled path.
Why consent and AI processing rules become a governance test
The proposal would relax some consent requirements for biometric verification and certain cookie use cases while also allowing legitimate-interest processing for AI under documented balancing tests. It would additionally permit limited use of residual sensitive data for AI development and testing when removal is disproportionately burdensome. This does not remove governance duties; it concentrates them into documentation, minimisation, and objection-handling controls, where weak evidence becomes the real failure mode.
Practical implication: tighten documentation and objection-handling controls before relying on broader consent exemptions or AI processing bases.
NHI Mgmt Group analysis
Privacy simplification does not reduce governance complexity, it relocates it. The Digital Omnibus appears to trim duplication, but the harder work moves into scoping, evidence, and exception handling. Organisations that rely on broad privacy templates will find that the real control failure is inconsistent classification across teams, not the absence of another legal rule. The practical conclusion is that privacy operations need stronger decision traceability, not just fewer forms.
Identity-linked privacy records become more operationally sensitive when scope shifts. Consent signals, access logs, DSAR evidence, and breach notices all depend on identity data handling that sits at the edge of compliance and security. Where the GDPR and related rules are simplified, teams still need to prove why a record was treated as personal, non-personal, or exempt. The practitioner takeaway is that IAM and privacy governance must converge around evidence quality, not merely policy language.
AI compliance will increasingly depend on documented data discipline rather than broad prohibitions. The proposal’s approach to legitimate interest and residual sensitive data suggests a model where permissibility comes with stronger documentation and minimisation expectations. That aligns with NIST AI RMF style governance thinking, where process quality matters as much as substantive restriction. The practitioner conclusion is to treat AI data controls as a governed workflow, not a one-time legal review.
Browser-level consent management is emerging as the practical control boundary. If websites and apps must honour consent signals more consistently, the control surface shifts from banners alone to the orchestration of preference state across channels. That creates a new operational dependency between privacy tooling, identity context, and application behaviour. The takeaway for practitioners is to design consent as an interoperable control, not a user-interface exercise.
What this signals
Data scoping will become the new privacy control point. If the proposal advances, organisations will spend less time proving that every record is covered by the same rule set and more time proving why a record is in or out of scope. That makes classification logic, re-identification assumptions, and retention rules central to privacy governance.
Consent orchestration is moving toward a multi-channel control model. Browser signals, banner flows, and application behaviour will need to stay aligned, or users will see inconsistent outcomes that are difficult to defend. Privacy teams should expect consent tooling to be evaluated like an identity control, with state consistency mattering as much as user-facing presentation.
For practitioners
- Reclassify personal-data inventories Map where pseudonymised or minimally identifiable data is currently treated as personal data and document the re-identification assumptions that justify each classification.
- Redesign breach notification workflows Build one incident path that can support internal triage, regulatory reporting, and individual notification decisions without duplicating evidence collection across regimes.
- Tighten consent signal handling Verify that websites and apps can accept browser-level consent signals and still fall back cleanly to banner-based consent where needed.
- Strengthen AI data governance evidence Require documented balancing tests, minimisation decisions, and objection-handling steps before using personal or residual sensitive data in AI development.
Key takeaways
- The Digital Omnibus proposal would reduce some compliance friction, but it shifts governance pressure toward scope decisions, evidence, and exception handling.
- Breach reporting, consent handling, and AI data use would all become more workflow-dependent, which raises the value of consistent privacy operations.
- Identity, privacy, and AI governance teams should prepare for a regulatory model that is simpler on paper but more demanding in documentation and control alignment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST AI RMF, NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while GDPR defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.5 — Principles relating to processing of personal data | The proposal directly changes how personal data scope and lawful processing are assessed under GDPR. |
| Recommendation — Document scope, minimisation, and lawful-basis decisions so GDPR treatment remains defensible as definitions shift. | ||
| NIST AI RMF | GOVERN — AI Governance and Accountability | The article ties AI processing changes to documented governance and accountability expectations. |
| Recommendation — Embed AI data-use approvals and objection handling into governed workflows with clear accountability. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | The proposal affects how sensitive and personal data are classified, retained, and protected across systems. |
| Recommendation — Reassess data protection controls against changed scope assumptions and document why records are protected or excluded. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Record Review, Analysis, and Reporting | Faster and more unified breach reporting still depends on reviewable evidence and consistent incident records. |
| Recommendation — Strengthen audit review and incident evidence handling so reporting decisions can be justified consistently. | ||
| CIS Controls v8 | CIS-5 — Account Management | Identity-linked privacy workflows depend on consistent governance of accounts, access, and accountability. |
| Recommendation — Tie privacy approvals to accountable account ownership so consent and DSAR decisions are traceable. | ||
Key terms
- Sensitive Data Scope: Sensitive data scope is the defined boundary of information an identity, system, or agent is allowed to access. For AI agents, this scope should be explicit, least privilege, and continuously enforced so the agent cannot read or expose data beyond its approved task.
- Consent Orchestration: Consent orchestration is the practice of turning consent into enforceable rules that follow data across systems. It combines policies, metadata, control logic, and monitoring so downstream platforms can respect purpose, retention, and usage limits even after data leaves the original collection point.
- Legitimate Interest Assessment: A Legitimate Interest Assessment is the documented balancing test used to decide whether processing personal data is justified by a legitimate interest. It examines purpose, necessity, and the impact on individuals, and organisations should review it before collecting or sharing data so that privacy risk and objection handling are properly addressed.
- Data Subject Access Request (DSAR): A DSAR is a request from an individual to see the personal data an organisation holds about them and how it is used. In governance terms, it becomes a test of whether data location, access history, and response ownership are actually under control.
Deepen your knowledge
NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps security and identity practitioners align governance decisions across identity, access, and control lifecycles.
Published by the NHIMG editorial team on October 16, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org