One night, several clocks

On a Friday evening, a team notices that part of its servers has been encrypted and the logs show data leaving the network. If the company serves clients in Ukraine, the EU, the UK and Canada, it may face not one reporting deadline but several. They start at different moments, go to different bodies and ask for different things. The shortest run out in four hours, the longest allow a month, and they begin together.

This article gives two practical things: a map of who reports to whom, and when, for the regimes we have checked against primary sources; and a design for one process that covers every deadline at once. It covers reporting to regulators only. For the response itself, see our article on the incident response plan.

This is not legal advice: confirm the deadlines and thresholds that apply to your company with a lawyer and the relevant regulator.

Start with the clock itself

The most common mistake with maps like this is counting from the start of the attack. The rules start the clock at different moments:

• "Became aware". GDPR, NIS2 and the CRA count from the moment the organisation becomes aware of the breach or significant incident.

• "Classified". DORA asks for the initial notification within four hours of classifying the incident as major, and in any case within 24 hours of the entity becoming aware of it.

• "Determined the threshold was met". The FCA expects an initial report as soon as practicable, and its guidance says that means within 24 hours of the firm determining that a threshold has been met.

So two timestamps matter: when you became aware, and when you classified. Record both to the minute, with the name of the person who decided, or you cannot show you met the deadline.

The map, regime by regime

Below is only what we have checked. Every regime has conditions: sector, size, type of data, where you operate. Read this as a list of questions to ask about your own situation, not as an answer.

Ukraine

• Banks: NBU Resolution No. 178, as amended by No. 24 (from 1 March 2025). A bank notifies the National Bank of Ukraine of a significant cyber incident in a preliminary report within 24 hours, an interim report within 72 hours, and a final report within a month. More on NBU requirements: NBU cybersecurity compliance.

• NBU Resolution No. 143. It creates no duty to report incidents to the NBU yourself; the NBU may request information in writing. Do not confuse it with No. 178.

• Other sectors. Non-bank institutions, the public sector and Ukrainian personal data law are outside this article. Check your own position.

European Union

• NIS2, Article 23(4). An early warning within 24 hours of becoming aware of a significant incident, an incident notification within 72 hours, and a final report no later than a month after the notification. The directive sets the frame; the channel and details come from the national law of the member state that regulates you, so check each country separately. See NIS2 compliance.

• DORA (EU financial entities). Initial notification within four hours of classification and no later than 24 hours from becoming aware; intermediate report within 72 hours; final report within a month (Delegated Regulation 2025/301, Article 5). If you are an ICT supplier to such an entity, its clock starts when it learns of the event, and your contract needs to make sure it learns in time. See DORA compliance.

• GDPR, Article 33. A personal data breach must be notified to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless it is unlikely to result in a risk to people's rights and freedoms. If you are later, explain why. A processor (a company handling data on a client's behalf) must tell the client without undue delay.

• The Cyber Resilience Act (CRA), for manufacturers of products with digital elements: software and devices sold in the EU. Since 11 September 2026: an early warning of an actively exploited vulnerability or severe incident within 24 hours, a notification within 72 hours, and a final report within 14 days of a fix becoming available (vulnerabilities) or within a month of the 72-hour notification (incidents). One submission through ENISA's Single Reporting Platform; it goes to the CSIRT of the country of main establishment, and ENISA sees it at the same time.

United Kingdom

• UK GDPR, Article 33. The same 72 hours, to the Information Commissioner's Office (ICO).

• FCA policy statement PS26/2 (from 18 March 2027). A single set of rules for reporting operational incidents, covering firms with FCA permissions, payment service providers and others. Most firms file one short report with no updates. A narrower group follows an enhanced scheme: an initial report as soon as practicable (the FCA expects it within 24 hours of establishing that a threshold is met, and says not to wait for that limit), updates after significant changes, and a final report within 30 working days of resolution. Payment service providers file the initial report within four hours of first detecting the incident. Firms also submit a register of material third-party arrangements annually.

• The Cyber Security and Resilience Bill. Not yet law, so we give no figures.

Canada

• PIPEDA, section 10.1. A breach of security safeguards that creates a real risk of significant harm must be reported to the Privacy Commissioner, and the affected people must be told. The report is due "as soon as feasible" after the organisation determines that the breach has occurred. The Act sets no hour count.

• OSFI (federally regulated financial institutions). Report a technology or cyber security incident within 24 hours, or sooner if possible.

• CCSPA (the critical cyber systems protection law). Royal Assent was given on 15 June 2026. A designated operator reports an incident to the Communications Security Establishment within a period set by regulation, not exceeding 72 hours, and straight afterwards tells its regulator. Check whether the reporting provisions are in force when you plan. The wider picture: Canadian data breach notification.

United States, for completeness

CIRCIA will require reports of covered cyber incidents (72 hours under the statute) and ransom payments (24 hours). CISA has not finished the rule, and until it takes effect there is no duty to report under CIRCIA.

Why five separate processes fail

Typically the Ukrainian office informs the NBU, a lawyer in Brussels prepares a CSIRT report, a manager in London writes to the ICO, and each takes facts from their own chat thread. Two regulators then receive two versions: "access, no data taken" and "data exfiltrated". Once they compare notes, the question is no longer the deadline but trust.

The answer is not five procedures. It is one fact base and one classification, from which the reports are assembled as different views of the same record.

One process that covers every deadline

What follows is our recommendation, not the requirement of any rule. The decision at the entrance is made once; only the addressee and the form differ.

1. One starting point

Assign a role that records "when we became aware" and "when we classified", in a shared log rather than private messages. For every regime on the map, those times are the base from which the deadline is counted. Note also when the information reached someone with authority to classify: the gap between "the administrator saw it" and "management knows" often eats the most time.

2. Classification in a few questions

A short questionnaire, completed by the incident manager within the first hour. Sample questions:

• Is personal data involved, and whose (EU, UK, Canadian, Ukrainian residents)?

• Are services to clients that are financial institutions or critical infrastructure operators affected?

• Does it involve a product we sell in the EU, or a vulnerability in one?

• Which legal entity, in which country, is affected?

• Is there any sign of a ransom payment?

The output: the regimes whose clock is already running, and when the nearest one expires. Add a rule: "we don't know" counts as "yes" until you find out.

3. Who decides

You need three names, each with a deputy:

• Incident manager. Keeps the timeline and completes the questionnaire.

• Decision-maker on notification. Usually the CISO or a senior manager, free to say "we notify" without further approvals.

• A lawyer or external adviser on call. Confirms which threshold has been crossed and checks the wording.

The decision-maker must be reachable around the clock: an incident at 22:00 on Friday cannot wait for Monday.

4. The matrix and the templates

The matrix lives in your internal documentation. One row per regime: regulator, when the clock starts, the deadline, the submission channel, who files, a link to the template, and whether the client has to consent. A sample row: "NBU, significant incident, 24 hours from determination, filed by the CISO, template so-and-so".

Build templates as a core plus adapters. The core: what happened, when it was detected, which systems and data are affected, the impact on clients, what has been done, contacts. An adapter adds the fields one regulator requires. The core is completed once, so the reports cannot drift apart.

Keep an "incomplete" first version too: early reports need what is known, not a finished investigation, so the template must allow "unknown, investigating".

5. A decision log

The log is not only a timeline of events. Record each decision: what was known, who decided, what and why. Above all record "do not notify" decisions: if you judge that a threshold is not met, note what the conclusion rests on. GDPR requires reasons when a notification is later than 72 hours, and the log also feeds the final report.

6. Rehearsal

Once a year, run a tabletop exercise (a scenario discussed around a table, with no real actions). Ask: who decides? Which regimes switch on? Who gets the first message? It often shows that nobody covers weekends, or that a supplier contract has no notification deadline. Better to learn that in an exercise.

A hypothetical example

A Kyiv company builds a cloud platform for financial institutions; its clients include an EU bank and a UK payments firm. On Friday at 22:10, monitoring detects unauthorised access to a database holding the bank's customers' personal data. At 22:40 the incident manager records the starting time and completes the questionnaire: personal data of EU residents (GDPR, the company acting as processor), an EU financial-institution client (DORA, its clock starts when it learns of the event), a UK payments client (its own rules). The CISO decides within the hour to notify clients, who receive a message built from the core template and then file their own reports. The times and sequence are illustrative; the point is that each step was written down in advance.

Common mistakes

• Counting from the start of the attack rather than from the moment the rule specifies. It gives a false sense of how much time you have.

• Waiting for a "single window". The CRA has such a platform; the other regimes still require separate reports.

• Relying on suppliers without a contract. If your client has to tell its regulator within hours and you tell it "when we've sorted it out", it will be late.

• Starting from a regulator's template rather than from the fact base. The reports then diverge.

• Having no one responsible at weekends.

• Forgetting that people stay quiet. The clock cannot start until the employee who noticed something odd speaks up; make that safe.

Where to start

Not with a new tool. Take a past incident, or an invented one, and walk through it: when did we become aware, who classified, which regimes switched on, who filed, how long it took. That shows where the process is weakest. Then build the matrix for the regimes that apply to you, and name three people with deputies.

If you would like to go through which clocks could start for your company, and whether you have the people and templates, we can help build the process within cybersecurity risk management. Let's talk.

Frequently asked questions

When does the clock start?

It depends on the rule. GDPR, NIS2 and the CRA count from the moment the organisation became aware. DORA has two anchors: four hours after classification and no later than 24 hours from becoming aware. The FCA expects a report once the firm has established that a threshold is met. So record both moments.

Do I have to tell every regulator about every incident?

No. Each regime has a threshold: a "significant" incident under NIS2, a "major" one under DORA, a risk to people's rights under GDPR, a "real risk of significant harm" under PIPEDA. Classification establishes which have been crossed.

What if we still know very little?

File what you know and state clearly what you do not. Early reports (the NIS2 early warning, the DORA and FCA initial reports) are designed for incomplete information; fuller detail follows later.

Can I file one report with all the authorities?

Usually not. The CRA is the exception: a manufacturer makes one submission through a single platform, and the CSIRT and ENISA receive it. Under the other regimes you report to each addressee separately, which is why one core set of facts helps.

Who in the company should decide to notify?

Someone with the authority to say "we notify" without a long approval chain: often the CISO or a member of management, with legal support. What matters is that they are reachable around the clock and have a deputy.

Does this apply to a small business?

It depends on the regime. Many requirements are tied to sector, size or type of data, while GDPR applies whatever your size if you process personal data. Start with the questions above and confirm the answers with a lawyer.