ISO 27001 evidence collection checklist: owners and dates

Published 22 October 2026. Updated 7 November 2026 by GRCompliance.

A folder full of documents is not the same as an evidence trail.

If you are the governance, risk and compliance analyst preparing your next surveillance audit, you probably do not need another folder. You need to know which records support which claims, whether those records cover the right period, and who has checked them.

The International Organization for Standardization and the International Electrotechnical Commission publish the information security management standard commonly called ISO 27001. An information security management system is the organisation's way of managing information security risks, responsibilities and improvement. Evidence should help you judge that system, not merely decorate it.

This ISO 27001 evidence collection checklist gives you a practical starting point. It is an operating aid, not a complete statement of the standard's requirements or a promise of certification.

What matters this week, and what can wait

This week, choose the systems and review period in scope. Give each important control an evidence owner and a reviewer. Test whether someone other than the owner can retrieve and understand the latest record.

A control is a measure used to manage risk: an access review, a restoration test or an approval process, for example.

A redesigned dashboard, a new folder naming scheme for every historic file and a large migration can safely wait until you know which evidence is missing. Do not postpone action on an actual security weakness while improving the filing system.

Start today with one control that protects an important service. Ask: what would convince a reasonable reviewer that this control operated when we said it did?

Define the claim before collecting the file

“Access is reviewed” is too loose to guide collection. “The service owner reviewed privileged accounts for the production support system for the agreed quarter, recorded decisions and followed up removals” tells you what to look for.

Write down four boundaries before sending a request:

• The service, system or business process covered.
• The control activity and the claim it supports.
• The period covered, including any expected recurring records.
• The person responsible for producing the evidence and the person reviewing it.

Do not quietly extend a record beyond its scope. A review of office accounts does not necessarily cover production administrators. A current configuration export does not establish that the same configuration was present throughout an earlier period.

Agree those boundaries with control owners. Otherwise you may spend a week collecting technically correct files that answer the wrong question.

Keep collection and review distinct

The evidence owner obtains the record and explains its origin. The reviewer checks relevance, coverage and any exceptions. The control owner remains responsible for the activity itself.

In a small team, one person may hold several roles. Make that visible and arrange a proportionate second check for important decisions. An unexplained “approved” label is not a substitute for a review.

Build a usable evidence index

An evidence index is a register of records and their context. It can begin as a spreadsheet. Keep sensitive records in an appropriately protected location rather than placing everything in the index itself.

Download the blank evidence index or use the workbook with a fictional example. No registration is needed. The example is practice data, not a client record or an approved control design.

The dates serve different purposes. A report generated today might describe last quarter. A review scheduled next month does not change the period already covered. Keep those facts in separate columns.

Choose evidence that answers the question

Useful evidence usually comes from the activity itself. A service ticket can show the request, decision and completion. A system export can show the relevant configuration or accounts. A test record can show the scenario, result and unresolved limitations.

A policy says what should happen. It rarely proves by itself that the activity happened. Keep the approved policy and the operating record, linked to the same control where useful.

The following examples are fictional illustrations, not reports of real events.

Screenshots can help explain a result. Include enough context to identify the system and date, while removing unnecessary personal or confidential information. A cropped green indicator with no scope is weak evidence, however tidy it looks.

Handle missing, stale and unsuitable evidence honestly

Missing means there is no usable record yet

Create a request with a specific deliverable, owner and due date. “Please provide the restoration test record for the agreed service and period, including result and follow-up actions” is clearer than “send backup evidence”.

If the activity never happened, record a control gap. Do not manufacture a retrospective record or ask someone to backdate an approval. Start the activity now and explain the historical limitation.

Stale means the record no longer supports the claim

Age alone does not decide suitability. A policy may remain valid after review; a recent screenshot may already be obsolete following a system change. Compare the record with the control's intended frequency, current environment and required coverage.

Record why a new item is needed. That helps the owner provide the right replacement rather than simply renaming the old file.

Unsuitable means the record answers a different question

A successful backup job does not demonstrate a successful restoration. A training invitation does not demonstrate attendance or understanding. A supplier certificate may support due diligence but does not answer every question about the service you buy.

Return unsuitable evidence with the missing criterion and a next action. Preserve the review decision so the same item is not repeatedly submitted without improvement.

Make review a repeatable task

For each item, ask:

1. Can I identify the originating system and responsible person?
2. Does it cover the right service, control and period?
3. Does the content support the stated claim?
4. Are failures, exclusions and sampling limits visible?
5. Are follow-up actions assigned and connected to a decision?
6. Is the original protected and retrievable by an authorised reviewer?

Acceptance means the item is suitable for its stated purpose. It does not mean every related risk has disappeared. If a restoration test failed, the failed test may be valid evidence of the activity while the recovery control still needs corrective action.

Keep both conclusions. Turning a failure into a green status removes the very information management needs.

Use GRCompliance without confusing storage with assurance

GRCompliance Core keeps controls, risks, policies, evidence and audits together. Its public documentation confirms evidence linked to controls and an audit workspace for collected evidence and findings.

Use the controls management guide to connect the activity to its control. Then practise with one non-sensitive example: identify the control, add the supporting evidence and inspect how a reviewer would find it. Keep the source, scope and decision context with the record; if a particular field is unavailable, include that information in the supporting document.

This is a workflow to evaluate, not a claim that the downloadable index imports automatically. Check field mapping and edition behaviour before moving a working evidence library.

Try the live demo with fictional data only. The public Core documentation says the demo resets weekly. The free open-source Core is self-hosted; read the self-hosting guidance before deciding who will operate and protect your own installation.

Software cannot make legal determinations or guarantee certification. People still decide what is relevant, whether a control works and what to do about a gap.

Frequently asked questions

What belongs in an ISO 27001 evidence collection checklist?

Include scope, control, claim supported, originating source, protected location, coverage period, owner, reviewer, status, exceptions and next review date. Adapt the index to your management system rather than treating the template as the standard.

Is a screenshot enough evidence?

Sometimes it supports a narrow point. It needs context, a date and a clear connection to the claim. A screenshot of a configuration today does not establish how a recurring process operated over a longer period.

How often should evidence be reviewed?

Set the frequency from the control activity, risk, changes and relevant obligations. Do not assume every item needs the same monthly or annual cycle. Review sooner when incidents or system changes undermine an earlier conclusion.

Can the same evidence support several frameworks?

Yes, when it genuinely supports each requirement and covers the relevant scope and period. Maintain separate mappings and explanations where necessary. Reusing a record is sensible; assuming equivalence without review is not.

Sources

Reviewed 7 November 2026. The checklist and examples are practical suggestions, not reproduced standard text.

• International Organization for Standardization: information security management standard overview.
• GRCompliance public product overview: evidence tasks and risk-management descriptions.
• GRCompliance Core documentation: controls, linked evidence, audit workspace, self-hosting and demo limitations.