The risk register: the document every framework assumes you have

No text says “risk register”. All of them assume one.

Regulators rarely prescribe tools; they prescribe outcomes and evidence. That is why you will not find a sentence ordering you to keep a risk register. What you find instead is a set of obligations: documented risk analysis, management oversight, effectiveness assessment, evidence on demand. Their only practical common denominator is a register, meaning one maintained record of your risks, their owners, their treatment and their history.

NIS2: documented risk analysis, personally overseen

Article 21 of NIS2 (Directive 2022/2555) requires essential and important entities to take “appropriate and proportionate” risk-management measures, on an all-hazards basis. The list in Article 21(2) starts, in point (a), with “policies on risk analysis and information system security”. It closes, in point (f), with policies and procedures to assess the effectiveness of the measures themselves. A policy on risk analysis with nothing recording its output is not a policy; it is a statement of intent. The register is where the analysis becomes verifiable.

Article 20 raises the stakes: management bodies must approve the risk-management measures, oversee their implementation, and can be held liable for infringements. They must also follow training sufficient to identify and assess the risks. You cannot approve or oversee what is scattered across personal files. Oversight presupposes a single, current view of the risk position: which risks exist, at what level, treated how, accepted by whom.

And NIS2 does not wait for an incident to check. Under the supervision provisions (Articles 32–33), competent authorities can conduct inspections and security audits and require evidence of the implementation of the risk-management policies. The register is the natural exhibit A. Its absence is the natural finding number one.

DORA: a documented framework, reviewed every year

For financial entities, DORA (Regulation 2022/2554) goes further. Article 6 requires a “sound, comprehensive and well-documented ICT risk management framework”, reviewed at least once a year and continuously improved on the basis of lessons learned. A framework you must document, review annually and improve is a framework that produces records: assessments, decisions, residual levels, review dates. That is a register in everything but name.

And once, the name is actually there. Article 28 requires every financial entity to maintain a register of information covering all its contractual arrangements with ICT third-party providers, keep it current, report on it to the competent authority and produce it on request. For the supply-chain slice of your risk, the register is not inferred from the obligations. It is the obligation.

ISO 27001: no records, no certificate

ISO 27001:2022 makes the same point through the audit door. Clauses 6.1.2 and 8.2 require the organisation to define a risk assessment process and to retain documented information about its results; clause 8.3 does the same for risk treatment, alongside the Statement of Applicability. When the certification auditor arrives, “retained documented information about the results of risk assessments” has a shape: it is your register, with dates, owners, levels and treatment decisions. Without it there is nothing to audit, and nothing to certify.

What the articles add up to

Put the obligations side by side and they specify, quite precisely, what your register must be able to show:

• One maintained record of risks from every source: projects, audits, supplier assessments (NIS2 Art. 21(2)(a); DORA Art. 6)
• A named owner and current status for every risk, because oversight requires accountability (NIS2 Art. 20)
• Treatment decisions and residual levels, including formal acceptance of what you chose not to fix (ISO 27001 cl. 8.3)
• Review dates and effectiveness checks, because the framework must be reviewed, not just written (DORA Art. 6(5); NIS2 Art. 21(2)(f))
• A third-party register with current information on every ICT provider (DORA Art. 28)
• History and evidence on demand: who changed what, when, producible for a supervisor or auditor (NIS2 Art. 32–33; ISO 27001 cl. 8.2)

A spreadsheet can hold the first column of that list. It cannot hold the rest: it has no owners it can enforce, no review dates it can trigger, no history it can prove, and no way to keep the supplier view current. The texts do not ban spreadsheets. They simply describe properties a spreadsheet does not have.

How SynapseRM answers each obligation

None of this strictly requires software; it requires discipline. What a platform does is make the discipline cheap. In SynapseRM, the register maintains itself as a by-product of the work, instead of being a second job someone does after the work. Concretely:

• One record, every source. A risk enters once, from a project assessment, an audit recommendation or a supplier review, and lands in the same registry. Assets, criticality, exceptions and findings all reference that record.
• Ownership and review, built in. Every risk carries a named owner and a next-status date. Overdue items surface automatically in the to-do view and in alerts, which is exactly the oversight Article 20 expects management to exercise.
• The full lifecycle, recorded. Identified, treated, mitigated, accepted or closed, with inherent and residual levels and the path between them. Formal acceptance lives in the Exception Registry with a justification and an expiry date, matching ISO 27001 clause 8.3.
• Evidence on demand. An immutable history of who changed what and when, a dedicated read-only auditor role, and reports generated on schedule or in one click. When the supervisor invokes Articles 32–33, the answer is an export, not a working week.
• The DORA register, literally. The TPRM module keeps the register of ICT third parties current, tiered by criticality and exportable for the authority, as Article 28 requires.

That is the difference between having done risk management and being able to prove it. The texts ask for the second.