The Digital Omnibus Proposal: An Analysis of GDPR’s Most Significant Evolution
Expert commentary on the European Commission’s proposed amendments and their practical implications for data protection compliance
The European Commission’s Digital Omnibus Proposal represents the most comprehensive revision to the General Data Protection Regulation since its implementation in May 2018. Published as part of the broader Digital Single Market strategy, this proposal seeks to address seven years of practical experience,
jurisprudential developments, and technological evolution, particularly concerning artificial intelligence, biometric systems, and cross-border data flows.
This analysis examines the proposal’s most significant provisions, evaluates their practical implications across different sectors, identifies potential implementation
challenges, and assesses areas of legal uncertainty that remain unresolved. Drawing on the complete proposal text and preliminary analysis, this commentary is intended for data protection officers, legal practitioners, compliance professionals, and policymakers navigating the transition period.
1. Redefining Personal Data: Article 4(1) and the Entity-Relative Identifiability Test
The Commission proposes adding a critical clarification to Article 4(1)’s definition of personal data. The new text states,
“Information relating to a natural person is not necessarily personal data for every other person or entity, merely because another entity can identify that natural person. Information shall not be personal for a given entity where that entity cannot identify the natural person to whom the information relates, taking into account the means reasonably likely to be used by that entity.”
The amendment adopts a risk-based, contextual assessment model. This aligns with the GDPR’s broader risk-based architecture but introduces significant interpretive challenges around the ‘reasonably likely to be used’ standard. What constitutes ‘reasonable likelihood’ will vary dramatically across sectors, technologies, and organizational capabilities.
Controllers must now assess their own re-identification capabilities, a task requiring technical expertise in statistical disclosure control, linkage attacks, and differential privacy. Organizations receiving data will need to document why they lack re-identification means, creating some evidentiary burdens.
Key Insight: The Commission and EDPB are tasked with developing criteria for assessing when pseudonymized data cease to be personal for certain
entities (proposed new Article 41a). Until these implementing acts are adopted, controllers face interpretive uncertainty.
2. Scientific Research: Articles 4(38) and 5(1)(b) Amendments
Article 4 gains a new point (38) defining scientific research:
“Any research which can also support innovation, such as technological development and demonstration. These actions shall contribute to existing scientific knowledge or apply existing knowledge in novel ways, be carried out with the aim of contributing to the growth of society’s general knowledge and wellbeing and adhere to ethical standards in the relevant research area. This does not exclude that the research may also aim to further a commercial interest.”
Resolving the Commercial Research Debate
This definition ends years of debate about whether Article 89 safeguards apply to private-sector R&D. By explicitly permitting commercial interests, the Commission
acknowledges that pharmaceutical companies, technology firms, and industrial research labs conduct legitimate scientific research despite profit motives.
The definition requires “contributing to society’s general knowledge and wellbeing.” Pure market research, product testing for competitive advantage without knowledge contribution, or proprietary research withheld from publication may not qualify. The boundary remains contested.
Ethical Standards Requirement
The definition mandates adherence to ‘ethical standards in the relevant research area.’ This incorporates external frameworks (Declaration of Helsinki for medical
research, IEEE ethics guidelines for AI research, etc.) by reference. Compliance officers must identify applicable standards for their sector and demonstrate adherence.
For multi-jurisdictional research, conflicts between ethical frameworks create complexity. U.S.-based clinical trials following FDA guidance may differ from EU
member state medical research ethics committees. The proposal doesn’t resolve which standards govern.
Purpose Limitation Clarification (Article 5(1)(b))
The amendment changes “shall…not be considered to be incompatible” to “shall…be considered to be compatible” for research processing.
This seemingly minor wording shift has substantial impact, controllers no longer need to conduct Article 6(4) compatibility assessments when repurposing data for
scientific research.
However, this doesn’t exempt research from requiring a legal basis under Article 6(1). Organizations still need consent, legitimate interests, or another basis, but need
not demonstrate purpose compatibility separately.
3. Article 9(2) Special Categories: Biometric Verification and AI Residuals
New Exemption (k): AI System Development
The proposal adds Article 9(2)(k), permitting processing of special categories when necessary for developing or operating AI systems defined in the EU AI Act (Regulation (EU) 2024/1689). This acknowledges that training datasets inevitably contain some sensitive data despite filtering efforts.
New paragraph 9(5) imposes strict requirements on controllers to implement measures to avoid collecting special categories data. If identified despite precautions, such data must be removed. If removal requires disproportionate effort, the Controller must effectively protect the data from producing outputs or disclosure.
The definition requires “contributing to society’s general knowledge and wellbeing.” Pure market research, product testing for competitive advantage without knowledge contribution, or proprietary research withheld from publication may not qualify. The boundary remains contested.
New Exemption (l): Biometric Verification
Article 9(2)(l) permits biometric processing for identity verification when “the biometric data or the means needed for the verification is under the sole control of the data subject.”
This targets on-device biometric authentication (Face ID, fingerprint sensors) where data never leaves the user’s device.
The “sole control” requirement means cloud-processed biometrics remain subject to Article 9’s general prohibitions. Facial recognition systems transmitting images to remote servers cannot invoke this exemption. The boundary between on-device and hybrid systems requires technical specification.
Unresolved Question: What about trusted execution environments (TEEs) where data is processed server-side but encrypted in ways the service provider cannot
access? Is this “sole control”?
4. Article 12(5): Access Request Abuse Standard
The current Article 12(5) permits refusing or charging for “manifestly unfounded or excessive” requests, with controllers bearing the burden of demonstrating this status. The proposal amends this for Article 15 (access requests) specifically, adding:
“or also…because the data subject abuses the rights conferred by this regulation for purposes other than the protection of their data.”
Additionally, the burden of proof shifts to the controllers, who must show that requests are “manifestly unfounded” OR that there are “reasonable grounds to
believe” they’re excessive, which is a lower evidentiary threshold for excessiveness.
Practical Application
This addresses the proliferation of DSARs weaponized for non-data protection purposes, such as competitors conducting industrial espionage, litigants on fishing
expeditions, activists targeting organizations, and automated DSAR services sending bulk requests.
Controllers must maintain records showing: (1) the request’s non-data protection purpose, evidenced through request patterns, stated motivations, or external context; (2) the resource burden imposed; (3) previous requests from the same subject; (4) public statements by the requester indicating ulterior motives.
The “reasonable grounds to believe” standard for excessiveness creates a rebuttable presumption. Controllers no longer need definitive proof but must present credible evidence. This will likely spawn litigation over what constitutes “reasonable grounds.”
5. Article 33: Data Breach Notification Threshold and Timeline
Presently, Article 33 requires notifying supervisory authorities of breaches “unlikely to result in a risk to the rights and freedoms of natural persons.”
The proposal changes this to “likely to result in a high risk”, aligning with Article 34’s threshold for notifying data subjects.
Under current law, virtually all breaches trigger notification unless affirmatively shown to pose no risk. The new standard requires positive likelihood of high risk, vastly reducing notification volume.
Industry surveys suggest 60-75% of current breach notifications involve low-to-medium risk scenarios. The threshold change could reduce supervisory authority notifications by two-thirds, allowing authorities to focus on genuinely serious incidents.
Extended Timeline and Harmonization
The notification deadline extends from 72 to 96 hours. This provides crucial additional time for incident response teams to assess breach scope, implement
containment, and prepare accurate notifications.
More significantly, Article 33(6) mandates that the EDPB prepare a common notification template and a list of circumstances constituting “high risk”. The
Commission will adopt these via implementing acts (Article 33(6a)), creating EU-wide harmonization.
Furthermore, a single-entry point system modeled on NIS2 Directive (Article 23a of Directive (EU) 2022/2555) will centralize notifications, eliminating the need to identify the competent supervisory authority under Articles 55-56.
Implementation Considerations
Transitional Period: Article 33(1a) specifies controllers continue notifying supervisory authorities directly until the single-entry point becomes operational.
Organizations must monitor the system’s launch and update incident response procedures accordingly.Accountability: Controllers still must assess all breaches, document assessments showing why incidents don’t meet the high-risk threshold, and maintain records per Article 33(5).
Risk Assessment Criteria: The EDPB’s forthcoming list of high-risk circumstances will be crucial. Organizations should participate in consultation processes and begin internal classification of breach types likely to meet the new threshold.
Accountability: Controllers still must assess all breaches, document assessments showing why incidents don’t meet the high-risk threshold, and maintain records per Article 33(5).
6. Article 35: EU-Wide DPIA Lists and Common Methodology
Under current Article 35(4)-(6), each supervisory authority establishes national lists of processing requiring DPIAs (“black lists”) and exempt processing (“white lists”).
This has created 27+ divergent regimes. A processing activity requiring a DPIA in France might be exempt in Germany, complicating multinational operations.
The proposal fundamentally restructures Article 35. New paragraphs (4)-(6) task the EDPB with preparing EU-level DPIA lists and a common DPIA template and
methodology. The Commission adopts these via implementing acts (Article 35(6a)).
Mandatory review occurs every three years (Article 35(6b)), with the EDPB assessing whether updates are needed based on technological and legal developments.
Existing national lists remain valid until Commission adoption (Article 35(6c)), preventing regulatory gaps during the transition.
Benefits:
- Organizations know definitively whether processing requires a DPIA across the EU.
- Reduces compliance costs and facilitates supervisory authority review.
- Ensures similar processing is assessed similarly EU-wide.
Challenges:
- Sector-specific nuances may be inadequately reflected in one-size-fits-all lists.
- Three-year review cycles may not keep pace with technological change.
- A common template may not suit all processing types.
Political Risk: The EDPB’s proposal must pass Commission scrutiny. Political considerations may dilute technical recommendations, particularly around emerging
technologies where member states hold divergent views.
Timeline and Political Process
The Digital Omnibus Proposal enters the ordinary legislative procedure. Assuming Parliament first reading by Q2 2026, Council position by Q4 2026, and trilogue negotiations through 2027, entry into force is unlikely before Q2 2028. However, certain provisions (breach notification, DPIA harmonization) depend on subsequent
implementing acts, delaying full application.
It is recommended that organisations participate in EDPB public consultations on DPIA lists, breach templates, and pseudonymization criteria. Start conducting gap
analysis comparing current practices against proposed requirements, particularly for AI systems and biometric processing and establish internal working groups
combining legal, technical, and business stakeholders to develop implementation strategies.
About the Author
Tanya Chib is a data protection lawyer focusing on EU regulatory developments, cross-border compliance, and emerging technology governance. This analysis is
provided for informational purposes and does not constitute legal advice. Organizations should consult qualified counsel regarding specific situations.
Leave a Reply