Sweden's Cybersecurity Law: what boards need to know by 15 January

A law for boards, not just IT

Sweden's Cybersecurity Law (Cybersäkerhetslagen, 2025:1506) entered into force on 15 January 2026 ^[1]. It implements the EU's revised Network and Information Security Directive, known as NIS2, and places clear duties on boards and senior management ^[2].

The law covers essential and important entities in 18 sectors: energy, transport, banking and financial markets, healthcare, drinking water, wastewater, digital infrastructure, space, public administration, ICT service management, postal and courier services, waste management, chemicals, food production and processing, manufacturing of critical products, digital providers and research institutions ^[1]. A company or agency that falls within scope must register with the Swedish Authority for Privacy Protection (IMY) by 15 April 2026 ^[1].

Management approval is required for cybersecurity risk management measures, and boards must ensure staff get training ^[2]. These are not tasks to delegate and forget.

The reporting deadlines

Significant incidents must be reported to IMY in three stages ^[1]:

• Early warning: within 24 hours of becoming aware of the incident.
• Incident notification: within 72 hours, with initial assessment of severity, impact and, if known, whether it is suspected to be unlawful or malicious.
• Final report: no later than one month after the incident notification, containing a detailed description, severity, impact, identified causes and measures taken or planned.

The 24-hour and 72-hour clocks start when the organisation becomes aware of a significant incident ^[1]. That means the question is not only what happened, but when you knew it had happened.

What counts as significant

Not every incident triggers the reporting duty. The law sets out criteria for what counts as significant, including whether it has caused, or could cause, serious operational disruption or financial loss, or affected other entities or the public ^[1]. An organisation must assess each incident against those criteria.

That assessment itself becomes part of the record if the incident is challenged or reviewed later. Did the board know about it? When was it escalated? Who decided it was, or wasn't, significant?

What this means for you

If your organisation is in scope, ask these questions before the deadline:

• Have we registered with IMY by 15 April 2026?
• Has the board formally approved the cybersecurity risk management measures?
• Do we have a process for detecting, assessing and escalating incidents quickly enough to meet the 24-hour early warning deadline?
• Can we show when we first became aware of an incident, in a way nobody can quietly rewrite afterwards?
• Is there a clear chain of responsibility from detection to board level?

The law does not say how to keep the records, but it is worth deciding early. When a supervisor or an auditor asks how you met the deadlines, the answer should be straightforward.

Logs, timelines and the evidence question

Cybersecurity risk management requires systems, processes and documentation ^[2]. Part of that is logging: access logs, event logs, incident timelines. The law does not prescribe a particular logging technology, but logs are what tell you what happened and when.

The risk is that logs are kept by the same people who could change them. An administrator with the right access can edit a log entry, and without an independent record it becomes a question of trust.

A digital witness addresses that. For incident timelines, what you 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, not the record itself, so the content never leaves your systems.

When a supervisor or an auditor asks when you became aware of an incident, anyone you share the timeline with can check that it is exactly what was recorded at that time, unchanged since. Internal audit, supervisors and incident responders can verify it independently.

What it doesn't do: it doesn't replace your incident response process, your monitoring or your backups. It shows that a timeline hasn't changed. It doesn't prove the timeline is complete or that the response was adequate.

How it works: your system sends a fingerprint of each record to WitniumChain through the REST API, the SDK or the MCP server, and gets a witness ID back. To check, anyone you share the record with calculates the fingerprint again and compares it with the sealed one. The first 2,000 witnesses a month are free. Read the docs at witniumchain.com/docs ^[3].

How it would work

1. An alert is logged at 14:22 on a Tuesday. A fingerprint of that entry is sealed immediately.
2. The incident is escalated at 16:48 and the decision note is sealed.
3. The early warning is sent to IMY at 10:15 the next day, within 24 hours, and that submission is sealed.

If the timeline is questioned six months later, each sealed fingerprint can be checked against the current record. A match shows nothing has changed. Change one character and it won't match.

What to watch

The law is in force. The registration deadline is 15 April 2026 ^[1]. IMY has published guidance on its website, and further technical standards may follow at EU level.

For entities that also fall under DORA, the Digital Operational Resilience Act, there is overlap in the incident reporting requirements. DORA applies to financial entities from 17 January 2025 and has its own deadlines ^[4]. An incident that triggers both sets of rules must be reported under both.

The next question for many boards will be whether the documentation and logging systems can actually deliver what the law expects, not just on paper but on the day someone asks.