Back to Resources

A Swedish regulator fined a supplier 1.8 MSEK, partly for missing real-time intrusion monitoring. What that means for your databases.

Key takeaways

• On 22 September 2026, Sweden's data protection authority fined a system supplier 1.8 MSEK after a breach that affected 2.2 million people.
• One of the deficiencies the regulator named was the lack of automatic real-time monitoring to detect intrusions and suspicious activity.
• The decision is under GDPR, not the Cybersecurity Act, so it applies to any organisation that processes personal data, public or private.
• Monitoring that nobody reads, or that only covers the network edge, will not answer the questions a regulator asks after an incident.

When a regulator writes down what was missing, the list becomes a checklist for everyone else. In September, the Swedish Authority for Privacy Protection (IMY) did exactly that. Most IT teams would say they have monitoring. Fewer could show that it would have caught an intruder working inside their database servers last night.

What the regulator decided

On 22 September 2026, IMY fined a system supplier to Swedish municipalities 1.8 million kronor for insufficient security. The case goes back to a breach in August 2025. The supplier provides HR and case-management systems to a large share of Sweden's municipalities, and the breach exposed data on around 2.2 million people: personal identity numbers, contact details and sensitive information about sick leave, rehabilitation and incidents in schools. Techtidningen's summary gives the background.

IMY found that the company had broken Article 32(1) of the GDPR, the article on security of processing, and that it had acted negligently. The authority pointed to three things:

1. The technical and organisational security was not appropriate for the kind of data being processed.
2. Controls around software installation were inadequate.
3. There was no automatic real-time monitoring of the systems to detect intrusions and suspicious activity.

The third point is the one worth stopping at. It is not a recommendation in a guidance document. It is a finding in a sanction decision.

Why this matters beyond one supplier

It would be easy to read this as a story about one company and one breach. Three things make it broader.

It is GDPR, not a sector law. The decision does not depend on whether an organisation falls under NIS2 or Sweden's Cybersecurity Act. Anyone processing personal data has the same Article 32 obligation. Payroll, patient records, customer accounts and student data all live in databases, and in the Nordics a large share of them run on SQL Server.

The bar is "appropriate", and the regulator just described it. Article 32 has always asked for security appropriate to the risk. It has rarely said what that means in practice. Here a regulator has said, in a concrete case, that appropriate includes automatic detection in real time. Auditors and insurers tend to pick up language like that quickly.

It lands at the same time as stricter rules. In Sweden, the detailed regulations under the Cybersecurity Act have applied since 1 October 2026, covering security measures, audits and scanning. Vinge's overview notes that organisations must also review existing supplier agreements from a risk perspective. Denmark has been under NIS2 since July 2025. The direction is the same everywhere: show that you would notice, not only that you have a firewall.

What "real-time monitoring" means for a database

Most organisations have monitoring somewhere. The gap is usually in what it covers and who acts on it.

• Network monitoring is not database monitoring. A firewall or endpoint tool sees traffic and processes. It does not necessarily see a new login with sysadmin rights, a permission change, a job that suddenly exports a large table, or a backup that quietly stopped running.
• Logs are not monitoring. SQL Server can log a great deal. If nobody reviews the logs, or they are only searched after an incident, they help with the investigation but not the detection.
• Alerts need an owner. An alert that goes to a shared mailbox at 03:00 has not been seen. Real-time only means something if the signal reaches someone, or something, that can act.
• Coverage needs an inventory. You cannot monitor an instance you do not know about. In estates without a dedicated DBA it is common to find instances that were installed with a business system years ago and never added to any tool.

Five questions to ask this month

1. Do we have a complete list of SQL Server instances, including the ones that came with business systems?
2. For each instance, would we be alerted automatically to a new privileged login, a permission change or a disabled audit?
3. Who receives those alerts outside office hours, and what do they do?
4. When did we last restore a backup and check that the data was usable, not only that the job was green?
5. If a regulator asked tomorrow, could we show the monitoring history for the last 90 days in less than an hour?

If any of these answers is "we would have to check", that is the place to start. None of them requires buying anything to answer.

How DB24 approaches it

DB24 is not an intrusion detection system, and real-time detection usually takes several layers. What DB24 covers is the database layer. On each SQL Server instance, DB24 uses standard SQL Server triggers to record changes to logins, server roles, databases and objects as they happen, including who made the change and the command that was run. The history is kept in a central datastore. When a new login or a server role change is collected, DB24 sends a security alert by email to the people subscribed to it. Backups are watched as well. DB24 detects, reports and alarms on backup deviations: databases that missed their backup, backup files that are older than they should be, files that deviate in size or are flagged as damaged, and jobs that quietly stopped running. Version and update status for the whole estate, and an AiQ score for each instance, are on one page.

If you want to see what that looks like on your own servers, contact us.