SBOMs for ISO 27001, NIS2 and DORA Assurance

It is 07:42 on a Friday when Amelia, the CISO of a fast-growing FinTech, receives the alert no security leader wants to see.

A widely used open-source package has a critical remote code execution vulnerability. The software composition analysis tool says the component may exist in the authentication service, possibly in billing, and perhaps in a third-party API wrapper used by the payment workflow. Engineering needs time to confirm. Legal asks whether the NIS2 notification clock has started. The DORA program manager asks whether the affected service supports a critical or important function for a financial entity. Sales asks whether this will block a renewal. The board asks the simplest and hardest question, “Are we exposed?”

Without a software bill of materials, the honest answer is often, “We do not know yet.”

In 2026, that answer is not just a technical gap. It is a governance weakness, a contractual risk, an audit exposure and, for regulated entities, a resilience problem. SBOMs have moved from DevSecOps hygiene to board-level evidence for software supply chain assurance, ISO/IEC 27001:2022 control operation, NIS2 cybersecurity risk management, DORA ICT third-party governance, GDPR accountability and customer due diligence.

The key is not simply generating an SBOM file. The key is proving that software components are identified, approved, monitored, risk-rated, patched, contractually governed and traceable to accountable owners. That is where Clarysec’s policy library, Zenith Blueprint: An Auditor’s 30-Step Roadmap and Zenith Controls: The Cross-Compliance Guide turn a developer artifact into defensible compliance evidence.

Why SBOMs are now software supply chain assurance evidence

An SBOM is an inventory of software components, including open-source packages, commercial libraries, versions, sources, licenses and dependency relationships. A useful SBOM helps answer four questions that regulators, customers and boards now care about:

1. What is inside our software?
2. Where is it deployed?
3. Is it vulnerable, unsupported, unlicensed or unapproved?
4. Who owns remediation, mitigation or risk acceptance?

Those questions map directly to modern legal and regulatory expectations.

NIS2 applies to many medium and large entities in essential and important sectors, including digital infrastructure, cloud computing providers, data centre service providers, managed service providers, managed security service providers, online marketplaces, search engines, social networking platforms and certain digital providers. It may also apply based on national designation and sector-specific transposition. For in-scope entities, NIS2 requires management bodies to approve cybersecurity risk-management measures and oversee implementation. Article 21 includes supply chain security, secure acquisition, secure development and maintenance, vulnerability handling and disclosure, incident handling, business continuity, asset management, access control, cryptography, effectiveness assessment and cyber hygiene.

DORA, applicable from 17 January 2025, creates a uniform EU digital operational resilience framework for financial entities. It covers ICT risk management, ICT-related incident reporting, resilience testing, ICT third-party risk management, contractual arrangements and oversight of critical ICT third-party service providers. DORA expects financial entities to identify ICT assets, ICT-supported business functions, dependencies, interconnections, vulnerabilities, risk scenarios, changes and third-party-supported processes.

GDPR adds a privacy layer. If a vulnerable component affects systems processing personal data, the question becomes whether personal data could have been accessed, altered, lost, disclosed or otherwise compromised. Controllers and processors need evidence showing they can identify affected systems, data flows, sub-processors and breach impact.

NIST CSF 2.0 reinforces the same operating model through GOVERN, IDENTIFY, PROTECT, DETECT, RESPOND and RECOVER. Its supply chain outcomes expect supplier responsibilities, criticality, contractual requirements, due diligence, monitoring, incident planning and end-of-relationship provisions.

When Amelia’s board asks whether the FinTech is exposed, an SBOM-backed organization can answer with evidence:

• Which products and releases contain the vulnerable component
• Which deployed environments are affected
• Which customers, regions, functions and data flows are connected
• Which supplier or internal owner is accountable
• Which compensating controls are active
• Whether NIS2, DORA, GDPR or contractual thresholds may be triggered
• Which fix, mitigation, exception or risk acceptance has been approved

That is the difference between a component list and a control system.

ISO 27001:2022 is the backbone for SBOM governance

ISO/IEC 27001:2022 is a strong foundation for SBOM governance because it is a management system standard, not just a technical checklist. Its clauses require organizations to define context, interested parties, scope, leadership commitment, policy, roles, risk assessment, risk treatment, objectives, performance evaluation, internal audit, management review and continual improvement.

SBOM programs fail when they sit outside the ISMS. Engineering may generate files, but nobody enforces vulnerability remediation SLAs, supplier obligations, evidence retention, risk acceptance or customer disclosure rules. ISO 27001 fixes that by turning SBOMs into part of the organization’s risk management system.

Under Clauses 4.1 to 4.4, the organization determines internal and external issues, interested-party requirements, legal and regulatory obligations, contractual expectations and ISMS scope. For SBOM assurance, the scope should explicitly include:

• Products and services delivered to customers
• Cloud and SaaS production environments
• CI/CD pipelines, source repositories and artifact registries
• Open-source and commercial software components
• Outsourced development and integration partners
• ICT third-party providers and subcontractors
• Customer security requirements under DORA, NIS2, GDPR and contracts

Clauses 5.1 to 5.3 make software supply chain risk a leadership issue. Management must align security objectives with business direction, provide resources, assign responsibilities and communicate policy. Clauses 6.1.2 and 6.1.3 turn SBOM findings into risk assessment and risk treatment evidence. A critical vulnerable component in an internet-facing authentication service is not just a ticket. It is a risk scenario affecting confidentiality, integrity, availability, contractual commitments, regulatory reporting and operational resilience.

The most relevant ISO/IEC 27001:2022 Annex A controls for SBOM assurance are:

Clarysec maps these relationships through ISO/IEC 27002:2022 attributes in Zenith Controls. For example, Zenith Controls treats ISO/IEC 27002:2022 control 5.21, “Managing information security in the ICT supply chain,” as preventive, protecting confidentiality, integrity and availability, aligned to the Identify cybersecurity concept, and operating across governance, ecosystem and protection domains. It treats control 8.25, “Secure development life cycle,” as preventive and aligned to Protect. It treats control 8.8, “Management of technical vulnerabilities,” as preventive and aligned to Identify and Protect, connecting vulnerability management to governance, ecosystem, protection and defense.

That translation matters because different reviewers ask different questions. An ISO auditor may ask whether component risk is in the Statement of Applicability. A DORA reviewer may ask whether a component supports a critical or important function. A customer may ask whether unresolved vulnerabilities exceed contractual SLAs. The same SBOM evidence can support all three, if it is governed correctly.

The Clarysec policy layer for audit-ready SBOMs

A reliable SBOM program needs policy language. Developers need to know what must be recorded. Procurement needs to know what suppliers must provide. Security needs to know which findings trigger escalation. Compliance needs to know which evidence must be retained.

For smaller organizations, the Secure Development Policy - SME creates the minimum viable SBOM control:

The GM or a designated developer must maintain a list of all external components used, including: 6.6.2.1 Version and source 6.6.2.2 Known vulnerabilities or patch status 6.6.2.3 Last update or review date

That requirement is simple, but powerful. It establishes version visibility, source traceability, vulnerability status and review cadence.

The Application Security Requirements Policy - SME adds lifecycle review:

Any third-party tool, plugin, or external code library used in an application must be recorded and reviewed annually for security impact and patch status.

The Vulnerability and Patch Management Policy - SME connects SBOMs to remediation:

Developers must monitor and update third-party libraries (e.g., open-source packages)

For enterprise environments, the Secure Development Policy raises the expectation:

The use of open-source or third-party code must be approved, tracked, and validated through:

It also makes scanning mandatory:

All third-party components must be scanned for vulnerabilities before deployment and during runtime using automated tools.

Outsourced development must follow the same standard. The Outsourced Development Policy requires:

Secure use of open-source libraries, subject to vulnerability scanning and approval

Supplier contracts need enforceable evidence rights. The Third-Party and Supplier Security Policy - SME requires contract clauses covering confidentiality, security obligations, breach notification timelines, audit rights, subcontracting restrictions and secure termination:

Contracts must include mandatory clauses covering: 5.3.1 Confidentiality and non-disclosure 5.3.2 Information security obligations 5.3.3 Data breach notification timelines (e.g., within 24–72 hours) 5.3.4 Audit rights or the availability of compliance evidence 5.3.5 Restrictions on further subcontracting without approval 5.3.6 Termination terms, including secure data return or destruction

For enterprise customers, the Third party and supplier security policy includes:

Rights to audit, inspect, and request security evidence

If a SaaS provider, outsourced development partner or commercial software supplier will not provide security evidence, vulnerability status, notification commitments or audit access, your software supply chain assurance has a blind spot.

The Supplier Dependency Risk Management Policy turns dependency concentration into measurable resilience risk:

Supplier Dependency Register: The VMO shall maintain an up-to-date register of all critical suppliers, including details such as services/products provided; whether the supplier is sole-source; available alternate suppliers or substitutability; current contract terms; and an assessment of the impact if the supplier were to fail or be compromised. The register shall clearly identify high-dependency suppliers (e.g., those for which no rapid alternative exists).

That register should connect to SBOMs. If a critical library comes from a sole-source supplier, supports a regulated customer workflow and has no rapid substitute, it is not just a package. It is a resilience dependency.

From SBOM file to operational control in one sprint

A practical SBOM program should start with one product line and one production environment. Do not try to inventory the entire enterprise on day one. If Amelia’s FinTech begins with its customer onboarding and payment workflow, the team can create a repeatable evidence model before scaling.

Step 1: Define SBOM scope inside the ISMS

Create a scope statement linked to your ISMS scope and regulatory drivers:

• Product: Customer onboarding and payment SaaS platform
• Environment: EU production
• Repositories: auth-service, billing-service, payment-api, reporting-api, frontend-app
• Build systems: Git provider, CI/CD platform, container registry
• Deployment: Kubernetes cluster, managed database, object storage
• Data: account data, authentication logs, billing metadata, payment references
• Customers: EU financial entities and commercial customers
• Regulatory drivers: ISO 27001:2022, NIS2 customer assurance, DORA ICT third-party due diligence, GDPR security accountability

This aligns with ISO 27001 Clause 4 scope logic and NIST CSF Profile scoping.

Step 2: Generate and store SBOMs at build time

Configure CI/CD pipelines to generate an SBOM for every build artifact, including container images. Standard formats such as CycloneDX and SPDX are commonly used. Store each SBOM in a controlled evidence repository linked to the build ID, commit hash, deployment record and release version.

This directly supports the Secure Development Policy - SME requirement to maintain version, source, known vulnerability or patch status and review date.

Step 3: Enrich SBOM data with exploitability and business context

Do not stop at a package list. Add operational risk context:

• Is the component vulnerable?
• Is the vulnerable function reachable?
• Is the service internet-facing?
• Does the service process personal data?
• Does it support a critical or important function for a DORA customer?
• Is a patch available?
• Is there a compensating control?
• Has risk acceptance been approved by the risk owner?

A critical CVE in a test-only package is different from a critical CVE in a production authentication service. ISO 27001 risk assessment and treatment clauses help make that distinction defensible.

Step 4: Link SBOMs to supplier and outsourced development controls

If a component is provided by a commercial supplier or outsourced development partner, update the supplier record:

This supports NIS2 Article 21 supply chain security and DORA Article 28 expectations for ICT third-party risk strategy, due diligence, contractual safeguards, registers of information, audit planning, termination rights and exit strategies.

Step 5: Define remediation rules and evidence

Tie remediation SLAs to business impact, not just CVSS scores.

This is where SBOMs become useful for NIS2, DORA and GDPR. A remediation workflow should consider significant incident potential, major ICT-related incident impact, personal data breach criteria, contractual notification obligations and operational resilience impact.

Step 6: Add a release gate

Before deployment, require the pipeline or change process to confirm:

• SBOM generated successfully
• No critical unapproved vulnerabilities remain
• New third-party components are approved
• License policy has passed
• SCA, SAST, DAST or other required testing is complete
• Change ticket is linked
• Rollback plan is documented for high-risk releases

This connects A.8.25 secure development, A.8.29 security testing and A.8.32 change management into a single auditable workflow.

Step 7: Build the release evidence pack

For each release, retain:

• SBOM file
• Build ID and commit hash
• SCA scan output
• Vulnerability triage record
• Approved exceptions
• Change approval
• Deployment record
• Test results
• Supplier evidence if applicable
• Incident or problem record if the release remediated a vulnerability

When an auditor asks how third-party libraries are managed in production, Amelia’s team does not scramble through Slack threads. They open the release evidence pack.

Cross-compliance mapping: one SBOM program, many obligations

The commercial value of an SBOM program increases when it is mapped once and reused across frameworks. Clarysec’s cross-compliance approach avoids duplicate work by translating the same evidence into different assurance languages.

NIS2 incident reporting can move quickly when exploitation causes or is capable of causing severe operational disruption, financial loss or considerable material or non-material damage. NIS2 uses staged reporting, including early warning within 24 hours of awareness, incident notification within 72 hours and a final report within one month of the incident notification. SBOMs help determine whether the affected component is present, whether customer services are affected and whether cross-border impact is plausible.

DORA uses a structured ICT incident lifecycle, including detection, recording, classification, root cause analysis, escalation, communication plans, management body escalation and regulatory reporting for major ICT-related incidents. SBOM evidence supports classification because it connects a vulnerable component to affected clients, downtime, geographical spread, data losses, service criticality and economic impact.

NIST CSF 2.0 adds useful language for customer assurance. Zenith Controls maps A.5.21 to supply chain governance outcomes such as GV.SC-05, where cybersecurity requirements for suppliers are established, communicated and integrated into contracts and other agreements. Demanding SBOMs, vulnerability disclosure, audit evidence and remediation timelines becomes a contractual control, not an ad hoc request.

How the Zenith Blueprint sequences the work

The Zenith Blueprint turns control language into an implementation roadmap.

In the Risk Management phase, Step 14 connects secure development, CI/CD controls, dependency scanning, change management, incident handling and developer training. In the Controls in Action phase, Step 20 is explicit about third-party and open-source components:

This control also applies to third-party and open-source components. Relying on external libraries is standard practice, but each inclusion is a trust decision. Developers should evaluate dependencies based on reputation, maintenance frequency, known vulnerabilities, and license restrictions. Tools like SBOMs (Software Bill of Materials) are increasingly vital to track what’s embedded in your stack.

Step 21 frames security testing as context-driven and recommends layered testing for business-critical or internet-exposed systems, including software composition analysis for third-party libraries, static and dynamic analysis, penetration testing, threat modelling validation, misuse case testing, fuzzing and manual exploratory testing.

Step 23 addresses supplier agreements, including confidentiality obligations, access control responsibilities, technical and organisational measures, incident reporting timelines, right to audit, subcontractor controls and end-of-contract provisions.

The practical lesson is simple. SBOMs belong in risk management, secure development, testing, supplier governance, incident response and management reporting.

The audit lens: what different reviewers will test

A mature SBOM program must survive different audit styles.

An ISO 27001:2022 auditor will start with the ISMS. They will ask whether software supply chain risk is in scope, whether interested-party requirements include NIS2, DORA customers, GDPR and contracts, whether component risk is part of the risk methodology, whether the Statement of Applicability includes relevant Annex A controls and whether policies are implemented over time. They may sample one release and trace it from policy to pipeline, SBOM, vulnerability scan, change approval, deployment and post-release monitoring.

A DORA reviewer or financial customer will focus on operational resilience and ICT third-party risk. They may ask which components support the service used by the financial entity, whether the service supports a critical or important function, how ICT assets and dependencies are documented, whether vulnerabilities are monitored, whether annual testing covers critical systems and whether contracts include assistance, audit rights, incident notification, data location, subcontracting and termination terms.

A NIST CSF assessor will look for outcomes. Under GOVERN, they will test legal, regulatory, contractual, privacy and supply chain governance. Under IDENTIFY, they will expect asset, software and service visibility. Under PROTECT, they will test secure development and pipeline controls. Under DETECT and RESPOND, they will examine vulnerability alerts, analysis, escalation and communications. Under RECOVER, they will ask how component compromise affects restoration and customer communications.

A COBIT or ISACA-style auditor will focus on governance, accountability, risk ownership, control design and evidence reliability. They may test whether SBOMs are complete, whether vulnerability tickets close within policy, whether exceptions expire, whether supplier evidence is current and whether management receives meaningful reporting.

Common SBOM failures to avoid

SBOM programs usually fail for predictable reasons.

The first failure is generating SBOMs but not storing them as controlled evidence. If the file is overwritten with every build and cannot be linked to a release, it is weak audit evidence.

The second failure is separating SBOMs from vulnerability management. A component list without triage, ownership, remediation or risk acceptance does not prove control operation.

The third failure is excluding transitive dependencies. Vulnerabilities often hide below the direct dependency layer.

The fourth failure is leaving outsourced development outside the process. If a vendor delivers code without component disclosure, scanning evidence or approval records, the software supply chain has an unmanaged blind spot.

The fifth failure is signing supplier contracts without evidence rights. Procurement signs the agreement, engineering consumes the service and security later discovers there is no audit right, no vulnerability disclosure obligation, no subcontractor restriction and no exit support.

The sixth failure is failing to map components to business services. A vulnerable package means little until you know whether it affects authentication, payments, reporting, patient data, cloud administration, customer onboarding or a regulated financial workflow.

The seventh failure is hiding unresolved critical vulnerabilities from leadership. NIS2 and DORA both make management accountability explicit. Critical component risk should be visible to governance forums, not buried in engineering backlogs.

What good looks like in 2026

An audit-ready SBOM program has visible traits.

There is an approved policy requiring third-party and open-source components to be approved, tracked, scanned and reviewed. The CI/CD pipeline generates SBOMs automatically. SCA scans run before deployment and during runtime where applicable. Critical vulnerabilities trigger defined escalation. Exceptions have owners, expiry dates, compensating controls and risk acceptance.

Supplier contracts include security obligations, breach notification timelines, audit rights, subcontracting controls and termination provisions. Critical suppliers are reviewed at least annually. Supplier dependency and concentration risks are visible. Outsourced development teams follow the same secure development and component approval rules as internal teams.

Management reporting connects technical risk to business impact:

• Critical vulnerable components by product
• Exposure by customer or regulated service
• Open remediation beyond SLA
• Components without approved source
• Unsupported or end-of-life libraries
• Supplier evidence gaps
• Exceptions awaiting renewal or closure
• Incidents linked to component vulnerabilities

This is when SBOMs stop being a compliance artifact and become a management tool.

Turn SBOMs into defensible compliance evidence

The next time a critical component alert lands at 07:42, the answer should not be, “We need two hours to find out where it is.”

It should be, “Here is the affected component, here are the services, here are the customers, here is the risk rating, here is the remediation plan and here is the evidence.”

Clarysec can help you design that control system. We help organizations define SBOM scope inside the ISMS, map ISO 27001:2022 Annex A controls to NIS2, DORA, GDPR, NIST CSF 2.0 and COBIT-style audit expectations, implement secure development and supplier policies, build release evidence packs and prepare audit-ready assurance using Zenith Controls and the Zenith Blueprint.

Ready to turn your software supply chain from a source of uncertainty into a demonstration of resilience?

Download the relevant Clarysec policies, use the Zenith Blueprint to sequence implementation, and use Zenith Controls to map your evidence across ISO 27001:2022, NIS2, DORA and customer assurance requirements. Contact Clarysec to start with a focused SBOM readiness assessment and build a practical, audit-ready software supply chain assurance program.