How do you keep ISMS evidence current and verifiable?

The audit folder is complete. Yet the evidence no longer fits: since the last test, the application has moved to a different service provider. The file exists, but its contents describe the old environment.

Current ISMS evidence answers a specific review question for the right scope and period. Its upload date is not enough. You need a traceable connection between the requirement, the implemented measure, the evidence and the decision based on it.

This first part of “Evidence that holds up in practice” shows how to maintain that connection. The result is a small evidence inventory recording responsibility, review triggers and outcomes. Part two covers reuse across audits; part three covers introducing revised policies.

What should the evidence actually demonstrate?

Start with a sentence: “We want to demonstrate that …” Add the specific claim, the area concerned and, where applicable, the period.

“There is a rule for sharing files” is a different claim from “External shares end after the agreed period”. An approved policy may answer the first question. The second requires operational evidence, such as a traceable review of selected shares.

In Kopexa, evidence is attached directly to measures. Measures are mapped to the appropriate Controls: the requirements whose implementation they support. The relationship is evidence → measure → Controls. This makes clear which implementation the evidence documents and which requirements it is relevant to.

The BSI IT-Grundschutz module ISMS.1, 2023 edition addresses the controlled creation and archiving of documentation, its currency and confidentiality in A13. The inventory below is our practical working aid, not a prescribed BSI form.

Separate creation date, reporting period and next review

A report produced today may analyse last year’s data. A policy may remain valid without changes for months. A technical test may lose its relevance to current operations after a system change.

Record these separately:

• Created or approved: when was this version produced?
• Reporting period: which state or period does it describe?
• Last reviewed: when did someone assess its suitability for your question?
• Next review trigger: which date or change will trigger another assessment?

There is no universal expiry date for all ISMS evidence. Requirements, contracts, review purpose and changes determine what you need. Do not invent annual validity for every file simply because it is convenient to put in a calendar.

An example: the policy fits, the sharing evidence does not

Fictional example for this series: a company operates a project portal. External participants should receive project documents only for a limited period. The measure “Control external sharing” implements that requirement. Policy R-12 version 2 and test record P-07 covering selected shares in the old portal are attached to it. The measure is mapped to the relevant Controls.

After the portal changes, the organisational rule initially remains the same. The old test record does not demonstrate that expiry works in the new portal. A review must resolve that gap.

The identifiers are invented. Adopt the structure, not the example values. Add the associated measure and its Controls to your inventory. Link the specific evidence version and record where the original source is held. Restrict sensitive evidence to those who need access.

Review after changes and at planned intervals

Choose triggers appropriate to the subject. A system migration can affect technical test results. A change in responsibilities can alter approvals and contacts. An additional legal entity may fall outside the scope previously assessed.

Add regular reviews where changes might otherwise go unnoticed. The date creates the trigger; the substantive review produces the result. Automatically moving a date without reviewing the content does not make evidence more current.

Start each review with four questions:

1. Does the evidence still describe the relevant area and the correct version?
2. Does its time reference fit today’s review question?
3. Has anything material changed since it was created?
4. What can we conclude from it, and what remains unresolved?

Document the result even when no change is needed. That shows someone assessed the content rather than merely uploading the file again.

Turn a gap into a task

“Evidence missing” is too vague as an assignment. In the example, the task is: “Test time-limited external sharing in the new portal; document scope, results and outstanding deviations.” Add an owner, a deadline and a completion criterion.

When new evidence replaces an earlier record, preserve the relationship. Do not silently overwrite its historical meaning. The old test record may remain relevant to an earlier audit while current operations require a new version. Retention and access follow your applicable requirements; not every old file needs to be retained indefinitely.

The article on preserving evidence history when changing ISMS software explains how to handle these chains during a migration.

Start with one important piece of evidence

Choose evidence you rely on for a current decision. Examine it alongside its measure and mapped Controls. Write down the review question, scope, time reference and responsibility. Then check whether the file actually supports that claim. An identified gap becomes a concrete task, not a hidden comment in the audit folder.

The second part of the series explains how to use the same evidence across audits while keeping remaining gaps visible.