Regulatory Compliance Mapping

Compliance mapping is the process of translating high-level legislative and regulatory requirements (for example, controls mandated by NIS2, DORA, or the Cyber Resilience Act) into concrete, auditable technical checks against your actual software.

In practice, this means taking what the law and your regulators say you must do and expressing it as:

• specific policies,
• measurable controls, and
• repeatable reports

that your teams can operate every day.

SBOM Observer is built to help with exactly this problem. It uses the Software Bill of Materials (SBOM) as the primary data source and a policy engine to continuously check whether your software estate aligns with your regulatory obligations.

---

Why regulations care about SBOMs

Regulations like NIS2, DORA, and the Cyber Resilience Act (CRA) all push in the same direction:

• know what you are running,
• understand your exposure,
• react quickly when new risks appear, and
• be able to prove that you do this in a structured way.

That is very hard to do if you do not have an accurate inventory of the components you depend on. This is where SBOMs come in.

An SBOM gives you:

1. A complete component list – all external libraries, tools, and services your software depends on.
2. A linkable data model – each component can be tied to vulnerabilities, licenses, suppliers, and policies.
3. A stable artifact for auditors – something you can store, share, and refer back to when regulators ask, "what did you know, and when?".

Without SBOMs, most of the supply-chain-related parts of NIS2, DORA, and CRA become manual spreadsheet work. With SBOMs, they can be expressed as queries and policies.

---

NIS2: from Article 21 to actionable checks

The Network and Information Security Directive 2 (NIS2) aims to reach a high common level of cyber security across EU member states by improving risk management, incident response, and resilience.

It applies to "essential entities" (critical sectors under proactive supervision) and "important entities" (key supporting sectors typically under reactive supervision). If your organisation falls under NIS2, you must be able to present formal documentation to auditors that shows how you meet the directive’s requirements.

While NIS2 has many articles, most of the day-to-day technical work is driven by Article 21. ENISA (the EU Agency for Cybersecurity) provides guidance that expands these requirements into domains and detailed controls in its Technical Implementation Guidance on Cybersecurity Risk Management Measures.

While this section uses NIS2 as a concrete example, the same pattern applies to most modern cyber security and resilience regulations. They use different terms, but when it comes to software supply chain security they broadly ask for the same things: know your components, understand your risk, act in time, and be able to prove it. SBOM Observer can be used to map and operationalise these expectations for NIS2, DORA, CRA, and other frameworks in the same way.

Several of these NIS2 domains directly touch your software supply chain and therefore your SBOMs.

Example domains mapped to SBOM Observer

In other words, NIS2 says what outcomes you must achieve; SBOMs plus SBOM Observer give you the data and tooling to show how you achieve them.

---

DORA and CRA: similar questions, different angles

Other EU initiatives ask many of the same questions in slightly different words:

• DORA (Digital Operational Resilience Act) focuses on the operational resilience of financial entities. It expects you to understand your ICT third-party risk, have robust change and incident processes, and demonstrate control over critical suppliers.
• The Cyber Resilience Act (CRA) focuses on security of products with digital elements, including requirements around vulnerability handling, secure development, and transparency towards customers.

For both, SBOMs and SBOM Observer help you:

• show which third-party components are in scope for a specific product or service,
• trace vulnerabilities and remediation across releases,
• demonstrate that you have a repeatable way to identify and mitigate known risks, and
• prepare documentation and evidence packs when regulators or customers request them.

The vocabulary might differ, but the building blocks are the same: inventory → risk assessment → remediation → evidence. SBOM Observer follows the same core idea in the product: generate SBOMs, analyse them, enforce policies, prove outcomes to stakeholders, and share results where needed.

---

SBOM Observer as a compliance mapping engine

Manually mapping 100+ regulatory controls to individual applications does not scale. SBOM Observer’s policy engine is designed to turn these expectations into repeatable checks against your SBOM data.

At a high level, you:

1. Define policies that encode a regulatory expectation (for example, "no components with known critical vulnerabilities that are likely to be exploited").
2. Continuously enforce policies against SBOMs, applications, or portfolios.
3. Focus on policy violations – SBOM Observer evaluates policies automatically and highlights where reality does not match your rules.

What policies can express

Some typical patterns that map well to regulatory language:

• Risk management and remediation
  Policies that check for unresolved high-severity vulnerabilities, end-of-life components, or missing patches, and that require remediation within a certain timeframe.

• Configuration and hardening
  Policies that block known-bad packages, enforce minimum versions, or ensure particular frameworks or libraries are present.

• Access and supplier control
  Policies that restrict which registries, suppliers, or ecosystems may be used, supporting supplier due-diligence requirements.

• Evidence and audit readiness
  Every policy evaluation is stored. You can export results, link them to tickets, or include them in audit packages to show ongoing compliance, not just a one-time assessment.

---

Practical next steps

If you are starting a compliance mapping initiative with SBOM Observer:

1. Inventory your applications – Generate SBOMs using the Observer CLI or your existing build tooling.
2. Translate regulatory text into policy ideas – Start with a small set of clear, testable rules. Use the NIS2 supply-chain and vulnerability-management requirements as a first target.
3. Implement and iterate policies – Use the policy concepts and how-to guides to turn those ideas into concrete policies.
4. Review policy violations with your risk and compliance teams – Align on which violations matter, how they should be handled, and how the resulting history will be used as evidence for auditors.

Over time, this gives you a living, testable map between what the regulations require and what your software actually does, grounded in policy evaluations and their violations.