The Miljödata breach: what it tells municipal IT buyers about NIS2

The breach

In September 2022, someone broke into Miljödata's systems and got hold of personal data from 69 Swedish municipalities ^[1]. The attacker used stolen credentials—username and password—to access backups stored in a Microsoft cloud environment. The backups were unencrypted, so everything in them was readable ^[1].

Miljödata supplies environmental systems: registers for septic tanks, heat pumps, oil tanks and chimney sweeps. The data included names, addresses and details about private properties. It's the sort of information that municipalities handle every day and that most people assume is kept secure.

Sweden's Data Protection Authority (IMY) investigated and fined Miljödata SEK 1.8 million in August 2024 ^[1]. The fine wasn't for the breach itself—breaches happen—but for what the investigation found: the backups should have been encrypted, access controls weren't strict enough, and Miljödata's overview of its processing activities was incomplete ^[1].

Why it matters now

This happened before NIS2 applied in Sweden, but the pattern is one that the new cybersecurity regulation is built to address. Under the law that came into force on 15 January 2026, essential and important entities—including many municipalities and their critical suppliers—must manage ICT risks, including supply chain risks, and report significant incidents ^[2].

Think of it like this. You hire someone to fix your roof. If they leave a ladder leaning against the house and a burglar climbs in, you're still the one who has to deal with the police, the insurance claim and the neighbours asking what happened. Under NIS2, the same goes for IT suppliers: the entity is responsible for making sure the supplier can do the job securely, and for reporting when things go wrong.

The supply chain question

Municipalities don't write their own environmental registers. They buy systems, and those systems handle personal data and connect to municipal networks. That makes the supplier part of the chain.

NIS2 asks entities to assess the security of suppliers and service providers, and to include security requirements in contracts ^[2]. It's a fairly plain rule, but it covers a lot: who has access to what, how backups are protected, how the supplier would tell you about a breach, and what happens if they don't.

In the Miljödata case, the backups were kept by the supplier, in the supplier's cloud environment, without encryption ^[1]. The breach didn't happen because a municipality did something wrong. It happened because the supplier's setup had gaps, and 69 municipalities were exposed as a result.

The cybersecurity regulation doesn't stop breaches, but it does put the question on the table early: have you checked what your supplier does with your data, and do you have it in writing?

The reporting clock

Under the Swedish cybersecurity regulation, 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 ^[2].

The clock starts when you become aware of the incident, not when it's convenient. That's the same principle as when you lose your bank card: the 24 hours start when you notice it's gone, and the bank expects you to call straight away.

For a municipality that finds out about a breach from a supplier, the question is immediate: when did we know, and what did we do? If the supplier took three days to tell you, that's three days you didn't have. The deadlines don't care.

Sealing the timeline as it happens

This is where a digital witness fits. The thing to seal is each step of the incident response: the first detection note, the decision to escalate, and each report as it is sent. Sealing takes a fingerprint, not the data, so the incident details themselves never leave your systems.

You seal at each step. If a supervisor later asks why the early warning went out after 30 hours instead of 24, you can show the sealed record of when the first note was written, when the decision to escalate was made, and when the report was sent. The record hasn't changed, even if someone with administrator rights wanted it to.

Anyone you share the record with—internal audit, the supervisor, an insurer—can check that it's exactly what was recorded at the time. 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, they calculate the fingerprint again and compare it with the sealed one. The first 2,000 witnesses a month are free. Read the docs.

What it shows is when each step was recorded, in a way nobody can quietly rewrite afterwards. What it doesn't show is that the report was complete or that the response was adequate. Those are separate questions.

What this means for you

If you're responsible for IT in a municipality or another essential or important entity, here are three questions worth asking now:

Do you know which of your suppliers handle data that would trigger reporting duties if it were breached? The environmental register is one example. There are others.

Have you checked the contracts? Do they say how backups are protected, who has access, and how quickly the supplier will tell you about an incident?

Could you show, six months after an incident, exactly when you became aware of it and when you reported it? The deadlines are strict, and memory isn't evidence.

The Miljödata breach happened before NIS2 applied, but the lessons are current. Suppliers are part of the chain, the deadlines start when you know, and the records you keep now are the ones you'll be asked for later.