You Cannot Secure What You Cannot See. What Does Your Asset Register Miss?

A booking service stops mid-afternoon. Within minutes the asset register is open, and every row is correct: right hostnames, right owners, reviewed last quarter.

The failed component talks to an interface configured years ago and to a supplier retained on a contract held elsewhere. Neither was ever a row. Take this as an illustration rather than a case study, but most service owners will recognise it. None of it makes the register wrong. Completeness counted in entries says little about how far an outage travels, because outages travel along connections.

A list records what somebody remembered to add

Four areas are particularly likely to expose weaknesses in an asset register.

Some of these assets may already be recorded individually. The problem is that the register does not necessarily explain how they interact, which services rely on them or what happens when one fails. A configuration management database (CMDB) can hold those relationships, and the NCSC describes one as a potentially significant part of an asset management solution. An inventory without them is still only a list.

Shadow IT is the one category that sits outside the register by definition. The NCSC, which also calls it grey IT, describes it as assets used within an organisation for business purposes but not accounted for in asset and risk management processes. That makes it an unknown risk, because it is unlikely to align with the organisation's security or data governance policies.

What happened when government measured its own estate

In the first year of GovAssure, between April 2023 and July 2024, 35 departments self-assessed 72 IT systems they identified as critical to their most important services, and independent reviewers assessed 58 of them. The National Audit Office reported multiple fundamental system controls at low maturity across departments, with asset management among them.

The same report recorded at least 228 legacy IT systems in use by government departments in March 2024, with 120 of them (53%) lacking fully funded remediation plans at that date. The Government Cyber Action Plan of 6 January 2026 separately estimates that 28% of the government technology estate is legacy technology, and therefore highly vulnerable to attack.

Where the assumption gets tested: CAF A3 and B4

The NCSC Cyber Assessment Framework version 4.0, released in August 2025, has 4 objectives, 14 principles and 41 contributing outcomes. Principle A3 Asset Management requires everything needed to deliver, maintain or support the systems behind essential functions to be determined and understood: data, people, systems and supporting infrastructure such as power or cooling. Its single contributing outcome, A3.a, is rated only Not achieved or Achieved. There is no Partially achieved level.

Its Not achieved indicators are the useful part. Any one of them would normally be enough for a Not achieved judgement:

• Dependencies between assets are not understood, such as those between IT and operational technology.
• Only certain domains or types of asset are documented and understood.
• Knowledge critical to managing, operating or recovering the essential function is held by one or two individuals with no succession plan.

The framework does not say the next part, but it follows: a strong corporate IT inventory does not compensate for an undocumented operational technology estate, an unrecorded supplier dependency or a single-person knowledge gap.

Principle B4 System Security requires critical systems and technology to be protected from cyber attack, informed by an organisational understanding of risk. Its first outcome, B4.a, is itself called Secure by Design. Two of its four outcomes, secure configuration (B4.b) and vulnerability management (B4.d), run straight back through the register.

Where the NCSC Core Profile applies, its target for B4.d is Achieved, not Partially achieved.

New services get design scrutiny. What about the legacy estate?

UK Government Secure by Design policy says central government departments and arm's length bodies shall incorporate effective security practices based on its principles, and that other parts of the public sector may adopt it optionally. It requires threat modelling as the service evolves, and controls reassessed on change. That is where dependencies are meant to be understood early.

It is also where the limit sits. The policy applies to new or significantly changed services and infrastructure, and not to services in operation or routine maintenance, which is where much legacy technology lives. The policy expects that, over time, all digital services will either be retired or come into scope.

Three steps to start this quarter

These are recommendations, not requirements. Start with one essential service rather than the whole estate, establish what it depends on, including suppliers and interfaces, and record who owns each dependency. Then test the register against evidence rather than against itself, reconciling it with what the service demonstrably runs on, and give anything unsupported a mitigation and a replacement plan. Finally, prioritise by consequence to the service rather than by asset count, and give every gap a named owner and a date.

From asset visibility to connected assurance

Understanding the dependencies behind a critical service should not be a one-off exercise. Those relationships change as systems are upgraded, suppliers are replaced and services evolve.

One critical service. A clearer picture of what matters.

If your organisation struggles to identify the systems, suppliers and dependencies behind a critical service, E2E Security Consulting can help. Our consultants provide focused critical-asset and dependency reviews, helping organisations validate service relationships, identify architectural weaknesses, assess the associated risks and prioritise practical improvements. Accountability for the answer, and for what gets funded, stays with your organisation.

Start with the service that matters most. Establish what it depends on. Then make that knowledge useful for decisions. If you have not yet asked how long that service can afford to stop, our earlier article, How long can the service stop?, is the place to begin.

The test to run before an incident runs it for you

Ask it while asking is cheap, and judge the register by the answer rather than by its row count.