What counts as an asset
In information security an asset is more than a device with an inventory number. The usual distinction runs across two levels: primary assets (the information itself and the business processes that handle it) and supporting assets that carry them: applications, IT systems, networks, storage media, sites and rooms, the service providers in use, and staff with particular knowledge.
The order matters.
Record only the supporting assets and you have a list of equipment. It becomes a basis for decisions once it is linked to the business processes, because you can then answer which process stops when a given system is unavailable.
Which fields you need
| Field | What it is for |
|---|---|
| Unique identifier and name | mapping across system boundaries without confusing names |
| Type and category | selecting the requirements and modules that apply |
| Owner and business responsibility | the addressee for classification, approvals and risk decisions |
| Protection need per objective | the yardstick for whether the controls are appropriate |
| Operating model and location | telling in-house operation, outsourcing and cloud use apart |
| Dependencies | the basis for outage and propagation analysis |
| Life cycle status | catches systems out of vendor support before they become a problem |
| Reference to contracts and providers | the link to processing agreements and third-party risk |
| Criticality flag | separates the assets that carry heightened duties from the rest of the estate |
The owner is the most important field
A register without named owners creates work but no decisions. The owner classifies the protection need, approves access, carries the risk, and is the person to ask when an incident forces the question of whether a system may be shut down. A common mistake is to assign ownership wholesale to IT: IT operations is accountable for technical operation, not for the business value of the information being processed.
The life cycle of an entry
An asset register is not a stock, it is a flow. Every entry passes the same stations, and each one triggers a different obligation.
| Station | What happens in the register | What hangs off it |
|---|---|---|
| Procurement or in-house build | create the entry, set type and owner | provider assessment, contract, where applicable a data protection impact assessment |
| Go-live | classify the protection need, link the dependencies | derivation of the controls, inclusion in backup and monitoring |
| Operation and change | keep classification and dependencies current | fresh risk assessment on any material change |
| End of vendor support | change the life cycle status | decision on replacement, isolation, or a documented residual risk |
| Decommissioning | retire the entry, do not delete it | media disposal, withdrawal of access rights, contract termination, return of assets |
The last row is the one most often got wrong. Delete the entry when the asset goes and the evidence goes with it: that it ever existed, and that it was taken out of service properly. The correct move is a status change with a date.
How it differs from neighbouring registers
| Register | Purpose | Basis |
|---|---|---|
| Asset inventory | steering information security across the whole estate | ISO/IEC 27001, IT-Grundschutz |
| Record of processing activities | demonstrating accountability under data protection law | Art. 30 GDPR |
| Inventory of information and ICT assets under DORA | identifying and classifying the assets that carry ICT-supported functions, and their dependencies | Regulation (EU) 2022/2554, Article 8 |
| Register of information under DORA | overview of contractual arrangements on ICT services | Regulation (EU) 2022/2554, Chapter V, Section I, Articles 28 to 30 |
| Configuration management database (CMDB) | operational and change control for IT | IT service management |
The registers overlap but do not replace each other: different addressees, different mandatory fields, different triggers for updating. The two DORA rows are the pair confused most often, although they answer different questions: one is what the organisation runs, the other what it has bought in. Better to build all of them on a shared set of objects than to run them independently. Otherwise they drift apart within a short time, and during an incident none of them is treated as reliable.
What DORA requires of an inventory
Of the sources named on this page, Regulation (EU) 2022/2554 is the one that puts the inventory duty into binding words, and it describes almost exactly the structure recommended here. It binds financial entities directly. For everyone else it is worth reading as a model, because no other instrument is this specific.
- Article 8(1): identify, classify and adequately document all ICT-supported business functions, roles and responsibilities, together with the information assets and ICT assets supporting those functions and their dependencies. The adequacy of that classification is reviewed at least yearly.
- Article 8(4): identify all information assets and ICT assets, expressly including those on remote sites, and map the ones considered critical, together with their configuration and the links and interdependencies between them.
- Article 8(6): maintain the corresponding inventories and update them periodically and on every major change.
- Article 8(7): legacy ICT systems get an ICT risk assessment of their own, at least yearly.
Two of those choices travel well beyond the financial sector. The legislator separates the function from whatever carries it, which is the primary and supporting split by another name. And it asks not only for the list but for the edges between the entries: configuration, links, interdependencies. A register without dependencies does not answer that description.
How the register stays current
Completeness is not decided at the first stocktake but at the inflows. An asset register stays current only if it is connected to the processes in which assets appear and disappear: procurement, change procedures, joiners and leavers, contracting with service providers, and decommissioning. Automated discovery on the network and in the cloud supplements this but does not replace the business-side maintenance: it finds systems, not their owner, purpose or protection need.
The blind spot that remains is shadow IT: services procured by departments themselves, which show up neither in procurement nor in a network scan. It is contained less by technology than by organisation, for example by reviewing spend and by offering a low-friction way to register a new service.
The completeness test
The question that brings a register down is not "is this entry right?" but "how do you know nothing is missing?". Completeness cannot be shown from the register itself. It can be shown only by reconciling it against sources that came into existence independently of it.
| Cross-check | What it surfaces |
|---|---|
| Accounts payable and cost-centre reports | paid-for services with no entry, the most reliable route to shadow IT |
| Sign-in logs from the identity provider | applications that are actually in use, whatever was approved |
| Domain and certificate inventory | externally reachable services nobody owns any more |
| Network and cloud discovery | systems without an owner, test environments running on production data |
| Records of processing activities and the contract database | providers that process data but are not carried as assets |
Every divergence is a finding about a process rather than a data-entry slip: it shows that one of the inflows is not working. Add the missing entry alone and you have treated the symptom and left the inflow as it was.
Third-party and shared assets
Not every asset in scope belongs to the organisation. Employee-owned devices, customer systems, environments run jointly with a partner and data held at a provider still belong in the register as soon as your own information sits on them. Three further entries are needed for these: the owner on the other side, the basis on which the asset is used, and who carries which obligation when it is decommissioned. Leave them out and the gap does not show up in operation. It shows up at the end of the contract.
Regulatory context
ISO/IEC 27001 presupposes a register of assets with ownership assigned; without one, neither the risk assessment nor the scope can be evidenced. Its Annex A carries measures of its own in the organisational theme, covering the keeping of the inventory and the rules for acceptable use of the assets recorded in it. IT-Grundschutz, the German federal methodology, opens with the structure analysis, which is exactly this exercise. In Germany the catalogue in § 30(2) sentence 2 of the BSIG, the national NIS2 transposition, requires at no. 9 concepts for personnel security, access control and the administration of ICT systems, products and processes; an estate that has never been recorded cannot be administered on that basis. In every case the register is not an end in itself but the precondition for any further statement having a reference point at all.
What auditors actually ask
- Show me an asset that was added in the last few months, and the transaction it came out of.
- Who owns this system, and what classification did they set, with a date?
- Which business processes stop if this service is unavailable?
- Show me an asset that was decommissioned, and the evidence that it was wound down properly.
All four aim at the same place. What is examined is not the list but its connection to a transaction, a person and a point in time.
How Rizzqo turns the register into work
An asset register justifies its maintenance cost only once something follows from it. That is precisely Rizzqo's approach: the register is not a side filing but the place where the compliance work originates. Modelling happens in the two layers this entry describes. Primary assets, meaning information, processes and services, carry the protection needs and the categories of personal data. Supporting assets, meaning applications, systems, sites, providers and people-functions, hang beneath them and inherit those properties along the chain.
The decisive difference lies in the classification. It is not descriptive but the key by which requirements are dispatched: as soon as an asset is saved with a category and subcategory, the requirements held for that classification appear against it. Reclassify it and newly applicable requirements are added while no-longer-applicable ones fall away. And because every asset carries an owner and every requirement an assignee, work is routed rather than announced. Coverage follows from the finalised requirement answers, not from a self-declaration.