Back to knowledge base

Forensically substantiated evidence: what auditors and insurers really want to see

Published on June 16, 2026

Almost any security tool can produce a list of vulnerabilities. The problem is that such a list answers the wrong question. An auditor, a cyber insurer and a large customer do not ask "do you have a report?" but "can you demonstrate that it is correct, and that you did something with it?" That is a fundamentally different requirement, and it is exactly where most reporting falls short.

This article is about the difference between a list and evidence. What forensically substantiated evidence is, why auditors and insurers want to see it, and how to build it without kidding yourself.

In short

Why a list of vulnerabilities is not evidence

A vulnerability list feels reassuring: it looks like control. But it lacks three things that matter under assessment. It does not say how the finding was obtained, so you cannot verify it. It does not say whether it is still current, so it may already be outdated. And it says nothing about follow-up, so it shows no process.

For a board, that is the difference between a report you have to believe and a report you can retrace. How to go from raw signals to steerable information is covered in from CVE list to board report, and why a list is not yet board evidence in from vulnerability list to board evidence.

What forensically substantiated evidence is

Forensically substantiated evidence records the whole chain per finding. Not just "this service is vulnerable", but: which module looked, at which target, at what moment, and which underlying observation led to that conclusion. This creates something resembling a chain of custody in forensics: a continuous chain of observations you can retrace and, if needed, defend.

The difference is therefore not in knowing that a vulnerability exists, but in being able to show how and when it was found and followed up. That is what makes a duty of care defensible rather than a paper promise. Scanning produces that evidence, but scanning alone does not make you compliant; that nuance is in scanning is not NIS2 compliance.

What auditors want to see

An auditor does not test whether you were secure at one moment, but whether you have a process that demonstrably works. Concretely they look for: dated findings with origin, an owner and a decision per finding, an agreed remediation deadline, and a recheck confirming the fix was actually applied. A folder with those four elements, built up over time, is worth more at an audit than a policy document without proof of execution.

What cyber insurers want to see

With insurers, evidence plays at two moments. When taking out the policy they want to see demonstrable basic hygiene; that partly determines your premium and terms. On a claim they want to reconstruct the state of your environment around the incident. Dated, traceable evidence supports both and can prevent disputes over coverage. Without that substantiation you fall back on your word, and that is exactly what an insurer does not accept.

What large customers want to see

If you supply an organisation that falls under NIS2, it has to be able to substantiate its own supply-chain duty of care. That translates into questionnaires and audits in which your evidence becomes part of their file. A dated scan report with remediation status says more there than a page of prose; how to approach such a request is in answering a NIS2 supplier questionnaire.

How do you build this?

  1. Measure continuously, not once. A timeline is evidence of a process; a single scan is not.
  2. Record the origin per finding. When, how and by which module was it found?
  3. Attach owner, decision and deadline. Who picks it up, or why do you consciously accept the risk, and within what timeframe?
  4. Recheck and keep the result. Confirm the fix was actually applied, and retain that.
  5. Make it presentable. Translate the evidence into reports you can put before an auditor, insurer or customer.

Exposentry is built for this: NL-sovereign monitoring that records forensically substantiated evidence per finding, for your own domains and your chain. See the pricing or start a scan of your organisation, so you have the evidence ready before anyone asks for it.

Frequently asked questions

What is forensically substantiated evidence? Evidence that records per finding how and when it was obtained, comparable to a chain of custody, so it is retraceable and defensible.

Why is a list of vulnerabilities not enough? A list says what may be wrong, but not how it was established, whether it is correct and whether it was followed up. Assessors look at your process.

What exactly do cyber insurers want to see? Demonstrable basic hygiene when taking out a policy, and a reconstruction of the state around the incident on a claim. Dated evidence supports both.

Is forensic evidence the same as a compliance certification? No. Evidence is factual technical proof and a necessary building block, not a stamp in itself.

How long should I keep evidence? As long as it serves a purpose: around audits, policy periods and the term of customer contracts. A continuous timeline is more valuable than isolated snapshots.

Written by Edward Hasekamp, founder of Exposentry and core maintainer of the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides NL-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.