The Asos hack was worse than first reported, and the clock started when they knew

What happened

In October 2024, Asos told customers that 'a small number' of accounts had been accessed without authorisation ^[1]. Months later, the BBC reported that the actual figure was closer to 65,000 customers, and that significantly more information had been stolen than the company first said ^[2].

The company has not explained the difference between the two numbers. What it does show is a familiar pattern: the first story is rarely the whole story, and the timeline of who knew what, and when, becomes the thing everyone wants to see.

Why the timeline matters

When you drop your bank card in the street, the clock starts ticking the moment you notice it is gone, not the moment you get round to reporting it. Incident reporting works the same way.

Under the EU's Cybersecurity Act (NIS2), implemented in Sweden through the new Cybersecurity Act (cybersäkerhetslagen), essential and important entities in 18 sectors must send an early warning within 24 hours of becoming aware of a significant incident ^[3]. A full incident report follows within 72 hours, and a final report within a month.

The wording is careful: 24 hours from when you became aware, not from when the breach started or when you finished investigating. If you spotted unusual activity on a Tuesday morning, the early warning is due by Wednesday morning, even if you are still working out how bad it is.

That turns the incident timeline into something auditors, supervisors and insurers will want to see. When did the monitoring alert fire? When did someone escalate it? When was the report sent? And, if those dates do not line up, why not?

The problem with logs you keep yourself

Logs are like receipts: nobody cares about them until there is an argument. The trouble is, a log kept by the same people who could edit it is the first thing questioned when the argument starts.

Say a supervisor asks why the early warning went out after 30 hours instead of 24. If the only record of when you became aware is a log entry you could have quietly changed yesterday, you are on the back foot before the conversation begins. It does not matter that you did not change it. What matters is that you could have.

Access controls and monitoring are the foundation. They stop most changes and record the attempts. But they do not help when the person asking to see the log is also the person with the keys.

What a digital witness adds

This is where a digital witness fits. The thing to seal is each step 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 at that moment and stores the fingerprint on WitniumChain, a chain where any later change would show, even one made by us. The record itself stays in your systems. When a supervisor, auditor or insurer asks to see it, they calculate the fingerprint again and check it against the sealed one. If it matches, the record is exactly what was written on the day. Change a single character and it will not match.

Internal audit, supervisors and incident responders can all check it. You do not have to trust the organisation that sealed it, because the check is independent.

What it does not do is show that the report was complete, that the response was adequate, or that the timeline was reasonable. Those are separate questions. What it does is take the argument about whether the log has been edited off the table, so the conversation can be about what actually happened.

How it would work

1. Your incident management system sends a fingerprint of the detection note, the escalation record and each report to WitniumChain through the REST API, the SDK or the MCP server.
2. Each step gets a witness ID. The data never leaves your systems.
3. When someone asks to see the timeline, they recalculate the fingerprint from the record you give them and check it against the sealed one.

What this means for you

If your organisation falls under NIS2 or the Swedish Cybersecurity Act, here are three questions worth asking now:

• Could you show a supervisor exactly when your team became aware of an incident, in a way nobody could quietly rewrite afterwards?
• Do your incident playbooks say who records each step, and where that record lives?
• If an insurer asked to see the early warning you sent, would the timestamp on it hold up?

The Asos case is a reminder that the first story is rarely the last one. When the numbers change and the timeline gets questioned, the side without its own checkable records starts the conversation on the back foot.

A digital witness per step is not complicated. It is a fingerprint, a seal and a check anyone can do. What it gives you is a timeline that holds up when someone asks to see it, without anyone having to trust you.

The first 2,000 witnesses a month are free. The hard part is deciding to do it before the incident, not after.

What to watch

Sweden's Cybersecurity Act came into force on 15 January 2026, implementing NIS2 ^[3]. The 24-hour and 72-hour clocks are already ticking for essential and important entities in sectors including energy, transport, healthcare, digital infrastructure and public administration.

If you are not sure whether your organisation is covered, the Swedish Civil Contingencies Agency (MSB) and the sector supervisors have published guidance.