A cyber security asset inventory is supposed to answer a simple question: what do we have, and is it protected? In practice, most Australian IT teams can't answer either half with confidence. The inventory exists, but it's a snapshot from a procurement cycle ago, missing cloud workloads, shadow SaaS, and half the endpoints that arrived after the last refresh. Attackers don't need much more than that.
Why inventories fall behind so quickly
The core problem isn't that organisations don't build inventories. They do. The problem is that they build them once, attach them to a compliance audit, and treat them as done. A live IT environment changes faster than any manual process can track. New cloud instances spin up in minutes. Developers bring in third-party services. Contractors connect personal devices to corporate networks.
Three patterns show up consistently across Australian organisations that have gone through incident reviews:
- The inventory lives in a spreadsheet maintained by one person who has since left or changed roles.
- Cloud assets are tracked separately from on-premises assets, so nobody holds a complete view.
- Software inventory is maintained for licencing purposes, not security purposes, and misses versions, patch levels, and EOL status.
The result is that when a zero-day vulnerability lands, the first question a team asks is "do we have this software?" and the honest answer is "we think so, in a few places, maybe." That's not a defensible position.
The specific gaps that cause the most damage
Not all inventory gaps carry equal risk. The dangerous ones tend to cluster in a few areas.
Unmanaged endpoints. BYOD policies and remote work arrangements have added thousands of devices to Australian corporate networks that never appear in asset registers. A laptop connecting over VPN, a personal tablet used for email, a smartphone on a mobile device management exemption. Each one is a potential entry point with no patch history recorded anywhere.
Cloud-native resources. Infrastructure-as-code and auto-scaling mean assets come and go without a human reviewing a purchase order. An S3 bucket created by a developer on a Friday afternoon, a Lambda function provisioned by a CI/CD pipeline, a database snapshot left in a staging account. Cloud IAM misconfigurations multiply when nobody knows the resource existed in the first place.
End-of-life software. Software asset management tools typically track what's installed. They're less good at flagging that what's installed stopped receiving patches eight months ago. EOL operating systems and libraries sit inside containers and virtual machines, invisible to tools that look at the OS layer rather than the application layer.
Third-party integrations. Every SaaS tool that plugs into your environment via an OAuth token or API key is, functionally, an asset. It has access to your data. It can be compromised. Most asset inventories don't record it.
What a usable inventory actually looks like
A usable asset inventory isn't a list of devices. It's a continuously updated data model that captures what an asset is, what it runs, who owns it, what it connects to, and what its current security state is. That last field is the one most inventories omit entirely.
Several technical approaches combine to keep an inventory current. Network scanning tools like Nmap and more specialised agents such as those in Tenable or Qualys platforms discover assets by reaching out to them, rather than relying on humans to record them. Configuration management databases (CMDBs) pull from those discovery tools automatically. Cloud-native solutions like AWS Config, Azure Resource Graph, or GCP Asset Inventory track infrastructure in real time at the platform level.
The harder part is stitching those data sources together. Most Australian organisations running hybrid environments have assets split across on-premises directories, cloud consoles, and endpoint management platforms. None of those systems talks to the others by default. Building the integrations to merge them into a single view takes time that security teams rarely have.
Ownership is the other missing field. An asset without a clear owner has no one accountable for patching it, decommissioning it, or investigating alerts against it. Tagging cloud resources with an owner and business unit at provisioning time, and enforcing that policy in code, is far more reliable than trying to attribute ownership retroactively during an incident.
How asset inventory connects to broader security controls
The Australian Signals Directorate's Essential Eight maturity model places application control and patch management at the top of the mitigation list. Both controls depend entirely on knowing what's running. You can't patch software you haven't catalogued. You can't apply application control policies to assets that aren't in your inventory. The inventory isn't one control among many. It's the prerequisite for almost every other control working as intended.
The same logic applies to privileged access reviews. If your asset inventory doesn't include the service accounts and API credentials attached to each system, you can't reliably audit who has access to what. Attackers who compromise a forgotten service account on a forgotten asset can move laterally for months without triggering any alert keyed to known assets.
Practical steps Australian IT teams can take now
The gap between a spreadsheet and a live asset inventory doesn't close overnight. A realistic remediation path starts with discovery rather than documentation. Run a network scan across all subnets, including those provisioned for cloud VPCs and VPNs, and compare the output to what the CMDB says exists. The delta is your immediate problem list.
After discovery, enforce ownership at provisioning. Every new asset, whether a virtual machine, a SaaS subscription, or an API integration, should require an owner field and a business unit tag before it can be activated. This is a policy and tooling problem, not a cultural one. Make it impossible to provision without tagging, and the ownership problem largely resolves itself going forward.
Finally, schedule automated reconciliation. The inventory should be compared against discovery outputs weekly, not annually. Discrepancies should generate tickets, not reports that sit in an inbox. A CI/CD pipeline that provisions infrastructure should also update the asset record automatically. Manual processes will always drift; automated ones won't unless the integration breaks, which is itself a discoverable failure.
None of this is novel. The ACSC has published guidance on asset discovery and inventory as part of its broader cyber hygiene framework for years. The gap is almost never in awareness of what good looks like. It's in the operational discipline to treat asset inventory as a live system rather than a compliance artefact.