Guide
How can you reuse evidence across multiple audits?
One record can support several audits. A coverage matrix shows where scope, reporting period or review criteria require additional work.
Three audits ask about external file sharing. Your team copies the same policy into three folders. Soon afterwards, it changes. One folder already contains the new version; the others still contain the old one.
Maintain evidence in one authoritative place and assess its suitability for each audit separately. This avoids conflicting copies without treating different requirements as equivalent.
Part two of “Evidence that holds up in practice” takes you from existing evidence to a coverage matrix. Use the process in part one to check whether evidence is current. Here, the question is what additional claim another audit requires.
A shared topic does not mean an identical requirement
ISO 27001, TISAX, an internal control system and a customer contract can address similar topics. That does not mean the same evidence completely satisfies every review point. Requirements can concern different roles, systems, periods or types of examination.
When comparing standards, mapping describes relationships between requirements. The NIST OLIR programme describes relationships between elements of different documents. NIST explains in the OLIR FAQ that derived mappings provide a starting point for comparisons. Assessment in your own context remains necessary.
In practice, record which part of the requirement each evidence item supports. “Relevant to access protection” is too vague when the next audit examines whether access was actually terminated.
In Kopexa, the measure connects evidence and Controls
Evidence → measure → multiple Controls: in Kopexa, evidence is attached to a measure. That measure is mapped to the appropriate Controls. A shared measure can support requirements from several standards without maintaining its evidence separately for each standard.
In the example, “Control external sharing” implements the intended sharing process. The policy and test record are attached to this measure. Mapped Controls show which requirements this implementation is relevant to. Assess separately whether the evidence covers each review purpose.
One set of evidence, three different questions
Fictional example: policy R-12, version 2, describes time-limited external sharing in the project portal. There is also a current test report P-08 and a documented briefing for the affected project managers. These records can support several review questions, but they demonstrate different things.
One measure, jointly maintained evidence and separate review questions. The Control labels are examples, not quotations from standards.
| Audit and example criterion | Scope and period | Suitable evidence | Supported claim | Additional review |
|---|---|---|---|---|
| Internal ISMS audit: sharing process is defined | Project portal currently in use | R-12, approved version 2 | Process and responsibility are defined | Does the content reflect actual working practice? |
| Customer audit: shares in the specific project expire | Agreed project and review period | P-08 with a suitable sample | Tested shares meet the defined criterion | Are the project and required period fully covered? |
| Internal control: affected roles know the new process | Intended project managers after the change | Briefing materials and documented attendance | The change was communicated | Can participants apply the process in an example scenario? |
This matrix is not a normative mapping between standards. It shows how to turn “access protection” into separate review questions. In your actual register, record the exact requirement, including source and version.
Check five differences before reusing evidence
Scope: does the evidence cover the relevant legal entity, location, system and service? A group-wide title is not enough if the sample covers only one site.
Period: does the question concern today’s state or performance over a particular period? A current screenshot does not automatically answer a question about the previous quarter.
Review criterion: does the file demonstrate a rule, its implementation or a test result? A policy can describe the process; an effectiveness test needs more.
Extent of examination: which cases were examined, and which were not? A sample remains a sample. State its limits rather than extending the evidence to unexamined areas.
Permission to share: may the recipient see the complete evidence? If redaction is needed, check whether the relevant claim can still be assessed. Where appropriate, agree on controlled inspection rather than an unprotected copy.
Build a coverage matrix instead of more audit folders
Start with the measure: which Controls does it support, and which evidence fits each review question? Record that assessment in the coverage matrix. The reference points to the specific evidence version attached to the measure.
A compact entry contains:
- Control or requirement, including source and version;
- mapped measure;
- scope and required period;
- evidence reference, including version and provenance;
- supported claim and remaining gap;
- responsible reviewer and assessment date;
- any additional task or evidence needed.
The same evidence may therefore be sufficient for an internal audit and only partly sufficient for a customer audit. That is not a contradiction. The questions differ.
Our article on OSCAL and connected security evidence explains the underlying technical structure. To get started, however, you first need a traceable substantive mapping.
What happens when shared evidence changes?
Central storage makes maintenance easier but does not replace an impact assessment. When R-12 is revised, follow its measure to the affected Controls and audits. Does the new version describe the same process? Has the audience changed? Which ongoing audit needs the new version?
For completed audits, retain a traceable record of the version examined at the time. A link pointing to a different file today must not silently change the historical audit basis. Decide how to preserve that basis under your documentation and retention requirements.
A new evidence version requires an impact assessment; it does not rewrite the past.
A requirement change can also trigger a review even when the file itself has not changed. Maintain the version on both sides: the evidence and the requirement source.
The benefit becomes clear in the work that remains
Choose two real audit requirements addressing similar topics. Check whether the same measure supports both. Examine its evidence and record separately what it demonstrates and what is still missing for each requirement. A shared basis saves repeated searching and avoids conflicting copies. Outstanding work remains visible.
A mapping in software replaces neither your professional judgement nor the auditor’s assessment. A Kopexa demo can explore this workflow using your two requirements.
The third part continues with the people involved: how does a revised policy move from review to the employees expected to follow it?
Quick answers
Frequently Asked Questions
Still have a question? Find the answers here.
Can evidence be used for several audits?
Yes, if it supports each review question. Assess scope, period, criterion and extent of examination separately for each audit. The same file can be sufficient for one audit and only partly sufficient for another.
Does mapping prove that a requirement is fulfilled?
No. In Kopexa, measures are mapped to Controls and evidence is attached to the measure. This mapping alone does not demonstrate full fulfilment. Whether the evidence is sufficient for the specific requirement needs a separate assessment.
What happens when there is a new evidence version?
Review the mappings that depend on it. For completed audits, keep a traceable record of the version used at the time instead of silently replacing the historical audit basis.
Sources
- NIST: National Online Informative References – FAQ — NIST [Accessed ]