8 November 2026

The auditor is coming. What vulnerability management records will you show?

A district hospital. The quality officer has been asked to prepare material for a security audit. For vulnerability management she has last year's update policy, a dozen emails from the IT staff along the lines of "servers updated", a spreadsheet someone kept until spring and an undated screenshot from the scanner.

She asks IT for "evidence that we patch". She gets a scan report dated today. It looks fine; it just does not show how vulnerabilities were handled in previous months.

What the law says

Article 10(1) of the Polish National Cybersecurity System Act (KSC), as amended in 2026, requires essential and important entities to develop, apply and update documentation on the security of their information system. For entities in some financial sectors the Act provides exclusions in Article 8i. Article 10(2) splits it into two parts: normative and operational.

Normative documentation includes the documentation of the information security management system, that is policies, procedures and rules. Article 10(4) defines operational documentation as records attesting that the activities required by the normative documentation are carried out, including automatically generated records in system logs.

Article 10(6) then requires oversight of the documentation: access only for authorised persons, protection against loss and loss of integrity, and marking of versions. Article 10(7) requires keeping it for at least 2 years, with a specific rule on how that period is counted set out in the provision; it does not apply to entities subject to the Act on the national archival resource and archives.

In practice this means something simple. The policy says what the company intends to do. Operational documentation has to show that it actually did it.

Where the gap is

Vulnerability management evidence has three typical weaknesses.

It shows a state, not a history. A scan report from audit day says how many vulnerabilities there are now. It does not say how many there were in March, whether deadlines were met or what happened to the vulnerability that disappeared in May. Today's good result does not replace a year of records.

It is scattered. Some in the scanner, some in emails, some in the ticketing system, some in the head of an administrator who has since changed jobs. Putting it together takes weeks, and the gaps in the middle remain.

It is created at the last minute. A spreadsheet filled in a week before the audit looks exactly like what it is: a spreadsheet filled in a week before the audit. If material is created after the fact, that must be clearly marked, not presented as a record from that time. A record that was not made back then cannot be credibly reconstructed.

What to put on the table

The list below covers only vulnerability management and is not a list of questions every auditor will ask. It is a set that helps show that the process described in the policy actually operates. Each item makes sense regardless of the tool.

1. Rules and deadlines. A policy or procedure with remediation deadlines by severity. Plus confirmation that the same deadlines apply in practice, that is in the tool or spreadsheet IT works with. A mismatch between policy and practice is the first thing a comparison reveals.

2. Scope. A list of servers covered by scanning and information on what the scan does not cover and why. A report without a scope does not say which part of the company it describes. More on that in the next part.

3. Regularity. Scan history with dates. Not one report, but a series showing that scanning took place regularly and that gaps can be explained.

4. Timeliness for a period. How many vulnerabilities were removed on time, how many late, how many are overdue now and how long remediation took on average. For a specific period, such as a quarter, not "in general".

5. Decisions. Every vulnerability that was deliberately not removed: with a justification, a risk owner, a review date and who approved it. The previous part covered how to make such a decision. Separately, systems without vendor support, with a migration plan.

6. Action plan. Who is to do what and by when. A plan on its own is not proof of execution, but it shows that the backlog has owners.

7. Trail of changes. Who changed the deadlines, who accepted a risk, who assigned a task, with dates. Without it, items 1 and 5 are just declarations.

How to collect it so you are not doing it a week before the audit

Close periods. Once a quarter, save the set from items 3 to 7 for the finished quarter and put it in one place. Do not edit it later. If something was wrong, add a dated correction instead of changing the old record.

Describe what is inside. Each set should state which period and which servers it covers. Without that, in a year nobody will know what it refers to.

Store it the way Article 10 requires. Access only for people who need it, a copy that cannot be overwritten by accident, and a retention period no shorter than the Act requires (or, for entities subject to archival law, than the archival rules require).

Check that the records are being made. Once a month someone other than the administrator opens the latest set and checks that it is complete. Better to notice a gap after a month than after a year.

Where Secvalis helps, and where it does not

The Evidence Pack in Secvalis is an archive with the management report, the ISO 27001 report, the EOL report, the risk acceptance register, the remediation plan, the audit log, the dataset and a manifest with SHA-256 checksums of the other files, which let you check that the files match that list. This applies only to servers covered by Secvalis: fleet scope and evidence from outside the product have to be checked separately.

Report data for a closed period can be saved as a JSON file with a SHA-256 checksum. Some metrics are then calculated against the end of the period, while fleet state and assignments come from the time the dataset is created. The audit log records decisions, including risk acceptances, assignments, threshold changes and evidence freezes, with CSV export. The compliance map shows which data is available in the product and in which areas evidence has to come from outside it.

A checksum lets you verify that the files match the manifest. It is not a signature and on its own does not prove who prepared the bundle or when. Secvalis does not replace normative documentation or evidence from other areas: backups, business continuity, training, access control or physical security. Nor does it replace a documentation archive for the required retention period. The bundle has to be downloaded and stored according to the documentation oversight rules the company has adopted. Whether the material is sufficient is for the auditor to judge.

You can look at an example bundle in the sample Evidence Pack, with no registration.

In the next part: the vulnerability report looks good. Before you celebrate, check what part of the company it actually describes.

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.