A software vendor can be fined under GDPR for a breach of its customers' data

In August 2025, Miljödata, a Swedish company that sells software for handling sick leave, rehabilitation and workplace incidents, installed a new component for its firewall on a server connected to the internet. The version it installed had a known vulnerability, and the firewall supplier had published a warning about it more than a year earlier. About a week later an attacker used that vulnerability to get in, spent three days inside the company's systems before anything raised an alarm, and left with data on about 2.2 million people, by the company's own count. On 22 September 2026 Sweden's data protection authority, IMY, fined Miljödata 1.8 million kronor, about 160,000 euros 1. Miljödata handled the data mainly as a processor, on behalf of its customers, and it was fined directly: GDPR Article 32 requires the processor, as well as the controller, to keep personal data secure 2.

IMY named two failures and called both basic security measures: Miljödata did not check which version of the component it had installed, and its monitoring did not catch the intruder. Both are ordinary mistakes for a small software company, which makes the decision a useful checklist for anyone who sells software holding other people's data.

What happened at Miljödata?

Miljödata is a small company in Karlskrona with more than 300 customers. A large share of them are Swedish municipalities, regions and other public bodies, and the rest include private employers 1. When the attack became public in August 2025, Miljödata's chief executive told The Record that around 200 municipalities and regions were affected.

The attacker got in on 20 August through the firewall component, using an SQL injection, and gave itself the highest privileges on the server. It then moved between servers for three days, began encrypting them on the night of 23 August, and copied data out. Part of the data appeared on the dark web on 14 September 1.

The data covered about 20 items per person: names, contact details, Swedish personal identity numbers, job details and absence records, plus health data, rehabilitation notes and, in some cases, data about children 1.

Why was the software vendor fined when its customers own the data?

Because Article 32(1) of GDPR names both. It says "the controller and the processor shall implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk" 2. Here the controllers are the municipalities and employers, and the processor is Miljödata.

Miljödata told IMY it acted mainly as a processor, sometimes as a sub-processor (when it was sold through another supplier), and as a controller only to a limited extent. IMY did not settle which role applied to which activity. It said Article 32 binds both roles the same way, and that Miljödata designed and ran the services, so Miljödata was the one able to secure them 1.

Getting hacked is not by itself a GDPR violation. The question IMY asked, following the EU's top court, was whether Miljödata had taken the measures needed to prevent a breach as far as possible 1. The fine rests on the two basic measures it found missing.

The customers have their own cases. IMY said on 22 September that it was still reviewing two municipalities and one region in connection with the attack 3, and its letter to one of them, Region Västmanland, shows the review is about the region's own security for the data it put into Miljödata's system 4.

What did IMY say Miljödata should have done?

IMY found two failures, and said each was a basic measure given what the data was 1.

It did not check the version of what it installed

Miljödata had an approval process for new components: a needs analysis, a review of the impact on operations and security, and a decision with a manager. The process never asked which version had arrived, and Miljödata said it had no reason to ask, because the component was an expensive product from a well-known supplier.

IMY did not accept that. The server faced the internet, the component was not tested in a separate environment before going live, and the vulnerability had been public on the supplier's own website for more than a year. Checking that the right version was installed was, in IMY's words, a basic security measure, and skipping it let the attacker in.

I think this is the finding most small teams should take personally. It is easy to treat a security product as finished once it is running, because it feels like protection rather than exposure. It is also software on an internet-facing server, with versions and published vulnerabilities like anything else you install, and IMY treated it that way. In a cloud-hosted SaaS the same thing looks like a VPN gateway, a self-hosted admin panel or CI runner, or a vendor image you deployed once and never checked again.

Its monitoring did not catch the intruder

Miljödata did have security tooling. It ran an EDR tool alongside monitoring from its server provider and its own checks. IMY found the monitoring was mainly aimed at performance and availability, and that the attacker got around the virus detection, the security monitoring and the multi-factor login 1.

IMY said automatic, real-time monitoring for suspicious activity and intrusion attempts was a basic measure for this kind of data, and that earlier detection would have limited how much the attacker reached. It also noted that Miljödata set up round-the-clock security monitoring shortly after the breach, which showed the company had the capacity to do it 1.

What did not count as enough

Besides the two-factor login and the EDR tool, two more things Miljödata had in place did not change the outcome 1:

• Encryption. Attachments and free-text fields were encrypted. IMY said it limited the harm a little, but it was the minimum expected for this data, so it earned no credit.
• Its own risk assessment. Miljödata had rated the likelihood of a cyberattack as relatively low, partly because it had a limited public profile, while rating the consequences of an attack as large. IMY based the required level of security on the data itself: health records, identity numbers and data about children, for more than two million people, called for a high level of security.

How big is a fine like this for a small software company?

The 1.8 million kronor fine is about 3% of Miljödata's 2025 turnover of 58.5 million kronor 1. The maximum under Article 83(4) is 10 million euros or 2% of worldwide turnover, whichever is higher, so for Miljödata it was 10 million euros 2.

Miljödata argued for no penalty at all, or at most a reprimand (a formal finding with no money attached), on the grounds that it was the victim of a crime, had acted fast and had already strengthened its security. IMY said the breach was too serious for a reprimand and that the company had been negligent 1. (I wrote separately about what decides between a fine and a reprimand.)

Reporting the breach on time and cooperating with the investigation did not lower the fine, because the law requires both of every company. Helping customers file their own breach reports on time did not lower it either. What did lower it, to some extent, was outreach that let customers protect themselves: individual meetings with several hundred of them, information meetings, and coordinating with the association of Swedish municipalities and regions 1.

If you sell software that holds your customers' personal data, what should you check?

If an attacker gets in through a gap like Miljödata's, you can be fined yourself, and each customer can be investigated over its own security for the data it put in your product. These are the checks this decision points to:

• List every component on a server that faces the internet, including security products. For each one, record the version installed and check it against the supplier's security advisories before it goes live, then again on a schedule. The US cybersecurity agency CISA publishes a free catalog of known exploited vulnerabilities, flaws attackers are already using, and it is a good first filter. Verizon's 2026 Data Breach Investigations Report found that 31% of breaches start with an exploited software vulnerability, ahead of stolen passwords.
• Make sure your monitoring would catch an intruder, and test that it does. Logins from unusual places, new admin privileges, connections between servers that never talk to each other, and large data exports should each alert someone in real time. Having an EDR tool installed is not the test. Miljödata had one, and its first alarm came three days in, when the service broke.
• Drop "nobody is targeting us" from your risk assessment. Miljödata rated an attack as unlikely partly because few people knew of it. IMY looked at the data instead. If you hold health data, identity numbers or data about children, plan for the high level of security that data requires.
• Plan how you will tell and help each customer. Article 33(2) requires a processor to tell the controller "without undue delay" after it becomes aware of a breach 2. Your customers then have to notify their regulator within 72 hours where feasible, unless the breach is unlikely to put anyone at risk 2. Decide now who contacts each customer and what information they get. Outreach that let customers protect themselves lowered Miljödata's fine; helping them file their reports did not.
• Read the security annex of your DPA. In its review of Region Västmanland, IMY asked for the region's processor agreement and how security duties were split with Miljödata 4. If your customer gets that letter, your DPA is the document they reach for, and the law requires it to commit you to the security measures you are obliged to take 2. Make sure the annex describes what you run today, and update it when your infrastructure changes. Lawcel, the compliance tool we build, watches the documents side of that: it reads your pull requests and flags the ones that make a legal document, a DPA included, out of date. It does not check your server versions.

For what a breach then asks of the controller, including who has to be told, see the French regulator CNIL's fine against a hospital that did not tell everyone affected.