Norway's aid agency breach shows why *incident timelines* matter

When the clock starts

Norad, Norway's development aid agency, disclosed on 5 November 2026 that a cyberattack on its Grants Portal may have swept up the names and email addresses of 20,614 registered users ^[1]. The portal is used by both Norad and Norway's Ministry of Foreign Affairs to collect funding applications for aid projects.

The disclosure itself is routine. What makes it worth looking at is the question it doesn't answer: when did Norad know?

Under the Cybersecurity Act, in force in Sweden since 15 January 2026, essential and important entities must send an early warning within 24 hours of becoming aware of a significant incident ^[2]. Becoming aware means what it says. The clock starts when someone in the organisation notices something is wrong, not when the forensic report lands or when senior management agrees on a press line.

Think of it like losing your bank card. The question isn't when you worked out where you lost it, it's when you noticed it was gone. That's when you're supposed to ring the bank.

What the law asks for

The Cybersecurity Act sets three deadlines. First, an early warning within 24 hours of becoming aware ^[2]. Then an incident notification within 72 hours, with what you know so far. Finally, a final report within a month, with lessons learned.

Each deadline counts from when you became aware, and supervisors will ask how you know when that was. A timestamp on an email won't do if someone could have edited it later. A Slack message can be deleted. A note in a shared document can be quietly changed.

The law doesn't say how to prove when you knew. It just says you have to report on time, and if you're late you'd better be able to show why.

The evidence gap

Most organisations keep some sort of incident log. The problem is that the people who keep the log are the same people who might later wish they'd written something different.

Say detection happens at 14:23 on a Tuesday. The team logs it, investigates, escalates and sends the early warning at 16:00 on Wednesday, 25 hours and 37 minutes later. Six months later, a supervisor asks why it was late. Someone with access to the incident log could, in theory, change the detection time to 15:30 on Tuesday. Now it looks like the warning went out in time.

Nobody plans to do that. But when a regulator is asking questions, the temptation to tidy up the record is there. And even if nobody touches it, how do you show that nobody did?

How a digital witness would work here

This is where a digital witness fits. The thing to seal is each step of the incident as it happens: the first detection note, the decision to escalate, and each report as it is sent.

Sealing takes a fingerprint of the record, not the record itself, so the content never leaves your systems. The fingerprint goes to WitniumChain, and you get a witness ID back. Later, anyone you share the record with can calculate the fingerprint again and check that it matches the sealed one. Change a single character in the record and the fingerprint changes completely.

Internal audit, supervisors and incident responders can check the records. What the witness shows is when each step was recorded, in a way nobody can quietly rewrite afterwards. What it doesn't show is that the response was adequate or that the report was complete. Those are separate questions.

Your system can seal records through the REST API, the SDK or the MCP server, and the first 2,000 witnesses a month are free. Full details are in the docs.

How it would work

1. Detection: the first analyst to spot the anomaly logs it and seals the note. Time: 14:23, Tuesday.
2. Escalation: the incident manager decides to escalate and seals that decision. Time: 15:10, Tuesday.
3. Early warning: the report is sent to the supervisor and sealed. Time: 16:00, Wednesday.

Six months later, the supervisor asks for the timeline. You share the sealed records. The supervisor checks them and sees that nothing has changed since each step was taken.

What this means for you

If you run an essential or important entity under the Cybersecurity Act, ask yourself three questions.

First, who in your organisation decides when you became aware of an incident? That decision starts the clock, and it needs to be documented as it happens, not reconstructed later.

Second, where do you keep the records of detection, escalation and reporting? Are they in a system where someone with the right access could change them?

Third, if a supervisor asked you to prove when each step happened, what would you show them? A log you keep yourself is a start. A log you can prove hasn't been edited is better.

What to watch

The Cybersecurity Act applies to essential and important entities across 18 sectors, including energy, transport, healthcare, digital infrastructure and public administration ^[2]. The 24-hour deadline for early warnings has been in force since 15 January 2026.

The EU Cyber Resilience Act, which covers products with digital elements, will require manufacturers to report actively exploited vulnerabilities and severe incidents within 24 hours of becoming aware ^[3]. That regulation enters into force in December 2027, with the reporting duty applying from December 2030 for most products.

Both laws count the hours from awareness, not from certainty. The sooner you seal each step, the clearer the timeline.