Elena Vasquez had eleven weeks until her Stage 2 audit and, by every internal measure she'd built, Meridian Health Analytics was ready. The risk register was current. The policies were signed. Her CISO had told the board, in writing, that certification was "on track, low risk." Elena believed it, because every individual piece of the ISMS existed somewhere — scattered across a policy folder, a ticketing system, three different SharePoint sites, and the memories of a security engineer named Priya who happened to know where everything was.
What Elena didn't have was a map connecting each of the 93 Annex A controls and 7 management clauses to the specific evidence an auditor would ask to see. She had documents. She did not have an evidence trail an auditor could follow in real time, control by control, without her narrating every step. That distinction cost her company approximately $58,000 in direct terms — a lead auditor day that ran nine hours instead of five, a second unplanned visit to close out three major nonconformities, six weeks of delayed sales cycles while a healthcare payer prospect waited on the certificate before signing a $1.2 million annual contract, and forty hours of Elena's team scrambling retroactively to produce records that should have taken minutes to pull.
The nonconformities themselves were almost insulting in how avoidable they were. The auditor asked for evidence that access reviews under control 5.18 had actually happened in the last quarter — not that a policy existed requiring them, but that they had occurred, with named reviewers and dated outputs. Elena's team had done the reviews. They just hadn't kept the sign-off trail in a place anyone could find inside the audit window. The auditor asked for management review minutes tied to Clause 9.3 showing that leadership had actually discussed ISMS performance, resource adequacy, and risk trends — not a meeting invite, but minutes with decisions attached. They had held the meeting. Nobody had written it up properly. Each gap was a five-minute fix if you'd built the evidence map eighteen months earlier. Rebuilt under audit-week pressure, each one ate half a day and racked up auditor findings that made the whole engagement look less mature than the ISMS actually was.
This is the article I wish I could have handed Elena in month one. It is not a summary of what ISO 27001 requires — you'll find that in the clause-by-clause and control-specific articles linked throughout this piece. This is the checklist: what an auditor checks, clause by clause and Annex A theme by theme, and what evidence you need within arm's reach to answer without hesitation.
Who This Is For
This checklist is written for ISMS managers, information security officers, internal auditors, and consultants who are within three to six months of a Stage 1 or Stage 2 audit, a surveillance audit, or a recertification cycle, and who need a structured way to self-assess readiness before the certification body arrives. It assumes you already understand what ISO 27001 requires — if you need the foundational explanation of a clause or control, this article links out to it, and if a term trips you up along the way, keep the ISO 27001 Terminology and Glossary open in another tab. What you'll walk away with here is a working, printable checklist: every clause's checkpoints and typical evidence, every Annex A theme's representative controls and evidence expectations, the high-scrutiny controls that auditors probe hardest, a way to score your own readiness before the audit, and the mistakes that turn a clean audit into a nonconformity-riddled one.
How to Use This Checklist
Work it in two passes. First, walk Clauses 4 through 10 — these are the management-system requirements that apply to every certified organization regardless of industry, and auditors always start here because a weak management system undermines confidence in everything else you show them. Second, walk Annex A — but only the controls your Statement of Applicability marks as applicable. Every organization's Annex A footprint differs. A control marked "excluded" in your Statement of Applicability (SoA) needs a documented justification, not operational evidence — don't waste audit-prep time building evidence for controls you've legitimately scoped out, and don't assume a control is out of scope just because it's inconvenient. The auditor will check your SoA justifications as carefully as your evidence.
flowchart TD
A[Clauses 4-10: Management System Requirements] --> B[Risk Assessment and Treatment - Clause 6]
B --> C[Statement of Applicability - SoA]
C --> D{Control Applicable?}
D -->|Yes| E[Annex A Control: Build Evidence]
D -->|No, Justified Exclusion| F[Document Exclusion Rationale]
E --> G[Evidence Pack: Policy + Records + Logs + Sign-off]
F --> G
G --> H[Internal Audit Verifies Evidence]
H --> I[Management Review Confirms Readiness]
I --> J[Stage 1 / Stage 2 / Surveillance Audit]The logic in that diagram is the logic of the whole standard: clauses drive risk assessment, risk assessment drives the SoA, the SoA determines which of the 93 controls actually need evidence, and your internal audit should have already tested that evidence before the certification body ever sees it. If you're building your checklist in any other order, you're building it backwards.
"The auditors who fail Stage 2 aren't the ones with weak security. They're the ones who can't produce the record proving the security control operated on the date in question. I don't audit your intentions. I audit your evidence." — Marcus Webb, Lead Auditor, Veritas Certification Body
Clause-by-Clause Checklist: Clauses 4 and 5
Every certification audit — Stage 1, Stage 2, and every surveillance visit after — walks the management-system clauses first. Auditors use these clauses to judge whether the ISMS is genuinely governed or just documented. Read the full requirement breakdowns in Clause 4: Context of the Organization and Clause 5: Leadership and Management Commitment if you need the underlying "why" — this table is the "what to have ready."
Table 1: Clause 4 — Context of the Organization
Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|
Internal and external issues affecting the ISMS are identified | A documented context analysis (PESTLE, SWOT, or similar) reviewed at a defined interval | Analysis was done once at kickoff and never revisited |
Interested parties and their requirements are identified | A stakeholder register naming parties (regulators, customers, shareholders, employees) and their security-relevant requirements | Register lists parties but not their actual requirements or how they're tracked |
Legal, regulatory, and contractual requirements are identified | A legal/regulatory register mapped to controls, updated when law or contracts change | Register exists but hasn't been updated since a recent contract or regulatory change |
ISMS scope is defined and documented | A written scope statement covering locations, assets, technologies, and exclusions with rationale | Scope statement is vague ("our IT systems") or doesn't match what's actually being audited |
Scope excludes are justified | Documented rationale for anything excluded from the ISMS boundary | Exclusions exist with no rationale, or exclude things auditors consider core to the business |
Table 2: Clause 5 — Leadership
Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|
Top management demonstrates leadership and commitment | Meeting minutes, resourcing decisions, and communications showing leadership engagement, not just a signed policy | A policy signed once with no ongoing management involvement visible |
Information security policy exists and is communicated | The policy itself, plus proof of distribution/acknowledgment to staff | Policy exists on a server nobody outside IT has read or acknowledged |
Roles, responsibilities, and authorities are assigned | An org chart or RACI matrix naming specific individuals against ISMS responsibilities | Responsibilities assigned to a title, not a named accountable person, or duplicated across roles with no clarity |
Top management ensures ISMS requirements are integrated into business processes | Evidence security is a standing agenda item in business planning, budgeting, or project processes | Security treated as a side function bolted onto a business process, invisible in planning artifacts |
Interested parties deserve their own note here: auditors increasingly probe whether the requirements register in Clause 4 is a living document tied to actual contracts and regulations (see interested parties and stakeholder requirements), rather than a one-time brainstorm. If your register hasn't changed in the last review cycle but your customer base or regulatory footprint has, that's a gap an experienced auditor will find in the first hour.
Clause-by-Clause Checklist: Clauses 6 and 7
Clause 6 is where most nonconformities are born, because it's where risk assessment, risk treatment, the Statement of Applicability, and information security objectives all have to line up with each other. The full mechanics are covered in Clause 6: Planning — Risk Assessment and Objectives; here's the auditor's checklist.
Table 3: Clause 6 — Planning
Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|
A documented risk assessment methodology exists and is applied consistently | A risk methodology document plus a risk register showing the methodology actually applied to real assets | Methodology document exists but the risk register uses a different, undocumented scoring approach |
Risks are assessed for likelihood, impact, and current risk level | A risk register with named risk owners, current scores, and treatment decisions | Risks listed with no clear owner or stale scores from the initial assessment |
Risk treatment options are selected and documented | A risk treatment plan tied to specific risks and specific controls | Treatment plan exists in name only — no link between individual risks and the controls meant to treat them |
Statement of Applicability lists all 93 controls with justification | A current SoA showing applicable/excluded status and justification for each, referencing risk assessment output | SoA copied from a template with generic justifications not tied to the organization's actual risk assessment |
Information security objectives are set, measurable, and monitored | Documented objectives with targets, owners, and monitoring evidence (dashboards, reports) | Objectives are aspirational statements with no measurable target or tracking mechanism |
Planning of changes to the ISMS is controlled | Change records showing security impact was considered before ISMS-affecting changes were made | Significant changes (new systems, new locations, M&A) made with no documented security impact assessment |
Clause 7 is the "support" clause — resourcing, competence, awareness, communication, and documented information. It's deceptively easy to under-prepare for because none of it feels as technical as risk assessment, but auditors treat weak competence and awareness evidence as a leading indicator of a fragile ISMS. See Clause 7: Support for the full requirement walkthrough.
Table 4: Clause 7 — Support
Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|
Resources for the ISMS are determined and provided | Budget records, staffing plans, or tooling investments tied to ISMS needs | Resourcing decisions exist but were never documented as ISMS-related |
Competence of people affecting security performance is ensured | Training records, certifications, or role-based competence matrices for security-relevant roles | Competence assumed informally ("they've been doing it for years") with no documented evidence |
Awareness of the security policy and individual roles is confirmed | Training completion records, quiz results, or acknowledgment logs across the workforce | Awareness training delivered once at onboarding with no refresh or completion tracking |
Internal and external communication needs are defined | A communication plan naming what, when, how, and to whom (regulators, customers, staff) | No documented communication plan — communication happens ad hoc with no auditable trail |
Documented information is controlled (creation, approval, version, access) | A document control procedure with version histories, approval trails, and access restrictions on ISMS records | Documents circulate in multiple versions with no clear "current approved version" |
"Clause 7 is where I find out whether an ISMS is real or theatrical. If nobody in the warehouse can tell me what they're supposed to do if they see a USB drive plugged into a machine that shouldn't have one, the training records didn't produce awareness — they produced a checkbox." — Fiona Chen, Internal Audit Lead, Northbridge Payments
Clause-by-Clause Checklist: Clause 8
Clause 8 is where planning becomes operation — where the risk treatment plan and the Annex A controls it selected actually get executed, day to day, in production. Auditors use Clause 8 evidence to sanity-check whether Clause 6's paperwork reflects reality. The requirement detail lives in Clause 8: Operation — Implementing Risk Treatment.
Table 5: Clause 8 — Operation
Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|
Operational planning and control processes are documented and followed | Documented operating procedures for security-critical processes (change management, access provisioning, incident response) | Procedures documented but staff execute a different, informal process in practice |
Risk assessments are performed at planned intervals and when significant changes occur | Dated risk assessment records showing periodic reviews and event-triggered reassessments (new vendor, new system, incident) | Risk assessment only performed at initial certification, never re-triggered by later changes |
Risk treatment plan is implemented and tracked to completion | A treatment tracker showing planned vs. actual completion dates for each control implementation | Treatment plan items marked "in progress" for multiple audit cycles with no forcing function to close them |
Outsourced processes affecting the ISMS are controlled | Contracts, SLAs, or oversight records for any outsourced process within the ISMS scope | Outsourced function (e.g., hosting, payroll, SOC) has no documented security oversight or right-to-audit clause |
Clause-by-Clause Checklist: Clause 9
Clause 9 is the evidence auditors trust most, because it's the organization checking its own work — monitoring, measurement, internal audit, and management review. A weak Clause 9 undermines confidence in every other clause, because it suggests nobody would have caught a failure even if one occurred. Full detail is in Clause 9: Performance Evaluation.
Table 6: Clause 9 — Performance Evaluation
Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|
Monitoring, measurement, analysis, and evaluation methods are defined | Documented metrics (KPIs) with defined methods, frequency, and named responsible parties | Metrics exist on a dashboard but nobody can explain the calculation method or the target |
Internal audit program covers the full ISMS scope over a defined cycle | An audit program/schedule, audit plans, and audit reports showing scope coverage across clauses and controls | Internal audits performed but scope repeats the same easy areas, never touching high-risk controls |
Internal auditors are objective and independent of the area audited | Auditor competence records and evidence no one audited their own work area | The person who implemented a control is also the one who "audited" it |
Management review is held at planned intervals with required inputs and outputs | Management review minutes covering audit results, nonconformities, risk trends, resource needs, and improvement opportunities, with recorded decisions | A meeting occurred, but minutes only note attendance — no inputs discussed, no decisions recorded |
Nonconformities identified through monitoring feed into corrective action | Traceable links between monitoring findings, internal audit findings, and corrective action records | Findings logged in one system, corrective actions tracked in another, with no traceable link between them |
Elena's Meridian Health Analytics nonconformity is a textbook Clause 9 finding: the review happened, the substance was real, but the paper trail an auditor needs — dated minutes with inputs and decisions attached — didn't exist in a retrievable form. Building an internal audit program that tests this exact retrievability, months before the certification body arrives, is the single highest-leverage thing you can do with your remaining prep time.
Clause-by-Clause Checklist: Clause 10
Clause 10 asks a simple question with a hard answer: when something goes wrong, does the organization actually learn and change, or does it just log the incident and move on? See Clause 10: Improvement for the full requirement.
Table 7: Clause 10 — Improvement
Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|
Nonconformities are identified, documented, and reacted to | A nonconformity log with root cause analysis, not just a description of what happened | Nonconformity recorded with a fix applied, but no root cause analysis showing why it happened |
Corrective actions address root cause, not just the symptom | Corrective action records showing the underlying cause was addressed and effectiveness was reviewed later | Corrective action closes the ticket the same day the symptom is patched, with no follow-up review |
Continual improvement of the ISMS is demonstrated over time | Trend analysis across audit cycles, incident data, or risk register showing measurable improvement | ISMS metrics look identical year over year — no visible maturity trend for auditors to point to |
"Clause 10 is where I decide whether an organization is going to be easy to certify again next year or hard. If every nonconformity gets a root cause, a fix, and a check that the fix worked, I trust the system. If it's just ticket-closing, I start wondering what else got closed without being fixed." — Tom Bracewell, Information Security Consultant, Bracewell Risk Advisory
Annex A Checklist: A Note Before You Start
Annex A of ISO/IEC 27001:2022 contains 93 controls across four themes — Organizational (5.1–5.37), People (6.1–6.8), Physical (7.1–7.14), and Technological (8.1–8.34). Every one of those 93 controls must be considered during risk treatment, but not every one has to be operated by every organization. Applicability is determined by your risk assessment and documented in your Statement of Applicability (SoA). If your SoA marks a control as excluded — say, control 7.4 physical security monitoring, because your organization operates entirely on cloud infrastructure with no physical premises to monitor — the auditor doesn't expect operational evidence for it. The auditor expects a documented, risk-based justification for the exclusion that holds up to scrutiny. Confusing "excluded" with "ignored" is one of the fastest ways to turn a legitimate scoping decision into a nonconformity, because an auditor who finds an unjustified or thin exclusion rationale will treat it exactly like a missing control.
The tables below don't attempt to list all 93 controls individually — that level of granular detail belongs in the theme overview and per-control articles linked throughout. What follows is a checklist by theme: representative controls, what the auditor checks, and what evidence you should have ready, organized so you can walk your SoA theme by theme and confirm you're not missing anything foundational.
Annex A Checklist: Organizational Controls (5.1–5.37)
The Organizational theme is the largest of the four — 37 controls covering policy, roles, asset management, access control, supplier relationships, incident management, and business continuity. It's also the theme auditors spend the most calendar time on, because it touches governance decisions that ripple into every other theme. The full 37-control breakdown lives in Annex A Organizational Controls: Complete Overview.
Table 8: Organizational Controls (5.1–5.37) — Representative Checkpoints
Control Cluster | Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|---|
5.1 Policies for information security | Policy set exists, approved, communicated, and reviewed at planned intervals | Approved policy documents, distribution/acknowledgment records, review history with dated revisions | Policy hasn't been reviewed since initial approval, or review dates are backdated |
5.2–5.4 Roles, segregation of duties, management responsibilities | Security roles assigned to named individuals; conflicting duties segregated | RACI matrix, org chart, evidence that (for example) the person who approves access isn't the same person who grants it | Segregation exists on paper but the same person holds both roles in practice due to a small team |
5.7 Threat intelligence | Threat intelligence is collected, analyzed, and used to inform decisions | Subscription/feed records, analysis reports, evidence intelligence fed into risk assessment or control changes | Feed subscribed to but nobody can show intelligence ever changed a decision |
5.8 Information security in project management | Security is integrated into the project lifecycle | Project templates/checklists with a security gate, evidence security was assessed on recent projects | Security review exists as a template field nobody actually fills in |
5.9–5.14 Asset management | Assets are inventoried, classified, labelled, and returned on termination | Asset inventory, classification scheme, labelling evidence, asset return records tied to offboarding | Inventory is incomplete or hasn't been reconciled against actual deployed assets recently |
5.15–5.18 Access control | Access is granted, reviewed, and revoked per a documented policy, with authentication and rights managed | Access control policy, periodic access review records with named reviewers and dates, identity/authentication records | Access reviews performed but not evidenced with sign-off, or terminated employees found with active accounts |
5.19–5.23 Supplier relationships | Security requirements are built into supplier agreements and monitored, including cloud services | Supplier security clauses in contracts, supplier risk assessments, monitoring/review records, cloud service risk assessments | Contracts signed before security requirements existed, never retrofitted |
5.24–5.28 Incident management | Incidents are planned for, assessed, responded to, learned from, and evidence is preserved | Incident response plan, incident log with assessment and response records, post-incident review/lessons-learned reports, evidence handling procedure | Incidents handled informally with no consistent log, or lessons-learned step skipped entirely |
5.29–5.30 Business continuity and ICT readiness | Information security is maintained during disruption; ICT continuity is planned and tested | Business continuity plan with security considerations, ICT disaster recovery plan, test/exercise records | Continuity plan exists but has never been tested, or the test didn't include security-relevant scenarios |
5.31–5.34 Legal, IP, records, privacy | Legal/regulatory/contractual requirements, IP rights, records, and PII are protected per requirements | Legal register, IP handling procedures, records retention schedule, privacy/PII handling procedure | PII handling procedure exists but doesn't reflect actual data flows discovered later in a DPIA or similar |
5.35–5.37 Independent review, compliance, documented procedures | Security is independently reviewed, compliance with policy is checked, and operating procedures are documented | Independent review reports (internal audit or external), compliance check records, documented operating procedures for key processes | Independent review conflated with the internal audit program without covering the required independence |
For access control specifically, auditors will ask to see the last full access recertification cycle, not just the policy describing how it should work — see Access Control Policy: Controls 5.15–5.18 for the underlying requirement detail, and note that this is one of the handful of controls flagged as high-scrutiny later in this checklist. Supplier security and incident management (5.19–5.23 and 5.24–5.28) get similarly close attention because they're where an organization's security posture is most exposed to third parties and to real-world failure — see Supplier Relationship Security and Incident Management Under ISO 27001.
Annex A Checklist: People Controls (6.1–6.8)
The People theme has only eight controls, but auditors treat it as a proxy for how seriously an organization takes the "human layer" of security — the layer every technical control ultimately depends on. See ISO 27001 People Controls Overview for the complete breakdown.
Table 9: People Controls (6.1–6.8) — Representative Checkpoints
Control Cluster | Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|---|
6.1 Screening | Background checks are performed proportionate to role risk, before or shortly after hire | Screening records/attestations for a sample of employees, especially those in privileged or sensitive roles | Screening policy exists but records for actual hires can't be produced, or screening wasn't proportionate to role sensitivity |
6.2 Terms and conditions of employment | Security responsibilities are included in employment terms | Signed employment contracts or offer letters referencing security obligations | Security clause added to new contracts but never retrofitted into existing employee agreements |
6.3 Security awareness, education, and training | All personnel receive role-appropriate, recurring security awareness training | Training completion records, curriculum content, evidence of role-specific modules (e.g., developers get secure coding awareness) | Training delivered once at onboarding with no recurring cadence, or completion tracked for less than the full workforce |
6.4 Disciplinary process | A formal, communicated disciplinary process exists for security policy violations | Disciplinary policy, evidence it has been applied (redacted case records) or explicitly a "zero cases to date" position with the process demonstrably in place | Disciplinary process referenced in policy but HR has no record it's ever been invoked or tested |
6.5 Responsibilities after termination or change of employment | Security obligations and access revocation are handled on exit or role change | Offboarding checklist, access revocation timestamps matched against termination dates | Access revoked days after termination date, or offboarding checklist has no security-specific step |
6.6 Confidentiality or non-disclosure agreements | NDAs are signed by employees, contractors, and relevant third parties | Signed NDA records for a sample of staff and contractors | NDAs used for employees but skipped for contractors or short-term vendors with equivalent data access |
6.7 Remote working | Remote working security requirements are defined and applied | Remote work policy, evidence of controls applied to remote devices/connections (VPN, endpoint management enrollment) | Remote work policy exists but wasn't updated after a shift to hybrid/remote work expanded the population it applies to |
6.8 Information security event reporting | Personnel know how and are able to report security events/weaknesses | Reporting mechanism (hotline, ticketing category, email alias), evidence of actual reports received and actioned | Reporting channel exists but training never mentioned it, and no reports have ever been logged — a red flag for a channel nobody knows exists |
Control 6.3 deserves special attention going into any audit: auditors have grown far more skeptical of "training was assigned" as a proxy for "awareness was achieved," and increasingly ask for completion rates, quiz/assessment scores, and evidence that content is refreshed rather than reused verbatim year after year. Full guidance is in Security Awareness, Education, and Training: Control 6.3.
Annex A Checklist: Physical Controls (7.1–7.14)
The Physical theme covers 14 controls spanning perimeter security, entry control, equipment protection, and secure disposal. Even organizations that are cloud-first and largely remote need to address this theme — data center controls (usually inherited via a cloud provider's own certifications), home-working environments, and office premises all fall inside its scope to some degree. Full detail is in ISO 27001 Physical Controls Overview.
Table 10: Physical Controls (7.1–7.14) — Representative Checkpoints
Control Cluster | Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|---|
7.1–7.3 Perimeters, entry, and securing offices/rooms | Physical perimeters and entry points are controlled and monitored; sensitive rooms have additional protection | Badge/access logs, visitor logs, CCTV retention evidence, floor plans marking secure zones | Visitor log kept inconsistently at reception, or badge access logs not retained long enough to cover an audit lookback |
7.4 Physical security monitoring | Premises are monitored for unauthorized physical access | CCTV coverage maps, alarm system records, monitoring response logs | Monitoring system installed but no one reviews footage or alerts unless there's already an incident |
7.5–7.6 Environmental threats and working in secure areas | Facilities are protected against environmental threats; secure area rules are defined and followed | Environmental controls documentation (fire suppression, flood protection), secure area access rules and evidence of adherence | Secure area procedures exist for the data center but not for on-premises server rooms |
7.7 Clear desk and clear screen | A clear desk/clear screen policy is defined and observably followed | Policy document, screen lock timeout configuration evidence, walk-through/spot-check records | Policy exists but screen lock timeouts aren't centrally enforced and vary by device |
7.8–7.13 Equipment siting, off-premises security, media, utilities, cabling, maintenance | Equipment is protected from environmental and access risk, on and off premises, throughout its lifecycle | Equipment inventory with siting rationale, off-premises equipment handling procedure, media handling log, maintenance records | Maintenance performed by third parties with no evidence of security vetting or supervision |
7.14 Secure disposal or re-use of equipment | Equipment and media are securely wiped or destroyed before disposal or reuse | Disposal/destruction certificates from a certified vendor, or documented wipe verification for internally handled disposal | Old equipment sits in storage indefinitely with no disposal process, or disposal happens with no destruction certificate retained |
Physical controls are frequently underestimated by SaaS and cloud-native organizations who assume "we don't have a data center" means this theme barely applies. It still governs office premises, home-working environments under control 6.7, and secure handling of any physical media (laptops, backup drives, printed documents) anywhere in the organization's footprint — see Physical Security Perimeters and Entry Controls and Clear Desk and Clear Screen Policy for detail on the controls most often overlooked in that scenario.
Annex A Checklist: Technological Controls (8.1–8.34)
Technological controls make up the largest theme at 34 controls, and it's the theme where auditors most often turn a documentation review into a live evidence-pull request — asking to see an actual configuration screen, an actual log query, or an actual scan report rather than a policy describing what should happen. The full breakdown is in ISO 27001 Technological Controls Overview.
Table 11: Technological Controls (8.1–8.34) — Representative Checkpoints
Control Cluster | Checkpoint | Evidence Auditor Expects | Common Gap |
|---|---|---|---|
8.1–8.5 Endpoint devices, privileged access, restriction, source code, authentication | Endpoints are managed and secured; privileged access is tightly controlled; authentication is secure | MDM/endpoint management console evidence, privileged access inventory and approval records, MFA enforcement configuration | Privileged accounts exist outside the formal inventory (service accounts, break-glass accounts) with no documented owner |
8.6 Capacity management | Capacity is monitored and forecast to avoid availability failures | Capacity monitoring dashboards, forecasting records tied to growth or peak-load planning | Capacity monitored reactively only after an incident, with no forward planning evidence |
8.7 Protection against malware | Malware protection is deployed, updated, and monitored across the estate | Endpoint protection console showing coverage percentage, update/signature status, detection/response logs | Coverage gaps on unmanaged or BYOD devices not reflected in the console |
8.8 Management of technical vulnerabilities | Vulnerabilities are identified, assessed, and remediated within defined timeframes | Vulnerability scan reports, a remediation tracker with SLA-based timeframes, evidence of closure for high/critical findings | Scans run regularly but remediation SLAs are aspirational — high/critical findings sit open for months with no tracked exception |
8.9–8.14 Configuration, deletion, masking, DLP, backup, redundancy | Configuration baselines are defined and enforced; data is deleted, masked, and backed up appropriately; redundancy exists for critical facilities | Configuration baseline documents and drift-detection evidence, backup logs and restore test records, DLP policy and alert logs | Backups run on schedule but restore has never actually been tested |
8.15–8.17 Logging, monitoring activities, clock synchronization | Logs are generated, protected, actively monitored, and time-synchronized | Log retention configuration, SIEM/monitoring alert records, evidence of clock sync across systems generating logs | Logs are collected but nobody actively reviews or alerts on them — "logging" without "monitoring" |
8.18–8.19 Privileged utilities, software installation | Use of privileged utility programs is restricted; software installation on operational systems is controlled | Restricted utility access list, software allowlisting/approval records | Local admin rights broadly granted, undermining both controls simultaneously |
8.20–8.23 Network security, network services, segregation, web filtering | Networks are secured, segmented, and filtered appropriately | Network diagrams showing segmentation, firewall rule reviews, web filtering policy and logs | Network diagram is out of date relative to the actual current architecture |
8.24 Use of cryptography | A cryptography policy governs key management and encryption use | Cryptography policy, key management procedure, evidence of encryption in transit/at rest for sensitive data | Encryption applied inconsistently — some data stores encrypted, others assumed to be but never verified |
8.25–8.31 Secure development lifecycle | Security is built into development, from requirements through testing to deployment, including outsourced development | SDLC documentation, security requirements in project specs, code review/security testing records, outsourced development contract clauses | Security testing performed inconsistently, skipped under deadline pressure with no documented exception process |
8.32–8.34 Change management, test information, audit testing protection | Changes are controlled; test data is protected; production systems are protected during audit/testing activities | Change management records with approval trails, evidence test environments don't use unmasked production data, audit testing safeguards | Production data copied into test/dev environments without masking, violating 8.11 and undermining 8.33 simultaneously |
The High-Scrutiny Controls: Where Auditors Dig Deepest
Not all 93 controls receive equal attention in a typical audit. Certain controls sit at the intersection of high risk and easy-to-fake documentation, so experienced auditors probe them harder and ask for corroborating evidence beyond the policy document itself.
Table 12: High-Scrutiny Controls and What Auditors Actually Ask For
Control(s) | Why It Draws Scrutiny | What Auditors Ask Beyond the Policy |
|---|---|---|
5.1 Policies for information security | The foundational document — if it's stale or unread, everything built on it is suspect | "Show me the last review date and who approved it. Show me evidence staff have read it, not just that it was emailed." |
5.15 / 8.2 Access control and privileged access | Access is the most common root cause of real-world breaches; auditors assume it's the weakest link until proven otherwise | "Show me the last full access recertification. Show me a terminated employee's account being disabled the same day, not a week later." |
6.3 Security awareness, education, and training | Easy to mark "complete" without producing measurable behavior change | "Show me completion rates by department, not just an aggregate number. Show me what changed in the curriculum this year." |
8.8 Management of technical vulnerabilities | Directly tied to real exploitation risk; remediation SLAs are frequently aspirational rather than enforced | "Show me your oldest open critical finding and explain why it's still open." |
8.15 / 8.16 Logging and monitoring activities | Logging without active monitoring is a common gap that looks compliant on paper | "Walk me through what happens when this alert fires at 2 a.m. Who sees it, and how fast?" |
5.24–5.28 Incident management | Incidents test whether the whole ISMS actually functions under pressure, not just in a tabletop exercise | "Show me your most recent real incident record end to end — detection, assessment, response, lessons learned, evidence handling." |
"If I only had time to check six controls before deciding whether to trust the rest of the ISMS, it would be these. Access control and vulnerability management tell me about technical discipline. Awareness and incident management tell me about organizational discipline. Get those four right and the rest of the audit usually goes smoothly." — Priya Raman, ISMS Manager, Solace Cloud Technologies
Building Your Evidence Pack
Everything above points to the same conclusion: an ISO 27001 audit is not primarily a test of whether your controls are good. It's a test of whether you can prove they operated, on specific dates, in specific ways, without the auditor having to take your word for it. The organizations that sail through Stage 2 have built what I call an evidence pack — a structured, pre-assembled set of artifacts mapped directly to clauses and controls, ready before the auditor asks, not assembled in response to the ask.
A usable evidence pack has four properties. First, it's mapped — every clause and every applicable Annex A control has a named owner and a named evidence location, not a vague "somewhere in SharePoint." Second, it's dated — every artifact shows when it was created or last updated, because an auditor's first question about any document is almost always "when was this last reviewed." Third, it's sampled — for recurring activities like access reviews or vulnerability scans, you need more than one instance; auditors typically ask for evidence spanning the certification period, not a single cherry-picked example. Fourth, it's retrievable in minutes, not hours — if your team has to search across four systems and ping three people to find a single piece of evidence, that friction itself becomes a finding, because it suggests the control isn't actually embedded in daily operations.
Table 13: Evidence Pack Structure by Source Type
Evidence Source | What It Proves | How to Keep It Audit-Ready |
|---|---|---|
Governance documents (policies, procedures, the ISMS manual) | The rules exist and are approved | Maintain a master document register with version, approval date, and next review date visible at a glance |
Registers (risk, asset, legal/regulatory, supplier, nonconformity) | Ongoing management of the ISMS's core inputs | Update registers on a fixed cadence, not only when someone remembers; assign a named register owner |
Meeting records (management review, internal audit closing meetings) | Leadership and oversight actually functioned | Use a consistent minutes template capturing inputs discussed and decisions made, not just attendance |
System-generated logs and reports (SIEM alerts, vulnerability scans, backup logs, access recertification exports) | Technical controls operated as designed, continuously | Automate export/archival of these reports on a schedule so they don't depend on someone remembering to save them |
Training and competence records | People-layer controls (6.1–6.8) actually reached the workforce | Use an LMS or tracking sheet that captures completion rate by department, not just a total count |
Incident and nonconformity records | The organization detects, responds to, and learns from failure | Log every incident and nonconformity in one system with a mandatory root-cause and lessons-learned field before closure |
Build this pack at least two full quarters before your audit window, not two weeks before. It should live somewhere your internal audit program can test it directly — see ISO 27001 Internal Audit: Planning, Execution, and Reporting for how to structure an internal audit that exercises this exact evidence pack rather than a separate documentation review. If your internal audit can't find something in the pack, neither will the auditor be able to when they ask for the same thing under time pressure.
A Readiness Scoring Approach
Self-assessment is only useful if it produces a number you can act on, not a feeling. Score each clause and each applicable Annex A control cluster on a simple four-point scale, and let the pattern of scores tell you where to focus your remaining prep time.
Table 14: Readiness Scoring Scale
Score | Label | Definition |
|---|---|---|
0 | Not started | Requirement not yet addressed; no evidence exists |
1 | Documented only | Policy/procedure exists, but no operational evidence it's been followed |
2 | Operating, evidence incomplete | Control is operating, but evidence is scattered, undated, or only partially retrievable |
3 | Audit-ready | Evidence is mapped, dated, sampled across the period, and retrievable within minutes |
Score every clause (4 through 10) and every Annex A theme cluster your SoA marks applicable, then total the results. An organization scoring mostly 2s and 3s with a handful of 1s is in reasonable shape with focused work remaining; an organization scoring mostly 0s and 1s six weeks before Stage 2 needs a hard conversation with the certification body about rescheduling, because a premature audit produces major nonconformities that delay certification further than a short, honest postponement would. Run this scoring exercise as a facilitated workshop with control owners in the room — scores tend to be more honest when the person accountable for the evidence has to defend the number out loud.
"I make every control owner score their own area before I score it independently. The gap between their self-score and mine is the most useful data point in the entire readiness exercise — it tells me exactly where overconfidence is hiding." — Daniel Osei, CISO, Kestrel Logistics
Common Mistakes That Turn a Clean Audit Into a Nonconformity-Riddled One
Table 15: Common Audit-Prep Mistakes
Mistake | Why It Happens | How to Avoid It |
|---|---|---|
Treating the SoA as a one-time document instead of a living record | SoA finalized at initial certification and never revisited as the business changes | Review and update the SoA at every management review, tying changes to risk assessment updates |
Confusing "we have a policy" with "we have evidence the policy is followed" | Policy-writing is easier and faster than building operational evidence trails | Build evidence collection into the process itself (automated logs, sign-off workflows) rather than bolting it on afterward |
Preparing documentation but not preparing people | Assuming auditors only read documents and never interview staff | Run mock interviews with frontline staff, not just control owners, before the audit |
Letting internal audit rotate through only the "easy" controls | Internal auditors default to familiar, low-friction areas year after year | Build a multi-year internal audit program that guarantees full-scope coverage, prioritizing high-scrutiny controls every cycle |
No traceability between findings, corrective actions, and re-verification | Findings tracked in a spreadsheet disconnected from the ticketing/GRC system actually used day to day | Use a single system of record for nonconformities and corrective actions, linked to evidence of closure and effectiveness review |
Waiting until the audit window to assemble evidence | Evidence collection seen as a pre-audit task rather than a continuous operational discipline | Build the evidence pack (Table 13) at least two quarters ahead and test it via internal audit before the certification body arrives |
Excluding controls in the SoA without adequate justification | Exclusion feels like the fastest way to reduce audit scope | Tie every exclusion explicitly to risk assessment output and revisit exclusions whenever the business or threat landscape changes |
Case Study: Meridian Health Analytics — The Cost of an Unmapped ISMS
Elena Vasquez's team eventually closed all three major nonconformities and certified, but not on the original timeline. The retrospective her CISO commissioned afterward quantified what an unmapped evidence trail actually costs: the extended lead auditor day added roughly $6,000 in certification body fees; the follow-up visit to close nonconformities added another $14,000 in fees and internal labor; the forty hours her team spent reconstructing evidence retroactively, at blended internal cost, ran close to $9,000; and the six-week delay in issuing the certificate pushed back a $1.2 million healthcare payer contract that required proof of certification before signature, creating real opportunity cost for the business. Total direct and opportunity cost: roughly $58,000 against an audit that should have been routine. As a healthcare analytics vendor, Meridian's ISO 27001 evidence pack also fed directly into the HIPAA security-rule due diligence its payer customers required, which made the weak evidence trail doubly expensive — the same gaps a certification auditor flagged were the ones customer security teams asking about HIPAA safeguards would have found next. The fix that followed was the evidence pack structure described above — built over one quarter, tested by an internal audit cycle, and referenced directly against this kind of clause-by-clause and control-by-control checklist before the next surveillance audit. Meridian's second audit, a year later, ran on schedule with zero major nonconformities.
Case Study: Kestrel Logistics — Turning Readiness Scoring Into a Six-Week Sprint
Daniel Osei inherited an ISMS at Kestrel Logistics eight weeks before a scheduled Stage 2 audit, with no confidence in the previous ISMS manager's "we're ready" assessment. He ran the readiness scoring exercise described in Table 14 against every clause and every applicable Annex A control cluster, with control owners scoring themselves first and Daniel scoring independently second. The gap analysis exposed a hard truth: Clause 9 management review scored a 3 from the outgoing manager and a 1 from Daniel, because minutes existed but contained no documented inputs or decisions — exactly the gap that had cost Meridian $58,000. Physical controls scored a 0 across the board for a newly opened second warehouse that had never been brought into ISMS scope. Daniel used the six weeks remaining to rebuild management review minutes going forward with a proper template, fast-track a physical control gap assessment for the new warehouse, and update the SoA to reflect the expanded scope honestly rather than quietly excluding the new site. Kestrel passed Stage 2 with two minor nonconformities — both related to the newly scoped warehouse and both closed within the standard 90-day corrective action window.
Case Study: Northbridge Payments — Building the Evidence Pack Before It Was Needed
Fiona Chen's approach at Northbridge Payments, a fintech processing card transactions, was preventative rather than reactive. Eighteen months before her organization's first certification audit, she built the evidence pack structure from Table 13 as a standing operational discipline rather than an audit-season scramble: every register had a named owner and a fixed update cadence, every recurring control (access reviews, vulnerability scans, backup restore tests) auto-exported evidence into a mapped repository, and her internal audit program was explicitly designed to test retrievability — auditors picked a control at random and timed how long it took to produce the corresponding evidence. Anything over fifteen minutes triggered a process fix before the real audit. The result: Northbridge's Stage 2 audit, covering the full scope including the high-scrutiny controls in Table 12, produced zero nonconformities, an outcome the certification body's lead auditor described in the closing meeting as unusual for a first-time certification of an organization this size.
Table 16: Case Study Outcomes Compared
Organization | Starting Point | Approach Taken | Outcome |
|---|---|---|---|
Meridian Health Analytics | Believed ready; no evidence map | Reactive fix after nonconformities found | Certified, but ~$58,000 direct/opportunity cost and a delayed contract |
Kestrel Logistics | Inherited unmapped ISMS, 8 weeks to audit | Readiness scoring exercise exposed gaps; targeted 6-week sprint | Certified with 2 minor nonconformities, both closed on schedule |
Northbridge Payments | 18 months of lead time before first certification | Evidence pack built as standing operational discipline from the start | Certified with zero nonconformities |
"The difference between Kestrel's audit and Meridian's wasn't the quality of the security controls — both organizations had reasonably mature security programs. The difference was entirely in whether evidence had a home before someone asked for it." — Sarah Kline, Head of Compliance, Meridian Health Analytics
What to Have Physically Ready on Audit Day
Everything above is about building the evidence pack over months. This is the shorter, sharper list for the week of the audit itself — the things that turn a well-prepared ISMS into a smoothly-run audit day rather than a scramble to open the right browser tab while an auditor waits.
Table 17: Audit-Week Readiness List
Item | Why It Matters | Owner |
|---|---|---|
Current SoA and risk treatment plan, cross-referenced and printed or bookmarked | The auditor will ask for these first, on both Stage 1 and Stage 2, and will use them to scope the rest of the audit | ISMS Manager |
A named contact per clause and per Annex A theme, available during the audit window | Auditors ask follow-up questions; a control owner who can answer in real time avoids "I'll get back to you" delays that stall the schedule | ISMS Manager / department heads |
Login access to systems generating evidence (ticketing, SIEM, MDM, LMS, GRC platform) pre-arranged for the audit team | Screen-sharing a live system is far more convincing than a static export, and pre-arranging access avoids mid-audit IT delays | IT/Security operations |
A room or video-call schedule blocking out interview time with frontline staff, not just management | Auditors sample staff interviews across levels; having people available on short notice avoids rescheduling that eats into audit time | HR / department heads |
The prior audit's nonconformity log with evidence of closure for each item | Certification bodies always check whether previous findings were actually resolved, not just marked closed | Internal Audit Lead |
A single point of document access (one shared drive, one GRC tool) rather than scattered folders | Every minute spent searching for a document in front of an auditor reads as evidence the control isn't embedded in daily operations | Document Controller |
Keep this list separate from the full evidence pack — it's a logistics checklist, not a compliance one, but skipping it is exactly how technically-ready organizations still have a rough audit week.
The Strategic Close: Audit Readiness as a Sales Asset, Not Just a Compliance Cost
Every checklist in this article exists to answer one question an auditor will ask in some form about every clause and every control: can you prove it? But there's a second audience for that same evidence pack that's easy to forget while you're focused on the certification body — your customers, your prospects, and your board. The organizations I've watched build the strongest ISO 27001 programs treat audit readiness as a continuously maintained asset, not a once-a-year fire drill, precisely because that same evidence pack becomes the fastest possible answer to a security questionnaire, a due diligence request, or a board question about risk posture. Meridian Health Analytics didn't just fix its audit process after its rough first certification — it started using the same evidence pack to answer customer security questionnaires in days instead of weeks, turning a compliance cost center into a sales enablement function. That's the real payoff of doing this work properly: the certificate is the byproduct, but the evidence discipline underneath it is the asset.
If you're within a few months of an audit and want to pressure-test where you actually stand, run the readiness scoring exercise in Table 14 this week, not next quarter — most of the gaps that turn into expensive nonconformities are gaps that were visible six months earlier to anyone who looked. PentesterWorld's security and compliance team can help you validate technical evidence for the high-scrutiny controls in Table 12 — from vulnerability management and access control to logging and monitoring — well before a certification body auditor puts them under a microscope.
Turn This Checklist Into a Working Toolkit
A printed checklist article is a starting point, not the finished job — the readiness work described above goes faster with the right templates in hand. If you're building your own version of the tables in this article, start by downloading our Internal Audit Checklist, which mirrors the clause-and-control structure used here and is built specifically to feed your internal audit program before the certification body arrives. Pair it with our Certification Readiness Checklist to run the Table 14 scoring exercise with your own control owners in the room.
For the Annex A side of the exercise, our Annex A — All 93 Controls at a Glance cheat sheet gives you a single-page reference to walk the SoA theme by theme without flipping between multiple articles, and our Clauses 4–10 Cheat Sheet does the same for the management-system requirements covered in the first half of this checklist. If you're still assembling your baseline documentation set rather than auditing an existing one, our ISO 27001 Mandatory Documents Checklist tells you exactly what's required versus optional before you even get to evidence-pack building. And if you're starting further back — designing the ISMS itself rather than just preparing it for audit — our Complete ISO 27001 Implementation Guide eBook walks the full build, clause by clause and control by control, from scoping through certification.