How to Build an ISO 27001 Evidence Register That Actually Helps During an Audit

An evidence register should answer four practical questions: what proof is expected, who owns it, whether it is current and what happened when it was reviewed.

A list of filenames cannot do that. It may show that a file exists while leaving the team to reconstruct the decision trail during an audit. A useful register connects the original assessment gap to the evidence request, the work completed, the reviewer’s decision and final closeout.

What an evidence register is for

The register is the traceability layer between a requirement and the proof used to support it. A practical chain is:

Assessment or requirement → expected evidence → evidence item → owner → period or version → review decision → closeout

This is broader than a document register. Policies and procedures matter, but an audit may also need operating records such as approvals, test results, tickets, logs, meeting records and reports.

If an assessment identifies missing or weak evidence, record that gap before collecting more files. The ISO 27001 gap analysis guide explains how to turn an assessment result into prioritised work.

Fields worth tracking

These fields cover most day-to-day evidence decisions without turning the register into another administrative burden.

Field	What to record	Why it matters
Evidence ID	A stable identifier such as EV-2026-014	Gives audit notes and findings a reliable reference
Title	A clear description of the item	Makes the register usable without opening every file
Requirement or work item	The assessment question, control or action it supports	Preserves the reason the evidence was collected
Evidence nature	Implementation, operating or both	Helps distinguish design from proof that a process operated
Owner	The person or function responsible	Makes follow-up possible
Source	The system, folder or record location	Points to the authoritative copy without duplicating it
Period or version	The period covered, completion date or approved version	Shows what the item actually represents
Freshness trigger	A date, system change, process change or incident	Prompts review when the evidence may no longer be representative
Review status	Available, under review, accepted, rework required or superseded	Separates collection from acceptance
Reviewer and decision date	Who reviewed it, when and with what conclusion	Creates an auditable decision trail
Audit or review use	The audit, assessment or management review where it was used	Supports controlled reuse
Related action or finding	The action created when evidence was missing or insufficient	Connects the register to closeout

Use the fields that support real decisions. A smaller register that owners keep current is more useful than a large one with empty columns.

Start with expected evidence, not uploaded files

Begin each row with the question the evidence needs to answer. For example:

• Is the process defined and approved?
• Did it operate during the period being reviewed?
• Was the output reviewed by an appropriate owner?
• Did the team act on exceptions?

That distinction helps the team request the right combination of records. A procedure may show how work should happen, while a completed test report shows what happened on a particular date. The guide to implementation evidence and operating evidence provides a practical way to separate those roles.

Worked example: a restore test that has gone stale

The following fictional scenario shows how a register can turn an evidence concern into controlled follow-up.

A small software company has daily backup logs and a current recovery procedure. Its latest restore-test report is 14 months old and predates a material production change. The team should not discard the old report: it remains a record of the earlier test. But it should not treat that report as sufficient proof of the current environment without review.

Stage	Register entry or decision
Assessment	Current backup records exist, but recent restore-test evidence for the changed environment is missing
Expected evidence	Approved recovery procedure, current backup records, restore-test plan, results, exceptions and review decision
Reuse check	The old report supports historical operation but does not cover the current environment
Evidence request	Recovery owner confirms whether a later test or equivalent record exists
Implementation action	Plan a proportionate restore test, assign an owner and due date, and define what must be recorded
Review	Reviewer checks the scope, result, exceptions and follow-up rather than accepting the file by name
Closeout	Link the accepted test result and review decision to the original assessment item; supersede the request, not the historical record

The value of this trail is not the number of files collected. It is the visible decision: why more evidence was needed, who acted, what was reviewed and why the item was closed.

Reuse evidence without creating duplicate folders

One evidence item may support several assessment questions, controls or audits. Reference its stable ID and authoritative source from each relevant work item. Avoid uncontrolled copies: they drift, lose context and separate freshness decisions from the source.

For each reuse decision, confirm:

1. the evidence covers the relevant scope;
2. the period or version is appropriate;
3. no significant change has made it unrepresentative;
4. the reviewer can access the authoritative record; and
5. any limitations are recorded with the decision.

Treat freshness as both time and change

Evidence can become stale because time has passed, but time is not the only trigger. A system migration, supplier change, control redesign, incident or material scope change may require an earlier review.

Record a planned review date and event-based triggers where they matter. The register should prompt a decision, not silently declare an item valid because a date has not arrived.

Separate the evidence item from the review decision

“Uploaded” is not the same as “accepted.” Use a small set of statuses with clear meanings:

• Available: the item exists at the recorded source;
• Submitted: the owner has proposed it for the assessment or audit;
• Under review: a reviewer is checking relevance, scope, period and completeness;
• Accepted: the reviewer considers it suitable for the stated use;
• Rework required: a specific gap or follow-up action is recorded; and
• Superseded: a newer item is authoritative, while the old record is retained according to the organisation’s rules.

The reviewer should record the decision and any limitation. This prevents a green status from hiding an unresolved exception.

When a spreadsheet is enough

A controlled spreadsheet can work for a small team when ownership is clear, links remain stable and review activity is modest.

Consider a more connected workflow when the team repeatedly encounters duplicate evidence, unclear ownership, missed follow-up dates, separate findings trackers or time-consuming status reconciliation. The ISO 27001 software guide gives a structured way to compare spreadsheets, document tools and dedicated implementation software against the work your team actually performs.

The AuditPrepared ISO 27001 Platform connects assessment work, reusable evidence, assigned implementation actions, audits, findings and follow-up. Evaluate it against the same evidence trail your team must operate; the approach in this guide remains usable whether you choose a spreadsheet or software.

A seven-step setup for a small team

1. List the assessment questions or work items that need proof.
2. Define the expected evidence and its purpose.
3. Assign an owner before requesting files.
4. Reference the authoritative source rather than creating uncontrolled copies.
5. Record the period, version and freshness triggers.
6. Separate submission from review and acceptance.
7. Link missing or rejected evidence to an action, then record the closeout decision.

If you are still establishing the baseline, the free ISO 27001 readiness checker can help identify areas that need deeper assessment before you build the detailed evidence trail.

Frequently asked questions

Is an evidence register required in a specific format?

Use a format that preserves the traceability, ownership and review decisions your organisation needs.

Should the evidence files be stored inside the register?

Usually, the register should point to the authoritative source. Store files under your organisation’s access, retention and document-control arrangements.

Can one item support more than one requirement?

Yes. Record each relevant use and review the item against that context. Reuse is efficient when scope, period and limitations remain visible.

What should happen when evidence is rejected?

Record the reason, owner and proportionate next action. Keep the review decision linked to the original request so the final closeout shows how the concern was resolved.

Final takeaway

An effective ISO 27001 evidence register is a decision trail, not a file list. Connect the assessment need to an owner, authoritative evidence, freshness check, review decision and closeout. That structure makes evidence easier to reuse, gaps easier to act on and audit preparation easier to manage.