Name: NexCyber MRCC — Machine-Readable Compliance Certificate
Availability: InStock

31 July 2026By NexCyber Editorial Cross-regulation

CRA, NIS2, DORA, the AI Act and RED demand overlapping evidence. What genuinely transfers between them, and the three places where it stops.

The short answer

Most organisations facing more than one EU regulation build a separate programme for each, and produce the same artefacts several times over.

They were drafted at different times, for different purposes, by different directorates. But they converge on a small set of underlying capabilities: knowing what is in your product, hearing when something is wrong, being able to tell the right people in time, and proving all three afterwards.

one artefact, built once   ->  usually answers a requirement in
                               two or three instruments at once
the OBLIGATION             ->  never transfers

Producing an SBOM does not make you CRA-compliant. It satisfies a requirement that the CRA, NIS2 and DORA each state in their own terms — and each judges against its own criteria.

---

What genuinely transfers

The software bill of materials

CRA     Annex I Part II — identify and document components, machine-readable,
        at least top-level dependencies
NIS2    Article 21(2)(d) — supply chain security. Your customer asks you for it.
DORA    ICT third-party risk — dependency mapping feeds the register

One artefact, three regimes. Build it in CI and it stays true for all three at once.

The coordinated vulnerability disclosure policy

CRA     Annex I Part II — required outright, with a contact address
NIS2    Article 21(2)(e) — vulnerability handling and disclosure
buyers  first thing a serious procurement questionnaire checks

It costs a page and an inbox. It is verifiable from outside, which is exactly why it carries weight — and it is the single cheapest credibility signal on this list.

The incident runbook with named owners

CRA     Article 14 — 24h / 72h / final report, from 11 September 2026
NIS2    Article 23 — 24h / 72h / one month
DORA    incident classification and reporting to the competent authority

Different reporter, different subject, different authority — one process.

A single event can generate several notifications on several clocks. That is a runbook problem, and it is far cheaper to design once than to discover mid-incident.

The management body decision

NIS2   Article 20 — management bodies approve the measures, oversee
       implementation, and can be held liable
DORA   Article 5 — the management body bears final responsibility

A minuted decision naming the framework and the date it was approved serves both. It is the cheapest artefact in any programme and the first one an auditor asks for.

The asset and dependency inventory

Underlies CRA scope determination, NIS2 risk analysis, DORA's register of information, and the AI Act system inventory. Nothing downstream can be right if this is wrong.

---

Where it stops — and this is the part most mappings omit

1. Conformity assessment does not transfer

The CRA requires, for some products, a third-party assessment or a European cybersecurity certificate. No amount of NIS2 or DORA work substitutes for it. RED Article 3(3) has its own route, its own standards, its own notified body.

These are legal acts performed on a product, not evidence about an organisation.

2. Classification is instrument-specific, and the words collide

CRA        default · important (Annex III) · critical (Annex IV)
NIS2       essential · important
AI Act     unacceptable · high · limited · minimal

"Important" means something different in the CRA and in NIS2. A team that maps them onto one internal scale will produce a scale that is wrong in at least one regime — and the error will be invisible, because the word looks right.

3. The AI Act asks a question the others do not

The other four ask whether a system is secure. The AI Act asks what a system decides, and about whom. A fundamental rights impact assessment has no equivalent anywhere else, and no security artefact stands in for it.

This is the dotted line on the diagram. Everything else composes; this does not.

---

What this changes in practice

Stop organising the programme by regulation. Organise it by artefact.

by regulation   ->  CRA project · NIS2 project · DORA project
                    the same SBOM built three times, three times inconsistently
by artefact     ->  one SBOM · one disclosure policy · one runbook ·
                    one minuted approval · one inventory
                    each mapped to the obligations it answers

The second structure is also the one that survives an audit, because a market surveillance authority does not ask what your programme is called. It asks what you can show, and how fast.

And it changes who owns what. An SBOM built by regulation belongs to a compliance project that ends. An SBOM built as an artefact belongs to the build pipeline, and stays true.

---

Five decisions

1List artefacts, not regulations. Start from what you must be able to show.
2Map each artefact to every obligation it answers, and write the mapping down. The mapping is itself evidence of a considered approach.
3Keep classifications separate. Never merge CRA "important" and NIS2 "important" into one internal field.
4Treat conformity assessment as a scheduling item, not a documentation item. It has a queue you do not control.
5Run the AI Act determination separately. It asks a different question, and folding it into a security programme is how the fundamental rights assessment gets discovered late.

---

Map your own evidence — free, no account

[Free applicability assessment](/assess) — which regulations reach you, and which obligations follow
[Compliance responsibility mapper](/resources/responsibility-mapper) — a RACI by role
[Penalty calculator](/resources/penalty-calculator) — exposure on your own turnover

---

One Evidence Set, Five EU Regulations — What Maps