25 August 2026

Evidence Pack: how to build a verifiable evidence bundle

Ask ten administrators how they prepare evidence for a vulnerability management audit and nine will describe the same nightmare: a week of taking screenshots, pasting them into a document, adding comments, digging out old emails and assembling something meant to pass for a coherent picture. The result is ugly, laborious and, worse, unconvincing to an auditor, because a screenshot is the weakest kind of evidence there is.

I want to show an alternative: an evidence bundle that makes it easier for an auditor to check scope, data and file consistency. I call it an Evidence Pack. It is one ZIP file for a specific period, but it remains material to assess, not a guarantee that a control will close without questions.

What is in the pack

Four elements, each with a specific role.

A PDF report. A summary of the process over the period, written for a human: how many vulnerabilities were handled, how SLA deadlines were met, what the exceptions and risk acceptances were, the overall picture. This is the document the auditor reads first, to understand what they are looking at.

Raw data as CSV. The full data behind the report, in a format the auditor can take into their own spreadsheet and analyse their own way. This is the difference between "trust our summary" and "here are the numbers, check for yourself". A good auditor will appreciate the latter, because it gives them independence.

A checksum manifest. For every file in the pack, a SHA-256 digest is calculated. This lets the recipient verify the pack's internal consistency against the manifest. The manifest alone does not prove who generated the pack, when it was created or whether the source data was true.

An explicitly defined period and scope. Which machines the pack covers and for what date range. Without that the evidence hangs in the air, because it is unclear what it refers to. With it, the auditor immediately knows they are looking at a complete set for, say, the second quarter, for all eighteen machines in the register.

Why a checksum changes the conversation

This is the crux and worth pausing on. Without checksums, every piece of evidence rests on trust: the auditor has to believe you are showing real data rather than a version tidied up for the occasion. That is an uncomfortable position for both sides, because an auditor is professionally obliged not to take things on someone's word.

A checksum enables one specific verification. The recipient can calculate file digests and compare them with the manifest. A match confirms that the files correspond to that manifest. It does not establish creation time or authorship; those require additional controls such as a digital signature, trusted timestamp or out-of-band delivery of the digest.

What the auditor does with the pack

It may work as follows. The auditor opens the PDF report, analyses the CSV and spot-checks vulnerabilities, deadlines and exceptions. They verify that the files correspond to the manifest and compare scope with the asset register. The bundle reduces the effort needed to gather and transfer material, but the auditor still assesses its credibility, completeness and connection to the real process.

What is not in the pack and why

Honesty requires saying what is deliberately not in the pack, too. There are no personal data, because proof of a vulnerability process does not need them, and pulling them in would create a data protection problem rather than solve one. There are no secrets, passwords or keys, because an evidence pack circulates between people and must not become a channel for leaking sensitive things. The pack contains exactly what is needed to prove the process and nothing beyond that, and that too is a trait an auditor will appreciate.

A boundary worth stating

I will not sell you the illusion that one pack settles the whole audit. An Evidence Pack documents selected aspects of the vulnerability management process. It does not prove the entire process on its own, let alone the whole security management system: policies, training, business continuity, access control and all the rest still require other evidence.

See it with your own eyes

Rather than describe it, I prefer to show it. I built a sample evidence pack on fictional data, in exactly this structure: PDF, CSV, checksum manifest, explicit period and scope. You can download it, open it and show it to your auditor before you buy anything, to judge whether such a set answers their questions: download the sample Evidence Pack.

The difference between forty screenshots and one ZIP with a manifest is not merely aesthetic. A structured bundle lets the recipient check consistency and trace the data. Its credibility still depends on the source process and controls beyond the ZIP itself.

Sources

One email a week with newly published vulnerabilities worth knowing about. No account needed.

This digest covers new vulnerabilities in general, not your servers. If you want to know which of them actually run in your infrastructure, that is what Secvalis does: it scans your machines and reports only what concerns them.