Written by Kevin Dutton, Senior Consultant and ITIL® Master (Version 5), IT Governance Expert.
When the auditors scanned the network
In 2023, the South Australian Auditor-General scanned the networks of six government agencies. The team compared what was actually running with what the agencies’ ICT asset registers said. Of roughly 28,000 assets found, about 5,000 could not be matched to a register.
The details will sound familiar to anyone who has worked in IT or finance. Some agencies were being billed by vendors for ICT assets that were not in their own register.
Decommissioned assets had never been removed. Devices belonged to other agencies or to vendors. Some registers were missing serial numbers, some had duplicate serial numbers, and several had outdated warranty dates.
Here is the interesting part. The Auditor-General reported no major concerns overall. In other words, this is what normal looks like.
At MindMagine, we have worked with banks, insurers, telecom operators, airlines, energy and technology companies across Asia since 2001. We see the same pattern again and again.
Finance keeps one record of the IT estate. IT keeps another. Both are maintained in good faith, and both slowly drift away from reality and from each other.
This article makes a simple case. The way most organisations run configuration management and asset management is dated. AI now gives us the tools to do something better: turn the old records into a federated knowledge lake. It is written for IT and finance together, because neither can fix this alone.
One estate, two clocks
The same server, laptop or software licence usually lives in two systems, owned by two departments, built for two different purposes.
The overlap is large, but the records are kept apart. They use different IDs, follow different update cycles and answer different questions. Sooner or later one is updated and the other is not. There is an old saying for this: if you have one clock, you know the time. If you have two clocks, you are never sure.
The split is built into the frameworks too. When ITIL 4 introduced IT asset management as a practice in its own right, Axelos noted that asset management came from procurement and finance, while configuration management came from IT. ITIL Version 5 keeps both practices, and its Plan, Implement and Control module groups them with change enablement, release and deployment. The frameworks see the connection. Most organisations still run the two as separate worlds.
Why this view is dated
Both records were designed as static registers: filled in by hand, checked once a year, and owned by one department. Each answers its own questions well. Neither answers the questions that matter most today, such as “what does this business service really cost?” or “what breaks if we retire this asset?”.
A practitioner writing on Substack put the gap neatly: for the auditor, the CMDB is a ledger; for the operator, it should be a map. Too often it is updated after the incident, not before the change. A ledger tells you what you own. A map tells you how it all connects.
Organisations now need both, in one view.
Federation, not merging
The answer is not one giant database. It is one logical view in which every fact has exactly one owner.
Many organisations try to stop the two clocks by moving everything into one tool. In our experience this rarely works. Finance will not run its books from an IT tool, and IT will not run operations from the finance system. Both have good reasons.
Federation takes a different route. Each system stays the source of record for its own data, and a connecting layer brings it together. Red Hat describes the same idea: a financial management tool can be the primary home for cost data, while the CMDB mirrors it. We call the connecting layer a knowledge lake: one place that links records and documents from many sources, keeps the relationships between them, and lets people and AI ask questions across all of it.
Four principles make federation work:
- One source of record per attribute. Finance owns cost, depreciation, contracts and warranty. IT owns configuration, status and relationships. Other systems reference that data. They never keep their own copy.
- One shared identity. A common ID, such as an asset tag or serial number, links the asset record, the configuration item and everything known about it.
- Reconcile, don’t copy. Automated checks compare the sources and flag where they disagree, so the gap is found in days, not at year-end.
- Connect more than records. The lake also links incidents, problems, changes, contracts, licences, architecture documents and decisions. One view then shows what something is, what it costs, what depends on it and why it exists.
Every fact keeps one owner; the lake connects them
Change management controls what enters each source. The shared ID connects them, and the lake makes four uses possible.
Garbage in, garbage out
A knowledge lake built on records that nobody owns will give you faster, more convincing wrong answers.
AI makes analysis cheap. It does not make data true. IDC put it plainly: when your CMDB is a mess, AI simply makes that mess happen faster. The international standard for IT asset management, ISO/IEC 19770-1, says the same thing in its own way. Its recommended implementation order starts with trustworthy data, before lifecycle integration and optimisation.
What happens without ownership
The 2017 Equifax data breach is a hard lesson. According to the US Senate investigation, Equifax scanned its network for a known vulnerable software component, but the scans did not find it. Officials knew the scans had limits, because the company knew it lacked a full IT asset inventory. Staff who knew the software was in use were left off the email list that carried the warning. Its two largest competitors kept up-to-date inventories.
In our reading, this was less a tooling failure than an ownership failure. Nobody was clearly accountable for knowing what ran where, and who needed to know.
What accountability looks like
- Every CI and every asset has a named owner. The owner is accountable for the record being correct, complete and current. No owner, no record.
- The connections are owned too. Interfaces, dependencies, locations and relationships need an owner, just like the items themselves. They are the easiest part to forget, and often the most expensive.
- Finance and IT govern together. One shared forum agrees who owns what, settles the conflicts that reconciliation finds and reviews data quality.
- Data quality is measured and visible. Completeness, accuracy and freshness are reported per service and per owner, like any other service metric.
- AI proposes, the owner confirms. Relationships that AI infers stay marked as inferred until the owner verifies them.
Change management: where accountability starts
Change management is the gate to the knowledge lake. It is the only place where additions, modifications and removals of CIs, assets and relationships are approved, so it is where accountability for the data starts.
The rule is simple. If something did not go through a change, it should not be in the system. If something is in the infrastructure but not in the system, something bypassed the process.
When the review does not check reality
In 2012, Knight Capital deployed new trading code to its servers in stages. According to the SEC order, no second technician reviewed the deployment, and the firm had no written procedure requiring such a review. Nobody noticed that one of the eight servers still ran old code. When the market opened, that server sent millions of unintended orders. Knight lost about US$460 million that morning and later paid the SEC US$12 million to settle.
The new code was in place on seven servers. What was missing was a check that the result matched the intent on all eight.
How change management protects the lake
- No record without an approved change. New, changed and retired CIs, assets and relationships enter the lake through an approved change, including standard changes. Procurement, release and disposal link to a change record, so finance and IT stay in step.
- The request states the expected result. Which CIs and assets will be added, changed or removed, and which interfaces, dependencies and locations are affected.
- The review checks reality against the request. Compare what was registered in the lake, and what discovery finds in the infrastructure, with what the change request said. A change is not closed until these match or the difference is explained.
- Every gap goes back to an owner. The change owner or the CI or asset owner fixes it at the source.
The credibility test
The same comparison tells you how credible your change process is. Put what is really in the infrastructure next to what is in the knowledge lake and the federated sources:
- Items with no approved change point to unauthorised or unrecorded changes.
- Results that differ from the request point to weak planning or a weak review.
- A small and shrinking gap shows a change process you can trust.
Recurring gaps are not just data problems. They are input for improving the change process itself.
The finance case
For finance, two clocks cost money in three ways: ghost assets, licence exposure and no true cost per service.
Ghost assets and depreciation
A ghost asset is an item that is still on the books but no longer exists. It was scrapped, lost, moved to a vendor or replaced, and nobody told finance. It overstates the balance sheet and keeps generating depreciation, insurance and sometimes maintenance costs. The mirror image exists too: servers that finance wrote off years ago but IT still runs, often without support and without a refresh plan.
A common cause is simple. The disposal or move is visible in IT, but the update never reaches the finance register. At the University of Texas Permian Basin, internal audit found in 2023 that neither IT nor the accounting office could provide a current list of controlled IT assets, and recorded locations did not consistently match reality.
You will often see a figure quoted for how many ghost assets a typical register holds. We have not used it here: different sources attribute it to different research firms, and we could not trace an original study. Your own reconciliation will give you a better number anyway.
Licence audits and interfaces
Software licences are where an unknown connection becomes a real bill. In SAP UK v Diageo (2017), the UK High Court found that Salesforce-based applications exchanging data with Diageo’s SAP system counted as indirect use of the SAP software. SAP had claimed about £54.5 million in additional licence and maintenance fees. The court ruled on liability and left the amount for later.
The lesson for both IT and finance: an interface is not just a technical detail. It can change what you owe. That is why interfaces and dependencies need an owner and a place in the change review.
Public organisations face the same issue at scale. In 2024, the US Government Accountability Office found that federal agencies did not consistently track the licences they use or compare them with what they bought, and made 18 recommendations to nine agencies.
No true cost per service
When asset cost is not linked to the services it supports, nobody can say what a business service really costs. Budgets are split by guesswork, renewals are decided on habit, and IT struggles to show value. Billing suffers too. The North Carolina State Auditor found that the IT inventory records used to bill other agencies lacked adequate controls, and that IT and agency records were not kept consistent.
A federated knowledge lake fixes this at the root. Cost stays in the finance system, relationships stay in IT, and the shared ID links them. Cost per service becomes a query, not a project.
Rules and standards in Malaysia and APAC
To be added: the Malaysian and APAC regulations, accounting standards and supervisory expectations that apply to asset registers and IT controls.
How AI turns old records into a knowledge lake
AI does not replace your CMDB or your asset register. It does the reading, matching and connecting that was always too much work to do by hand.
Your organisation already holds most of the knowledge it needs. It is spread across the asset register, the CMDB, years of incident, problem and change tickets, contracts, licence agreements, runbooks and architecture documents. Until recently, connecting all of that meant months of manual effort. Current AI tools can take over much of that work.
Capabilities differ between tools, so always test on your own data first.
What AI can do in practice:
- Match records across systems. Compare serial numbers, hostnames, asset tags and purchase orders, and flag likely duplicates, ghosts and unrecorded items.
- Read unstructured text. Pull out which systems, dates and terms appear in tickets, contracts and documents.
- Propose relationships. If changes and incidents keep mentioning two systems together, suggest a dependency for the owner to confirm.
- Give a change board or a finance controller a plain-language picture of what is known about a service or an asset.
- Answer cross questions. “Which assets out of warranty support our payment service?” becomes a question you can simply ask.
Every relationship in the lake carries a trust level, so people know what they can rely on:
A few guardrails keep it safe. AI reads, owners decide. Inferred data never feeds financial reporting until it is verified. Finance data stays behind proper access control. Passwords and other secrets never go into the lake, and code and configuration are summarised, not copied.
How to start
Start small, with one service and one shared report, and let the results win the argument for the next step.
1. Agree the ownership matrix
Finance and IT decide together who owns which CI, asset, relationship and attribute, and confirm that every update goes through change management.
2. Pick one critical business service as a pilot
Map it end to end, instead of trying to model the whole estate.
3. Connect, don't copy
Set up read-only links to the asset register, the CMDB, incident, problem and change records, discovery data, contracts and key documents. The existing systems stay in place.
4. Create one shared ID
Use an asset tag, serial number or CI ID to link the asset record, the CI and related knowledge.
5. Run the " two clocks" report first.
List assets in the register but not in the CMDB, CIs with no asset record, and vendor bills for items in neither. It is a quick, visible win, and it shows both departments the cost of drift.
6. Let AI enrich, owners confirm.
AI reads tickets and documents and proposes relationships. Owners review and verify them.
7. Snapshot and audit continuously
Each run becomes a baseline. Every finding goes back to its named owner, and data quality is reported like any other service metric.
Who does what
What it makes possible
Once the 3sources are connected and owned, four things become possible that were hard or impossible before.
1. Real analysis of your infrastructure and assets
You can see cost per service, assets out of warranty or near end of life linked to the services they support, licences bought versus licences used, and assets nobody uses. Finance gets a register it can defend. IT gets a refresh and renewal plan based on facts.
2. Deeper assessment of incidents and problems
Every incident can be seen together with its CI, recent changes, asset age, warranty status and known errors. AI can spot patterns across incident text, such as the same model, firmware or vendor appearing again and again. Problem management gets stronger candidates, and finance sees which ageing assets are really driving support cost.
3. Structured risk management for changes
Before a change, impact analysis follows the dependency map: which services, interfaces and contracts are touched. History adds context: how similar changes went and which incidents followed. AI proposes a risk view, and the change board still decides. After the change, the review checks the registered result against the request.
4. A baseline before you set requirements
Before a project or a change starts, take a snapshot of what exists, what it costs, what depends on it and what problems it has. Requirements then start from facts, not assumptions. Finance gets a realistic business case, and IT avoids surprises halfway through delivery.
Each of these is only as reliable as the data and the ownership behind it.
Traps to avoid
In our experience, CMDB and asset programmes that stall usually do so for organisational reasons, not technical ones. PwC lists the usual failure patterns: unclear accountability, overambitious scope, manual maintenance, poor data quality and weak links to incident and change workflows. A knowledge lake can fall into the same traps.
- Modelling everything on day one. Keep the number of CI types small and start with what your pilot service needs.
- Treating it as a tool project. Buying a platform does not create ownership. Agree the ownership matrix first.
- Letting one department own it alone. If only IT or only finance runs it, the other side will keep its own clock.
- Fixing data downstream. Correcting a report does not fix the source. Send every finding back to its owner.
- Trusting inf erred data too early. Keep AI-proposed relationships marked as inferred until an owner verifies them.
Back to one clock
The South Australian auditors found thousands of unmatched assets and still reported no major concerns. Drift between finance and IT has become normal. What should no longer be normal is accepting it.
AI has made connecting the records cheap. Ownership and change management make the result trustworthy. Put the three together and you get something neither finance nor IT has had before: one view of the estate that both can rely on, for analysis, for incidents and problems, for change risk and for every new project.
How many clocks does your organisation run? We would like to hear how IT and f inance work together in your organisation, and where it gets stuck.
Contact MindMagine to talk it through, or explore our IT Change Management & Agile Change Control masterclass programme.
Glossary
Plain meanings of the terms used in this article, for readers on both sides.
About
About the author. Kevin Dutton is a Senior Consultant at MindMagine and an ITIL Master (Version 5).
About MindMagine. MindMagine, formerly Quint, has helped organisations across Asia with consulting, training and coaching since 2001, in more than 25 countries. Transforming Minds, Empowering Change.
Sources
- Auditor-General of South Australia, Report 2 of 2024: ICT asset management
- US Senate Permanent Subcommittee on Investigations, report on the Equifax data breach (2019)
- WilmerHale summary of the SEC order against Knight Capital (2013)
- The Register on the Knight Capital loss (2013)
- Society for Computers and Law on SAP UK v Diageo [2017] EWHC 189 (TCC)
- US GAO, Federal Software Licenses, GAO-24-105717 (2024)
- University of Texas Permian Basin, IT Asset Management audit (2023)
- North Carolina Office of the State Auditor, performance audit PER-2012-7285
- ISO/IEC 19770-1:2017, IT asset management systems
- Axelos, IT asset and configuration management and ITIL 4’s service value system
- ITIL Plan, Implement and Control (Version 5) overview
- Red Hat, What is a CMDB?
- IDC, The dirty secret of AI in ITSM (2026)
- PwC Luxembourg, CMDB isn’t dead
- The CMDB Delusion (Substack)
