The question at hand
Your security budget request is on the CFO's desk. You're asking for continuous monitoring tools, automated threat detection, and enhanced software validation processes. The response: "We've never had a major incident. Can't this wait until next quarter?"
The $183,000 fine imposed by IMY against Miljödata highlights the urgency of this question. The Swedish IT provider processed data for 80% of Sweden's municipal systems but lacked automated, real-time monitoring to detect intrusions. When ransomware hit in August 2025, 2.2 million people's sensitive information was exposed, including personal identity numbers and health data. The attacker demanded 1.5 Bitcoin and published the data anyway.
The regulatory finding was clear: Miljödata violated Article 32(1) by failing to maintain appropriate technical and organizational measures. The challenge you're likely facing is determining how much monitoring is "appropriate" and when investment becomes excessive.
The case for aggressive monitoring investment
Consider the costs. Miljödata's fine was $183,000. Add incident response costs, legal fees, customer notification expenses, and reputational damage, and you're easily into seven figures. The attacker's ransom demand was $168,000, nearly matching the regulatory penalty alone.
Article 32(1) requires security measures "appropriate to the risk." When processing sensitive personal data at scale, supervisory authorities expect defenses that match the threat landscape. IMY specifically noted two deficiencies: inadequate software validation and lack of automated, real-time monitoring.
Real-time monitoring isn't just theoretical protection. It reduces detection windows from weeks to hours or minutes. Automated systems can spot anomalous access patterns, unusual data transfers, and privilege escalations that manual reviews miss. When processing millions of records, human spot-checks can't scale.
The compliance argument is straightforward: You can't demonstrate "appropriate" measures under Article 32(1) if you're blind to active intrusions. Supervisory authorities increasingly expect evidence of continuous monitoring, not just quarterly security reviews. If you can't show logs proving you detected and responded to suspicious activity, you're documenting your own negligence.
Consider the processor liability angle. If you're a processor handling data for multiple controllers, your security failures cascade. IMY noted it launched investigations into two municipalities and one region connected to the Miljödata breach. Your single point of failure becomes everyone's problem.
The case for measured, risk-based investment
Now consider the counterargument: Security spending has no natural ceiling. You can always buy another tool, add another analyst, expand another capability. Where does "appropriate" end and gold-plating begin?
Article 32(1) requires consideration of "the state of the art, the costs of implementation and the nature, scope, context and purposes of processing." Cost isn't irrelevant. A small processor handling basic contact data doesn't need the same monitoring infrastructure as a health systems provider.
Real-time monitoring tools can generate alert fatigue. Security teams may drown in false positives, training themselves to ignore warnings until a real incident gets lost in the noise. Automated systems require skilled analysts to tune them, investigate alerts, and separate signal from background chatter. You're not just buying software; you're committing to ongoing operational overhead.
Some argue that basic hygiene delivers more protection per euro spent than advanced monitoring. Patch management, access controls, network segmentation, and staff training prevent more breaches than sophisticated detection tools catch. Miljödata's failure to adequately check newly installed software suggests fundamental process gaps, not missing monitoring dashboards.
There's also timing. Implementing comprehensive monitoring during a system migration or major infrastructure change introduces complexity and potential instability. Sometimes the risk-based answer is "not yet," not "never."
Where practitioners actually land
Most security and privacy teams adopt a tiered approach. They implement continuous monitoring for systems processing sensitive personal data and scale back for lower-risk processing. The question isn't whether to monitor, but what to monitor and how aggressively.
Practical implementations typically start with:
Critical asset identification. Map which systems process Article 9 special category data, large volumes of personal data, or data for vulnerable populations. These get priority monitoring coverage.
Baseline automated detection. Deploy tools that flag obvious anomalies (login attempts outside normal patterns, bulk data exports, privilege escalations) without requiring constant analyst attention. Set thresholds that balance detection and alert volume.
Software validation protocols. Establish mandatory security reviews before deploying new software or major updates. Miljödata's failure here was procedural, not technical. Require sign-off from security teams, not just functional testing.
Logging and retention. Even if you can't afford real-time analysis, capture detailed logs. Supervisory authorities expect you to reconstruct what happened during an incident. "We don't have those logs" is not an acceptable answer.
Tabletop exercises. Test whether your monitoring would actually detect realistic attack scenarios. If your tools wouldn't have caught the Miljödata intrusion, you're paying for theater.
The supervisory authority expectation is shifting. Five years ago, you could argue that monitoring was aspirational. After Schrems II, the cascade of ransomware incidents, and cases like Miljödata, that argument no longer holds. Article 32(1) compliance now assumes some level of automated detection capability.
Our take
The Miljödata fine settles the debate for any organization processing sensitive data at scale: You need automated monitoring, and you need it before the breach, not after.
But that doesn't mean buying every tool in the security processor catalog. The right answer is risk-proportionate investment that you can actually operate. A sophisticated monitoring platform that generates 10,000 unreviewed alerts per week provides no protection and won't satisfy Article 32(1).
Start with the systems that would hurt most if compromised. Implement detection for those environments first. Ensure you have staff who can investigate alerts and procedures for acting on findings. Then expand coverage as resources allow.
The cost argument cuts both ways. Yes, monitoring tools require budget. But the alternative is betting that you'll avoid the incident that costs multiples of that investment, destroys customer trust, and hands supervisory authorities evidence of your negligence. Miljödata took that bet and lost. The 2.2 million people whose data was exposed paid the price.
If your monitoring budget request is still sitting on someone's desk, forward them IMY's decision. Sometimes the best argument for prevention is the cost of the alternative.
