On the day it was handed over, the inventory was complete. Nine months later nobody can say how many of its entries are still true, which is another way of saying that a fair number are not. That is not negligence. It is the predictable consequence of how the record was created.
Half-life is not a property of the list
An asset inventory does not age at its own pace. It ages at the pace at which the organisation changes, and nobody who maintains the inventory sets that pace. A business unit signs up for a subscription. A development team spins up a cloud environment. A migration moves a processing activity to another region. A provider swaps a subcontractor. A role is renamed in a reorganisation.
Each of those events devalues an entry, and none of them creates a task.
An uncomfortable conclusion follows. An inventory that stays current only through deliberate maintenance is, in a changing organisation, structurally behind. The question is not how disciplined the maintenance is. The question is where the update comes from.
Five causes, and none of them is laziness
Collection was a project; maintenance is a request. The collection had a budget, a deadline and an owner. Maintenance has none of those. It lives in a policy and competes with work that has a client.
No system of record per field. The same value is maintained in three places: the inventory, the contract database and a spreadsheet in the business unit. Once they diverge, none of the three is defensible, and reconciliation is renegotiated every time.
The owner is a role with nothing to answer. An owner who is never asked a question does not notice a wrong value. Ownership is not created by populating a field; it is created when somebody regularly has to answer something for which they need the entry.
The record is decoupled from the processes that create reality. Procurement, access provisioning, commissioning and decommissioning change the landscape. If none of those transactions automatically creates or amends an entry, the entry is optional, and optional work is the first thing dropped under load. This is also where shadow IT comes from, not as a breach of the rules but as the shorter route. A business unit that can have a tool in ten minutes on a corporate card, and waits six weeks for the same thing through procurement, decides predictably. Shadow IT is therefore not a discipline problem but the difference between two lead times, and it shrinks only when that difference shrinks.
The level of detail exceeds the use. A data model with forty fields, six of which anybody ever queries, decays first in the other thirty-four. The damage does not stay there: anyone who sees that a third of the fields are visibly stale stops believing the six as well.
What makes a record survive
Invert each cause and you get a property.
A by-product, not an end in itself. Draw as much as possible from systems that have to be right for other reasons: accounts payable knows who gets paid; identity management knows who exists; the cloud provider's API knows what is running; device management knows what was issued. Those sources are maintained because otherwise an invoice goes unpaid or somebody cannot log in, not because a policy asks for it.
One source and one owner per field.
| Field | Defensible source | Trigger for update |
|---|---|---|
| Application or service | procurement and operations | commissioning, decommissioning |
| Business owner | organisation and role directory | change of role, reorganisation |
| Process supported | business impact analysis | process change |
| Protection requirements | protection requirements assessment | change to the procedure or the data |
| Provider and contract | contract database, accounts payable | signature, renewal, termination |
| Place of processing | contractually committed statement | migration, change of provider |
Events rather than cycles. The trigger for an update is a transaction, not a date. An annual stocktake finds an error on average half a year after it arose, and it is during that half year that the record is needed.
Make the discrepancies visible. The actual product of a well-run inventory is not the list but the difference. What is running that is not in the record? What is in the record that no longer answers? Who has an account but no entry in the HR system? Those discrepancies are tasks with an addressee.
Use enforces maintenance. The strongest mechanism is the cheapest. A record from which questions are answered every day gets corrected by the people using it. Who would be affected by this vulnerability? Which processes depend on this provider? Whom do we have to inform if this system fails? An inventory that surfaces once a year in an audit has not a single such corrector.
A CMDB, IT asset management and a security inventory are not the same thing
Most organisations already hold a record of some kind, so the obvious question is why it does not suffice. Usually it is a CMDB out of IT service management, or an IT asset management record out of procurement. Both are carefully kept and still fail to answer the security questions, because they were built for different ones.
| CMDB | IT asset management | Inventory for information security | |
|---|---|---|---|
| Governing question | what depends on what technically when something breaks? | what do we own, what does it cost, when does it run out? | what carries which business process, and how heavily does its loss weigh? |
| Unit | configuration item | contract, licence, device | information, process, and the objects carrying them |
| What drives maintenance | incident and change handling | cost, licence position, contract renewal | risk analysis, protection requirements, evidence |
| Typical gap | externally sourced services with no technical coupling | anything that generates no invoice | device and network detail nobody ever queries |
| What is missing for security | business owner, protection requirements, process supported | operating state, reachability, dependencies | – |
None of that is a judgement about quality. A CMDB that does not carry externally sourced services is not badly maintained; it does not carry them because they hang off no change process. An IT asset management record that misses a tool used free of charge is doing exactly what it was built to do: it follows the money.
The practical conclusion is therefore not another list. Do not build a third record alongside the other two; build a layer above them. Take from the CMDB and from IT asset management whatever is defensible there (existence, technical coupling, contract, lifecycle) and add only the three fields that are structurally missing and that neither source will ever produce: the business owner, the business process supported and the protection requirements. Those three are business statements. No scanner, no invoice and no change ticket generates them.
The reconciliation between the records is itself a finding. What sits in the CMDB but under no contract: possibly a system with no provider behind it. What sits in accounts payable but in no CMDB: the likeliest place to find shadow IT. What sits in both but has no business owner: the candidate for the next ownerless service.
Completeness is the wrong first question
The reflex after an audit is that the record must be made complete. Doing it in that order is the most expensive and least effective route available.
For the questions that actually hang on it (who is affected by a vulnerability, how far an incident reaches, what happens if a provider fails), you do not need more rows. You need correct relationships between a few rows. A record that says, for the thirty services with the highest protection requirements, which process, which owner and which provider hangs off each, answers more questions than a complete list with no relationships in it.
So start where the protection requirements are high and leave the rest deliberately coarse. A record documented as incomplete is a work in progress. A record that appears complete and whose quality nobody knows is a hazard, because decisions get made on it.
What depends on it
The instruments rarely require an asset inventory by that name. They presuppose one throughout. A risk analysis without a record has no subject matter; it is no accident that the catalogue of measures in § 30(2) sentence 2 BSIG opens, at number 1, with risk analysis and security concepts. And that catalogue is a binding minimum, because the measures have to cover at least what it names. An ISO/IEC 27001 scope cannot be determined while it is unclear what sits inside it. A protection requirements assessment needs objects to assign requirements to. And the question of who has to be informed during an incident is a query against exactly this record.
The record is therefore not an evidence document but the data foundation from which the evidence is produced. That also explains why programmes that address it last are slow everywhere else. How assets are kept in one record with owners, classification and the requirements that apply is shown on the asset management page.
The property that keeps an inventory alive
Of the five causes, one can be removed structurally, and it is the most important: a register kept only for audits has no defender between two audits. Every other cause bites harder when that one is present.
In Rizzqo the inventory is therefore not a side filing but the source of the work. An object's classification, meaning its category and subcategory, is the key by which requirements are dispatched: a newly recorded object immediately gets its requirement list with assignees, and if it is reclassified, newly applicable requirements are added and no-longer-applicable ones fall away. Leaving the entry out does not buy a quieter list but produces a system with no duties and no owner, which shows up in an audit. The incentive therefore points the same way as the maintenance.