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 — is a controller within the meaning of the GDPR. 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 additionally liable as processors under Art. 28 and must provide "sufficient guarantees" of appropriate technical and organisational measures to their clients.
The three core technical requirements #
State of the art #
Art. 25(1) and Art. 32(1) both require "the state of the art". The term is deliberately dynamic: what is state of the art today will not be in 18 months. A component without ongoing maintenance falls out of this standard sooner or later — without any external event, simply through the passage of time.
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 breaks this guarantee without the controller even noticing immediately.
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: without evidence, the argument of "appropriate security" is worthless in proceedings.
What changes through the interplay with CRA, NIS2, and Product Liability #
The GDPR no longer stands alone. The Cyber Resilience Act specifies the state of the art for software products and makes SBOM and five years of security updates a statutory obligation. The NIS2 Directive obliges critical sectors to ensure supply chain security. The new Product Liability Directive names data loss expressly as a ground for liability.
For GDPR proceedings, this has two consequences:
- The "state of the art" under Art. 25/32 is no longer abstract but is positively defined by the CRA and NIS2. An SBOM, vulnerability management, and security updates are thus no longer best practice but an express statutory minimum standard.
- A single incident can trigger parallel legal consequences: GDPR fine under Art. 83, product liability claim for data loss, supervisory measures under NIS2, CRA penalty.
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 mitigating factor: those who can substantiate them pay less in individual cases.
72-hour notification deadline requires an SBOM baseline #
Art. 33(1) sets the deadline, Art. 33(3) defines the content: categories and approximate number of affected data records, likely consequences, measures taken. Those who do not know their software components cannot deliver a reliable report within 72 hours — and thereby incur an additional violation of the reporting obligation.
De facto reversal of burden of proof #
The accountability principle under Art. 5(2) effectively reverses the burden of proof: those who cannot demonstrate compliance with the principles are treated in proceedings as if they had not complied. This aligns with the structure of the Product Liability Directive — and makes documentation the single most important defence instrument.
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. At the time of deployment, each of these libraries was active and free of defects. Some time later, several of the following may have occurred without anyone noticing:
- An upstream project is archived because the maintainer loses interest or moves on professionally.
- A project is deleted — the author removes the repository, the package manager loses the reference. There is no obligation for an open source author to keep their project available.
- A project is set to EOL without notice. Security updates cease, even though the project still "lives".
- A project becomes unmaintained — formally active, but nobody responds to pull requests or issues any more.
None of these changes triggers an automatic alert for you. No scanner reports them because there is no CVE. For the GDPR, they are nevertheless immediately relevant: they break the guarantee under Art. 32(1)(b) of permanent resilience of systems, and they make the recoverability under (c) illusory — if nobody patches any more, there is nothing to recover.
Open source projects have no obligation to maintain their software or keep it available. 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 risk | OTTRIA service |
|---|---|
| Falling below the state of the art | Ongoing 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 dependencies | Take 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. 33 | Up-to-date SBOM with maintenance status, assignment of vulnerabilities to affected data categories |
| Processor guarantees under Art. 28 | Reliable evidence for TOMs that MSPs can present to their clients |
| Unknown transitive dependencies | SBOM evaluation and monitoring across the entire supply chain, not just direct dependencies |
What OTTRIA does not cover #
- Your role as controller or processor. The GDPR obligations lie with you. OTTRIA provides the technical and documentary basis for their fulfilment but does not itself assume responsibility under Art. 4 No. 7 or No. 8.
- Your Data Protection Officer. OTTRIA is not a DPO and does not provide advice on consent, records, data subject rights, or deletion concepts.
- Legal advice. OTTRIA provides technical governance and documentation, not legal assessment.
- Non-OSS components. Proprietary software, in-house developments, and purchased products are not covered.
- Your systems. OTTRIA does not work in your systems.
What do you present to the supervisory authority? #
In fine proceedings, the documentation decides. The more reliably you can substantiate the state of the art, the ongoing maintenance, and the measures taken, the lower the fine assessment under Art. 83(2)(d) will be.
OTTRIA delivers #
- Evidence of systematic OSS governance: processes, responsibilities, regular assessments — reliable against Art. 32(1)(d)
- Documentation of the state of the art per component: deployed version, known vulnerabilities, applied patches, maintenance status
- Remediation history for vulnerabilities: time of discovery, assessment result, remediation, effectiveness review
- SBOM with complete dependency structure, including transitive dependencies
- Evidence of ongoing monitoring and proactive maintenance, including for abandoned projects
You add #
- Your record of processing activities under Art. 30
- Your data protection impact assessment under Art. 35 (if required)
- The mapping of components to specific processing activities
- The overarching TOM documentation under Art. 32
- Your contracts with processors under Art. 28
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.
Documented due diligence is not a decoration — it is the only lever with which the fine can be demonstrably reduced in proceedings.
Download GDPR factsheet (in preparation)