Incident Notification Deadlines When Identity Data Is Involved: GDPR, NIS2 and DORA Side by Side

For information; not legal advice.

Suppose someone gains access to a store of identity document images. Within hours, several different clocks may be running, each one started by a different event and stopped by a different message to a different recipient. The data protection law has one. The directive on network and information security has another. If the company is a bank, an insurer or another financial entity, the digital operational resilience regulation has a third, and its first deadline is the shortest of all. The company that processes the images on your behalf has a duty of its own, and its message to you is what starts several of your clocks.

This article lays the regimes side by side. It states each deadline as the legal text states it, says who sends what to whom, and then follows one hypothetical incident through the clocks of a customer and its verification provider. It is a map, not an opinion on any particular case. Which regime applies to a given company depends on its sector, its size, the Member State where it is established and its role as controller or processor. Those are questions for counsel.

It builds on the buyer's guide to evaluating a provider's security and privacy, which has a short section on incidents and the processor's duty, and on retention and erasure of identity data in verification callbacks, which is about holding less to begin with.

Four questions that sort an incident

Before any deadline, four questions sort the incident.

Is personal data involved? If personal data was destroyed, lost, altered, disclosed or accessed without authority, the General Data Protection Regulation (GDPR) applies.
Is the entity within the scope of the NIS2 Directive? If it is an essential or important entity, and the incident is significant, Article 23 applies.
Is the entity a financial entity under the Digital Operational Resilience Act (DORA)? If so, and the ICT-related incident is major, Article 19 applies, and for that reporting it applies instead of NIS2 (see the exception below).
Is the entity the manufacturer of a product with digital elements? If so, Article 14 of the Cyber Resilience Act applies to actively exploited vulnerabilities and severe incidents.

More than one answer can be yes, with one important exception between the second and the third. Article 4 of the NIS2 Directive says that where a sector-specific Union legal act requires essential or important entities to notify significant incidents, and the requirement is at least equivalent in effect to the Directive's, the relevant provisions of the Directive do not apply to those entities. Recital 28 of the Directive names DORA as such an act for financial entities, and says that the DORA provisions on major ICT-related incident reporting apply instead of the Directive's. So a financial entity covered by DORA reports its major ICT-related incidents under DORA, not additionally under NIS2, and the NIS2 rows of this article are for entities outside that case. Whether a particular company is in that case is a question for counsel. Outside it, the same event can be a personal data breach and a significant incident, or a personal data breach and a major ICT-related incident, and each regime asks for its own notification, to its own recipient, on its own clock. The fourth regime is covered in the article on coordinated vulnerability disclosure and appears below only as a row of the table.

What starts the clock

Awareness

The GDPR clock starts when the controller has become aware of the breach. The European Data Protection Board, in its guidelines on personal data breach notification, version 2.0 adopted on 28 March 2023, considers that a controller should be regarded as aware when it has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised. It adds that the controller must have measures to establish at once whether a breach has taken place, and that the emphasis should be on prompt action to investigate an alert. Its examples include a lost, unencrypted storage key, where the controller becomes aware when it realises the key was lost, even if it cannot tell whether anyone read the data.

NIS2 counts from awareness too. Article 23 counts 24 hours and 72 hours from the moment the entity becomes aware of the significant incident. Delegated Regulation (EU) 2025/301, under DORA, sets two limits for the first notification: no later than 24 hours from the moment the entity became aware of the incident, and within four hours from its classification as major.

Awareness through a processor

A verification provider is, for the images and data it processes on your instructions, usually a processor, although the roles depend on the facts and the contract. For a processor, Article 33(2) of the GDPR says it shall notify the controller without undue delay after becoming aware of a personal data breach. The guidelines explain two consequences. The processor does not first have to assess the risk to individuals, since that assessment belongs to the controller. And the controller should, in principle, be considered aware once the processor has informed it of the breach. The text sets no number of hours for the processor, and the guidelines recommend that the processor notify promptly, with further information in phases, and that the contract can require early notification to help the controller meet its own deadline.

The consequence for a buyer is arithmetic. A buyer who simply waits for the provider to speak has no control over when its own clock starts. A contract that says "without undue delay" and nothing more leaves the figure to argument after the event. A contract that names a number of hours, a channel and a person leaves you able to plan.

Regulation (EU) 2016/679 defines a personal data breach as a breach of security that results in the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed.

To the supervisory authority

Under Article 33(1), the controller notifies the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after having become aware of the breach, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. If the notification is not made within 72 hours, it must be accompanied by reasons for the delay. The notification must at least describe the nature of the breach, including where possible the categories and approximate number of data subjects and records, give the name and contact details of the data protection officer or another contact point, describe the likely consequences, and describe the measures taken or proposed. Where it is not possible to provide all of this at once, the information may be provided in phases without undue further delay. The controller must also document every breach, with the facts, the effects and the remedial action, so that the authority can verify compliance. That duty to document applies to breaches that are not notified as well.

To the people affected

Article 34 applies a higher threshold. When the breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller must communicate it to the data subject without undue delay, in clear and plain language, with at least the contact point, the likely consequences and the measures taken or proposed. Three exceptions apply. The communication is not required if appropriate protection measures were applied to the affected data, in particular measures that render the data unintelligible to anyone not authorised to access it, such as encryption. It is not required if later measures ensure that the high risk is no longer likely to materialise. And it is not required if it would involve disproportionate effort, in which case a public communication or similar measure must inform people in an equally effective way. The supervisory authority may require the controller to communicate, or may decide that an exception is met. Whether the encryption exception holds in a given case depends on facts such as the keys, the algorithm and whether the keys were also exposed, and a statement that data was encrypted is where the analysis starts.

Other points from the guidelines

The EDPB guidelines say that risk is to be assessed in three levels: no risk, risk and high risk. They say that a controller not established in the Union but subject to the Regulation is still bound by Articles 33 and 34, and that the mere presence of a representative in a Member State does not trigger the one-stop-shop system, so the breach must be notified to every supervisory authority in whose Member State affected data subjects reside. They say that the legal responsibility to notify stays with the controller even when a processor makes the notification on its behalf with proper authorisation. And they say that where one incident affects several controllers served by one processor, the processor reports to each of them.

The United Kingdom

The UK GDPR keeps the same shape. The Information Commissioner's Office states that organisations must report certain personal data breaches to the supervisory authority within 72 hours of becoming aware of the breach, where feasible, and must inform individuals without undue delay when the breach is likely to result in a high risk. It says that all breaches must be recorded, whether or not they are notified. It also notes that a change made by the Data Use and Access Act moved the reporting time for breach reports under the Privacy and Electronic Communications Regulations from 24 hours to 72 hours after becoming aware of the breach, as stated in the update dated 20 August 2025.

The NIS2 Directive: Article 23

Directive (EU) 2022/2555 asks essential and important entities to notify their national computer security incident response team, or where applicable their competent authority, of any incident that has a significant impact on the provision of their services. An incident is significant if it has caused or can cause severe operational disruption of the services or financial loss for the entity, or has affected or can affect other persons by causing considerable material or non-material damage.

The notification has stages.

Early warning, without undue delay and in any event within 24 hours of becoming aware, indicating where applicable whether the incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact.
Incident notification, without undue delay and in any event within 72 hours of becoming aware, updating the early warning and adding an initial assessment of severity and impact and, where available, indicators of compromise.
Intermediate report, on request of the response team or authority, on relevant status updates.
Final report, not later than one month after the incident notification, with a detailed description, the type of threat or root cause, the mitigation applied and ongoing, and the cross-border impact where applicable.
Progress report and final report for an incident still ongoing when the final report is due, with a final report within one month of the handling of the incident.

A derogation applies to trust service providers, which must give the incident notification within 24 hours instead of 72. The passage of the Directive quoted here does not define the term, and a verification provider that is also a trust service provider should read that sentence carefully with its counsel.

Two further duties fall on the entity. Where appropriate, it must notify the recipients of its services, without undue delay, of significant incidents likely to adversely affect the provision of those services. And where there is a significant cyber threat, it must tell potentially affected recipients about the measures or remedies they can take. For authorities, the Directive requires a response to the early warning within 24 hours where possible, with initial feedback and, on request, guidance. It also states that the mere act of notification does not subject the notifying entity to increased liability.

NIS2 is a directive, so each Member State transposes it into national law, and the national law decides which authority receives the notification, through which portal and in which language. This article has not checked the national laws and states none of them.

DORA: Article 19 and its technical standards

Regulation (EU) 2022/2554, the Digital Operational Resilience Act, has applied since 17 January 2025. Article 19 requires financial entities to report major ICT-related incidents to the relevant competent authority, using the templates required by Article 20. A major ICT-related incident is one with a high adverse impact on the network and information systems that support critical or important functions of the financial entity.

The deadlines sit in a Commission delegated regulation: Delegated Regulation (EU) 2025/301 of 23 October 2024, published in the Official Journal on 20 February 2025, which sets the content and time limits of the initial notification and of the intermediate and final reports. Article 5 of that regulation sets these limits.

Report	Time limit
Initial notification	As early as possible, within four hours from classification of the incident as major and no later than 24 hours from the moment the financial entity became aware of the incident
Intermediate report	At the latest within 72 hours from the submission of the initial notification, and an updated report without undue delay when regular activities have been recovered
Final report	No later than one month after the intermediate report or, where applicable, after the latest updated intermediate report

The limit for the intermediate report is a ceiling, not the only trigger. DORA Article 19 also asks for an intermediate report as soon as the status of the original incident has changed significantly or its handling has changed on the basis of new information, followed, as appropriate, by updated notifications whenever a relevant status update is available and whenever the competent authority asks for one; recovery of regular activities is one mandatory occasion for an update, not the only one.

If an incident is not classified as major within 24 hours of awareness but is classified so later, the initial notification is due within four hours of the classification. An entity that cannot meet a limit must tell the authority without undue delay, no later than that limit, and explain the delay. A deadline that falls on a weekend or a bank holiday may be met by noon of the next working day. That relief does not apply to an initial notification or an intermediate report by credit institutions, central counterparties, operators of trading venues, and other financial entities identified as essential or important entities under Article 3 of the NIS2 Directive. The competent authorities may also decide that the relief does not apply to initial notifications and intermediate reports of other financial entities that are significant or have a systemic character for the financial sector at national or Union level, and the decision applies only to incidents reported after the entity is told of it. Those two exclusions name only initial notifications and intermediate reports, so the text leaves the relief in place for final reports.

The forms are in Commission Implementing Regulation (EU) 2025/302, also of 23 October 2024 and published on 20 February 2025, which lays down the standard forms, templates and procedures for reporting a major ICT-related incident and for notifying a significant cyber threat. The joint final report of the European Supervisory Authorities, dated 17 July 2024, records how the time limits were set, including that the intermediate and final report deadlines run from the previous report and not from classification.

Three other points matter to a customer of a verification provider.

Clients. Where a major incident affects the financial interests of clients, the financial entity must inform them without undue delay once aware, with the measures taken.
Outsourced reporting. A financial entity may outsource its reporting obligations to a third-party service provider, and remains fully responsible for fulfilling them.
Contract. The contractual provisions for ICT services include the provider's obligation to assist the financial entity at no additional cost, or at a cost determined in advance, when an ICT incident related to the service occurs.

The second and third points mean that a financial entity cannot hand the duty to a provider, and can insist on help from it.

Who notifies whom: the table

The table gives, for each regime, the sender, the recipient, the time and the main content. Times are measured from the moment shown; where the text says "without undue delay" the deadline is not a number of hours.

Regime	From	To	When	Main content
GDPR Article 33(2)	Processor	Controller	Without undue delay after becoming aware	The breach and what the processor knows; no risk assessment needed
GDPR Article 33(1)	Controller	Supervisory authority	Without undue delay and where feasible within 72 hours of awareness; reasons if later	Nature, categories and approximate numbers, contact point, likely consequences, measures
GDPR Article 34	Controller	Data subjects	Without undue delay, if high risk	Plain language; contact point, likely consequences, measures
NIS2 Article 23, early warning	Essential or important entity	National response team or competent authority	Within 24 hours of awareness	Suspected unlawful or malicious cause; possible cross-border impact
NIS2 Article 23, notification	The same	The same	Within 72 hours of awareness (24 hours for trust service providers)	Initial assessment, severity, impact, indicators of compromise
NIS2 Article 23, final report	The same	The same	Within one month of the notification	Description, root cause, mitigation, cross-border impact
NIS2 Article 23(1)	The same	Recipients of its services	Without undue delay, where appropriate	Significant incidents likely to affect the service
DORA Article 19, initial	Financial entity	Competent authority	Within four hours of classification as major and within 24 hours of awareness; where the classification comes only later, within four hours of that classification	Content set by the standards of 2025/301 and the template of 2025/302
DORA Article 19, intermediate	The same	The same	Within 72 hours of the initial notification, and an updated report when regular activities have been recovered	Status update and updated information
DORA Article 19, final	The same	The same	Within one month of the intermediate report or, where applicable, of the latest updated intermediate report	Root cause, resolution, costs and losses
DORA Article 19(3)	The same	Clients	Without undue delay	Incident and mitigation measures, if their financial interests are affected
CRA Article 14, early warning	Manufacturer	National response team and ENISA	Within 24 hours of awareness	Actively exploited vulnerability or severe incident
CRA Article 14, notification	The same	The same	Within 72 hours of awareness	General information, nature, corrective measures
CRA Article 14, final report	The same	The same	14 days after a corrective measure for a vulnerability; one month after the notification for an incident	Description, root cause, measures

The Cyber Resilience Act's Article 14 has applied since 11 September 2026, as the text of that Regulation states. The NIS2 rows apply to entities outside the case in which a sector-specific act such as DORA applies instead. The table is a summary and the texts control.

One incident through the clocks: an illustration

The following case is hypothetical and simplified. A bank, which is a financial entity under DORA and therefore reports major ICT-related incidents under DORA and not under NIS2, uses a verification provider as a processor. On a Tuesday morning, the provider's monitoring shows that an unauthorised party read stored document images of the bank's customers. The illustration follows the GDPR and DORA clocks only; a company outside the DORA case would follow the NIS2 rows of the table above instead of the DORA rows.

Moment	Event	Clock that starts or moves
Start	The provider sees the access and has a reasonable degree of certainty that personal data was compromised	The provider is aware; its duty to tell the bank runs from here, without undue delay
Two hours in	The provider tells the bank, through the channel and to the person the contract names	The bank is in principle aware; the GDPR and DORA clocks start from here for the bank
Five hours in	The bank classifies the incident as major under its DORA criteria	The DORA limit of four hours from classification runs
Nine hours in	Four hours after classification	The DORA initial notification is due, sent with the template
Twenty-six hours in	Twenty-four hours after the bank's awareness	The outer DORA limit, which the earlier limit has already met
Seventy-four hours in	Seventy-two hours after the bank's awareness	The GDPR notification to the data protection authority is due
Eighty-one hours in	Seventy-two hours after the initial notification, if it was sent at nine hours	The DORA intermediate report is due
When the risk is assessed	If the breach is likely to result in a high risk	The bank communicates to the affected customers without undue delay

In this case the shortest clock is the DORA one, because the bank classified the incident quickly. Had classification taken longer, the limit of 24 hours from awareness would have been the one to watch. Two things follow. First, the DORA limit is short enough that the bank needs the provider's facts within hours, which is why a vague contract term is a risk. Second, the bank needs one incident record that supports all of its notifications, not a separate one for each.

One record for several notifications

The content that each regime asks for overlaps. A single incident record, kept from the first alert, can supply all of them if it holds these items.

Timeline with the source of each timestamp: first alert, awareness, classification, containment, recovery.
Who decided what and when: that the incident is a breach, that it is significant or major, that individuals must be told.
What data was affected: categories, approximate numbers of people and of records, and whether the data was encrypted and whether the keys were exposed.
Likely consequences for the people affected and for the service.
Measures taken and proposed, including those that users can take.
Indicators of compromise, where available.
Cross-border impact: which Member States and which entities.
Root cause, updated as the analysis matures.
Third parties: which provider, which processor, which authority was told and when.
Reasons for any delay.

The GDPR documentation duty, which covers breaches that are not notified, makes this record a legal requirement and not only good practice.

What is changing

Two developments are worth knowing about, and neither should be assumed in force.

The first is a proposal from the European Commission. In its Digital Package, the Commission proposed a single-entry point through which entities could submit one report to cover several reporting obligations, with the European Union Agency for Cybersecurity, ENISA, to build and maintain it. The page fetched for this article, last updated on 20 November 2025, says that the proposal would bring reporting under NIS2, the GDPR, DORA, the Critical Entities Resilience Directive and the EU Digital Identity Regulation under it, and that it would not modify existing reporting obligations or the authorities that receive reports. The same page says the proposal would also clarify when and how data breaches are notified to supervisory authorities. A proposal is not law. This article has not verified whether, or in what form, any part of the package was adopted, and a reader should check the Official Journal.

The second is national: the transposition of NIS2 differs from one Member State to another, and so do the portals and the forms.

Holding less data

One way to reduce what an incident can expose is to hold less. The NeuroVision documentation describes an erase call that destroys the document data, contacts, images and video of a session, and the person record that session created unless another session or a manual entry still holds that record, while the session record stays with its verdict and without the personal data. The response reports the state of each kind of data (text, media, person and questionnaire) as erased, kept, unconfirmed or absent. A part reported as kept comes with a reason: another session of the same person still holds the record, the record was entered by hand, or the record is on a blacklist. So erasure is not an unconditional promise that every trace of a person is gone, and the response is what tells you which parts were destroyed. An answer of erased means the destruction is finished; an answer of in_progress means it is started and not finished, and the PD_ERASURE_COMPLETE webhook reports it when it is. The documentation says that the identifiers clientKey and clientUser stay on the session and in the journal after destruction, so they must carry no personal data. Deleting what you no longer need is a control a customer exercises before any incident, and it changes the answer to the question "what was exposed". It does not change the duty to notify about what was exposed.

Where this sits in a verification flow

An incident at a verification provider reaches its customer through the contract and the channel it names. Check that the agreement names a notification time in hours, a contact that is staffed at night and on weekends, the information the provider will give in the first message, and the provider's duty to help with the customer's own notifications. For retention and erasure through the platform, read receiving webhooks and the data protection page, and to put these questions into a contract discussion, contact the team.

Sources

All sources were fetched on 28 October 2026.

Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (General Data Protection Regulation), Official Journal of the European Union, via the Publications Office.
Directive (EU) 2022/2555 of 14 December 2022 (NIS2 Directive), Official Journal of the European Union, 27 December 2022, via the Publications Office.
Regulation (EU) 2022/2554 of 14 December 2022 (Digital Operational Resilience Act), Official Journal of the European Union, 27 December 2022, via the Publications Office.
Commission Delegated Regulation (EU) 2025/301 of 23 October 2024, Official Journal of the European Union, 20 February 2025.
Commission Implementing Regulation (EU) 2025/302 of 23 October 2024, Official Journal of the European Union, 20 February 2025.
Regulation (EU) 2024/2847 (Cyber Resilience Act), Official Journal of the European Union, 20 November 2024.
Guidelines 9/2022 on personal data breach notification under GDPR, version 2.0, adopted 28 March 2023, European Data Protection Board.
Personal data breaches: a guide, Information Commissioner's Office.
Final report on draft RTS and ITS on content, format, timelines and procedures for reporting of major incidents and significant cyber threats under DORA, Joint Committee of the European Supervisory Authorities, JC 2024 33, 17 July 2024.
Digital Package, questions and answers, European Commission, Shaping Europe's digital future, last update 20 November 2025.
Erase session personal data and Webhooks, NeuroVision documentation.