The artefact each Annex A control needs, who produces it, and how big a sample the auditor is likely to ask for.
An ISO 27001 evidence checklist is the list of artefacts you hand an auditor to prove each control is operating, not merely written down. It has two halves. The first is the documented information ISO/IEC 27001:2022 names by clause, which is the same for every organisation. The second is the evidence for the Annex A controls your Statement of Applicability marks applicable, which is specific to you. ISO publishes no such list. This page sets it out, control by control, with the artefact, its owner and the sample auditors commonly ask to see.
Evidence in an ISO 27001 audit is a dated record that a control was actually applied, produced by the process that performs the control rather than written for the auditor. A policy saying access is reviewed quarterly is intent. The completed review, with the user list, the reviewer's name, the date and the tickets for accounts removed, is evidence. The auditor's test: could this artefact exist if nobody had done the work? If so, it is not evidence.
ISO/IEC 27001:2022 names a fixed set of documented information across clauses 4 to 10, and an ISO 27001 evidence checklist has to include all of it whichever Annex A controls you applied. The standard names what must exist, not how to format it, so these can sit in twelve files or three, as long as each is controlled, dated and available at the audit.
| Clause | Documented information the auditor will ask for |
|---|---|
| 4.3 | The scope of the ISMS, including what is excluded and why |
| 5.2 | The information security policy, with an approval date and an owner |
| 6.1.2 | The information security risk assessment process |
| 6.1.3 | The risk treatment process and the Statement of Applicability |
| 6.2 | Information security objectives and the plan to achieve them |
| 7.2 | Evidence of competence for the people holding ISMS roles |
| 8.2 | The results of the risk assessments you actually ran |
| 8.3 | The results of risk treatment |
| 9.1 | Monitoring and measurement results |
| 9.2 | The internal audit programme and the internal audit reports |
| 9.3 | The results of management review |
| 10.2 | Records of nonconformities and the corrective action taken |
Get the Statement of Applicability right first, because it is what the auditor reads to decide what else to ask for. Every applicable control becomes a line on your evidence checklist, and every exclusion needs a justification. If yours is not written, start with how to write a Statement of Applicability your auditor will accept.
Annex A of ISO/IEC 27001:2022 holds 93 controls in four themes: 37 organisational controls numbered 5.1 to 5.37, 8 people controls numbered 6.1 to 6.8, 14 physical controls numbered 7.1 to 7.14, and 34 technological controls numbered 8.1 to 8.34. You owe evidence only for the applicable ones. The table covers those auditors sample most often at a first certification audit.
| Annex A control | Evidence the auditor asks for | Owner |
|---|---|---|
| A.5.1 Policies for information security | Approved policy set, each policy carrying an owner, a version and an approval date | ISMS owner |
| A.5.9 Inventory of information and other associated assets | Asset register export showing owner, classification and date of last review | IT |
| A.5.15 Access control | Access control policy plus the role to permission mapping actually in force | IT |
| A.5.18 Access rights | One completed access review: user list, named reviewer, date, and tickets for accounts removed | IT |
| A.5.19 to A.5.22 Supplier relationships | Vendor register, security clauses in a signed contract, latest review of a critical supplier | ISMS owner |
| A.5.24 to A.5.28 Incident management | Incident procedure, incident log, and one closed incident end to end with timestamps and lessons | Security lead |
| A.6.1 Screening | Background check records for recent hires, with consent recorded | HR |
| A.6.3 Awareness, education and training | Completion report for the current cycle, listing every named employee and their date | HR |
| A.6.5 Responsibilities after termination | Completed leaver checklist for a recent departure, with access removal timestamps | HR and IT |
| A.8.2 Privileged access rights | Current privileged account list, the approval behind each, and evidence they are reviewed | IT |
| A.8.8 Management of technical vulnerabilities | Scan report, the remediation tickets it produced, and your own fix timeframes per severity | Engineering |
| A.8.13 Information backup | Backup configuration, a successful job log, and a dated restore test with its result | IT |
| A.8.16 Monitoring activities | An alert that actually fired, who saw it, and what was done about it | Security lead |
| A.8.24 Use of cryptography | Encryption settings at rest and in transit, key management rules, and who holds the keys | Engineering |
| A.8.32 Change management | One change end to end: request, test, approval and release, inside the audited period | Engineering |
Notice how many rows name a person and a date rather than a document. Most first-time ISO 27001 findings are not missing controls. They are controls that cannot produce a dated record showing the control ran as claimed.
ISO/IEC 27001 prescribes no sample size and no retention period anywhere in the standard, so any checklist quoting a fixed number as an ISO requirement is wrong. The auditor sets the sample from your population size and the control's risk. The period is set by you: whatever interval your own policy states is what you are measured against. Writing "quarterly" in an access control policy then running two reviews a year is a nonconformity. Writing "twice yearly" and running two is not.
| Evidence type | Sample commonly requested | Period it must cover |
|---|---|---|
| Access reviews | One completed review, sometimes two | Your own policy cycle |
| New starters | Two to five recent hires | Since the ISMS started operating |
| Leavers | Two to five recent departures | Since the ISMS started operating |
| Changes | Three to ten spread across the period | The audited period |
| Incidents | The full log, one walked end to end | The audited period |
| Backups | Configuration plus at least one restore test | Your own test interval |
| Training | The whole current cycle, not a sample | The current training cycle |
| Internal audit | The full programme and every report | Since the last audit |
| Management review | Every review held | Since the last audit |
Two rows catch small teams out. Training and management review are not sampled, they are checked in full, so one employee missing from the training report is visible immediately. Running your own ISO 27001 internal audit first is the cheapest way to find that.
An ISO 27001 auditor rejects evidence for four recurring reasons, none about the control being weak. No date, or a date outside the audited period, makes an artefact unusable. Evidence produced for the audit rather than by the process, such as a screenshot taken that morning to stand in for a review that never ran, is rejected on sight. A mismatch with your own documents, where the policy says one thing and the record another, becomes a nonconformity. And an artefact with nobody attributable on it proves little: an access review with no named reviewer shows only that a list was exported. See also what auditors really look for in your evidence.
Organise ISO 27001 evidence by control, not by system or team, because the auditor navigates by control and every minute spent hunting for an artefact is billed to you. Build the index from the Statement of Applicability so the two cannot drift apart, then record three things against each applicable control: the artefact, who owns producing it, and the date it was last produced. Fix that list before collecting anything, because deciding what counts once is cheaper than gathering the same screenshot twice. This is what CertAssist is built for: every Annex A control on one board with an evidence checklist per control, editable policy templates, and read-only auditor access. CertAssist does not connect to your systems and does not pull your data, so there is nothing to integrate and nothing to breach.
An ISO 27001 evidence checklist will not carry you through certification on its own in three cases. If your controls are not actually running, the checklist just documents the gap faster. If your scope is complex, with multiple legal entities, regulated data or a large physical estate, you need a consultant to shape the scope and the risk assessment. And if you need continuous monitoring across hundreds of cloud accounts, an integrated platform will serve you better. That is a real trade-off: integrations buy automated collection and ongoing monitoring in exchange for granting a vendor standing access to your systems. A checklist earns its keep in the common case, a team of roughly 5 to 200 people certifying for the first time. Whatever you use, an accredited certification body still has to perform the audit and issue the certificate.
What is on an ISO 27001 audit evidence list?
An ISO 27001 audit evidence list has two parts. The first is the documented information named by clauses 4 to 10: the ISMS scope, the information security policy, the risk assessment and treatment processes, the Statement of Applicability, the objectives, and records of competence, monitoring, internal audit, management review and corrective action. The second is one artefact per Annex A control that your Statement of Applicability marks applicable.
What is an ISO 27001 controls evidence checklist?
An ISO 27001 controls evidence checklist maps each applicable Annex A control to the specific artefact that proves it operates, the person who produces that artefact, and the date it was last produced. It is built from your Statement of Applicability rather than from the full 93 controls, because you only owe evidence for the controls you declared applicable. Keeping the two aligned prevents the most common audit finding.
What is evidence of competence in ISO 27001?
Evidence of competence is what Clause 7.2 of ISO/IEC 27001:2022 requires you to retain for the people holding roles in your ISMS. In practice it is a qualification, a training certificate, a role description matched to a named person, or a documented record of relevant experience. It applies to your internal auditor and ISMS owner in particular, and a small team can satisfy it with a short competence record per role.
Who can perform an ISO 27001 audit?
Internal audits under Clause 9.2 can be performed by anyone competent and impartial, including your own staff or a contractor, provided they do not audit work they built themselves. The certification audit is different: only an accredited certification body can issue an ISO 27001 certificate, and accreditation is traceable through the International Accreditation Forum. Consultants and software vendors cannot certify you.
How long does an ISO 27001 audit take?
Certification is split into a Stage 1 documentation review and a Stage 2 audit of the controls in operation, usually a few weeks apart. Audit duration is set by the certification body from your headcount and scope complexity, not by ISO/IEC 27001 itself, so a small single-site organisation takes far less auditor time than a multi-entity one. Ask your certification body for the audit day calculation in the quote.
ISO/IEC 27001 is maintained by ISO/IEC JTC 1/SC 27.
All 93 ISO 27001:2022 Annex A controls on one board, with an evidence checklist per control, editable policy templates and read-only auditor access, for a flat US$225 a month.
See pricing FrameworksFlat $225 a month, or $2,475 a year (12 months for the price of 11). All prices in USD.
