The asset nobody owns
The most dangerous asset in your enterprise is the one nobody owns. Not the unpatched server. Not the shadow SaaS. The one that does not appear on any inventory, has no named owner and maps to no business outcome.
Most security programmes begin with controls: endpoint protection, a SIEM, application scanning, cloud hardening, identity controls, more telemetry. All of it matters. But there is a prior question. Do we know what we are protecting, why it matters to the business, who owns the risk, and whether the controls protecting it are working? For many enterprises the honest answer is less certain than the dashboards suggest.
You can’t defend what you haven’t classified.
Asset clarity in one view
Every cyber incident is a failure of visibility, ownership or accountability. Tools do not fix any of those. Governance does.
Skip step two, and every downstream control is a guess.
- No clear view of crown-jewel assets
- No ownership accountability
- Overconfidence driven by tool spend
- Post-incident surprises
- Asset inventory mapped to business value
- Named owners for data, applications and identity
- Risk reports aligned to assets, not incidents
- Security spend justified by risk exposure
Every incident is a failure of one of three things
VisibilityNobody knew the asset existed, what it held, or what depended on it.
OwnershipSomebody knew, but nobody was responsible for it.
AccountabilitySomebody was responsible, and nothing happened.
Tools do not fix any of those. Governance does. That is why cyber security cannot begin with tools alone.
The sequence every mature programme runs
Identify: what existsDiscover continuously, and beyond servers and endpoints: applications, APIs, cloud workloads, SaaS, identities, data stores, third-party connections, automation accounts, and now AI systems and agents.
Classify: what mattersWhat information does it process? Is that data personal, regulated or proprietary? Does the asset support revenue, is it exposed, and does its failure create a regulatory obligation?
Prioritise: what is criticalExposure, business criticality, threat likelihood and consequence, weighed together. Budgets are finite, so prioritisation happens either deliberately or by accident.
Protect: what is at riskThe right controls on the right assets, proportionate to exposure. Not every control, everywhere.
Skip step two, and every downstream control is a guess.
At Rhinexa we add a fifth step: assure. Showing that a control existed at the last audit is not the same as showing that it is operating now. The progression is policy, control, operation, evidence, assurance. A programme becomes credible when it moves from “we have controls” to “here is the evidence that they are working”.
The six asset classes your board should be able to name
Each class has a business consequence when it fails. If your risk register does not tie back to these, you are reporting incidents, not managing risk.
Most registers now need a seventh line. AI systems and agents consume sensitive data, carry identity and increasingly take actions through tools. They belong in the same asset, identity, policy and assurance model, not in a separate one. AI agents need identity, policy and evidence covers that shift.
What the board should actually worry about
Warning signs
- No clear view of crown-jewel assets
- No ownership accountability
- Overconfidence driven by tool spend
- Post-incident surprises
What good looks like
- Asset inventory mapped to business value
- Named owners for data, applications and identity
- Risk reports aligned to assets, not incidents
- Security spend justified by risk exposure
If your CFO can name every revenue stream but your CISO cannot name every crown-jewel asset, that is the gap your next breach report will expose.
Five questions for the board
Boards do not need operational inventories. They need confidence that management understands the organisation's most consequential exposures.
- Criticality. What are our most critical cyber-dependent business assets?
- Accountability. Who is accountable for each of them?
- Consequence. What happens, operationally, financially, regulatorily and reputationally, if they fail?
- Protection. Which controls protect them?
- Evidence. What shows that those controls are operating effectively?
If answering those questions takes several teams three weeks and a reconciliation of spreadsheets, that is itself useful risk information.
Ownership is where governance breaks
Technical custody is not risk ownership. An infrastructure team operates a server; it does not own the business consequence if the application on it becomes unavailable. A security team finds a vulnerability; it does not own the decision to accept the risk. The GRC team records the risk; it does not own remediation.
For every important asset the organisation should be able to name the business owner, the technical owner, the data owner where relevant, the control owner and the risk owner. Those may sometimes be the same person. They should never be ambiguous.
From inventory to assurance
InventoryWe know what exists.
OwnershipWe know who is accountable.
Business criticalityWe understand what failure means.
Risk-aligned controlSecurity investment follows business exposure.
Continuous assuranceWe can demonstrate that critical controls remain effective.
Maturity does not end with an accurate inventory. It ends with evidence-backed confidence.
One structural reason programmes stall at stage one: budgets are organised by tool category. Endpoint, network, SIEM, identity, application, cloud, data. Those categories are useful for operations and they fragment the view of risk. A single critical business service depends at once on an application, several cloud workloads, a privileged identity, a few APIs, sensitive data, third-party SaaS, network connectivity and, increasingly, an AI component. Protecting each in isolation does not show that the service is resilient. The mature question is: what business outcome are we protecting, and can we show that the combined controls are sufficient?
Where to begin
Do not wait for a perfect map of the estate. Start with the crown jewels: the ten or twenty business services where cyber failure would hurt most. For each, establish the owner, the supporting assets, the sensitive data, the critical identities, the major dependencies, the relevant threats, the expected controls and the evidence available today.
Then ask three questions. What do we know? What are we assuming? What can we prove? The gaps between those three answers are where the real work begins.
You cannot govern what you cannot see.
Cyber security does not start with a SIEM. It starts with a list. Which of the six classes is weakest in your programme right now?
Krishna works at the intersection of cyber security, infrastructure, AI and enterprise risk, with a focus on engineering trustworthy and resilient technology foundations.
Follow on LinkedInThis perspective expands a post first published by the author on LinkedIn.
