In 2026, 68% of organisations subject to NIS2 have produced a documented risk management policy. Among them, fewer than 30% have an exhaustive inventory of their third-party software components, that is, a functional Software Bill of Materials (SBOM). This gap is not trivial: it represents one of the main areas of opacity in current compliance programmes, and the first unaddressed attack surface in NIS2/DORA audits of 2025-2026 (ENISA Threat Landscape 2026).
In this article, you will learn what NIS2 and DORA actually require in terms of software inventory, why most organisations confuse an application inventory with a regulatory SBOM, and how to close this gap without redesigning your governance architecture.
The regulatory context: two directives, one converging requirement
Article 21 of NIS2 requires essential and important entities to put in place "policies and procedures regarding risk analysis and information system security". In the ENISA guidelines published in 2025, this wording explicitly covers the traceability of the software components used in critical information systems.
DORA goes further in the financial sector: the regulation requires a mapping of ICT dependencies (Article 28) including third-party providers, but also, and this is less often cited, the open source software components integrated into processing chains. An undocumented component is, from the DORA auditor's perspective, an undeclared concentration risk.
These two frameworks converge on a common requirement: know precisely what runs in your systems, where it comes from, who maintains it, and what the associated vulnerability surface is. This is the functional definition of an SBOM.
What organisations produce, and what regulation requires
The most widespread confusion opposes two types of inventory.
The functional inventory: this is what most organisations already have. It lists deployed applications, licences and major versions. It answers the question "Which software do we use?" It is produced by IT teams for asset and budget management purposes.
The regulatory SBOM: this is what NIS2 and DORA implicitly require. It lists the components of each application: open source libraries, transitive dependencies, frameworks, containers, third-party modules. It answers the question "What is the software we use built from, and who is responsible for its maintenance?"
The operational difference is major. Take a concrete example: your ERP is in your functional inventory. But what about the 847 npm dependencies of that ERP's frontend, 12 of which are maintained by open source projects dormant for 18 months? They do not appear there, yet they represent your real exposure to vulnerabilities such as Log4Shell or XZ Utils.
In 2026, 43% of cyber incidents reported under NIS2 involved a vulnerability in an uninventoried third-party component (ENISA CSIRT Network, Q1 2026). This is not a detection problem: it is a knowledge problem.
Three common mistakes in building a compliant SBOM
First mistake: treating the SBOM as a one-off project. Most organisations, when they produce an SBOM, do so as part of an audit or certification mission. The result is a static document reflecting the state of the system on a given day. Six months later, half the dependencies have changed, new ones have been added, and some have been abandoned by their maintainers. An SBOM that is not continuously updated is not a compliance asset: it is documentary debt.
Good practice: build SBOM generation into your CI/CD pipelines. Tools such as Syft, SPDX or CycloneDX can produce an SBOM with every build and version it alongside your code. The SBOM then becomes a living artefact, not an annual report.
Second mistake: limiting the inventory to direct dependencies. Transitive dependencies (the dependencies of your dependencies) represent on average 73% of the total software surface of a modern application (GitHub Advisory Database, 2025). Inventorying only the libraries you explicitly import means ignoring three quarters of your exposure.
The XZ Utils incident in 2024 was precisely of this nature: a backdoor introduced into a level 2 transitive dependency, invisible in the first-level inventories of almost all affected organisations.
Third mistake: separating the SBOM from vulnerability management. An SBOM without an associated vulnerability feed is a catalogue, not a risk management tool. The real value of a regulatory SBOM, in the NIS2/DORA sense, lies in its ability to answer the question: "If a critical CVE is published tomorrow on this library, how many systems in my scope are affected, and which are critical?"
This rapid response capability is explicitly expected under DORA (ICT incident management, Article 17) and implicitly under NIS2 (24-hour notification, Article 23). Without an SBOM connected to an automated CVE feed, answering this question generally takes several days, well beyond regulatory deadlines.
How to assess your SBOM maturity in 30 minutes
Four questions help position your organisation.
Do you have an SBOM for your 10 most critical information systems (in the NIS2/DORA sense), including transitive dependencies? If not, you have a functional inventory, not an SBOM.
Is this SBOM regenerated automatically at each deployment? If not, its freshness cannot be guaranteed to the auditor.
Is your SBOM connected to a vulnerability feed (NVD, OSV, GitHub Advisory) with automatic alerts? If not, it is not operational in an incident response context.
Can you produce, in under an hour, the list of systems affected by a given CVE on any component of your inventory? If not, your regulatory response time is at risk.
Presidio includes a software dependency mapping module connected to major CVE feeds, allowing you to centralise SBOM tracking in your NIS2/DORA compliance dashboard. Request early access →
Conclusion
Three takeaways. The functional inventory does not cover transitive dependencies, which represent 73% of your real software surface. A static SBOM produced for the audit is not a compliance asset: it is an outdated snapshot. And the ability to respond quickly to a critical CVE is an operational obligation under NIS2 and DORA, not an optional best practice.
Organisations that treat the SBOM as an audit deliverable will systematically miss the incident notification deadline on the day a critical vulnerability hits their estate. Those that build it into their development pipeline reduce that delay from several days to a few hours.
And in your context: how long would it take you today to list all the systems affected by the next Log4Shell?
Also read: Third-party governance under NIS2/DORA and Shadow IT and asset inventory under NIS2.