GDPR Article 32: The Fine for the Security Test You Didn't Run
Sweden fined Miljödata under GDPR Article 32 for skipping software testing and real-time monitoring — not for the breach. Why 'appropriate measures' now bites.
Two GDPR decisions landed in the same 48 hours this week, and only one of them made the headlines. On 21 September Ireland's Data Protection Commission fined Google €403 million over how it processed location data — the number everyone quoted. The one that should worry every CISO is smaller and quieter: on 22 September Sweden's regulator fined the software supplier Miljödata roughly $183,000 after a breach that exposed 2.2 million people. The regulator did not fine Miljödata for being breached. It fined them for the specific security controls they never had in place before the breach — and it named them.
That distinction is the whole story. GDPR enforcement is quietly shifting from "you leaked data, here is a penalty" to "your technical measures were inadequate under Article 32, and we can point to which ones." The second framing is far more dangerous, because it means the fine no longer waits for the worst-case breach. It waits for a regulator to look at your control set and find a gap.
What the Swedish regulator actually penalised
Miljödata builds HR and work-environment systems used by roughly 80% of Sweden's municipalities. In August 2025 a threat actor — later self-identifying as "Datacarry" — breached the company, disrupted services across more than 200 regions, demanded 1.5 BTC, and when the ransom went unpaid, published the stolen data. The exposed records were not marketing emails: personal identity numbers, sickness-absence and rehabilitation records, even reports of incidents involving minors.
The Swedish authority IMY, closing its inquiry a year later, grounded the penalty in Article 32 of the GDPR — the "security of processing" article. Its two named failures were precise:
- Inadequate testing of new software before it went into production.
- Lack of automated, real-time monitoring of the environment.
Read those again as an engineer, not a lawyer. The regulator did not say "you should have had better firewalls." It said you shipped software you had not adequately tested, and you had no continuous way to see an attacker moving inside your systems. Those are not paperwork gaps. They are the two controls that would have (a) caught the exploitable defect before production and (b) caught the exfiltration while it was happening instead of when Datacarry published the dump.
"We weren't breached because we were careless — we were breached, and then they decided the controls were inadequate."
That is exactly the trap. Article 32 adequacy is assessed after the fact, against the state of the art at the time. A control you can't evidence you had is, for enforcement purposes, a control you didn't have.
What GDPR Article 32 actually requires
Most teams treat Article 32 as a vague "keep data secure" clause. It is more specific than that, and the specificity is where fines now live. Article 32(1) requires controllers and processors to implement "appropriate technical and organisational measures" taking into account "the state of the art," and it spells out two obligations that map directly onto the Miljödata findings:
| Article 32 clause | What it actually demands | Miljödata's gap |
|---|---|---|
| 32(1)(b) | Ongoing confidentiality, integrity, availability and resilience of processing systems | No real-time monitoring to detect loss of confidentiality in progress |
| 32(1)(d) | A process for regularly testing, assessing and evaluating the effectiveness of technical measures | Inadequate testing of new software before deployment |
The phrase "regularly testing, assessing and evaluating the effectiveness" is not aspirational. It is a legal obligation that has sat in the regulation since 2018, and it is now being enforced as one. An annual penetration test, filed and forgotten, is a weak answer to "regularly … evaluating the effectiveness" when the software you ship changes weekly. "State of the art" is a moving reference point: what counted as adequate testing in 2020 is not what a regulator expects in 2026, when autonomous exfiltration and same-day exploitation are the baseline threat model.
Google's €403M and the accountability trap
The Google decision, widely covered for its size, looks like a different kind of case — it concerns lawfulness, transparency and retention across Web & App Activity, Location History and Location Accuracy, not a breach. But it carries the same underlying lesson for security teams. For the Location Accuracy feature, the DPC found Google in breach of the accountability principle because it could not demonstrate that the processing was lawful, fair and transparent.
Could not demonstrate. That is the recurring word across modern enforcement: the burden is not only to be compliant but to show it, on demand, with evidence that predates the request.
"Location data can greatly enhance online service utility, but can also reveal significant private information about individuals." — Graham Doyle, Deputy Commissioner, Irish DPC
Tie the two cases together and the pattern is unmistakable. Miljödata could not evidence adequate testing or monitoring. Google could not evidence lawful processing. In both, the missing thing was not the control in the abstract — it was a defensible, contemporaneous record that the control existed and worked. Enforcement has moved to the evidentiary layer.
GDPR Article 32 is now an enforcement priority, not a checkbox
This is not an isolated Swedish quirk. The same "measure the effectiveness of your controls, continuously, and be able to prove it" obligation is being written into every regulation a European operator answers to at once:
- NIS2 Article 21 requires "policies and procedures to assess the effectiveness of cybersecurity risk-management measures" — the same testing-and-evaluation language, now with management personally accountable.
- DORA goes further for financial entities, mandating threat-led penetration testing (TLPT) on a defined cadence, with the results retained as supervisory evidence.
- GDPR Article 32(1)(d) underpins both, and — as Miljödata shows — is enforced on its own.
The operational problem this creates is not "which framework do we comply with." It is that a single control failure — no continuous testing, no real-time detection — is now simultaneously a GDPR fine, a NIS2 finding, and a DORA gap. One weakness, three regulators, and each one wants its own evidence bundle. Teams that manage this as three separate audit projects burn effort producing three versions of the same proof, and still cannot answer "show me the testing you ran on the release that got breached, and show me you saw the exfiltration."
Where the evidence actually has to come from
The Miljödata decision is worth reading closely because the regulator, perhaps unintentionally, wrote a two-line specification for what "appropriate measures" means in 2026: test software before it ships, and monitor the running environment in real time. Everything defensive follows from closing those two gaps with evidence you can put in front of an auditor.
This is the operational question Zero Hunt is built to answer, and Article 32 frames it more cleanly than any marketing brief could. The "regularly testing … the effectiveness" obligation is met by continuous, change-triggered validation rather than an annual snapshot: Zero Hunt's 10-agent offensive engine runs a full campaign against a new or changed asset within the hour it appears on the perimeter, so the "did we test this release" question has a signed answer before the release is the one in the incident report. The "real-time monitoring" gap is exactly what the on-appliance AI Traffic Analysis model addresses — four parallel inference heads reading the wire for exfiltration and lateral movement while it happens, not in the next morning's log review, which is precisely the window Miljödata lacked when Datacarry was staging its dump.
What turns both into a defence against an Article 32 finding is the evidence layer underneath: every scan, finding and remediation is mapped continuously across 32 frameworks — GDPR, NIS2 Title 13, DORA including the 2025 TLPT RTS, ISO 27001 — and ECDSA-signed at write time, so the record is contemporaneous and verifiable by construction. When a regulator asks Miljödata's question — prove your testing was adequate and prove you would have seen this — the answer is a signed bundle with a timestamp that predates the request, not a scramble to reconstruct what the control set looked like a year ago. The fine, increasingly, is not for the breach. It is for the evidence you could not produce. That is the gap worth closing before the letter arrives.
If you are mapping this against your own obligations, our note on continuous testing under NIS2 and DORA works through the cadence question in more depth. To see the evidence model against your environment, get in touch.