Plan for incident reporting clocks that start at different moments

Start with the trigger, not the hour count

One cloud incident can put an organization on six or more reporting clocks, and almost none of them start at the same moment. DORA's initial notification is due four hours after a financial entity classifies an incident as major, and no later than 24 hours after it became aware of the incident. ^[1] CERT-In's directions allow six hours from noticing a listed incident. ^[2] NIS2 asks for an early warning within 24 hours of becoming aware of a significant incident. ^[3] The US banking agencies allow 36 hours from a bank's determination that a notification incident has occurred. ^[4] GDPR gives a controller 72 hours, where feasible, from becoming aware of a personal data breach. ^[5] An SEC Form 8-K under Item 1.05 is due four business days after the registrant determines that an incident is material. ^[6]

So the planning answer is a list of decisions rather than a list of numbers. For each regime that applies, the response team has to recognize the event that starts the clock (noticing, awareness, classification, determination or materiality), record when it happened and on what evidence, and have the minimum content of the first notice ready before the deadline. Read that way, the comparison changes shape. CERT-In's six hours can begin before anyone knows whether personal data was touched, while the SEC clock may not begin until a disclosure committee meets days later. A team that runs one 72-hour timer from the first alert will be early for some regimes and late for others.

This is not legal advice. Which obligations reach a given organization depends on its sector, size, listing status, contracts and locations, and for NIS2 on the national law that transposes the directive, so counsel decides what applies and who files. What follows reads the primary texts as they stood on October 9, 2026, marks every proposed or pending rule with its status on that date, and translates each trigger into the facts and records that engineers are asked to produce.

The clocks in force and what starts them

The chart below puts each in-force first deadline that is stated in hours on one axis and names the start event in each label. It looks like a ranking from four hours to 72, but the bars have no common starting line. Item 1.05 is left off the chart because its limit is four business days, not a number of hours. Form 8-K counts the four business days after the materiality determination, and a determination made on a weekend or holiday starts the count on, and includes, the next business day. ^[6] Absent holidays, the calendar span therefore runs from four days for a determination on a Monday to six for one made Tuesday through Friday, and EDGAR treats a Form 8-K submitted after 5:30 p.m. Eastern time as filed on the next business day. ^[31]

Two of the clocks count from awareness. GDPR Article 33 requires the controller to notify the competent supervisory authority without undue delay and, where feasible, within 72 hours, unless the breach is unlikely to result in a risk to individuals; a later notice must give reasons for the delay, and details may follow in phases. ^[5] NIS2 stages its reporting: an early warning within 24 hours of becoming aware of a significant incident, an incident notification with an initial assessment within 72 hours, and a final report no later than one month after that notification, or a progress report if the incident is still running. ^[3] Because NIS2 is a directive, those duties reach entities through national law, which Member States had to apply from October 18, 2024. ^[3]

Financial entities report under DORA instead. Recital 28 of NIS2 names DORA as the sector-specific act whose incident reporting applies in place of the directive's for those entities. ^[3] DORA has applied since January 17, 2025. ^[7] Its delegated regulation sets two limits on the initial notification at once, four hours from classification as major and 24 hours from awareness, followed by an intermediate report within 72 hours of the initial notification and a final report within one month of the latest intermediate report. If classification happens only after the first 24 hours, the four hours run from that later classification. ^[1] The EBA's page, describing the draft standards, gives the outer limit as 24 hours after detection, while the regulation says from the moment the entity became aware; this comparison follows the regulation's wording. ^[8]

The two US clocks run from a decision. The OCC, the Federal Reserve Board and the FDIC require a banking organization's regulator to receive notice as soon as possible and no later than 36 hours after the organization determines that a notification incident occurred, meaning an incident that has materially disrupted or degraded, or is reasonably likely to, its banking operations, a business line whose failure would cause material loss, or operations that matter to US financial stability. ^[4] In the final rule the agencies said they expected banks to take a reasonable amount of time to reach that determination and that the 36 hours begin only once it is made. ^[9] Item 1.05 works the same way at a higher threshold: the registrant must determine materiality without unreasonable delay after discovery, then file within four business days. ^[6]

CERT-In's direction is the outlier. Service providers, intermediaries, data centres, body corporates and government organizations must report the incident types in its Annex I within six hours of noticing them or being told about them, and that list names attacks or suspicious activity affecting cloud computing systems. ^[2] CERT-In's FAQ says the directions apply to any entity in the matter of cyber incidents, and that a first report may carry only the information available at the time. ^[10]

Source. Legal time limits from the cited Official Journal texts, the eCFR and the CERT-In directions, read October 9, 2026; values copied, none calculated. ^{[1][2][3][4][5]}

Method. Hours copied from each text. Only limits stated in hours are plotted; SEC Form 8-K Item 1.05 (four business days after the materiality determination) is excluded because business days do not convert to a fixed number of hours. The DORA four-hour limit runs from classification and the 24-hour limit from awareness, whichever comes first. Pending rules are excluded.

Accessible table and figure data

Figure 1 accessible table

First notice and trigger	Start event	Hours	Legal text
DORA initial notification, after major classification	Classification as major	4	Delegated Regulation 2025/301, Art 5(1)(a)
CERT-In report, after noticing	Noticing an Annex I incident	6	CERT-In directions, para (ii)
NIS2 early warning, after awareness	Aware of a significant incident	24	Directive 2022/2555, Art 23(4)(a)
DORA initial notification, outer limit after awareness	Aware of the ICT incident	24	Delegated Regulation 2025/301, Art 5(1)(a)
US banking agencies notice, after determination	Notification incident determined	36	12 CFR 53.3, 225.302, 304.23
GDPR Article 33 notice, after awareness	Aware of a personal data breach	72	Regulation 2016/679, Art 33(1)

Figure 1 accessible table

First notice and trigger	Start event	Hours	Legal text
DORA initial notification, after major classification	Classification as major	4	Delegated Regulation 2025/301, Art 5(1)(a)
CERT-In report, after noticing	Noticing an Annex I incident	6	CERT-In directions, para (ii)
NIS2 early warning, after awareness	Aware of a significant incident	24	Directive 2022/2555, Art 23(4)(a)
DORA initial notification, outer limit after awareness	Aware of the ICT incident	24	Delegated Regulation 2025/301, Art 5(1)(a)
US banking agencies notice, after determination	Notification incident determined	36	12 CFR 53.3, 225.302, 304.23
GDPR Article 33 notice, after awareness	Aware of a personal data breach	72	Regulation 2016/679, Art 33(1)

Download imageDownload table CSV

Rules still moving on October 9, 2026

Four changes are pending or requested, and none of them yet imposes the obligation it describes. Each belongs in the plan as a watch item with an owner and a review date, not as a requirement to build to.

CIRCIA, the US Cyber Incident Reporting for Critical Infrastructure Act of 2022, directs CISA to require reports of covered cyber incidents within 72 hours after an entity reasonably believes one occurred, and of ransom payments within 24 hours. CISA published its proposed rule on April 4, 2024, held four town halls between June 15 and June 18, 2026, and says that multiple funding lapses affected the rulemaking. Until a final rule takes effect, no CIRCIA report is required. ^[11] The 2026 Unified Agenda entry for the rule gave September 2026 as the target for the final rule. ^[12] On October 9, 2026, CISA's page still described the final rule as work in progress. ^[11]

In the EU, the Commission's Digital Omnibus proposal of November 19, 2025, COM(2025) 837, would rewrite GDPR Article 33(1). Notice to the supervisory authority would be needed only when a breach is likely to result in a high risk to individuals, the limit would become 96 hours, and notices would go through a single entry point run by ENISA that would also carry NIS2, DORA, eIDAS and CER reports. The recitals give that entry point 18 months from entry into force, or 24 if the Commission delays it. ^[13] On October 9, 2026, Parliament's Legislative Observatory listed the procedure as awaiting committee decision, after a committee draft report on June 22 and amendments tabled on July 27, 2026. ^[14] Until it is adopted and applies, plan for today's risk-based test and 72 hours. The proposal text contains no change to the NIS2 limits of 24 and 72 hours, and it is a different instrument from the omnibus that amended the AI Act.

The UK's Cyber Security and Resilience (Network and Information Systems) Bill would replace today's single notice, due within 72 hours of a relevant digital service provider becoming aware of an incident ^[15], with an initial notification within 24 hours and a full notification within 72 hours, each copied to the national CSIRT, and would apply the same pattern to operators of essential services. It would also require digital service providers, managed service providers and data centre operators to tell UK customers likely to be adversely affected, as soon as reasonably practicable after the full notification. ^[16] The bill finished its Commons stages on June 16, 2026 and its Lords committee stage on September 7, with Lords report stage scheduled for October 26, 2026. ^[17] Even after Royal Assent, the reporting changes start only on a day the Secretary of State appoints by regulations. ^[16]

Five US financial industry groups (SIFMA, the American Bankers Association, the Bank Policy Institute, the Independent Community Bankers of America and the Institute of International Bankers) asked the SEC on April 10, 2026 to rescind Item 1.05 and Regulation S-K Item 106, replying to the Chair's review of Regulation S-K. ^[18] That is a request, not a proposal. The SEC's rulemaking activity list on October 9, 2026, covering actions back to June 2025, showed no proposal on cybersecurity disclosure, and the Form 8-K on sec.gov still contains Item 1.05. ^[19][6]

Five decisions that start a clock

The triggers fall into five kinds, listed below, and each needs a different piece of evidence to fix its time. The timeline after the list applies them to a hypothetical incident at a US-listed SaaS company that is a cloud computing service provider under an EU Member State's NIS2 law, a GDPR controller for its own account data and a processor for customer data, with users in India. The times are invented for illustration. The point is that three decisions spread over four days start five different deadlines, and that the earliest deadline falls before most of the facts are known.

• Noticing (CERT-In): six hours from noticing an Annex I incident or being told of one; neither the directions nor the FAQ define the moment further. ^[2][10]
• Awareness (GDPR, NIS2, the outer DORA limit and the UK bill): the EDPB reads GDPR awareness as a reasonable degree of certainty that a security incident has compromised personal data, reached after a short investigation that should begin at once. ^[20]
• Classification (DORA): four hours from the entity's own classification of the incident as major under Delegated Regulation 2024/1772. ^[1][21]
• Determination (US banking agencies): 36 hours from the bank's determination that the incident is a notification incident. ^[4]
• Materiality (SEC): four business days from the determination that the incident is material, a determination that must itself come without unreasonable delay after discovery. ^[6]

Source. Conceptual hypothetical; times are invented and the rules applied are from the CERT-In directions, NIS2 Article 23, the NIS2 implementing regulation, GDPR Article 33 and Form 8-K. ^{[2][3][24][5][6]}

Method. Conceptual illustration of one possible reading. Each deadline adds the cited limit to the hypothetical trigger time; whether each regime applies, and when each trigger occurred, are decisions for counsel in a real incident.

Accessible table and figure data

Figure 2 accessible table

Moment (hypothetical, UTC)	Team establishes	Clock it can start
Monday 01:40 UTC, an alert fires	Bulk object reads by a CI deploy role from an unfamiliar network	None confirmed; record the time in case counsel reads it as noticing
Monday 04:10, unauthorized access confirmed	The calls trace to a CI credential leaked in a build log	CERT-In report by 10:10; NIS2 early warning by Tuesday 04:10 if significant
Monday 15:30, personal data confirmed in scope	Object-level data events show customer records were read	GDPR notice by Thursday 15:30; tell affected controller customers without undue delay
Thursday 04:10, NIS2 incident notification due	Severity, impact and indicators of compromise assessed	Final report due one month after this notice
Thursday 17:00, incident found material	The disclosure committee records its determination	Form 8-K Item 1.05 by the following Wednesday, absent holidays

Figure 2 accessible table

Moment (hypothetical, UTC)	Team establishes	Clock it can start
Monday 01:40 UTC, an alert fires	Bulk object reads by a CI deploy role from an unfamiliar network	None confirmed; record the time in case counsel reads it as noticing
Monday 04:10, unauthorized access confirmed	The calls trace to a CI credential leaked in a build log	CERT-In report by 10:10; NIS2 early warning by Tuesday 04:10 if significant
Monday 15:30, personal data confirmed in scope	Object-level data events show customer records were read	GDPR notice by Thursday 15:30; tell affected controller customers without undue delay
Thursday 04:10, NIS2 incident notification due	Severity, impact and indicators of compromise assessed	Final report due one month after this notice
Thursday 17:00, incident found material	The disclosure committee records its determination	Form 8-K Item 1.05 by the following Wednesday, absent holidays

Download imageDownload table CSV

Where classification and materiality bite in cloud incidents

Classification is the trigger a cloud credential compromise is most likely to pull early. Under Delegated Regulation 2024/1772, an incident that affects critical services is major on one criterion alone when there has been any successful, malicious and unauthorised access to network and information systems that may result in data losses. Otherwise two other thresholds must be met, such as more than 10 percent or more than 100,000 affected clients, downtime of more than two hours for an ICT service that supports a critical or important function, or costs above EUR 100,000. ^[21] It follows that a financial entity which confirms that a stolen key reached a production account behind a critical service can reach a major classification, and start its four-hour clock, on the same shift.

Determination and materiality are decisions that people make, and the record of who made them and when is the evidence. The SEC staff's interpretations add three timing points. Asking the Attorney General for a national security delay does not move the filing deadline unless the Attorney General notifies the Commission in writing, before the 8-K is due, that disclosure would pose a substantial risk. Paying a ransom, or seeing the attacker stop, does not remove the need to assess materiality. And a series of related incidents can be material together even when none is alone. ^[22] In a statement on May 21, 2024, the director of the SEC's Division of Corporation Finance encouraged companies that disclose an incident before determining materiality, or one they judged immaterial, to use another item such as Item 8.01, and said that a later materiality determination still requires an Item 1.05 filing within four business days. ^[23]

Aggregation rules can start a clock without any new event. DORA treats incidents with the same apparent root cause, occurring at least twice in six months, as one major incident if together they meet the criteria, and asks entities to check for them monthly. ^[21] The NIS2 implementing regulation applies a similar twice-in-six-months rule to the providers it covers, including cloud, data centre and managed service providers, tied to its financial-loss threshold and checked quarterly. ^[24] A detection team that closes each repeat alert as a separate low-severity case loses the thread these rules ask it to keep.

Evidence each first notice needs

First notices are short by design, but none is empty, and each asks for facts that only logs and service owners can supply. The matrix pairs the minimum content each text names with the engineering evidence that usually supplies it. The middle column comes from the legal texts; the right-hand column is this publication's mapping and should be read as an interpretation.

DORA's initial notification asks for the most structure: an incident reference code, the date and time of detection, the classification and the criteria that made the incident major, the Member States affected, how the incident was discovered, its origin where known, and whether a business continuity plan was activated. ^[1] Duration is measured from when the incident occurred, from detection if that moment is unknown, and from the first trace in network or system logs if the entity learns that the incident began before detection. ^[21] In a cloud intrusion, the first suspicious API call in an audit log can therefore set the start of the measured duration, which feeds the threshold for incidents lasting more than 24 hours.

GDPR's minimum is about people and records: the nature of the breach, the categories and approximate numbers of data subjects and records, a contact point, the likely consequences, and the measures taken or proposed. ^[5] Approximate counts need object-level or row-level access evidence joined to a data inventory, because control-plane logs show that a role could reach a bucket, not which objects it read. Article 33(5) also requires every breach to be documented with its facts, effects and remedial action, whether or not it was notified, so the record built for the clock doubles as the compliance record. ^[5]

NIS2's early warning needs only two judgments, whether the incident looks unlawful or malicious and whether it could have cross-border impact, and the directive's recitals say the early warning should carry only what the authority needs so that reporting does not draw people away from handling the incident. The incident notification adds an initial assessment of severity and impact and indicators of compromise where available. ^[3] The banking agencies require no specific content beyond the fact that a notification incident has occurred. ^[9] Item 1.05 asks for the material aspects of nature, scope and timing and the material or reasonably likely material impact, and lets the registrant leave out technical detail that would impede response or remediation. ^[6]

Source. Middle column from the cited legal texts; right-hand column is a conceptual mapping by Cloud Security Desk, October 9, 2026. ^{[2][10][1][3][9][5][6]}

Method. Conceptual mapping. Content requirements are paraphrased from each text's minimum; the evidence column is an interpretation of which engineering records usually supply each item and is not exhaustive.

Accessible table and figure data

Figure 3 accessible table

First notice	What the text asks for	Evidence that supplies it
DORA initial notification, 4 hours	Detection time, criteria met, discovery, continuity plan	Detection record; affected critical service; client counts
CERT-In report, 6 hours	Incident details available at the time	Synced timestamps; logs kept for 180 days
NIS2 early warning, 24 hours	Suspected malicious cause; possible cross-border impact	Attacker indicators; affected regions and Member States
US banking notice, 36 hours	That a notification incident occurred	Determination record; service impact summary
GDPR Article 33, 72 hours	Nature, approximate numbers, consequences, measures	Data-access logs joined to a data inventory
SEC Item 1.05, four business days	Nature, scope, timing, material impact	Log-based timeline; business impact estimate

Figure 3 accessible table

First notice	What the text asks for	Evidence that supplies it
DORA initial notification, 4 hours	Detection time, criteria met, discovery, continuity plan	Detection record; affected critical service; client counts
CERT-In report, 6 hours	Incident details available at the time	Synced timestamps; logs kept for 180 days
NIS2 early warning, 24 hours	Suspected malicious cause; possible cross-border impact	Attacker indicators; affected regions and Member States
US banking notice, 36 hours	That a notification incident occurred	Determination record; service impact summary
GDPR Article 33, 72 hours	Nature, approximate numbers, consequences, measures	Data-access logs joined to a data inventory
SEC Item 1.05, four business days	Nature, scope, timing, material impact	Log-based timeline; business impact estimate

Download imageDownload table CSV

Retention and clock sync must exist beforehand

Two properties of the evidence cannot be created after the trigger: how far back the logs go, and whether their timestamps agree. CERT-In requires logs of all ICT systems to be kept securely for a rolling 180 days within Indian jurisdiction and provided with an incident report or on request. ^[2] Its FAQ says logs may also be stored outside India as long as they can be produced to CERT-In within a reasonable time. The directions are the binding text, so a team relying on the FAQ's reading should have counsel confirm it. ^[10] The NIS2 implementing regulation is less specific: in-scope providers keep and back up logs for a predefined period, protect them from unauthorized access or change and, to the extent feasible, synchronize time sources so that logs can be correlated. ^[24]

Default retention falls short of 180 days in most of the stores a cloud investigation starts from, and the one long default covers only some log types. AWS CloudTrail event history keeps 90 days of management events only. ^[25] Azure keeps Activity log events, which record control-plane operations, for 90 days unless a diagnostic setting sends them elsewhere. ^[26] Google Cloud keeps its _Required bucket for 400 days without configuration and its _Default bucket for 30 days, configurable from 1 to 3,650 days in projects. ^[27] The _Required sink takes only Admin Activity, System Event and Access Transparency audit logs; everything else, including Data Access audit logs where enabled, goes to _Default. ^[28]

The gap that hurts most in a breach is the data-plane record. An intrusion that began four months before detection, whose duration DORA would measure from its first log trace, can leave the team unable to give GDPR's approximate record counts at all if object-level logs were never kept that long. ^[21][5] Set retention for the data-access logs that answer the scope question to at least 180 days wherever CERT-In applies, and longer where the organization's own investigations show intrusions running longer before detection. Then verify the setting in every account, subscription and project, not in the policy document.

Clock agreement matters because several deadlines are computed from a logged moment. CERT-In requires ICT system clocks to be synchronized to the NTP servers of India's National Informatics Centre or National Physical Laboratory, or to sources traceable to them, and its FAQ accepts a cloud provider's native time service for workloads running in that cloud. ^[2][10] Record every trigger in UTC with the timestamp of the event it rests on, not the time someone typed it into a chat channel.

Provider notices and shared responsibility

Cloud incidents cross the provider boundary in both directions. When the provider is a processor, its notice can start the customer's GDPR clock. The EDPB says that, in principle, a controller should be considered aware once its processor has informed it of a breach, and that a processor need not assess risk before telling the controller. ^[20] The two provider addenda checked here promise speed, not hours. AWS's data processing addendum commits AWS to notify without undue delay after it becomes aware of a security incident, delivers notices to the customer's administrators by any means including email, makes the customer responsible for keeping those contacts accurate, and leaves the customer to decide its own notification duties. ^[29] Google Cloud's addendum promises notice promptly and without undue delay, describing the incident, the customer resources affected, Google's measures and recommended customer actions, with further details as they become available. ^[30]

That puts an engineering task in front of a legal one. On the EDPB's reading, a provider notice that lands in an unmonitored mailbox can still mark the moment of awareness. Route provider security contacts to a monitored incident intake, test the route, and log the receipt time of every provider notice in the incident record.

Financial entities also have a contractual lever. DORA requires ICT service contracts to oblige the provider to assist when an ICT incident related to the service occurs, at no additional cost or at a cost fixed in advance, and it lets an entity outsource the reporting itself while remaining fully responsible for meeting the deadlines. ^[7]

When the organization is the provider, its thresholds are written down. For cloud computing service providers, the NIS2 implementing regulation treats an incident as significant when a service is completely unavailable for more than 30 minutes; when availability is limited for more than 5 percent of its EU users or more than one million of them, whichever is smaller, for more than an hour; or when the integrity, confidentiality or authenticity of service data is compromised by a suspectedly malicious action or affects more than 5 percent or one million users. Managed service and managed security service providers face the same four tests, and scheduled maintenance does not count. ^[24] Where appropriate, NIS2 also asks entities to tell the recipients of their services, without undue delay, about significant incidents likely to affect those services. ^[3]

US bank service providers have their own trigger. They must notify at least one bank-designated contact at each affected banking customer as soon as possible after determining that an incident has materially disrupted or degraded, or is reasonably likely to, covered services for four or more hours; maintenance communicated in advance is excluded. ^[4] The agencies intended that notice to let each bank decide whether its own 36-hour duty has been triggered. ^[9]

Build the decision log before you need it

Every clock above turns on a recorded moment, so the incident record needs one entry per trigger rather than one severity field. Each entry states the trigger type, the regime it may start, when it happened in UTC and the source of that time, who made or recognized it, the evidence it rests on, and the computed deadline. When a decision is revised, the log gains a new entry instead of an overwritten one: DORA's initial notification has a field for reclassification from major to non-major, and Item 1.05 requires an amendment once information that was not determined at filing becomes available. ^[1][6]

The fragment below shows one entry from the hypothetical incident, in a layout the team controls. Two fields carry most of the weight. decided_at_utc is the trigger time, which is neither the attacker's first action nor the moment the alert fired; confusing them is how one regime's deadline gets computed from another regime's start. basis states, in a sentence a regulator could read, why the threshold was met, because GDPR's breach documentation must let the supervisory authority verify compliance and DORA's initial notification must name the criteria on which the incident was classified as major. ^[5][1] Keep the log in a system that survives the incident, not only in a chat workspace that could itself be in scope.

Name the owner of each trigger in advance. One workable split gives GDPR awareness to the privacy or data protection lead, DORA classification to whoever the entity's incident policy names, and the banking determination and SEC materiality to the people the governance documents assign, with counsel involved. The incident commander's job is to put the evidence in front of each owner as soon as it exists and to record the answer, including a recorded not-yet with the time of the next review.

{
  "incident_id": "INC-2027-0301",
  "trigger": "awareness",
  "regime": "GDPR Article 33(1)",
  "role": "controller",
  "decided_at_utc": "2027-03-01T15:30:00Z",
  "time_source": "Review of S3 data events for account 111122223333 completed",
  "decided_by": "privacy-lead@example.com",
  "basis": "Data events show the leaked CI role read objects holding customer contact records",
  "evidence_refs": [
    "s3://example-bucket/ir/INC-2027-0301/data-event-query.sql",
    "ticket:IR-4471"
  ],
  "deadline_rule": "72 hours from awareness, where feasible",
  "first_notice_due_utc": "2027-03-04T15:30:00Z",
  "notice_sent_utc": null,
  "supersedes": null
}

Exercise the clocks

A tabletop that tests reporting should move the triggers, not only the incident. These injects stress the parts of the comparison that teams most often assume away.

• A provider notice reaches a security contact address that nobody monitors and is found a day later; on the EDPB's reading, the controller's awareness may date from the notice. ^[20]
• The intrusion is confirmed late on a Friday. Form 8-K counts business days only, GDPR Article 33 and NIS2 Article 23 contain no weekend exception, and DORA's weekend relief does not cover initial or intermediate reports by credit institutions, central counterparties, trading venues or NIS2 essential and important entities. ^[6][5][3][1]
• Two minor incidents in five months share a root cause and a third arrives, which DORA, the NIS2 implementing regulation and the SEC staff all treat as a reason to assess the incidents together. ^[21][24][22]
• The data events needed for record counts were never enabled on the affected bucket or project, so the GDPR notice cannot give the approximate numbers Article 33(3) asks for where possible, and no later phase can recover them. ^[5]
• Counsel asks whether CERT-In applies to a workload with Indian users; the FAQ's statement that the directions apply to any entity in the matter of cyber incidents starts that conversation. ^[10]

Where this guide stops

One decision rule follows from the texts: notify on the earliest clock that has started, with what is known, and supplement later. Every regime compared here accepts an incomplete first notice, whether through GDPR's phased information, NIS2's staged reports, DORA's intermediate reports, Item 1.05's required amendment, CERT-In's later information or the banking agencies' content-free notice. ^{[5][3][1][6][10][9]} On a plain reading, none of them makes complete facts a condition for the clock to start, and GDPR and DORA ask for the reasons when a notice is late. ^[5][1]

The comparison stops at the texts named here. It does not cover other countries' regimes, US state breach laws, health or insurance sector rules, contractual notice periods in customer agreements, or national laws transposing NIS2, which the directive allows to go further than its minimum. ^[3] Each of those can add a clock. It reads the law as of October 9, 2026, and CIRCIA, the Digital Omnibus and the UK bill could each change a row before this page's review date.

If an incident is running now, the order is short. Record the first alert time. Put the question that starts each clock to its owner as soon as the evidence exists. Send the earliest notice with what is known, then work toward the fuller reports in deadline order, and keep the decision log that shows when each step happened.