CMDB: The Cyber Insurance Claim Risk You Don’t See Until It’s Too Late

The breach isn’t the first crisis. The inventory is.

Most senior teams only discover their “asset problem” when something goes wrong.

A ransomware event. A data leak. A suspicious login followed by a weekend of frantic calls.

Then someone asks a simple question that should have been easy:

“What is actually connected to our network, and who owns it?”

If the answer is a shrug, a spreadsheet, or “our vulnerability scanner shows everything,” you’re already in a vulnerable position. Not just technically. Commercially.

Because cyber insurance and Cyber Essentials (where you use it for assurance and eligibility) are both built on a shared assumption: the picture you presented of your environment is broadly true. If your picture is missing dozens of devices, old appliances, test environments, or “temporary” systems that became permanent, then the controls you believe you have may not exist where it counts.

A security breach is often survivable. A coverage dispute at the same moment you’re trying to recover can be existential.

This article isn’t about scaring people with worst-case headlines. It’s about one practical point that keeps showing up in real incidents:

If you can’t account for your entry points, you can’t credibly claim you manage patching, configuration, access, and malware protection across the estate.

And that becomes a problem when someone external—an assessor, an incident responder, or an insurer—starts asking for evidence.

How “unknown assets” become “undeclared risk”

Most organisations don’t set out to misrepresent anything. What happens is more mundane.

• An acquired business keeps running “for a few months” on its own kit.
• A contractor plugs in a remote access device “temporarily.”
• A legacy file server can’t be upgraded, so it’s left alone “until the project starts.”
• A lab network gets bridged to production to “make testing easier.”
• A department buys a device or service without telling IT.

None of those feel like a board-level decision. But each can create a real entry point into your network.

Now layer in two realities:

1. Your cyber insurance proposal (and renewal) typically relies on declarations about security practices—patching, malware protection, access control, logging, and third-party risk.
2. Cyber Essentials relies on a defined scope and an attestation that in-scope systems meet baseline requirements.

When your Configuration Management Database (CMDB) is incomplete, you are not just missing “assets.” You are missing:

• in-scope systems that should have been patched
• unsupported software that should have been removed
• remote access paths you didn’t know existed
• devices with default credentials
• unowned systems with no maintenance window

In that context, “we patch” becomes “we patch what we can see.”

That difference matters during underwriting, during certification, and during a claim review.

Why vulnerability management tools don’t equal visibility

A common failure mode looks like this:

• The organisation runs one vulnerability tool.
• The tool reports a manageable number of devices.
• Patching and remediation processes are designed around that list.
• Everyone assumes the list is the estate.

But discovery is not certainty.

Tools miss things for very ordinary reasons:

• Network segmentation blocks scanning.
• Credentials aren’t available, so the scanner can’t inspect properly.
• Devices are transient (developers spin things up; projects end; no one updates records).
• Shadow IT exists outside managed IP ranges.
• Remote or off-network endpoints don’t get seen.
• Appliances and “non-standard” devices are not covered or are poorly fingerprinted.

And even when a tool does see something, it often doesn’t answer the questions a senior team needs answered fast:

• Who owns it?
• What service does it support?
• What change process applies?
• What patch policy applies?
• What is the business impact if it is taken offline?

That’s CMDB territory. A vulnerability tool is a sensor. The CMDB is the map.

If you rely on a single sensor to define your entire map, you will have blind spots.

Cyber Essentials: where asset truth matters

Cyber Essentials is frequently treated as a once-a-year exercise. Answer the questions, pass the assessment, file the certificate.

But the scheme is built on the idea that baseline controls are applied across the in-scope environment: firewalls, secure configuration, access control, malware protection, and security update management.

In practice, the question that causes trouble is not “do you have a policy?” It’s:

“Can you prove your baseline controls apply to the systems that matter?”

If the CMDB is incomplete, two things happen:

1. Scope becomes guesswork.
   You can’t confidently state what is included, what is excluded, and why.
2. Evidence becomes fragmented.
   You might show patch compliance for “managed endpoints” but have no view of unmanaged appliances, old servers, or remote access devices.

Even if your intentions are good, the gap between your attestation and your reality is where risk lives.

The UK Government National Cyber Security Centre (NCSC) offers clear guidance both in their free to download Cyber Essentials: Requirements for IT Infrastructure PDF and on the Government National Cyber Security website

To quote the NCSC:

“Effective asset management doesn’t mean making lists or databases that

are never used. It means creating, establishing and maintaining

authoritative and accurate information about your assets that enables

both day-to-day operations and efficient decision making when you need

it. In particular, it will help you track and control devices as they'reintroduced into your business.”

“You must make sure that all software in scope is kept up to date. All software on in-scope devices must:

• be licensed and supported

• be removed from devices when it becomes unsupported, or removed from scope by using a defined sub-set that prevents all traffic to or from the internet

• have automatic updates enabled where possible

• be updated, including vulnerability fixes, within 14 days of release, where:

• the update fixes vulnerabilities described by the vendor as ‘critical’ or ‘high risk’
• the update addresses vulnerabilities with a CVSS v3 base score of 7 or above
• there are no details of the level of vulnerabilities that the update fixes provided by the vendor”

What “accurate CMDB” actually means in this context

An accurate CMDB is not a perfect inventory of every cable and monitor.

It’s a trusted record of the Configuration Items (CIs) that represent:

• what connects to your network,
• what supports business services,
• what creates security exposure,
• and who is accountable for each CI.

Accuracy is not a vague concept. It is measurable. A useful definition for senior teams is:

A CMDB is accurate when it is complete enough to support control claims (patching, configuration, access) and fast enough to support incident decisions (impact, isolation, restoration).

That requires four things:

1) Coverage (what you know exists)
You need reconciliation from multiple sources, not just one tool: directory services, endpoint management, network discovery, cloud accounts, procurement records, certificate logs, and service desk records.

2) Correctness (what the thing actually is)
Deduplicate, normalise, and reconcile naming. “SVR-01”, “Server01”, and “ProdFile1” can’t be three separate truths.

3) Ownership (who is responsible)
Every CI needs an accountable owner (not “IT”). For security, you also need an operational owner who can patch, approve downtime, and accept exceptions.

4) Relationships
A device record without service and dependency relationships is a list, not a CMDB. In an incident you need: what does this system support, and what breaks if we isolate it?

This is where many CMDB initiatives fail: they focus on populating records, not on making the data operational.

The evidence insurers ask for after an incident

After a significant incident, insurers and their appointed partners often ask for evidence that goes beyond “we have a policy.” They ask for operational proof.

Examples include:

• Asset lists: in-scope systems, internet-facing systems, remote access paths
• Patch evidence: update compliance reports, exceptions, timelines
• Change records: when critical systems were modified and approved
• Security control evidence: malware protection coverage, access control configuration
• Incident timeline: what happened when, what was impacted, what you did

If your CMDB cannot quickly produce a defensible list of what exists and what is in scope, then producing coherent evidence becomes slower and riskier.

This is where avoidable statements creep into a crisis:

• “We didn’t know that device was still connected.”
• “That system wasn’t in our patch cycle.”
• “We thought the scanner covered it.”
• “No one owns it.”

Those statements don’t just hurt recovery. They complicate the narrative around what you represented about your controls.

Under UK law, UK Insurance Act states:

“(1) Before a contract of insurance is entered into, the insured must make to the insurer a fair presentation of the risk.

(2) The duty imposed by subsection (1) is referred to in this Act as “the duty of fair presentation”.

(3) A fair presentation of the risk is one

(a) which makes the disclosure required by subsection (4),

(b) which makes that disclosure in a manner which would be reasonably clear and accessible to a prudent insurer, and

(c) in which every material representation as to a matter of fact is substantially correct, and every material representation as to a matter of expectation or belief is made in good faith.

(4) The disclosure required is as follows, except as provided in subsection (5)—

(a) disclosure of every material circumstance which the insured knows or ought to know, or

(b) failing that, disclosure which gives the insurer sufficient information to put a prudent insurer on notice that it needs to make further enquiries for the purpose of revealing those material circumstances.”

In simple terms, unless you declared that you do not have the ability to secure your environment because you do not have visibility of you IT landscape at the time you took out the policy, your insurer was not aware of the risk they were covering and therefore you are potentially not insured because as the law states “Before a contract of insurance is entered into, the insured must make to the insurer a fair presentation of the risk.”

A board-level test: six questions your CMDB should answer in minutes

If you want to know whether your “we’re insured” posture is built on solid ground, test the CMDB with questions a breach will force anyway:

1. What are all internet-facing entry points today?
   Not last quarter. Today. Devices, services, and remote access paths.
2. Which systems are not on a supported software version?
   List them, owners included, with a plan or a formally accepted exception.
3. Which devices have not received security updates within our required time frame?
   And: are they in scope for Cyber Essentials and your declared controls?
4. What is our patch compliance evidence by service, not by device type?
   “90% of endpoints patched” is less useful than “these customer services are fully covered.”
5. If we isolate this device, what business service is affected?
   This is about relationships in the CMDB, not guesswork on a call.
6. Who can approve downtime for the top 20 high-risk systems?
   A missing owner is a missing control.

If your current systems can’t answer these questions quickly and consistently, it doesn’t mean you are “bad at security.” It means you are operating without a reliable map.

How Apex helps: baseline, fix, run, assure

Apex’s work here is practical and operational. We focus on turning CMDB data into something you can use during assurance and during incidents.

Apex mechanism #1: CMDB accuracy baseline (measured, not assumed)
We establish an evidence-based baseline of CMDB quality using multiple authoritative sources. Typical measures include:

• coverage against discovery and management tools (what exists vs what’s recorded)
• duplicate and conflicting CI rates (how many “versions of truth”)
• ownership completeness (percentage of CIs with accountable owners)
• relationship completeness for critical services (can you do impact analysis)
• exception handling (where you knowingly can’t patch, and whether it’s recorded)

Apex mechanism #2: Data quality fixes that stick (deduplicate, normalise, reconcile)
We implement rules and automation so the CMDB improves every day, not just during a project:

• deduplication and normalisation standards (names, locations, environments)
• reconciliation rules between sources (what wins when data conflicts)
• lifecycle governance (build, change, retire) so stale assets don’t linger
• ownership assignment workflows so “unknown” doesn’t remain unknown

Apex mechanism #3: Operating model and change gates (so the CMDB stays true)
We put in place a lightweight operating model:

• RACI that makes ownership real (service owner, technical owner, data steward)
• change enablement gates that update the CMDB as part of change, not after
• periodic audits focused on internet-facing and high-risk CIs
• reporting that gives senior teams a single view of exposure and exceptions

Apex mechanism #4: Incident and service impact integration (faster, safer decisions)
We ensure the CMDB is relevant and meanigful to incident and change processes so you can:

• identify impacted services quickly
• isolate systems with confidence
• reduce mean time to restore service by knowing dependencies
• produce clearer evidence packs after an incident (asset truth + control truth)

This is not “CMDB for CMDB’s sake.” It’s configuration data that supports assurance, resilience, and claim defensibility.

Practical starting point: a 4 point CMDB accuracy sprint

If you want a pragmatic way to start, here’s an approach that doesn’t require a massive programme.

Step 1: Define “in scope” and “must be true”

• Agree the in-scope estate for Cyber Essentials and cyber insurance declarations
• Define the minimum CMDB fields for security assurance (owner, location, support status, patch policy, external exposure, service relationship)

Step 2: Reconcile from multiple sources

• Pull authoritative data from endpoint management, directory services, cloud accounts, network discovery, and service desk
• Compare to CMDB: identify unknowns, duplicates, stale records, missing owners

Step 3: Fix the high-risk 20%

• Prioritise: internet-facing systems, remote access paths, privileged systems, critical business services
• Assign owners and patch accountability
• Record exceptions properly with risk acceptance and review dates

Step 4: Put the operating model in place

• Implement change gates so new/changed systems update the CMDB
• Set up reporting: exposure, unsupported systems, patch exceptions by service
• Schedule a monthly audit for external exposure and high-risk systems

By the end, you should have a CMDB that is materially more accurate where it matters most.

FAQ

FAQ 1: Does a breach prove we didn’t do patch management?
No. A breach can happen for many reasons. The issue is whether your evidence supports the controls you declared, and whether unpatched, in-scope systems existed outside your visibility.

FAQ 2: Isn’t our vulnerability scanner enough?
A scanner is an important input, not the source of truth. It can miss segmented systems, remote endpoints, appliances, and anything outside its coverage. A CMDB reconciles multiple sources and adds ownership and relationships.

FAQ 3: What’s the difference between an asset register and a CMDB?
An asset register lists things you own. A CMDB models configuration items and their relationships to services, changes, incidents, and risk. That relationship view is what supports impact analysis and recovery decisions.

FAQ 4: How do we prove CMDB accuracy to auditors or insurers?
By showing reconciliation: multiple authoritative sources mapped to CMDB records, plus governance that keeps records current (change gates, ownership assignment, audits, and exception handling).

FAQ 5: We have “exceptions” we can’t patch. Is that a deal-breaker?
Not necessarily. What matters is that exceptions are known, owned, risk-assessed, time-bound, and reviewed—rather than invisible and unmanaged.

Want to know whether your CMDB is creating insurance and Cyber Essentials risk?
Apex runs a CMDB Accuracy & Exposure Baseline that compares what exists in your environment to what your CMDB says exists, and produces a short, board-ready action plan (coverage gaps, unowned entry points, and the top fixes that reduce exposure fastest).

Book a 30-minute “CMDB blind spot review” (we’ll tell you what to pull and what we’ll measure).