Governance & evidence
The model you maintain is the evidence you present.
Two regimes are seeded today: NIS2 and DORA. Coverage for both is computed from your landscape on request. Where the landscape cannot evidence a measure, the measure renders blank and stays blank.
Two words that must never be swapped
Modeled means your architecture states the control exists — the redundancy is drawn, the encryption attribute is set, the interdependency is recorded. Structure as evidence of intent.
Verified means a scanner ran against the running estate and its report was imported. Noveam records what the scanner said, and names it: reported by <source> at <time>. Noveam never claims to have verified anything itself, because it never did.
The two live on separate axes and are allowed to disagree. When they disagree, that is the most useful thing on the screen.
The most a Noveam coverage view will ever say about itself is Covered (modeled). There is no state above it. That ceiling is deliberate and it is enforced in the code.
21 clauses, and the blanks are on purpose
The catalogue is seeded by a migration, so it is versioned with the product rather than typed into a spreadsheet by whoever set the instance up. Ten NIS2 Art. 21(2) measures and eleven DORA clauses.
A clause only becomes assessable when a rule is wired to it and the objects that rule needs actually exist in the model. Until then it renders blank. It does not render as a pass.
NIS2
Of the ten NIS2 measures, four have live evidence in Noveam: business continuity and disaster recovery, supply chain security, cryptography and encryption, and access control. The other six are organisational measures that a model can reference but can never evidence, and they render Not modeled.
DORA
Of the eleven DORA clauses, four have live evidence: ICT asset identification and interdependency mapping, business continuity, backup and redundant capacity, and entity-level concentration risk. The remaining seven — governance and management-body accountability, incident management and reporting, resilience testing, key contractual provisions, the oversight framework, third-party interconnections, and the register clause itself — render blank.
Each regime reports in its own view. Shared evidence is never counted twice across two filings — that separation is enforced by a test, not by convention.
Assembled from the model, exported as a draft
The register is not a spreadsheet you maintain beside your architecture. Providers, contractual arrangements, ICT services and the critical or important functions those services support are objects in the same model as everything else. The register is a projection of it.
What comes out
- All fifteen ITS templates , in ITS order, including the ones your model cannot fill. Those are emitted empty, with a note saying why.
- XLSX with one worksheet per template , plus a CSV per template.
- Every worksheet, every CSV and every filename carries: DRAFT — assembled from the Noveam model; modeled, not a certified filing. Verify and complete before submitting to a competent authority.
- A field the model cannot derive stays empty. Never “N/A”, never zero. An unentered annual cost exports as an empty cell, because an empty cell is the true statement.
- LEI codes are validated locally , by the ISO 7064 MOD 97-10 check digit. Deliberately not a network lookup — a lookup would break the air gap.
- The full S01–S19 ICT service taxonomy , as typed values with their ITS Annex III labels.
The limit, stated first. Noveam produces a draft. Your entity owns the submission. Template coverage is complete; template fidelity is partial — several templates carry a reduced column set against the full ITS annex, and the supply-chain template records the direct provider, not an n-level subcontracting chain. There is no XBRL or DPM binding and no live GLEIF lookup. Both of those are deliberate.
Which functions are critical, and what holds them up
Functions are classified per Art. 3(22), and support propagates through the model: from the function to the ICT services that support it, to the contractual arrangements behind those services, to the providers who signed them. The same propagation feeds both the register and the landscape views, so the two cannot tell you different stories.
Limit, stated here: support is resolved over the modelled hops, not as a full transitive closure of the entire graph.
Two concentration checks, and one honest number
Two checks run against the register, both under Art. 29: one provider standing behind several critical or important functions, and a service marked non-substitutable under a critical function.
The threshold is three distinct functions behind one provider. Art. 29 sets no number. Three is Noveam’s stated default, chosen to match the quorum threshold the resilience checks already use. The code says so, and so does this page.
TIME
Invest, migrate, tolerate, eliminate — projected from two attributes you enter, across four building-block types. Anything you have not scored is excluded from the projection rather than given a default position on the chart.
OSCAL component definitions
The control catalogue exports as OSCAL component-definition JSON, v1.1.2, with every component marked with an evidence basis of modeled. Component definitions only — this is not a system security plan.
The limits of this page
- Noveam produces a draft register. Your entity reviews, completes and submits it.
- Two regimes are seeded: NIS2 and DORA. Nothing else.
- Several register templates carry a reduced column set against the full ITS annex.
- The supply-chain template records the direct provider, not a multi-level subcontracting chain.
- There is no XBRL or DPM binding, and no live GLEIF lookup.
- The concentration threshold is Noveam’s default, not a regulatory figure.
- Evidence is modeled. Only a scanner verifies, and only the scanner is credited.