In every incident debrief, the same questions arise. Why didn't automated alerts fire? What does "real-time monitoring" mean in practice? And most importantly, what should your team have been watching that you weren't?
The Miljödata breach offers a concrete case study. Sweden's data privacy regulator, IMY, fined the IT systems provider $183,000 after a breach affected 2.2 million people, exposing sensitive data like personal identity numbers and school incidents involving minors. The regulator found Miljödata violated GDPR Article 32(1) by failing to maintain adequate technical and organizational security measures. Two failures stood out: inadequate checks when installing new software and the absence of automated, real-time monitoring to detect intrusions and suspicious activity.
Here's what you need to know to translate that regulatory language into operational requirements.
Do You Really Need "Real-Time" Monitoring?
You need automated detection that runs continuously, not batch jobs that run overnight. Real-time means your systems generate alerts when defined conditions occur, without waiting for scheduled scans.
GDPR Article 32(1) requires security measures "appropriate to the risk," including the ability to detect security incidents. For systems handling sensitive personal data, daily review won't meet that standard. In the Miljödata case, the attacker demanded 1.5 Bitcoin (valued at $168,000 at the time), just under the eventual regulatory fine. Timing is critical. If you're discovering intrusions a day late, you've already lost negotiating time and containment opportunities.
Start with monitoring authentication anomalies, privilege escalation attempts, and unusual data access patterns. These events should trigger alerts within minutes.
What Does "Checking Newly Installed Software" Mean?
It means documenting and validating software before it touches production systems, especially if those systems process regulated data. IMY specifically cited Miljödata's failure to perform sufficient checks when installing new software.
Your pre-deployment checklist should include: source verification (is this the legitimate vendor package?), integrity validation (does the hash match?), vulnerability scanning (are there known CVEs?), and configuration review (does it introduce new attack surfaces?).
This isn't about perfection. It's about demonstrating that you applied appropriate technical controls before introducing new code into environments containing sensitive data. If you're installing software without documenting what you checked and what you found, you can't show a regulator that you met Article 32(1)'s requirement for appropriate security measures.
How Do You Prove "Adequate" Monitoring?
Documentation beats good intentions. You need evidence of three things: what you're monitoring, how you respond when alerts fire, and that the system actually works.
Your monitoring scope should map to the data you're protecting. For systems containing personal data covered by breach notification requirements, document monitoring for: unauthorized access attempts, data exfiltration indicators, configuration changes to security controls, and anomalous authentication patterns.
Then document your response procedures. When an alert fires for unusual data access, who gets notified? What's the escalation path? What actions do you take within the first hour?
Finally, test it. Run tabletop exercises where you simulate an intrusion scenario and verify that your monitoring would detect it and your team would respond appropriately. Keep those exercise records. When IMY investigated Miljödata, they looked for evidence of monitoring systems that could detect intrusions and suspicious activity. If you can't show what you monitor and how you respond, you can't demonstrate adequacy.
Does Being a Vendor Change Your Monitoring Obligations?
Yes, and the Miljödata case illustrates why. The company provided work environment and HR management systems used by 80% of Sweden's municipal systems. When their security failed, over 200 regions faced service disruption and data exposure.
IMY launched separate investigations into two municipalities and one region in connection with the Miljödata attack. Those investigations are ongoing, which means downstream customers may face their own penalties for relying on a vendor with inadequate security.
If you're processing data on behalf of other organizations, you're likely a data processor under GDPR. Article 32(1) applies to both controllers and processors. Your customers will ask for evidence of your security measures during vendor assessments. "We have monitoring" won't satisfy them. They'll want to see: what events you monitor, how quickly you detect incidents, how you notify them of security events affecting their data, and evidence that your monitoring actually works.
What's the Minimum Viable Monitoring Setup?
There's no safe minimum, but there is a defensible baseline. Focus on detective controls for the specific risks your data creates.
For systems containing sensitive personal data, implement: authentication monitoring that detects credential misuse, access logging that records who touched what data and when, change detection for security configurations, and network monitoring for unusual outbound traffic patterns that could indicate exfiltration.
The "automated" and "real-time" requirements matter. Manual log review once a week won't meet Article 32(1). You need systems that generate alerts without human intervention and that detect events as they occur.
The Miljödata case shows what happens when you skip this baseline. The breach affected 2.2 million people, exposed highly sensitive data including minors' school incidents and health information, and resulted in both a regulatory fine and a ransom demand. More importantly, the company couldn't demonstrate it had appropriate controls in place to detect the intrusion as it happened.
Where to Start Building Your Monitoring System
Start with GDPR Article 32(1), which requires security measures including "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services" and "the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident." Those aren't suggestions. They're legal requirements if you process EU personal data.
Then map those requirements to your actual systems. What data do you process? What would constitute a breach? What technical controls would detect that breach in progress?
Your cyber insurance underwriting questionnaire likely asks about monitoring capabilities. Those questions aren't random. Insurers know that organizations without detection capabilities face higher breach costs and longer dwell times. If you're struggling to answer those questions, you're probably not meeting Article 32(1) either.
Finally, document everything. When IMY investigates, they'll ask what you monitored, how you monitored it, and whether it worked. If you can't produce that documentation, you can't demonstrate adequate security, regardless of what you actually had in place.
