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, into which your technical and organisational measures expressly feed.

State of the art (Art. 25(1), Art. 32(1)). Both in the selection of processing means and in ongoing security, the GDPR requires you to take the "state of the art" into account. A component that has received no security updates for years or whose upstream is orphaned does not hold that standard on its own: either you take over maintenance, or you replace it.
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 takes exactly that permanence with them. 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. Backups, standby systems, and restart procedures get you back into operation. You can only work safely again once someone closes the exploited gap — and that takes someone able to patch the component.
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. The supervisory authority has to establish the infringement — your diligence is yours to evidence. Without documentation, you have no line of defence in proceedings.

Why this particularly affects old software #

Outdated or unmaintained software is widespread in day-to-day operations — and it is among the most reliable routes into a data breach that ends in a fine. The supervisory authorities rarely criticise only one point: alongside missing security updates and patchy vulnerability management, their decisions regularly cite inadequate access controls, missing attack detection, or failures to delete data. The five cases below show how varied these failings are — and how expensive.

Advanced Computer Software Group, 2025 (ICO, GBP 3.1 million). The ransomware attack began through a customer account without multi-factor authentication. To escalate privileges, the attackers most likely used the Zerologon vulnerability (CVSS 10.0), known for around two years and with a patch 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, and — depending on the product — 18 to 284 days of unavailability for customers. ICO decision.
Dedalus Biologie, 2022 (CNIL, EUR 1.5 million). A medical software provider failed to adequately protect the health data of around 500,000 people, including during a data migration. The CNIL based the fine on Art. 28, 29, and 32 GDPR — an object lesson in processor liability, here under Art. 28(3) among others. CNIL decision.
British Airways, 2020 (ICO, GBP 20 million). After gaining entry through a remote access route, attackers injected malicious code into a JavaScript file. Personal data of more than 400,000 people was affected. The supervisory authority found a breach of Art. 5(1)(f) and Art. 32: access controls and attack detection were inadequate, among other failings. ICO decision.
Deutsche Wohnen SE, 2019 (Berlin Commissioner). The IT systems were not adapted in time to delete personal data within the required periods. Berlin Regional Court I set the fine at EUR 900,000 on 9 June 2026; at the time of that announcement the judgment was not yet final. Court statement.
Morele.net, 2024 (Polish UODO, over PLN 3.8 million). After the 2019 decision was annulled, the authority imposed a fine again. The findings included missing two-factor authentication and inadequate monitoring. UODO statement.

The shared pattern: the technical and organisational safeguards were not sufficient, and nobody in the organisation had a complete view of its own software estate. Patch and vulnerability management is the part of that risk you can close systematically — and that is the task OTTRIA takes on for your open source dependencies.

Documented diligence bears on the level of a fine #

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 brings mitigating circumstances into the assessment. Whoever produces nothing forfeits that room — within a range of 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 turns on your SBOM #

Art. 33(1) requires notification of a data breach without undue delay and, where feasible, within 72 hours of becoming aware, unless a risk to data subjects is unlikely. Art. 33(3) specifies the information the notification must contain: categories and approximate number of affected data records, likely consequences, countermeasures taken. Art. 33 does not require an SBOM for this. In practice it decides whether you can assign affected components, data categories and measures in progress within hours, or whether you keep supplying information for weeks under Art. 33(4).

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 the software products it covers: an SBOM covering at least the top-level dependencies, and as a rule at least five years of security support. What the legislator expressly demands there shapes what counts as appropriate security in GDPR proceedings too.
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 covers the destruction or corruption of data not used for professional purposes. 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. A maintained SBOM, a traceable remediation history, and demonstrable diligence in component selection are what you can actually produce to a supervisory authority on Art. 32.

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): Art. 25/32 measures as a factor in setting the fine
Art. 83(4): Fine framework up to EUR 10 million / 2%
Art. 83(5): Fine framework up to EUR 20 million / 4%