ISO 27001 audit evidence is dated records created when the work happened: the documented information clauses 4 to 10 require, plus the tickets, logs and reviews that show Annex A controls operated. Certification auditors sample it across the audited period. A folder assembled the month before shows the current state and invites questions about every other month.
This guide covers what auditors ask for, required documented information, what auditors accept, automatic collection, missing evidence, evidence tools, what automation does not prove, and a checklist.
| Control area | Typical evidence | Where it lives | Goes stale |
|---|---|---|---|
| ISMS core (4.3, 5.2, 6.1, 6.2) | Scope, policy, risk register, SoA, treatment plan, objectives | Document store or GRC tool | When the business changes; review at least yearly |
| Assets (A.5.9) | Inventory with owners, reconciled with what runs | Device management, cloud accounts | With every new device or cloud resource |
| Access rights (A.5.18) | Joiner and leaver tickets, deprovisioning records, signed access reviews | HR system, identity provider, ticketing | With every hire and departure; reviews often quarterly |
| Authentication and configuration (A.8.5, A.8.9) | MFA coverage per account, baselines, drift reports | Identity provider, cloud posture tools | Continuously: one new admin account changes it |
| Vulnerabilities (A.8.8) | Scan results, tickets showing fixes within your deadline | Scanner, ticketing | Weekly to monthly |
| Backup (A.8.13) | Job reports and dated restore test results | Backup tool, test record | Jobs daily; restore tests at your policy’s interval |
| Logging and monitoring (A.8.15, A.8.16) | Retention settings, alert tickets, review records | Log platform, ticketing | Continuously |
| Change (A.8.32) | Change tickets or pull requests with approval | Ticketing, version control | With every change |
| Suppliers (A.5.19 to A.5.22) | Register, assessments, contract clauses, review records | Contract store, procurement | With every new supplier; reviews often yearly |
| Incidents (A.5.24 to A.5.27) | Incident log, response records, lessons applied | Ticketing | With every incident |
| Training (A.6.3, 7.2) | Completion records per person | Training platform, HR | With every joiner; cycles often yearly |
| Audit and review (9.2, 9.3, 10.2) | Audit programme and reports, review minutes, corrective action log | Document store, ticketing | At each planned interval |
The last column is practice, not a requirement. ISO 27001 mostly says “planned intervals” or “regularly” and leaves the frequency to you. The auditor then tests you against your own intervals.
What do ISO 27001 auditors ask for?
Certification bodies are accredited against ISO/IEC 17021-1. It requires auditors to obtain information “by appropriate sampling” and verify it to become audit evidence (9.4.4.1), through interviews, observation, and review of documentation and records (9.4.4.2). The interview tests whether people do what the record says. Every audit report states that auditing is based on a sampling process (9.4.8.2).
They sample across a period, not a moment. Not one access review, a sequence of them with dates. Stage 2 exists “to evaluate the implementation, including effectiveness” of the management system (9.3.1.3), and that needs history. In practice certification bodies expect around three months of operation first. At surveillance, the window is the period since the last visit. The first audit is set out in Stage 1 and Stage 2 audits.
Some records are checked at every visit. Each surveillance audit must cover internal audits, management review and actions on previous nonconformities, among other items (9.6.2.2). None can be produced afterwards with any credibility. Years two and three are covered in surveillance audits.
What documented information does ISO 27001 require?
Clause 7.5.1 splits it in two: documented information the standard requires, and whatever you decide is necessary for the ISMS to be effective. Its note says the extent differs with size, complexity and the competence of people. A 30-person company does not need a 200-page manual.
The required part, clause by clause, in ISO/IEC 27001:2022:
| Clause | Documented information |
|---|---|
| 4.3 | Scope of the ISMS |
| 5.2 | Information security policy |
| 6.1.2 | Risk assessment process |
| 6.1.3 | Risk treatment process, Statement of Applicability |
| 6.2 | Information security objectives |
| 7.2 | Evidence of competence |
| 8.1 | Enough to have confidence that processes ran as planned |
| 8.2, 8.3 | Results of risk assessment and risk treatment |
| 9.1 | Monitoring and measurement results |
| 9.2.2 | Audit programme and audit results |
| 9.3.3 | Results of management reviews |
| 10.2 | Nonconformities, actions taken, results of corrective action |
Clause 8.1 is the one that reaches into Annex A. Records must exist “to the extent necessary to have confidence that the processes have been carried out as planned”. That is where most operational evidence comes from. Annex A control 5.28, “collection of evidence”, is a different thing: it covers evidence “related to information security events”, meaning incidents and forensics.
Clause 7.5.3 then applies to the evidence itself. It must be available when needed, protected from loss of confidentiality, improper use or loss of integrity, version controlled, and retained or disposed of deliberately. A shared folder of screenshots that anyone can edit is hard to defend against that clause.
What evidence do ISO 27001 auditors accept?
The belief that evidence must be pretty causes a lot of unnecessary work. Auditors accept records created as a by-product of the work. A ticket with a date. A log entry. An approval in the tool where approvals happen. A signed-off review with the reviewer’s name and the date.
They notice evidence made for them, because it is easy to see. Documents with adjacent timestamps. A tidiness real operations do not have. A screenshot of a setting rather than a record of the change that set it.
They accept gaps that are explained. A patch record with a hole and a note saying why is a working system with a known issue. A patch record with no hole at all, for a company of forty people, is a claim nobody believes.
The bar is not perfection. It is contemporaneity: was this recorded when it happened?
Which ISO 27001 evidence can be collected automatically?
- Configuration state. MFA enforcement, encryption, access policies, cloud posture. Readable from the systems, continuously. If you still screenshot settings, fix this first.
- Event records. Logins, changes, patches, alerts, incidents. Systems create them anyway. The work is retaining them for the audit window.
- Human decisions. Risk acceptances, approvals, exceptions, supplier assessments, management review decisions. These cannot generate themselves, because the decision is the evidence. They need a place to live with an owner and a date.
- Periodic activities. Access reviews, training, restore tests, continuity exercises, internal audits. These need a schedule that produces a dated record whether or not anyone remembers the audit.
The first two should be automatic. Decisions need a system of record. Periodic activities need a calendar with teeth. Most audit-preparation pain comes from treating all four as decisions and doing them by hand.
What if evidence is missing before an ISO 27001 audit?
Four to six weeks before the audit, someone opens the control list and starts collecting. A screenshot of the MFA settings. A supplier list pulled from three people’s memories. A backup report for this month, because nobody kept the earlier ones. The audit passes, and it happens again next year, because only the deadline changed.
It costs more than the hours. Assembled evidence is current-state, which prompts the question about the other eleven months. It lands on the engineer who was busy with something else. It creates a file, not a record: a folder built in March describes March and contributes nothing to the next audit.
If you are there now:
- Do not back-date or recreate records. File metadata is not subtle, and one manufactured record discredits the real ones.
- List the applicable controls in your Statement of Applicability and mark each: record exists, partial, none.
- Start the missing recurring activities this week, imperfect. An imperfect access review with a date beats a perfect one that has not happened.
- Log each gap as a nonconformity with its cause and a corrective action, in line with clause 10.2. A gap your own system found and is closing is evidence the system works.
- Check the core records first: internal audit, management review, risk assessment. They are looked at on every visit.
- If Stage 2 is close and core records are missing, move the date. A surveillance audit cannot wait: the first must take place within 12 months of the certification decision (ISO/IEC 17021-1, 9.1.3.3).
What should an ISO 27001 evidence tool do?
The standard does not require one. Clause 7.5.2 asks only for an appropriate format and medium, paper included. In practice, a spreadsheet and a shared drive stop keeping up beyond a handful of source systems. Whichever tool you use, check that it:
- Reads evidence from the source systems instead of asking for uploads.
- Keeps dated history, not only the current state, so it can answer for the whole period.
- Maps each item to a control, so one record can serve several frameworks and customer questionnaires.
- Holds controls, gaps and tasks together, each with an owner and a due date.
- Sends exceptions to a person, not only to a dashboard.
- Controls the evidence as clause 7.5.3 requires: access, integrity, versions, retention.
- Exports what the auditor samples without a week of formatting.
A control then carries four things: an owner, a status, its evidence and a date. When an auditor or a customer asks, the answer is already there, as shown in how to answer a security questionnaire.
The technical reality: automated evidence proves a control ran, not that it worked
Evidence that assembles itself removes the scramble. It does not prove the control does its job, and the control text often asks for the part an automated record leaves out.
A.8.8 requires that exposure to vulnerabilities is evaluated and “appropriate measures shall be taken”. A monthly scan filing its own report proves the scan ran. It looks the same whether critical findings were fixed in three days or ignored for nine months. A.8.15 requires logs to be “produced, stored, protected and analysed”. Retention settings evidence the first three. A.8.13 requires backups to be “regularly tested”. A nightly job report proves no restore.
Stage 2 does evaluate effectiveness, but of the management system, on a sample. A few days of sampling can miss a finding that sat open for most of the year. Your own internal audit can do better if it tests rather than reviews: restore a backup, follow a scanner finding to closure.
Closing the gap means the evidence records the outcome, not only the activity: time to fix critical findings, alerts reviewed and closed, restores timed. Each finding needs an owner and a deadline enforced by something other than the audit calendar. That is how the CloudSoul platform works: automated collection from your systems, with human-in-the-loop expertise reviewing the exceptions. It is also how we run ISO 27001 programmes. If nobody in the company can own those exceptions, ISO 27001 without a security team covers who does what.
ISO 27001 audit evidence checklist
- Map every applicable control in the SoA to a record, the system it lives in and an owner.
- Collect configuration state and event records automatically, with dated history.
- Give every risk acceptance, exception and approval an owner and a date.
- Schedule periodic activities so each produces a dated record.
- Keep the audit programme, audit reports, review minutes and corrective action log current.
- Record gaps as nonconformities with corrective actions. Never back-fill.
- Make the evidence show outcomes: fix times, analysed logs, tested restores.
Sources
- ISO/IEC 27001:2022, Information security management systems: Requirements, clauses 4 to 10 (notably 7.5) and Annex A, ISO.
- ISO/IEC 17021-1:2015, Conformity assessment: Requirements for bodies providing audit and certification of management systems, clauses 9.1.3.3, 9.3.1.3, 9.4.4, 9.4.8.2 and 9.6.2.2, ISO.
Frequently asked questions
What evidence do ISO 27001 auditors ask for?
The documented information the standard requires, such as the scope, policy, risk assessment, Statement of Applicability, internal audit results and management review results, plus records showing that controls operated. Auditors sample these records and verify them through interviews and observation.
How far back do ISO 27001 auditors look for evidence?
Across the period being audited, not only the current state. At Stage 2 that is the time the management system has been running, in practice around three months or more. At a surveillance audit it is the period since the last visit.
What should you do if evidence is missing before an ISO 27001 audit?
Do not back-date or recreate records. Log each gap as a nonconformity with a corrective action and start producing the record now. If Stage 2 is close and core records such as the internal audit are missing, move the date.
Does ISO 27001 require a tool for evidence collection?
No. Documented information can be in any appropriate format or medium, paper included. It must be controlled: available when needed, protected, version controlled, and retained or disposed of deliberately.
Is Annex A control 5.28 about collecting audit evidence?
No. Control 5.28 covers evidence related to information security events, meaning incidents and forensics. Audit evidence falls under clause 7.5 on documented information and the clauses that call for it.
