The GDPR and Open Source Governance

The General Data Protection Regulation has been directly applicable law since

In public perception, it is mostly about consent, privacy notices, and access rights. But the technical and organisational obligations of the GDPR are at least equally stringent — and they affect every piece of software that processes personal data, which means virtually every business application.

For open source governance, four points are central: the "state of the art", the obligation to permanently ensure integrity and availability, the accountability principle, and the fine assessment in which documented technical and organisational measures expressly count as a mitigating factor.

State of the art (Art. 25(1), Art. 32(1)). Both in the selection of processing means and in ongoing security, the GDPR requires the "state of the art". A component that has received no security updates for years or whose upstream is orphaned falls below this standard by definition.
Integrity and availability "on a permanent basis" (Art. 32(1)(b)). The wording is unambiguous: systems must be confidential, integer, available, and resilient "on a permanent basis". A maintainer who disappears breaks exactly this guarantee. A one-time selection of a component is not evidence of permanent security.
Recoverability after an incident (Art. 32(1)(c)). The controller must be able to restore data availability "in a timely manner" after an incident. This presupposes that someone can patch the affected component — immediately, not whenever a maintainer happens to respond.
Regular testing of effectiveness (Art. 32(1)(d)). The GDPR requires a "process for regularly testing, assessing and evaluating" the measures. A scan once a quarter is not an evaluation — it is a stocktake. The effectiveness of a measure can only be assessed when it is documented how identified risks were addressed.
Accountability (Art. 5(2)). The controller must be able to demonstrate compliance with the principles. This effectively reverses the burden of proof: without documentation, you have no line of defence in proceedings before a supervisory authority.

Why this particularly affects old software #

Outdated or unmaintained software is widespread in day-to-day operations — and it is the most common starting point for data breaches resulting in fines. The supervisory authorities regularly base their decisions on the fact that relevant security updates were not applied, known vulnerabilities were not remediated, or outdated components continued to be used in production.

Advanced Computer Software Group, 2025 (ICO, GBP 3.1 million). First processor fine under UK GDPR. Ransomware attack via a critical vulnerability (CVSS 10.0) left unpatched for approximately two years, despite a patch being available. The ICO expressly criticised "ad hoc patch management" and insufficient vulnerability scanning as a breach of Art. 32. 79,404 data subjects affected, NHS 111 disrupted, approximately 300 days until full recovery.
Dedalus Biologie, 2022 (CNIL, EUR 1.5 million). A medical software provider lost approximately 500,000 health records through insufficient security measures, including during a data migration. The CNIL based the fine on Art. 28, 29, and 32 GDPR — an object lesson in processor liability under Art. 28(1).
British Airways, 2020 (ICO, GBP 20 million). Attackers injected malicious code via a manipulated JavaScript library (Magecart). Personal data of approximately 400,000 customers was compromised. The supervisory authority found a breach of Art. 5(1)(f) and Art. 32: the deployment and monitoring of the component were not state of the art.
Deutsche Wohnen SE, 2019 (Berlin Commissioner, EUR 14.5 million). An outdated archiving system permitted continued storage of personal data without any deletion capability. The supervisory authority deemed this a breach of Art. 5 and Art. 25.
Morele.net, 2019 (Polish UODO, PLN 2.8 million). The online retailer had left a known vulnerability unpatched for months. The supervisory authority found a breach of Art. 32.

The pattern is always the same: the vulnerability was known, the fix was available, the organisation had neither the overview nor the capacity to apply the fix in time. This is precisely where open source governance takes effect — and precisely the gap that OTTRIA closes.

Fines are reduced through documented diligence #

Art. 83(2)(d) expressly names the "degree of responsibility of the controller [...] taking into account technical and organisational measures implemented by them pursuant to Articles 25 and 32" as a factor relevant to fines. In plain language: whoever can demonstrate that they worked systematically, with documentation, and in line with the state of the art pays less. Whoever cannot provide evidence pays the full fine — up to EUR 10 million or 2% of worldwide annual turnover under Art. 83(4), and for breaches of the principles under Art. 5 even up to EUR 20 million or 4% under Art. 83(5).

The 72-hour reporting obligation needs an SBOM #

Art. 33(1) requires notification of a data breach within 72 hours of becoming aware. Art. 33(3) specifies the information the notification must contain: categories and approximate number of affected data records, likely consequences, countermeasures taken. This information presupposes that the controller can determine within hours which component is affected, which data categories it touches, and which measures are already in progress. Without a current, maintained SBOM, this deadline is practically impossible to meet.

Processors are liable throughout #

Art. 28(1) permits engagement only with processors that provide "sufficient guarantees" of appropriate technical and organisational measures. For MSPs, cloud providers, SaaS providers, and agencies, this is a direct sales factor: whoever cannot demonstrate these guarantees loses contracts — and their clients act unlawfully if they engage them regardless.

Interaction with CRA, NIS2, and Product Liability #

The GDPR does not stand alone. Its obligations systematically overlap with the more recent EU laws:

The Cyber Resilience Act specifies the "state of the art" for software products and requires a complete SBOM plus five years of security updates — both are effectively GDPR-relevant minimum requirements.
NIS2 obliges critical sectors to implement supply chain security. A breach of Art. 21 NIS2 is, in a damage case, simultaneously strong evidence of a breach of Art. 32 GDPR.
The new Product Liability expressly names data loss as a ground for liability. The same incident can therefore lead to a GDPR fine and a product liability claim in parallel — two separate legal consequences from a single cause.

What this means for you #

Whoever processes personal data — and that is virtually every company — is responsible for the state of the art of the software used. Open source components are not a special case but the standard: they are embedded in every business application. The GDPR requires not only that these components are secure but that their security is ensured on a permanent basis and demonstrably maintained.

Documented open source governance is therefore not an optional extra alongside GDPR compliance but its technical foundation. Without a maintained SBOM, a traceable remediation history, and demonstrable diligence in component selection, Art. 32 cannot be fulfilled.

Legal references #

The key GDPR articles in this context:

Art. 5(1)(f): Integrity and confidentiality
Art. 5(2): Accountability
Art. 25(1): Data protection by design, state of the art
Art. 28(1): Sufficient guarantees by processors
Art. 32(1): Security of processing, "on a permanent basis", regular testing
Art. 33(1): 72-hour notification deadline
Art. 83(2)(d): Fine-mitigating through Art. 25/32 measures
Art. 83(4): Fine framework up to EUR 10 million / 2%
Art. 83(5): Fine framework up to EUR 20 million / 4%