ISO 27001 Audit Evidence: Implementation vs Operating Evidence

A common audit-preparation mistake is to collect policies, procedures and screenshots and assume the evidence pack is complete. It may not be. A document can prove that a process has been designed. An auditor may still need evidence that the process actually operated. This distinction is useful across ISO 27001 because an effective information security management system is not demonstrated only by documented intentions. Organizations also need records showing that relevant activities were performed, reviewed and followed through. In practical terms, it helps to separate audit evidence into two questions:

1. Has the control or process been established?
2. Can we prove that it operated in practice? The first question is mainly about implementation evidence. The second is mainly about operating or effectiveness evidence.

What is implementation evidence?

Implementation evidence shows that a process, control or governance arrangement has been established. Typical examples include:

• approved policies;
• procedures;
• standards and guidelines;
• defined roles and responsibilities;
• configured security settings;
• approved methodologies;
• documented workflows;
• control designs;
• system architecture documentation;
• templates and forms used by the organization. For example, an Access Control Policy may explain how access should be requested, approved, reviewed and removed. That is useful implementation evidence because it demonstrates the expected control design. But the policy alone does not prove that access reviews were actually performed.

What is operating evidence?

Operating evidence shows that the process or control was actually used. Typical examples include:

• completed access reviews;
• approved access requests;
• incident tickets;
• investigated security alerts;
• vulnerability scan results and remediation records;
• completed supplier assessments;
• backup and restore-test reports;
• internal audit reports;
• management review minutes;
• completed training records;
• change approvals;
• corrective-action records;
• monitoring reports;
• test results;
• meeting records showing decisions and follow-up. Operating evidence answers a different question from a policy or procedure: what actually happened?

Simple examples

Access control

Implementation evidence:

• Access Control Policy
• access-management procedure
• role or access matrix Operating evidence:
• completed quarterly access review
• approved joiner/mover/leaver records
• sample access approvals
• evidence that inappropriate access was removed

Backup

Implementation evidence:

• Backup Policy
• backup procedure
• defined backup schedule Operating evidence:
• successful backup-job records
• failed backup alerts and follow-up
• restore-test report
• corrective action after a failed test

Logging and monitoring

Implementation evidence:

• logging and monitoring policy
• log-retention standard
• documented alerting rules Operating evidence:
• generated security logs
• actual alert records
• investigation tickets
• escalation records
• closure evidence This distinction is especially useful when considering ISO/IEC 27001 Annex A controls such as 8.15 Logging and 8.16 Monitoring activities. Logging records that something occurred; monitoring should also demonstrate that relevant activity is detected, reviewed and acted upon. Explore the related controls with the AuditPrepared Annex A Control Lookup: Annex A Control Lookup

Why auditors often ask for both

An auditor generally wants to understand both design and operation. A well-written procedure may show that the organization has defined a reasonable process. The auditor may then sample records to determine whether people actually followed it. For example, an organization may state that privileged access is reviewed quarterly. The next audit question is predictable: “Can you show me the latest completed review?” If the organization provides only the policy, the evidence does not answer that question. Similarly, a vulnerability-management procedure may describe scanning, prioritization and remediation. The auditor may then ask for recent scan results, tickets, closure records or evidence that overdue vulnerabilities were escalated. The strongest evidence package makes that transition easy.

A practical evidence model

For each important requirement or control, maintain a simple evidence structure: Requirement or control → Expected implementation evidence → Expected operating evidence → Evidence owner → Evidence period → Current evidence → Review status → Audit acceptance This prevents evidence collection from becoming a last-minute search through email, shared drives and personal folders.

Evidence needs context

A file by itself is often not enough. Consider a spreadsheet named: Access Review Final v3.xlsx Without context, an auditor or reviewer may still need to determine:

• which system was reviewed;
• which period the evidence covers;
• who performed the review;
• who approved it;
• what population was included;
• whether exceptions were identified;
• whether exceptions were closed;
• which requirement or control the record supports;
• whether the record is still current. That is why useful evidence management requires metadata as well as storage.

Evidence can become stale

Another common problem is treating evidence as permanently valid because the file still exists. An evidence item may become less useful when:

• the review period is old;
• the system has changed;
• the process owner has changed;
• the underlying control has been redesigned;
• the policy has been superseded;
• the audit scope has changed;
• a supplier assessment has expired;
• a new regulatory or contractual requirement applies. Useful evidence records should therefore track fields such as:
• owner;
• evidence period;
• review date;
• valid-until date where applicable;
• current version;
• related requirement;
• audits in which the evidence was used;
• latest review or acceptance status.

Reuse evidence without weakening audit judgement

Good evidence should be reusable. A completed privileged-access review may support an ISO 27001 audit, an internal compliance review and a customer assurance exercise. That does not mean the file needs to be copied into multiple folders. A stronger model is to maintain one controlled evidence item and map it to multiple relevant requirements or audit contexts. But reuse should not mean automatic acceptance. The same evidence may be suitable for one audit but not another because the scope, period, population or testing expectation differs. Separate three concepts:

1. The evidence item itself.
2. The requirements it may support.
3. The reviewer’s acceptance decision for a specific audit. That approach reduces duplication while preserving audit judgement.

A simple audit-preparation checklist

Before an audit, review important requirements and ask:

• What implementation evidence should exist?
• What operating evidence should exist?
• Who owns each evidence item?
• What period should the record cover?
• Is the latest evidence current?
• Has it already been used successfully in another audit?
• Does it support the current audit scope?
• Has a reviewer accepted it for this audit?
• Are there gaps that require a new evidence request? This turns audit preparation from file collection into evidence management.

Where organizations usually struggle

The problem is rarely that organizations have no evidence at all. More often, the evidence is:

• scattered across systems;
• badly named;
• missing ownership;
• difficult to map to requirements;
• old;
• duplicated;
• missing review history;
• stored without explanation;
• difficult to reuse safely. A structured evidence register can solve much of this problem before audit week begins.

Final takeaway

A policy can prove intent. A procedure can prove that a process has been designed. Operating records show whether the process actually happened. Strong ISO 27001 audit preparation normally needs both. The practical goal is not to create the largest evidence folder. It is to create a traceable evidence set that shows what has been established, what has operated, who owns the evidence, whether it is current, and whether it has been accepted for the audit in scope. Explore the AuditPrepared ISO 27001 Clause Explainer: ISO 27001 Clause Explainer Check your broader ISO 27001 readiness: ISO 27001 Readiness Checker