Denmark's 8.8 million-record breach raises the evidence question

What happened

Denmark is investigating a data breach at the country's national population register, known as the CPR register. Unauthorised users accessed the system, which holds data on approximately 8.8 million people: names, addresses, civil registration numbers and other personal information.^[1] The incident was first reported by The Record on 7 January 2025, citing Danish authorities.

The CPR register is maintained by the Danish Agency for Governmental IT Services and is central to public administration, healthcare and finance in Denmark. Nearly every resident is in it.

The reporting timeline

Under GDPR Article 33, a controller must report a personal data breach to the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it.^[2] The regulation says the notification must include when the breach occurred and when the controller became aware of it.

In Denmark, the cybersecurity law has applied since 15 January 2026.^[3] Essential and important entities must send an early warning within 24 hours of becoming aware of a significant incident, an incident report within 72 hours and a final report within one month. The clock starts when they became aware.

That puts a weight on logs. If someone later questions the timeline, the evidence is usually in the access logs, authentication records and detection alerts.

What logs can and cannot do

Logs show who accessed what, from where and when, assuming they are kept properly. The problem is trust. The organisation that keeps the logs is also the one that could change them.

Say an auditor or a supervisor asks why the early warning went out after 30 hours instead of 24. The organisation points to the detection log. But the log is kept by the same people who wrote the report. A sceptical examiner might wonder whether the timestamp was adjusted afterwards.

Access controls and monitoring reduce that risk, but they don't eliminate it. Someone with administrator rights can edit a log, and in a crisis those rights tend to be used.

How a digital witness helps

A digital witness seals log segments as they are written. The idea is simple: you take a fingerprint of each segment, seal it on a chain where any later change would show, and keep the record. If the log is questioned, anyone you share it with can calculate the fingerprint again and check it against the sealed one. Change a single character and it won't match.

For an incident like this, the thing to seal is each log segment at short intervals, say every few minutes, covering detection alerts, access records and incident response actions. The log itself stays in your systems; only the fingerprint is sealed.

Who can check it? Internal audit, supervisors and incident responders. They don't have to trust whoever keeps the log. They can check it.

What it shows: that a log segment hasn't changed since it was sealed, even by someone with administrator rights.

What it doesn't do: it doesn't replace access control, monitoring or backups. It doesn't show that the log is complete, or that the response was adequate. It shows that what you have now is what was written then.

Your system sends a fingerprint of each segment to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. To check, anyone you share the log with calculates the fingerprint again and compares it with the sealed one. The first 2,000 witnesses a month are free.

How it would work

1. Seal each log segment as it closes, for example every five minutes.
2. If the timeline is questioned, share the sealed segments with the examiner.
3. They calculate the fingerprint and compare it with the sealed one, without having to trust your word.

What this means for you

If your organisation falls under GDPR or the cybersecurity law, here are three questions worth asking now:

1. Could we show an auditor or a supervisor exactly when we detected an incident, using logs that nobody can say we quietly edited?
2. Do our access logs and authentication records cover who accessed what, and are they protected in a way that would hold up if questioned?
3. If we had to prove we reported within 24 or 72 hours, what evidence would we point to, and would it be enough?

Incident reporting rules count the hours from when you became aware. A log you can prove hasn't changed gives you a stronger position than one you ask people to trust.

What to watch

The Danish investigation is ongoing. Watch for the final report, which should say what data was accessed, how the breach happened and when the authorities were notified.

Under the cybersecurity law, entities must send a final report within one month of becoming aware of the incident.^[3] That report must include an assessment of the incident and the measures taken.

For entities covered by the law, the next reporting deadline is the one to prepare for now, not the one that has already passed.