Back to knowledge base

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

Published on June 16, 2026 · Updated on August 4, 2026

This article is general information about laws and regulations, not legal advice.

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 ask: 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

  • A list of vulnerabilities shows at most what may be wrong. Evidence also tells how it was established and what was done about it. A screenshot or loose PDF hits the same wall.
  • Forensically substantiated evidence records the chain: what was found and on which target, with the substantiation, the scan date and what was done about it. Comparable to a chain of custody.
  • Convincing evidence combines four things: traceability per finding, tamper-evidence (signed and timestamped), a continuous timeline and independent delivery.
  • Auditors, insurers and large customers assess your process, not just a snapshot. Traceable, dated evidence is what makes that process defensible.
  • Evidence is a building block under compliance. It supplies the facts on which policy, processes and governance rest.

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.

A screenshot or a manually exported PDF hits the same wall. You see an outcome, but not how it came about, not whether it still holds, and not whether someone edited it along the way. Without origin, without a timeline and without a seal, it remains a picture.

For a board, that difference means: a report you can verify and 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, per finding, the target and the underlying substantiation. That means: at which target the measurement looked and which observation led to the conclusion, together with the scan date and the modules deployed in the measurement. This creates something resembling a chain of custody in forensics: a continuous chain of observations you can retrace and, if needed, defend.

Evidence only becomes convincing when it combines four things:

  • Traceability per finding. The target and the substantiation per finding, with the scan date and the modules deployed in the measurement, so a third party can verify it for themselves.
  • Tamper-evidence. The report is demonstrably unchanged after delivery and dates from a fixed moment.
  • A continuous timeline. Proof of a process that works.
  • Independent delivery. The evidence comes directly from the measuring party to the client, separate from whoever manages the environment.

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. Scanning produces that evidence, but scanning alone does not make you compliant; that nuance is in scanning is not NIS2 compliance.

Why the report has to be tamper-evident

Evidence that can be altered unnoticed afterwards is not evidence. A date in the text or a logo on the cover says nothing: both can be changed in a minute. That is why, in production, Exposentry seals reports by default with a digital signature (PAdES) and an RFC3161 timestamp from an independent timestamping authority. Any change after signing breaks the signature, and the independent timestamp records the moment the report already existed. That makes it verifiable afterwards that not a byte has changed since signing, without the recipient having to take your word for it.

The same RFC3161 approach is also documented by OpenKAT, the open-source security scanner of the Dutch government, to which Exposentry founder Edward Hasekamp contributes as a collaborator. How to verify such a seal yourself is covered in how to check whether a security report is genuine.

What auditors want to see

An auditor tests 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.

There is another reason auditors and insurers look critically at who compiled the evidence. Evidence the environment's own administrator put together is marking its own homework. Measurement by a party that does not manage the environment and delivers the result directly to the client carries more weight. Why that separation matters is covered in independent reporting.

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 with an insurer that carries significant weight.

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. A timeline proves a working process.
  2. Record the target and substantiation per finding. At which target did it look and which observation led to the finding, and when and with which modules was the measurement done?
  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: EU-hosted monitoring that records forensically substantiated evidence per finding and seals reports by default in production, 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 the target and the substantiation, with the scan date and the modules deployed in the measurement, comparable to a chain of custody, so it is retraceable and defensible.

Why is a list of vulnerabilities not enough? A list says at most what may be wrong. Auditors and insurers assess your process and want traceable evidence of how findings were established and followed up.

How does a recipient know the report has not been altered? In production, Exposentry seals reports by default with a digital signature (PAdES) and an RFC3161 timestamp from an independent authority, so it can be checked afterwards that it was not changed after signing and at which moment it existed.

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 of compliance.

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 collaborator on the open-source OpenKAT project. See the project on GitHub and the profile at github.com/hasecon. Exposentry provides EU-sovereign, forensically substantiated vulnerability monitoring based on OpenKAT. More articles in the Knowledge base.