Article 32(1) of the GDPR requires controllers and processors to put in place technical and organisational measures that are “appropriate” given the state of the art, the cost of implementation, and the nature, scope, context and purposes of processing. The regulation never names a technology, a framework, or a control baseline. That is deliberate: a fixed list would be outdated within a year. It is also the reason security teams struggle to answer the question a supervisory authority actually asks after an incident, which is not “did you have a firewall” but “why did you believe your measures were adequate at the time.”
This piece works through what “state of the art” has meant in practice, how to build a record that survives a post-incident review, and what belongs in the evidence file you keep ready before anyone asks for it.
The wording of Article 32(1) and the four factors regulators weigh
Article 32(1) sets four variables that together define what “appropriate” means for a specific controller at a specific point in time:
- State of the art: what is technically achievable and reasonably available to organisations of comparable size and sector, not experimental research and not the cheapest option on the market.
- Cost of implementation: proportionality between the control’s price and the risk it reduces. A five-person nonprofit and a payment processor do not face the same bar.
- Nature, scope, context and purpose of processing: a mailing list of newsletter subscribers carries a different risk profile than a database of health records or biometric templates.
- Risk to the rights and freedoms of natural persons: the outcome-focused test. Controls are judged by whether they reduced the likelihood and severity of harm to the people whose data is processed, not by whether a checklist was completed.
Supervisory authorities and national cybersecurity bodies, including Germany’s BSI and France’s ANSSI, have repeatedly pointed to recognised baselines such as ISO/IEC 27001, the CIS Controls, and NIST SP 800-53 as reference points when assessing whether a controller’s measures matched what was reasonably available. GDPR does not mandate any one of these frameworks, but auditors use them as a comparison instrument: if your controls fall well below what a mainstream framework recommends for your risk tier, you carry the burden of explaining why.
In practice, the floor that keeps coming up across guidance documents and enforcement decisions looks like this:
| Factor | Practical baseline commonly expected |
|---|---|
| Transport security | TLS 1.2 or higher on all external endpoints, weak cipher suites disabled |
| Data at rest | Encryption for special category and financial data, key management separated from the data store |
| Access control | Multi-factor authentication on administrative and remote access accounts |
| Patch management | Defined SLA by severity, commonly 15 to 30 days for critical CVEs on internet-facing systems |
| Logging | Centralised, tamper-evident logs retained long enough to support incident investigation |
How supervisory authorities have interpreted “state of the art” in penalty decisions involving unpatched systems
Across published enforcement decisions in multiple EU member states, one pattern shows up more often than any other: the gap between a patch becoming available and a patch being applied to an internet-facing system. Authorities do not need to prove a vulnerability was exploited to conclude that Article 32 was breached. They only need to show that a known, rated vulnerability sat unpatched on a system exposed to the internet for longer than a reasonable operator would have allowed.
CVSS severity scoring functions as an informal external ceiling in these assessments. A critical-rated CVE (typically CVSS 9.0 or above) with a vendor patch available for months, sitting unremediated on a system processing personal data, tends to satisfy the negligence threshold on its own. The absence of a specific product or vendor from the decision is common; the presence of a stale patch window is not. Decisions have also cited plaintext or weakly hashed password storage, missing MFA on administrative panels, and default credentials left active on management interfaces as recurring failure patterns, independent of company size or sector.
The practical takeaway for a security team is that the clock on your patch SLA is evidence, whether or not you ever get breached. A documented policy that critical vulnerabilities are remediated within a fixed window, backed by scan data showing you actually met it, is one of the strongest pieces of state-of-the-art evidence you can produce.
Documenting which measures you chose and the reasoning behind them
A control that exists without a documented rationale is hard to defend under review, because “we had a firewall” answers a different question than “why was a firewall, configured this way, an appropriate measure given this processing activity.” For each significant control, keep a short record covering:
- The risk being addressed and where it appears in your risk register or DPIA.
- The alternatives considered, including ones you rejected and why.
- The measure selected, its configuration, and the standard or guidance it aligns with.
- The residual risk accepted after the control is in place, and who signed off on accepting it.
- The review date and the person responsible for re-evaluating it.
This is where compliance mapping earns its keep: tying each technical control to the specific article or clause it satisfies, across overlapping frameworks like ISO 27001, PCI DSS, and GDPR, turns a scattered set of tickets into a record an auditor can follow. A compliance mapping view that shows one vulnerability finding satisfying evidence requirements under three different frameworks at once saves the duplicate paperwork that usually eats a compliance team’s time before an audit.
Vulnerability data is one of the better sources for this kind of documentation, because it is timestamped by construction. Platforms built for continuous vulnerability management, such as SITEY, record discovery time, triage classification, remediation action, and closure automatically as part of the scanning workflow, rather than requiring someone to reconstruct the timeline from ticket comments after the fact.
Article 32(1)(d): regularly testing, assessing and evaluating effectiveness
Sub-clause (d) of Article 32(1) is often skipped over, but it is arguably the one supervisory authorities check most closely: a process for regularly testing, assessing, and evaluating the effectiveness of your technical and organisational measures. Having encryption and MFA is not enough on its own; you have to show a recurring process that verifies those controls still work.
A defensible testing cadence generally includes:
- Continuous or weekly automated scanning of internet-facing assets, not a once-a-year snapshot.
- An independent penetration test at least annually, or after any material architecture change.
- Retesting after remediation to confirm the specific finding is closed, not just that a ticket status changed.
- Periodic review of access control lists and privileged account inventories, since access sprawl is one of the more common gaps between policy and reality.
That last point on retesting deserves emphasis, because it is where a lot of vulnerability programs quietly fail the standard. A patch deployment that returns exit code 0 tells you the command ran, not that the vulnerability is gone. Platforms that automate this phase, such as SITEY, re-test the specific finding instead of trusting the patch command exit code, which is the difference between a closure record that will hold up under scrutiny and one that will not. Building this loop into your process, and pointing to it explicitly in your retest and closure workflow, is direct evidence for clause (d) rather than an inference an auditor has to make on your behalf.
Processor obligations and the security clauses of Article 28 contracts
Article 32 does not stop at the controller’s own infrastructure. Article 28(3)(c) requires that any processor acting on the controller’s behalf also takes measures required under Article 32, and that this obligation is written into the data processing agreement. If a payroll vendor, a support ticketing tool, or a managed hosting provider touches personal data on your behalf, their security posture is part of your Article 32 exposure, not a separate concern.
A processor-facing DPA should specify, at minimum: the security measures the processor commits to, breach notification timelines to the controller (commonly 24 to 48 hours, ahead of the controller’s own 72-hour clock to the supervisory authority), audit or evidence-request rights, and the flow-down of these obligations to any sub-processor. When a processor cannot produce a current SOC 2 report or ISO 27001 certificate, the fallback is to ask directly for their vulnerability scan cadence, last penetration test date, and patch SLA. A processor that cannot answer those three questions is a gap in your own Article 32 story, regardless of what your own internal controls look like.
Tracking which vendor’s contract review is due, and which processors have outstanding security questionnaires, fits naturally into the same task management workflow used for internal remediation, since the accountability and deadline pattern is identical.
The evidence file to keep ready for a supervisory authority request
When a breach notification triggers a review, or a data subject complaint escalates into an investigation, the supervisory authority’s questions arrive fast and expect documentary answers, not narrative ones. The organisations that respond well keep a standing evidence file rather than assembling one under deadline pressure. At minimum it should contain:
| Document | What it needs to show |
|---|---|
| DPIA and risk register | Risks identified and how each maps to a control |
| Patch management policy and SLA logs | Committed remediation windows and actual time-to-fix by severity |
| Vulnerability scan and retest history | Discovery, validation, remediation, and confirmed closure timestamps |
| Access control policy and MFA enforcement records | Who can reach sensitive systems and how that is enforced |
| Penetration test reports | Independent assessment of control effectiveness |
| Incident response plan and breach log | Detection-to-notification timeline for past incidents |
| Processor DPAs and security questionnaires | Article 28 flow-down of Article 32 obligations |
The recurring problem with this file is not that the documents do not exist, it is that they live in five different systems and nobody owns pulling them together on short notice. Reporting tooling that exports the full validation trail, discovery date, AI triage classification, remediation owner, and retest confirmation, as a single package is what turns “we should be able to find that” into a document attached to an email within the hour. This is the kind of export that reporting functionality inside a vulnerability management platform is built for, and it is worth testing that export before you need it under pressure rather than during the request itself.
State of the art is not a fixed target you hit once. It is a standard that moves as attack techniques, patch availability, and industry baselines move, which is exactly why the paper trail matters more than any single control. An organisation that can show a consistent process, tested regularly and adjusted when it falls short, is in a fundamentally stronger position than one that can only point to a list of tools it purchased.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.