Controls mapped to frameworks in the product. The risk register, through our specialists.
Most vendors claim a unified risk-and-control register. In practice that usually means a spreadsheet with controls on one tab and risks on another, loosely connected. On this platform the control-framework mapping is in-product: controls, frameworks, and the mappings between them, as first-class objects. The risk register itself is not an in-product module today; that side is run by our specialists against the same data.
Controls, frameworks, mappings: honest about which half.
The in-product side of this module is the control-framework mapping. Frameworks are first-class objects. Framework controls (the individual requirements inside a framework) are first-class objects. Mappings between controls in different frameworks are first-class objects with their own metadata. A single operational control can be mapped to its CRD, Solvency II, DORA, and ISO/IEC 27001 expressions; the mapping is queryable, not buried in a narrative document.
What that gives a firm today is the ability to answer "which of our controls satisfy which framework requirement" with a read of the platform rather than a freshly drafted matrix. The same control, mapped once, is visible through every framework view that asks about it. When a new framework is added, the existing controls are re-queried through its lens; the controls themselves do not change.
The second half (the risk register, with inherent and residual risk, risk appetite, risk acceptance, risk-to-control coverage, KRIs and KCIs) is not an in-product module today. Firms that need a risk register as part of their DORA, Solvency II, or IFD ICARA obligation run it through our specialists against the same control-and-framework data. When a risk-register module ships, the advisory work already sits in the platform as the starting data.
Control once, read through every framework.
The common alternative is framework-first control libraries. A firm under both DORA and Solvency II buys two control catalogues and maintains two versions of the same operational control: one phrased for DORA evidence and one phrased for the Solvency II system-of-governance documentation. A third catalogue arrives when an ISO/IEC 27001 certification starts. Each catalogue has its own review cadence and its own owner. The overlap between them is handled by a person, in a document, once a year.
On this platform the control is the primary object. Framework requirements are also primary objects, but they are not the control; they are what the control is being held to answer. A mapping is an explicit relationship. One control, mapped to its DORA requirement and its Solvency II expression, shows up in both framework views without duplication. When a new framework arrives, the mapping is the work; the control catalogue is not rewritten.
The specific claim, sharper: this module does not yet run a risk register. It runs the control-to-framework graph, honestly and in product. The risk register lives with our specialists, and we do not pretend otherwise on this page.
GRC tools unify in the screenshot. This module unifies in the schema.
Most GRC platforms present a unified risk-and-control dashboard as the product headline, then, on inspection, hold controls as per-framework copies underneath. The unification is a report over duplicated data. A control that changes in one framework's copy does not change in the others; drift is silent until an audit.
On this platform the unification is structural. The `framework`, `framework_controls`, and `control_framework_mappings` tables are the module. The control object has one record. Each mapping to a framework requirement is its own record with its own review cadence and assertion. The same platform-level architecture that keeps a supplier as one object across five frameworks keeps a control as one object across its framework mappings.
The second structural point is honesty about the boundary. We do not put a "risk register" tile on the dashboard today. Where the risk register is the regulatory artefact (ICARA, ORSA, ORA, DORA Art. 6 risk assessment), we run it advisorally, and we record the interpretation decisions on the platform so that when the module ships the history is already there.
Control mapping today. Risk register on the roadmap.
The module's in-product surface is control-framework mapping. It is useful today because the object supervisors ask about ("what control satisfies this requirement, who asserts it, and when was it last reviewed") is a read of the platform. A firm can maintain its control catalogue on the platform now and see it through every framework it falls under.
What the module does not do in product is hold a risk register. Inherent and residual risk per operational area, risk appetite statements and their board-level thresholds, risk acceptance workflows, risk-to-control coverage dashboards, KRIs and KCIs. None of these are shipped features. The data structure groundwork (the framework-mapped control graph) is laid; the register itself is advisory.
Firms under DORA Art. 6, Solvency II Art. 44, IFD Art. 24 ICARA, and IORP II Art. 28 ORA today work with our specialists for the risk-side artefact. We maintain the narrative and the supporting register alongside the in-platform control mapping. When the in-product risk register ships, the existing advisory data carries across.
A discovery call, not a product demo.
You describe the compliance problem consuming the most of your team's time. We walk the platform through an example close enough to your operation that you can judge whether this way of modelling compliance fits how you want to work.
Book a discovery call →