Most organisations focus their ISO 27001 preparation on writing policies. That is necessary but not sufficient. Stage 2 auditors spend the majority of their time looking at evidence — proof that the controls described in your policies and Statement of Applicability are actually being implemented and operating effectively.
A policy that says "access is reviewed quarterly" is just a document. The evidence that satisfies an auditor is a completed access review record, with dates, reviewer names, and the changes made as a result. This distinction — between saying and doing — is what Stage 2 is designed to test.
The 5 Types of Evidence Auditors Accept
Documentation
Stage 1 focusPolicies, procedures, SoA, risk register, asset register
Records
Primary Stage 2 evidenceLogs, completed forms, training sign-offs, meeting minutes
Observation
Used selectivelyAuditor sees a process being performed during the audit
Interviews
Checks real understandingStaff explain their role in ISMS processes and controls
System outputs
Technical control proofScreenshots, config exports, scan reports, alert logs
Clause-by-Clause: The Most Evidence-Heavy Areas
Some clauses are almost entirely document-based (you write a policy, it exists, audit passes). Others require extensive operational evidence collected over time. Know the difference before Stage 2.
Clause 6.1 — Risk Assessment (Evidence-heavy)
Auditors expect a completed risk register with: every identified risk scored for likelihood and impact, a named owner for each risk, and a documented treatment decision (mitigate, accept, transfer, avoid). The risk register must then link to the SoA — the controls you have applied must match the treatment decisions in the register. If you have decided to mitigate a risk with access controls, A.5.15 must appear as applicable in the SoA with a note linking back to that risk.
Clause 7.2 — Competence (Commonly missed)
You must be able to demonstrate that people working in ISMS-related roles are competent. Evidence: training completion records, certifications, or a documented assessment of competence for each role. This catches many organisations who trained staff verbally with no sign-off records.
Clause 9.1 — Performance Monitoring
The standard requires you to monitor, measure, analyse, and evaluate ISMS performance. Evidence: at minimum, metrics that feed into management review. This could be incident counts, vulnerability closure rates, training completion percentages, or SLA compliance. The key is that you are measuring something meaningful and using it to make decisions.
Clause 9.2 — Internal Audit
Auditors will ask to see your internal audit programme, the audit report, and the corrective actions raised. The programme must show that you planned to audit all relevant areas within the audit cycle. Non-conformities raised in the internal audit must have formal corrective actions with due dates and sign-off when closed. An internal audit with no findings at all will be questioned — a perfect ISMS after the first year is implausible and suggests the audit was not conducted with rigour.
Clause 9.3 — Management Review
Minutes are mandatory. Auditors check that the agenda covered the specific inputs required by Clause 9.3 (audit results, risk status, incidents, objectives progress, interested party feedback) and that management made documented decisions and assigned action items.
Pre-Stage 2 Evidence Checklist
Operational records
- Risk register — scored, treated, linked to SoA
- Asset register — complete with owners and classification
- Training records — all ISMS staff signed off
- Access review records — at least one completed cycle
- Vulnerability scan reports — with remediation log
- Incident log — even if empty, must be maintained
- Supplier assessment records — for key third parties
- Backup restoration test record — dated
Governance records
- Internal audit report — with findings and CAR log
- Management review minutes — with ISO 9.3 agenda items
- Corrective action records — all closed or in-progress
- Competence records — for all ISMS-related roles
- Objectives progress report — for each security objective
- Communication records — policy awareness evidence
- Change records — for any ISMS scope or policy changes
- Legal register — with compliance status per obligation
Annex A Controls: Technical Evidence Auditors Request
For each Annex A control marked as applicable in your SoA, an auditor can ask for evidence of implementation. The following controls are most frequently sampled in Stage 2:
A.5.15 — Access control
User account list with role assignments. Evidence of joiner/mover/leaver process — specifically that leavers have accounts disabled promptly. Access review records.
A.5.23 — Cloud security
Configuration of key cloud services (IAM, logging, encryption at rest). Cloud security posture output if applicable.
A.5.24 — Incident management
Incident log for the audit period. At least one incident should have a documented response trail, even if minor.
A.6.3 — Security awareness
Training completion records with dates and staff names. Evidence of what was covered and how sign-off was obtained.
A.8.8 — Vulnerability management
Scan tool output. Remediation decisions for all identified vulnerabilities — especially critical/high severity. Patch cadence evidence.
A.8.13 — Backup
Backup configuration screenshots and restoration test records with outcomes.
A.8.24 — Cryptography
Encryption configuration for data at rest and in transit. Key management procedure and evidence of its operation.
The Most Common Evidence Gaps
What causes major non-conformities in Stage 2
Evidence collected only for the audit
Auditors can identify records that were created in a rush before Stage 2. If all your access review records are dated the same week as the audit, this will be flagged. Controls must operate continuously, not just at audit time.
No evidence of monitoring
Saying you monitor vulnerabilities is not enough. You need scan outputs, dates, and documented decisions about what to do with each finding.
Training with no sign-off
Security awareness training must have individual attendance records. A generic "training was delivered" statement without names and dates is insufficient.
Incidents not logged because they were "minor"
All security incidents must be logged — including near-misses and low-severity events. A zero-entry incident log for a 12-month period will raise questions.