ICT assets, connected to the functions they support and the suppliers that run them.
DORA Article 6 requires an ICT asset register with criticality classification. Most firms keep that register in a spreadsheet disconnected from the function catalogue and the supplier list. On this platform an ICT asset is an object connected to the entities that use it, the functions it supports, and (via those functions) the suppliers and contracts that deliver it.
A register that knows what depends on it.
An ICT asset on this platform is a record with asset type, owner, vendor, status, and structured metadata. Its criticality is a classified attribute (not a free-text note) with the same evidence pattern the rest of the platform uses: asserted by whom, effective from when, review due when, with a source reference. An information asset is modelled alongside ICT assets where the firm distinguishes them.
What makes the module regulatory is the relationships. An asset is related to the entity that owns or uses it, with the role on that relationship (primary user, owner, custodian) captured explicitly. Through the function catalogue, an asset is related to the business functions it supports, and through those functions to the supplier contracts that deliver service to it. The asset register is not a flat list; it is a node in the graph that already holds the firm's suppliers, contracts, and functions.
The practical effect is that the DORA Article 8 question (which assets support which functions) is a read of the platform, not a fresh exercise each year. The CRD or Solvency II question (which assets are involved in a critical or material outsourcing) is the same read with a different filter.
The asset is a node in the graph, not a row in a spreadsheet.
The common alternative is an asset inventory maintained by IT operations, in a CMDB or a spreadsheet, with criticality filled in against a fixed list. The function catalogue is maintained separately by the business. The supplier list is maintained separately by procurement. Answering the question "which suppliers run the assets that support our critical functions" requires three datasets and a half-day of joining.
On this platform those three datasets are the same dataset, joined already. The asset record references entities. Function records reference the assets they need and the contracts that deliver them. Contracts reference suppliers. The question collapses to a graph traversal with no reconciliation step.
The specific claim is this: the ICT asset register on this platform is not a standalone inventory. It is the node in the same graph that already holds the supplier, contract, function, and entity records, with criticality as a first-class attribute, classified under the same evidence pattern.
CMDBs discover assets. This module regulates them.
A CMDB (or a cloud asset-discovery tool) builds an inventory by watching the infrastructure. It knows what exists, it keeps itself fresh, and it is the right tool for operational questions. It is not the right tool for regulatory questions. It does not know which assets support a critical function under DORA, which assets are subject to a material outsourcing under EBA-GL, or who asserted the criticality classification and when.
This module is the regulatory view. It is not a CMDB replacement and does not claim to discover assets. A firm with a CMDB feeds the register from it; a firm without one maintains the register directly. Either way, the object on this platform is the regulated object: with classification, with review cadence, with links to the functions and suppliers the regulation asks about.
The second structural difference is the function link. Most asset registers stop at "asset × owner × criticality". This register goes further: an asset is attached to the functions it supports, and those functions are attached to the supplier contracts that deliver them. The DORA Art. 8 reconciliation (functions to assets to suppliers) is a single read.
A register, not a monitor.
The module in product today covers the register and its regulatory relationships. It does not cover the operational disciplines a firm runs alongside its asset register: vulnerability scanning, patch management, runtime telemetry, change-management tickets. Those belong to tools the firm already owns. The platform integrates with them at the record level (an asset record can carry a reference to the CMDB identifier or the scanner record) but does not replicate their function.
The DORA Article 8 information-asset reconciliation report (the formal document a supervisor may ask for) is not an in-product export today. The underlying function-to-asset-to-supplier data that the report needs is all in product; producing the specific document format is advisory.
Asset-to-contract direct joins are indirect today: the link flows through the entity and function records rather than a dedicated bridge table. For most regulatory questions that is the correct shape. For a few edge cases a specialist will name the limitation.
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 →