SBOM Evidence Under ISO 27001: What Auditors Can Actually Test

Having an SBOM Does Not End the Audit

“Do you have an SBOM?”

“Yes.”

The development team opens a folder.

There is a JSON file inside.

Audit complete?

A Software Bill of Materials can provide valuable software visibility.

However, simply creating an SBOM does not prove that risk is controlled.

Instead, internal audit should test whether the SBOM works as part of the security process.

A stronger audit asks:

That is where SBOM evidence becomes useful.

What Does an SBOM Actually Prove?

An SBOM is similar to an ingredient list for software.

It may identify:

However, an SBOM does not prove those components are secure.

It provides visibility.

The organization still needs to evaluate and act on that visibility.

Therefore, internal audit should look beyond the SBOM file.

1. Test Whether the SBOM Exists for the Right Applications

Do not begin by reviewing individual SBOM fields.

First, ask:

Then compare the answer with the application inventory.

Now the auditor has something useful to investigate.

For example, why does the high-risk customer API have no SBOM?

Evidence to Request

• Application inventory.
• Software asset inventory.
• Criticality ratings.
• SBOM repository.
• Secure development procedure.
• Risk assessment.

Audit Test

Select several critical applications.

Then confirm that required SBOMs actually exist.

Do not simply accept the statement, “Our teams generate SBOMs.”

2. Verify That the SBOM Matches the Current Release

This is one of the most important checks.

An organization may have an SBOM.

However, it may describe software released six months ago.

Meanwhile, production may have changed many times.

Therefore, compare:

Also review:

• Build date.
• Release number.
• SBOM timestamp.
• Commit or build reference.
• Version information.

The organization has an SBOM, but it may not describe its current risk.

3. Test Component Coverage

Next, ask what is actually inside the SBOM.

A weak SBOM may list only direct dependencies.

The real application may rely on hundreds of components.

CISA’s 2025 guidance calls for coverage of components that make up the target software.

This includes transitive dependencies.

Sample Audit Test

Choose one direct dependency.

Then trace its dependency tree.

If Package C is missing, ask why.

Useful Evidence

• SBOM.
• Package manifest.
• Lock file.
• Software composition analysis report.
• Build records.
• Container scan.

You do not need to inspect thousands of components manually.

Instead, use sampling to test whether the SBOM process is reliable.

4. Test the Component Version

A component name alone has limited security value.

For example:

Which version?

That detail may determine whether a known vulnerability applies.

Therefore, sample several components.

Compare:

If the values differ, investigate the SBOM generation process.

5. Test Dependency Relationships

An SBOM should show how components relate to the application.

For example:

This relationship becomes important during incident response.

If Package C becomes vulnerable, the organization needs to find every affected application.

6. Test How the SBOM Is Generated

Next, ask how the SBOM is created.

Common methods include:

• Build pipeline generation.
• Software composition analysis.
• Source repository scanning.
• Container analysis.
• Manual generation.
• Supplier-provided SBOMs.

Automated generation may improve repeatability.

However, automation does not guarantee accuracy.

Internal Audit Should Check

• When generation occurs.
• Which tool creates the SBOM.
• Whether failed generation blocks the build.
• Whether someone reviews the output.
• Where the SBOM is stored.
• How errors are corrected.

7. Test Whether the SBOM Connects to Vulnerabilities

This is where an SBOM becomes operational.

Ask the security team:

A mature process may look like this:

The team should not need to email every developer to ask who uses a package.

Audit Test

Choose a previously disclosed vulnerability.

Ask the organization to show:

• Which component was affected.
• Which applications contained it.
• Who was notified.
• How risk was evaluated.
• What remediation occurred.
• How closure was verified.

This tests both the SBOM and the surrounding security process.

8. Test the Critical Vulnerability Today Scenario

A practical internal audit exercise is simple.

Then observe the process.

Can the team answer:

• Do we use the component?
• Which version do we use?
• Which applications contain it?
• Is it in production?
• Who owns those applications?
• Is the vulnerable function reachable?
• What action is required?

An SBOM should make this investigation faster.

If the team still relies on memory, the SBOM may not support vulnerability management.

9. Review Known Unknowns

No SBOM process is perfect.

The important point is whether the gaps are visible.

CISA’s 2025 guidance refers to incomplete dependency information as Known Unknowns.

Look for:

• Missing dependencies.
• Unsupported package types.
• Components intentionally excluded.
• Supplier components with limited visibility.
• Proprietary software with incomplete composition data.

A transparent incomplete SBOM may be better than one that falsely appears complete.

10. Test Supplier-Provided SBOM Evidence

Organizations do not build all their software.

Therefore, suppliers may also need to provide component transparency.

For critical suppliers, internal audit may review:

• Supplier SBOM requirements.
• Contract clauses.
• SBOM delivery method.
• Update frequency.
• Vulnerability notification process.
• Supplier security assessments.

Use a Risk-Based Approach

Not every supplier needs the same level of scrutiny.

A critical platform handling sensitive data deserves more attention than a low-risk utility.

11. Test What Happens After a Component Changes

Suppose a developer updates a package.

What happens next?

• Does the SBOM update?
• Does anyone verify the change?
• Does the new package add dependencies?
• Does vulnerability scanning run again?
• Does the build retain evidence?

This connects SBOM management with change management.

Evidence to Review

• Pull request.
• Dependency update.
• Build record.
• Security scan.
• Updated SBOM.
• Testing evidence.
• Deployment approval.

A good audit trail connects each software change with updated component evidence.

12. Test SBOM Ownership

An SBOM without an owner can quickly become stale.

Therefore, internal audit should identify clear responsibilities.

Determine who is responsible for:

• Generating the SBOM.
• Storing it.
• Maintaining it.
• Reviewing errors.
• Monitoring vulnerabilities.
• Responding to supplier updates.

Responsibility may be shared across several teams.

That is fine, but the responsibilities should be clear.

What Strong SBOM Evidence Looks Like

Strong evidence creates a clear chain.

That is much stronger than simply showing the auditor an SBOM file.

SBOM Evidence and ISO 27001 Controls

ISO/IEC 27001:2022 does not contain a control called “Maintain an SBOM.”

However, SBOM evidence can support several control areas.

The exact mapping depends on your scope, risk assessment, development model, and Statement of Applicability.

Common SBOM Internal Audit Findings

Watch for these common patterns.

Quick SBOM Internal Audit Checklist

Before closing the audit, confirm:

Centralize SBOM Evidence in Your SharePoint ISMS

Software teams may keep SBOMs and vulnerability data in technical tools.

Meanwhile, ISO 27001 evidence may sit elsewhere.

That can make audit traceability harder.

Canadian Cyber’s ISMS SharePoint Solution can help centralize:

Frequently Asked Questions

The Takeaway

The audit question should not be:

Instead, ask:

Internal audit should test the complete chain:

That chain turns an SBOM into useful security evidence.

The goal is not to create another JSON file.

The goal is to answer important questions faster.

When an organization can answer those questions with evidence, its SBOM program is doing real work inside the ISMS.

Stay Connected With Canadian Cyber

Follow Canadian Cyber for practical guidance on ISO 27001 internal audits, SBOMs, secure development, software supply chain risk, supplier governance, and SharePoint ISMS.