SBOMs as compliance evidence: ISO 27001, SOC 2 and NIS2

Evidence is not compliance

A control is met by a process that works. Evidence shows that it works. An SBOM shows one specific thing: what a given release contained. It shows nothing about access control, incident response or whether anyone acted on a finding.

It can also be wrong in a way nobody notices. A generator that read the wrong files produces a valid SBOM that misses half the product. The vulnerability scan of that SBOM is clean, the compliance platform sees that a scan ran, and every check reads green. What a green SOC 2 SBOM check verifies walks through that failure in detail.

Evidence from an SBOM counts when it is:

1. Tied to a release. One SBOM per version you shipped, not one for the repository.
2. Complete, or says what it missed. An SBOM that states its gaps can be trusted for what it lists.
3. Kept for the period the audit covers. An auditor sampling last March needs last March's SBOM.
4. Re-checked when new vulnerabilities appear. A list that nobody compares with new advisories proves little about vulnerability management.

For what an SBOM contains, see what is an SBOM. For the secure development frameworks of industrial products and US federal software, see IEC 62443-4-1 and NIST SSDF.

ISO/IEC 27001:2022

ISO/IEC 27001 is the standard an information security management system is certified against (glossary). Annex A lists 93 controls; an organization selects the ones its risk assessment calls for and records them in its Statement of Applicability. ISO/IEC 27002:2022 gives the implementation guidance. Neither names an SBOM. The table quotes control titles only and says in short what each control is about.

Control	What it is about	How an SBOM or build record serves as evidence	What it does not cover
5.9 "Inventory of information and other associated assets"	Knowing which assets you have and who owns them	The software you ship and run is an asset. A per-release component list is the inventory of what is inside it.	Hardware, data, people and services
5.19 "Information security in supplier relationships", 5.20 "Addressing information security within supplier agreements", 5.21 "Managing information security in the ICT supply chain", 5.22 "Monitoring, review and change management of supplier services"	Managing the risk that comes with suppliers and the ICT supply chain	Two directions. As a buyer, you can require SBOMs from suppliers and monitor them. As a supplier, your SBOM is what your certified customer's supply chain process asks you for. Open source components are part of the ICT supply chain but come with no supplier agreement, which is exactly why an inventory of them matters.	Contracts, supplier assessments and reviews
8.8 "Management of technical vulnerabilities"	Getting information about vulnerabilities, evaluating your exposure and acting on it	A current component list matched against advisories and re-evaluated when new ones appear, plus a record of which releases contained a vulnerable version and since when	Patching your infrastructure, scanning hosts, and the decisions themselves
8.25 "Secure development life cycle"	Rules for developing software and systems securely	A recorded, repeatable release process: every release built in the same pipeline, with its SBOM	Most of the control: training, environments, design and review
8.26 "Application security requirements", 8.27 "Secure system architecture and engineering principles", 8.28 "Secure coding"	Requirements, design and code	Not directly. These are about what you write, not what you pull in.	All of it: code review, SAST and design records are the evidence here
8.29 "Security testing in development and acceptance"	Testing security before release	A policy gate that blocks a build on a vulnerability finding is a recorded test with a result	Functional security testing, penetration tests
8.30 "Outsourced development"	Directing and monitoring development you outsource	Outsourced code built in your pipeline gets the same SBOM and checks as your own	The contract, the supplier's own practices

Be honest about 8.25 to 8.30: most of what those controls ask for is outside an SBOM. Claiming more is the quickest way to lose an auditor's trust in the rest.

Worked example: an auditor asks about 8.8

"How do you know when a new vulnerability affects a product you have already shipped?" Here is the evidence chain for one advisory, and who provides each link.

Step	Evidence	Comes from
1. The release's contents	The SBOM of version 4.2, recorded by the build that produced it	Your build tooling
2. The advisory match	A new CVE published for a library in that SBOM, matched by its package URL	Your vulnerability monitoring
3. The exposure window	Every build that contained the vulnerable version, and the date of the first one	Your build history
4. The decision	Who assessed it, when, and the outcome: fix, mitigate or not affected, with the reason	Your process and its records
5. The fix	Version 4.2.1, whose SBOM no longer contains the vulnerable version	Your build tooling

Tools can supply steps 1, 2, 3 and 5. Step 4 is your process, and it is the step auditors read most closely.

SOC 2

A SOC 2 report states whether controls meet the AICPA's Trust Services Criteria (2017, with points of focus revised in 2022). The criteria are outcome statements. They do not name SBOMs, and two of them are where SBOMs help.

• CC7.1 asks that the entity "uses detection and monitoring procedures to identify (1) changes to configurations that result in the introduction of new vulnerabilities, and (2) susceptibilities to newly discovered vulnerabilities". Evidence: an SBOM per release, re-evaluated against new advisories, and a record of how each finding was handled.
• CC8.1 covers change management: how changes to infrastructure, data, software and procedures are authorized, developed or acquired, tested, approved and implemented. Evidence: every release built in a recorded pipeline, the change in its dependencies visible from one build to the next, and policy gates as a control on what may ship.

The criteria are being revised. In October 2026 the AICPA published an exposure draft of the 2027 Trust Services Criteria, with a targeted restructuring of the criteria, comments due by 15 January 2027 and a proposed effective date for engagements beginning on or after 31 December 2027. It is a draft, and criterion numbers may change: check the final text before you map evidence to the new numbers.

If you already run a SOC 2 platform, keep it. The question is what the SBOM behind its checks shows: SOC 2 SBOM checks compared.

NIS2

The NIS2 Directive (EU) 2022/2555 applies to essential and important entities in the sectors it lists. If you are reading this as a software or device supplier, you are usually not in scope yourself. Your customer is, and its obligations reach you as questions. Article 21 sets the cybersecurity risk-management measures, and three passages produce most of those questions:

• Article 21(2)(d): "supply chain security, including security-related aspects concerning the relationships between each entity and its direct suppliers or service providers".
• Article 21(2)(e): "security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure".
• Article 21(3): entities must take into account "the vulnerabilities specific to each direct supplier and service provider and the overall quality of products and cybersecurity practices of their suppliers and service providers, including their secure development procedures". This is the sentence that turns into a questionnaire on your desk.

Implementing Regulation (EU) 2024/2690

Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024 sets out the technical and methodological requirements of the Article 21(2) measures for DNS service providers, TLD name registries, cloud computing service providers, data centre service providers, content delivery network providers, managed service providers, managed security service providers, online marketplaces, online search engines, social networking platforms and trust service providers. It does not bind the other NIS2 sectors, but it is the most detailed public statement of what "supply chain security" means, and other buyers borrow from it. The points that reach suppliers:

Point in the Annex	What it says	What a supplier gets asked
5.1.2(a)	Supplier selection takes into account "the cybersecurity practices of the suppliers and service providers, including their secure development procedures"	How do you develop securely, and how do you know what goes into your product?
5.1.4(e) and (f)	Contracts specify, where appropriate, the right to audit or to receive audit reports, and "an obligation on suppliers and service providers to handle vulnerabilities that present a risk" to the entity	Will you handle vulnerabilities in what you deliver, and can we see the evidence?
5.2	A registry of direct suppliers, with "a list of ICT products, ICT services, and ICT processes" each one provides	Which products and versions do you supply to us?
6.1.2(c)	For the acquisition of ICT services or ICT products: "information describing the hardware and software components used in the ICT services or ICT products"	What hardware and software components does your product contain? The closest any text on this page comes to an SBOM, and it still does not name one.
6.10	Vulnerability handling: monitor information about vulnerabilities through channels such as CSIRT announcements or "information provided by suppliers or service providers" (6.10.2(a)), and where a vulnerability needs no remediation, "document and substantiate the reason" (6.10.3)	How will you tell us about vulnerabilities, and why is this one not a problem?

The last point describes a not-affected statement with its reason. That is what a VEX document carries, although the regulation does not name a format.

Worked example: a questionnaire from a NIS2 customer

Five questions of the kind a customer derives from those points, with the evidence a supplier can attach. Some answers come from records your tooling keeps; others are policies you write.

Question	Evidence to attach	Record or policy
"List the software components in the product version you deliver to us." (6.1.2(c))	The SBOM of that version, in CycloneDX or SPDX, with its completeness stated	Record
"Describe your vulnerability handling and its timelines." (5.1.4(f))	Your vulnerability handling procedure, with severity levels and target times	Policy
"Which of the versions we run contained the vulnerable library, and since when?" (6.10)	Build history showing every build that contained the component, with dates	Record
"Why does this CVE not affect us?" (6.10)	A not-affected statement with its justification, such as "the vulnerable code is not present"	Record, based on your assessment
"How can researchers report vulnerabilities in your products?" (5.1.2(a))	Your coordinated vulnerability disclosure policy	Policy

One distinction to keep: for products with digital elements sold in the EU, the Cyber Resilience Act does require an SBOM. NIS2 does not.

DORA, if you sell to financial entities

The Digital Operational Resilience Act, Regulation (EU) 2022/2554, applies to financial entities, not to their suppliers directly. Financial entities must identify and document their ICT assets and their interdependencies and keep inventories of them (Article 8(1), 8(4) and 8(6)), manage ICT third-party risk as part of their ICT risk (Article 28(1)), keep a register of information on all their contracts for ICT services (Article 28(3)), and put minimum provisions into those contracts (Article 30). DORA does not name SBOMs. For a supplier of software to a bank, a per-release component list helps the customer meet Article 8.

One evidence map across all of them

Rows are pieces of evidence; each cell gives the control, criterion or point it supports, or "not directly".

Evidence	ISO/IEC 27001:2022	SOC 2	NIS2 and 2024/2690	DORA
1. An SBOM per release, with its completeness stated	5.9, 5.21, 8.8	CC7.1	Art. 21(2)(d); 6.1.2(c)	Art. 8 (the customer's inventory)
2. Continuous re-evaluation against new advisories	8.8	CC7.1	Art. 21(2)(e); 6.10	Not directly
3. Build history: which releases contained a component, and since when	8.8	CC7.1, CC8.1	6.10	Not directly
4. Triage and routing records	8.8	CC7.1	Art. 21(2)(e); 6.10	Not directly
5. Not-affected statements with reasons	8.8	CC7.1	6.10	Not directly
6. Policy gates that block a build	8.25, 8.29	CC8.1	Art. 21(2)(e)	Not directly
7. Supplier SBOMs monitored with your own	5.19, 5.21, 5.22	CC7.1	Art. 21(2)(d), 21(3); 5.2, 6.10	Art. 28(1)
8. Egress policy and network records for the build	8.25	CC8.1	Art. 21(2)(d)	Not directly

What an SBOM will not prove

• Your access control, incident response, business continuity, HR security, cryptography or physical security.
• That anyone fixed anything. That is your process, and its records.
• That your own code is free of flaws. Code review, SAST and testing are the evidence for that.
• What is inside binaries you received without an SBOM.
• That you are certified. An SBOM is not a certificate, and a certificate held by your tool vendor certifies the vendor's own management system, not you.

How CRACI fits

CRACI replaces your GitHub-hosted runners and records what each build pulled in, so the SBOM comes from the release build itself, with a completeness state for every job.

• Monitored SBOMs are re-evaluated continuously as new vulnerabilities are published (vulnerability tracking).
• Build history shows which builds contained a vulnerable dependency, and so the period you were exposed, within your retention period. If your audit covers a longer period, export each release's SBOM and keep it with the release.
• Security teams triage the vulnerabilities found and send them to the teams that own the fix, and CRACI supports VEX for recording which products a vulnerability does not affect.
• Policy gates can block a build on findings, including a build that contains a specific CVE.
• Third-party SBOMs can be added, so bought-in components are monitored alongside your own builds.
• SBOMs export as CycloneDX or SPDX, and the API returns SBOMs, network traces and provenance data. The egress policy records and limits where each build may connect.

CRACI supplies evidence for these controls. It does not make you ISO 27001 or SOC 2 compliant or ready for NIS2, and it is not a compliance automation platform. CRACI's own certificate is a separate fact: CRACI Corporation Oy's information security management system for the development and operation of the CRACI platform is certified to ISO/IEC 27001, issued by Into Certification. It covers how CRACI runs its service, not your organization or your products. See security at CRACI, and how CRACI works for the whole platform.

When CRACI is not the answer

• Your builds do not run on GitHub Actions. That is the only CI CRACI supports today; other CI systems are on the roadmap.
• You need a compliance automation platform for policies, access reviews and auditor workflow. Keep or buy one; see SOC 2 SBOM checks compared.
• Your evidence gap is mostly organizational: policies, training, incident response.
• Your main supplier risk is binaries you receive without SBOMs. Binary analysis answers that.

Answering one customer's request? See how to answer a customer SBOM request, the guide for component suppliers and the checklist your customer will run.

SBOMs as compliance evidence: frequently asked questions

Does ISO 27001 require an SBOM?

No. ISO/IEC 27001:2022 does not name SBOMs. Annex A controls 5.9 (inventory), 5.21 (ICT supply chain) and 8.8 (technical vulnerabilities) ask for outcomes an SBOM supports, and the organization and its auditor decide what evidence is enough.

Does SOC 2 require an SBOM?

No. The Trust Services Criteria are outcome statements and do not name SBOMs. An SBOM per release, re-evaluated against new advisories, is evidence for CC7.1, and a recorded build pipeline supports CC8.1 on change management.

Does NIS2 require an SBOM?

No. Article 21(2)(d) asks for supply chain security and 21(2)(e) for vulnerability handling, without naming SBOMs. Implementing Regulation (EU) 2024/2690, which covers certain digital service providers, asks for information on the hardware and software components of ICT products in point 6.1.2(c), still without the word SBOM.

Which ISO 27001 Annex A controls does an SBOM support?

Mainly 5.9 (inventory of information and other associated assets), 5.19 to 5.22 (suppliers and the ICT supply chain) and 8.8 (management of technical vulnerabilities). A build record touches 8.25, 8.29 and 8.30 in part. 8.26 to 8.28 are about requirements, design and code, outside an SBOM.

What do NIS2 customers ask their software suppliers for?

Usually a description of secure development, the components in the delivered version, a commitment to handle vulnerabilities, a way to receive vulnerability information, and reasons when a vulnerability does not apply. Those questions come from Article 21(3) and, for some sectors, the supplier points of Implementing Regulation 2024/2690.

Is an SBOM enough evidence for ISO 27001 control 8.8?

No. It shows what each release contains. Control 8.8 also needs evidence that you obtain vulnerability information, evaluate your exposure and act on it. Pair the SBOM with continuous re-evaluation, a record of affected releases, and the decisions you made.

What is the difference between being compliant and having evidence?

Compliance means your processes meet the framework's requirements, as judged by an auditor or a customer. Evidence is what shows those processes work. An SBOM is evidence for a few controls. It does not make you compliant with any framework.