An asset register is not an IT inventory
Your CMDB knows what hardware exists. It does not know what data sits on it, who owns it, how it is classified, or what stops working if it fails. Those are the questions every framework actually asks — and they are the ones almost no register answers.
Everything else rests on this
From the compliance programmes we build and run in Saudi Arabia: asset governance is the control most frequently marked as implemented while being substantially false. Not through dishonesty — because an inventory that was accurate when it was built has quietly stopped being accurate, and nobody has had a reason to check.
The reason it matters more than its position in a framework suggests is structural. Risk attaches to assets. Controls protect assets. Evidence proves the controls operate. If the bottom layer is wrong, everything above it is confidently wrong — and confidently wrong is worse than visibly incomplete, because nobody goes looking.
Artefacts proving the controls operate. Meaningless if the control protects something you no longer have, or misses something you do. Evidence management →
What you do to protect assets. Scoped by what the asset is and how it is classified — so a control applied to the wrong classification is either wasted effort or an unprotected exposure.
Risks attach to assets. A risk register without asset references describes worries rather than exposures, which is why it is hard to prioritise. Risk and audit →
What you have, what it holds, who owns it, how it is classified, and what depends on it. Get this wrong and every layer above inherits the error without anyone noticing.
Why the CMDB is not enough
IT asset management and asset governance overlap and are not the same discipline. They were built to answer different questions.
What exists, and where
- What hardware and software we have
- What version, what patch level
- Which team pays for it
- When the licence expires
- Where it sits in the network
What it means, and who answers for it
- What data it holds, and of what classification
- Whether that data includes personal data
- Who owns it — a named person, not a department
- What controls apply because of its classification
- What stops working if it fails, and what depends on it
- Whether it may be hosted where it currently is
The second list is what an assessor asks about and what a risk assessment needs. A CMDB is a genuinely useful input to it — often the best starting point you have — but exporting a CMDB into a compliance platform gives you a technology list, not an asset register, and the difference shows up during the first serious assessment.
The half most registers are missing
Most asset registers cover technology. In Saudi Arabia, a large share of what you are assessed on is data.
| Asset type | Examples | Who asks about it |
|---|---|---|
| Technology | Servers, endpoints, network devices, applications | The NCA, through the ECC and its specialised control documents |
| Data | Datasets, records, documents, databases | The NDMO for government data governance and classification |
| Personal data | Employee, customer and citizen records | SDAIA, under the PDPL — a processing activity is an asset |
| Cloud services | Hosted platforms, SaaS, storage | The NCA's cloud provisions, and vendor assessment |
| Critical systems | Systems whose failure has national or sector consequence | The NCA, with additional controls where designated |
| Suppliers | Third parties holding or processing your data | Every framework — and your data sits on their assets |
The last row is the one that unsettles people. A dataset hosted by a supplier is still your asset, still classified, still subject to retention and transfer rules. It just happens to live somewhere you do not control — which makes the vendor record and the asset record two views of the same exposure.
Classification decides everything after it
This is the single field with the most downstream consequence, and it is routinely assigned by whoever created the record.
Which protections apply
Encryption, access restriction, monitoring depth and handling rules are all determined by classification. Classify too low and the asset is under-protected; classify too high and you spend effort where it is not warranted.
Where it may live
Whether an asset may sit with a particular provider, or in a particular region, follows from its classification. A hosting decision made before classification is a decision made blind.
Whether it may leave
Classification and the presence of personal data determine whether an asset can cross the Kingdom's borders and under what conditions — which makes it a PDPL question as much as a security one.
How long you keep it
Retention obligations attach to what the data is, not to where it happens to be stored. Without classification, retention is applied by storage system rather than by requirement.
How seriously you respond
The severity of an incident is largely a function of what was affected. An incident process that cannot look up the classification of the affected asset is guessing at severity during the worst possible hour.
How it is destroyed
Secure disposal requirements follow classification too — and this is the end of the lifecycle that gets skipped most often, usually when equipment is replaced in a hurry.
In our experience classification is assigned once, at creation, by whoever happened to create the record, and then never revisited — even though the data in a system changes over time and its classification with it. A register where nothing has ever been reclassified is a register nobody has reviewed.
Why asset registers go stale
Every organisation has built one. Most are out of date, and the reason is structural rather than a failure of diligence.
A register built through an annual survey is already wrong before the survey is finished, because the estate changed while people were filling in the form. The next survey rebuilds it from scratch, because reconciling last year's list against reality is harder than starting again. And the person who knows what a given system actually holds is rarely the person who receives the form.
A point-in-time snapshot of a moving estate
Annual collection produces a register that is accurate for approximately one day and degrades from there. Nobody notices, because nothing depends on it visibly.
Assets owned by a department
An asset owned by "IT" is owned by nobody. When the classification needs reviewing or the disposal needs confirming, a department cannot answer — only a person can.
The systems nobody declared
A tool adopted by a team, holding real data, in no register. These are found during incidents rather than during surveys, because a survey only reaches the people who already know they should answer.
Assets that never leave the list
Registers grow because adding is easy and removing requires confidence. A register full of decommissioned systems is as misleading as one missing live ones, and considerably more common.
Built for an audit, not for use
A register assembled to pass an assessment is maintained until the assessment passes. One that the risk process and the incident process actually read stays current because being wrong has a cost.
Make something depend on it
When risks reference assets, controls are scoped by classification, and incidents look up what was affected, the register is maintained because people need it to be right — not because someone asked.
Asset governance in Govrly
A register the rest of the programme reads, rather than one that sits beside it.
Technology and data together
Systems, applications, datasets and processing activities in one place, because the NCA asks about the first two and the NDMO and SDAIA ask about the others — and they are frequently the same thing viewed differently.
A field with consequences
Classification recorded per asset and used to scope which controls apply — so it is a working field rather than a label, and reclassification is a change that visibly propagates.
A named person
Each asset carries an owner who can answer for it, with a review date. A department is not an owner, and an asset whose owner has left is a finding waiting to be raised.
Exposures, not worries
Risks reference the assets they threaten, so the register is read during risk assessment rather than during audit preparation — which is what keeps it current.
Scope that follows classification
Controls apply to assets by classification and type, so you can see what protects a given asset and what an asset is missing — rather than inferring both from a policy document.
Where your data actually sits
Assets hosted or processed by a supplier linked to that vendor's record, so the asset view and the vendor view describe the same exposure instead of two unconnected ones.
Building a register that stays true
The aim is not completeness on day one. It is a register that has a reason to be correct on day two hundred.
- Start from what already existsThe CMDB, the licence list, the network inventory, the finance asset register. None is complete and together they are a far better starting point than a blank form.
- Add the data assetsDatasets, records and processing activities. This is the half most registers are missing and the half the NDMO and SDAIA ask about.
- Assign a named owner to eachA person, not a department. This step is slow and it is the one that determines whether the register is maintainable at all.
- Classify, with the ownerClassification assigned by whoever created the record is a guess. Assigned with the owner it is a decision, and it can be defended when an assessor asks why.
- Record dependencies for the critical fewNot everything. For the assets whose failure actually matters, record what depends on them — that is what makes an incident assessment fast.
- Connect risks and controls to assetsThis is the step that makes the register load-bearing. Once the risk process reads it, being wrong has a visible cost.
- Handle decommissioning explicitlyRemoval needs a process, or the register grows into a list of things that used to exist and quietly loses credibility.
- Review on change, not on a calendarAn annual survey produces an annual snapshot. Review triggered by a new system, a change of owner, or a reclassification produces a register that tracks reality.
Technology and data assets in one register, each classified and owned by a named person, with controls scoped by classification and risks referencing the assets they threaten — so the register is read by the rest of the programme rather than maintained alongside it.
See it in a demo →Asset governance — FAQs
Is this the same as IT asset management?
They overlap and answer different questions. An IT inventory tells you what exists, its version and who pays for it. Asset governance tells you what data it holds, of what classification, who owns it, which controls apply because of that classification, and what depends on it. A CMDB is a useful input; it is not an asset register.
Can we just export our CMDB?
It is the best starting point most organisations have, and it is a starting point rather than the answer. What comes across is the technology list; what has to be added is classification, named ownership, data holdings and dependencies. The gap between the two shows up during the first serious assessment.
Are data assets really assets?
Under the frameworks that apply here, yes, and they are the half most registers are missing. The NDMO standards govern government data classification, the PDPL concerns personal data holdings, and a processing activity is an asset in every practical sense — it has an owner, a classification, retention obligations and a lifecycle.
Why does classification matter so much?
Because nearly every downstream decision follows from it: which controls apply, where the asset may be hosted, whether it may leave the Kingdom, how long it is retained, how severely an incident is treated, and how it must be destroyed. A wrong classification makes all of those wrong at once, and quietly.
Our register is out of date. How do we recover?
Not by running another survey. Start from the sources that already exist, assign named owners, and connect risks and controls to the assets. Once the risk process and the incident process read the register, it stays current because being wrong has a visible cost — which an annual survey never creates.
Who should own an asset?
A named person who can answer for it — typically in the function that operates or relies on it rather than in compliance. An asset owned by "IT" is owned by nobody, and when a classification needs reviewing or a disposal needs confirming, a department cannot answer.
What about assets hosted by our suppliers?
They are still your assets — still classified, still subject to retention and transfer rules — they simply live somewhere you do not control. Linking the asset record to the vendor record means the two describe the same exposure rather than two disconnected ones, which is what a privacy or third-party assessment expects.
How do we find the systems nobody declared?
The same discovery exercise that finds unassessed vendors finds them, because they are usually the same thing — a tool adopted by a team, holding real data, outside any register. Surveys do not find these, because a survey only reaches people who already know they should answer.
Do we need to record dependencies for everything?
No, and attempting it is how asset projects stall. Record dependencies for the assets whose failure actually matters. That is what makes an incident assessment fast, and it is achievable — whereas mapping every dependency across the estate is a project that never finishes.
How does this connect to the rest of the programme?
It sits underneath it. Risks attach to assets, controls protect assets, and evidence proves the controls operate. A register that the risk and incident processes read is maintained as a consequence of being used — which is the only mechanism that keeps one accurate over time.
Find out what your register is missing
Usually the data assets, the named owners, and the systems nobody declared.