deenx-default

GDPR: State of the art, permanent and demonstrable

The GDPR is the longest-standing of the EU laws discussed here — and in many companies the one least well substantiated technically. The reason is obvious: consent, records, data subject rights, and data protection officers have been on checklists for years. The technical and organisational measures under Art. 32, however, are often described once and then rarely updated. That is precisely where the liability risk begins.

Who is affected? #

Any company that processes personal data — from employee data to customer and supplier data to log data — has to observe the GDPR. Whoever decides on the purposes and means of processing is the controller; for them the obligations under Art. 5, 25, 32, and 33 apply regardless of sector and company size. Those who process on behalf of others — MSPs, SaaS, cloud, and hosting providers, agencies, system houses — are processors for that processing and must provide "sufficient guarantees" of appropriate technical and organisational measures to their clients under Art. 28.

The three core technical requirements #

State of the art #

Art. 25(1) and Art. 32(1) both require you to take "the state of the art" into account. The benchmark is deliberately dynamic: what suffices today may not suffice in 18 months. A component without ongoing maintenance therefore drifts further from it month by month — without any external event, simply through the passage of time. What matters is not its age but whether anyone is still securing it: are security fixes arriving, is someone taking over maintenance, are other effective safeguards in place? If that question stays open, you carry the risk.

Permanent resilience #

Art. 32(1)(b) requires that confidentiality, integrity, availability, and resilience are ensured "on a permanent basis". These two words are the decisive difference between a snapshot assessment and an ongoing obligation. An abandoned open source library whose upstream has disappeared or whose maintainer no longer responds endangers that resilience — without the controller even noticing immediately. For every such component you need a plan: keep maintaining it, replace it, or shield it effectively.

Regular review and documentation #

Art. 32(1)(d) requires a process for regularly testing, assessing, and evaluating the effectiveness of the measures. Art. 5(2) additionally requires the controller to be able to demonstrate compliance with all principles. Together, this creates a de facto documentation obligation: in proceedings what counts is not that your security was appropriate, but that you can prove it.

What changes through the interplay with CRA, NIS2, and Product Liability #

The GDPR no longer stands alone. The Cyber Resilience Act makes an SBOM and, as a rule, at least five years of security support a statutory obligation for the software products it covers. The NIS2 Directive obliges critical sectors to ensure supply chain security. The new Product Liability Directive covers the destruction or corruption of data not used for professional purposes.

For GDPR proceedings, this has two consequences:

Consequences #

Fine risk of up to 4% of annual turnover #

Art. 83(5) provides for fines of up to EUR 20 million or 4% of worldwide annual turnover for violations of the principles under Art. 5 — whichever is higher. For violations of Art. 25 to 39 (including Art. 32), the framework is up to EUR 10 million or 2% under Art. 83(4). In both cases, the entire corporate group is the basis for assessment. Within this framework, Art. 83(2)(d) expressly names the technical and organisational measures taken under Art. 25 and 32 as a factor in the assessment. Effective, evidenced measures therefore bear directly on the amount. There is no fixed discount for them. But in proceedings it makes a considerable difference whether you can describe your procedures or produce them.

72-hour notification deadline: without an SBOM you lose the first week #

Art. 33(1) requires notification without undue delay and, where feasible, within 72 hours of becoming aware — unless the breach is unlikely to result in a risk to the rights and freedoms of data subjects. Art. 33(3) defines the content: categories and approximate number of affected data records, likely consequences, measures taken. The law does not prescribe an SBOM for this. The clock runs regardless. Anyone who first has to work out which components are even in use during a software-related incident files an incomplete notification and keeps supplying information for weeks under Art. 33(4). Those who know their bill of materials scope the incident on day one.

Accountability #

The accountability principle under Art. 5(2) requires you to be able to demonstrate compliance with the principles. The supervisory authority has to establish the infringement — but your diligence is yours to evidence. Produce nothing here and you have no line of defence in proceedings. That is why documentation is your single most important instrument: it shows which risks you assessed and which measures you actually took.

EOL and deletion protection for the entire supply chain #

The visible components of an application are only the tip. Beneath every product you operate — whether shop system, ERP, CRM, reporting tool, messaging platform, or internally developed application — lies a dependency chain that changes independently of you and carries the risk.

Those who operate a product think about the product. But the actually executed software is the product plus its direct dependencies plus their own dependencies — a supply chain with hundreds of nodes, regardless of whether it is documented in a `package.json`, `requirements.txt`, `go.mod`, `pom.xml`, `Cargo.toml`, `composer.json`, `Gemfile`, or in the packages of a Linux distribution. Even if every library was maintained and free of known vulnerabilities when you went live, several of the following may have occurred some time later without anyone noticing:

None of these changes triggers an alert for you: there is no CVE, so no scanner reports anything. For the GDPR they are nevertheless immediately relevant, because they undermine the permanent resilience required by Art. 32(1)(b). And they bear on the prompt restoration required by (c): backups alone get you back into operation; you can only work safely again once someone closes the gap.

An open source licence alone gives you no commitment to maintenance or availability. But the statutory obligation for permanent resilience lies with you as controller. OTTRIA closes this gap: we monitor the entire dependency chain for archiving, deletion, EOL, and de facto abandonment — and take over maintenance ourselves or provide patches as needed, so that your supply chain continues to function even when the upstream no longer exists.

What OTTRIA covers #

Liability riskOTTRIA service
Falling below the state of the artOngoing assessment of deployed OSS components including transitive dependencies
Breach of "permanent" availability (Art. 32(b))Monitoring of critical dependencies for abandonment, EOL announcement, archiving, deletion by upstream
Abandoned, deleted, or EOL dependenciesTake over maintenance or provide patches for unmaintained projects, coordinated through our network
Missing regular review (Art. 32(d))Documented evaluation cycles with remediation history per component
Accountability obligation under Art. 5(2)Audit-ready OSS governance documentation as evidence of due diligence
72-hour notification deadline under Art. 33Up-to-date SBOM with maintenance status, assignment of vulnerabilities to affected data categories
Processor guarantees under Art. 28Reliable evidence for TOMs that MSPs can present to their clients
Unknown transitive dependenciesSBOM evaluation and monitoring across the entire supply chain, not just direct dependencies

What OTTRIA does not cover #

What do you present to the supervisory authority? #

In fine proceedings, what counts is what you can produce. Substantiate the state of the art, the ongoing maintenance, and the measures taken: under Art. 83(2)(d) they expressly feed into the assessment, alongside gravity, duration, and cooperation. The more concrete your evidence, the less room there is for the assumption that you simply let the risk run.

OTTRIA delivers #

You add #

Notes on German supervisory practice #

The German state data protection authorities and the BfDI have imposed fines on multiple occasions in recent years that were expressly based on a violation of Art. 32. The reasoning is similar in each case: the controller could not demonstrate that it kept the deployed components at the state of the art, applied security updates promptly, or tracked vulnerabilities systematically. In the assessment, the absence of documented procedures is regularly cited.

In live proceedings, documented due diligence is the last lever you have left.

Schedule initial consultation

Download GDPR factsheet (in preparation)

Further reading #