ISO 27001 checklist, clause by clause

A checklist made of clause headings tells you nothing about whether you are ready. This one follows the order the work actually happens in, and every item says what done looks like and what the audit team will ask you to produce.

Last reviewed 2026-09-15Written by Jacob Masse, TrazTech Inc.

ISO/IEC 27001:2022 has two halves that behave differently. Clauses 4 to 10 carry 25 mandatory requirements, none excludable. Annex A lists 93 reference controls, and which of those apply is an output of your risk treatment rather than an input to it. Ticking all 93 before doing a risk assessment produces a Statement of Applicability nobody can defend.

The order below is the dependency order. Scope constrains the risk assessment, the assessment produces the treatment plan, the plan decides Annex A, and the rest is evidence that the system is running. The requirements are set out clause by clause on the clauses page, and the route to a certificate here is on ISO 27001 certification in Canada.

25 Mandatory requirements in clauses 4 to 10, none excludable

93 Annex A reference controls, applicability decided by risk

2 Audit stages before a certificate is issued

Each item below names an artifact, the condition that makes it done, and the question asked about it in the audit room. An item is not done because a document exists. It is done when the document is approved, dated, owned by somebody who can explain it, and matched by what happens in the business.

Clause 4: context and scope

A scope written too wide drags systems, offices and teams into an audit that did not need to be there. One written too narrow gets challenged at stage 1, or satisfies nobody in your pipeline because the certificate does not cover the product the customer buys.

0 of 5 done ·

Internal and external issues are recorded in writing. Done looks like a short register of the regulatory, contractual, market and technical factors bearing on information security. At audit you will be asked how it is kept current.
Interested parties are identified with their requirements. Done looks like a table of customers, regulators, employees and suppliers against specific requirements: a contract clause, PIPEDA and any provincial statute reaching your data, a service level commitment.
Interfaces and dependencies are mapped. Done looks like every point where work inside the scope depends on something outside it: a parent company running your identity provider, a hosting provider, a contractor network. This is the item most often missing, and the one an auditor uses to test whether the scope is honest.
The scope statement is written, approved and short. Done looks like a paragraph naming the services, locations, organizational units and technology, plus any exclusion with a reason. It is reproduced on the certificate. The scope statement page works through the wording and the ISMS scope builder drafts one.
The management system is a thing with a boundary, not a folder of policies. Done looks like answering in one sentence what is inside and what is outside.

Clause 5: leadership

Clause 5 asks for three things and auditors test them by talking to people rather than reading documents. The evidence is whether the answers match.

0 of 4 done ·

Top management commitment is demonstrable. Done looks like a named executive who can describe the scope, the top risks and the objectives unprompted, plus minutes showing security decisions at that level. An auditor will interview them.
An information security policy is approved and published. Done looks like a document stating the commitment to meeting requirements and to continual improvement, framing the objectives, available to staff, with an approval date and an owner. Detail belongs in the supporting policies on the documentation page.
Roles, responsibilities and authorities are assigned and communicated. Done looks like named people against the duties: who maintains the risk register, who approves exceptions, who runs the internal audit.
The resourcing decision is made and visible. Done looks like budget, headcount or a contracted arrangement matching the plan. Clause 5 covers how this is tested.

Comparing firms for this? Tell us what you need and it goes to the ones in the directory that do this work. No charge, and no phone number required.

Clause 6: planning, risk and the Statement of Applicability

This is the largest block of work and it determines everything downstream. Do it in the stated order: a risk assessment run before the methodology is agreed produces results nobody can reproduce, and reproducibility is an explicit requirement.

0 of 6 done ·

A risk assessment methodology is documented and approved before any risk is scored. Done looks like written likelihood and impact criteria, a defined acceptance threshold, and the identification approach. The audit question is whether two people applying it to the same risk land in the same place.
The risk assessment is performed and the results retained. Done looks like a register where each risk has an owner, a cause, an effect on confidentiality, integrity or availability, scored likelihood and impact, and a treatment decision. The risk assessment page covers asset-based and scenario-based approaches.
A risk treatment plan exists with owners and dates. Done looks like each risk above the threshold carrying a chosen option, the controls implementing it, a target date and a residual score, with residual acceptance signed by the risk owner rather than the plan's author. The treatment plan page and the risk treatment planner cover the format.
The Statement of Applicability is complete and traceable. Done looks like all 93 Annex A controls listed, each marked applicable or not, each applicable one linked to the risk or requirement that made it necessary and to its status, and each exclusion justified. This is the document the audit team reads first. The Statement of Applicability page has the structure.
Objectives are set at relevant functions and levels, and they are measurable. Done looks like a number attached, and a plan naming what will be done, by whom, with what resources, by when, and how the result is evaluated.
Changes to the management system are planned rather than improvised. Done looks like pointing at a change that was considered, decided and recorded, such as a scope extension or a new hosting region.

The ordering trap

If your Statement of Applicability was produced by opening Annex A and marking almost everything applicable, the audit team can see it: the justifications read as generic and no control traces back to a risk. Letting the register drive control selection saves an argument at every audit that follows.

Clause 7: support

Clause 7 separates a system that exists on paper from one people use. Four of its five requirements are about human beings.

0 of 5 done ·

Resources are determined and provided. Done looks like the tooling, time and people the plan assumes being actually available, including whoever runs the internal audit.
Competence is determined, met and evidenced. Done looks like a statement of what each security role needs, and records showing the holder has it through education, training or experience.
Awareness reaches everyone working under your control, contractors included. Done looks like completion records showing people know the policy, their contribution, and what happens if they do not follow it. Gaps in contractor records are a standard finding.
Communication is planned rather than ad hoc. Done looks like a short table of what is communicated about security, when, to whom and how, including incident notification.
Documented information is controlled. Done looks like version numbers, approval, dates, an owner, defined retention, and control over access. A wiki is fine if it has history and approval. Clause 7 lists what has to be retained.

Clause 8: operation

Clause 8 is short in the standard and long in practice. Run the processes you designed and keep the evidence that you ran them.

0 of 4 done ·

The processes needed to meet requirements are planned, implemented and controlled. Done looks like tickets, logs, approvals and review records dated across the period, not a batch created the week before the audit.
Outsourced processes are identified and controlled. Done looks like knowing which parts of your security somebody else performs, and holding the contract terms, the review record and any assurance report they issue.
The risk assessment runs at planned intervals and on significant change. Done looks like a dated reassessment after an acquisition or a move to a new hosting provider.
The risk treatment plan is implemented and the results retained. Done looks like closed actions with evidence attached, and open actions carrying a revised date and a reason rather than silently slipping.

Clause 9: performance evaluation

Three requirements, and the last two are the ones a certification body checks have genuinely happened before it will issue anything.

0 of 4 done ·

Monitoring and measurement are defined and performed. Done looks like a written statement of what is measured, by which method, when and by whom, plus the retained results. Patch latency, access review completion and incident response times are typical.
An internal audit program is running and covers the whole system. Done looks like a schedule, criteria and scope per audit, auditors independent of the work they audit, completed reports with findings, and results reported to management. The internal audit page covers independence and scheduling.
A management review has been held and minuted against the required inputs: status of prior actions, changes in issues and interested parties, performance feedback including audit results and nonconformities, risk and treatment status, improvement opportunities, and decisions taken. Management review lists them in order.
At least one full cycle has run before the certification audit, with the management review held after the internal audit so it has something to review.

Clause 10: improvement

Two requirements, and an empty nonconformity log is itself a signal.

0 of 3 done ·

Nonconformities are recorded and reacted to. Done looks like a log where each entry has the nonconformity, the immediate correction, the consequences dealt with, and a date.
Corrective action addresses cause, not symptom. Done looks like a documented cause analysis, a check for similar nonconformities elsewhere, the action taken, and a review of its effectiveness. That last step is most often skipped and it is checked. Nonconformity and corrective action has the sequence.
Continual improvement is evidenced. Done looks like changes you can point at, traced to audit findings, incidents or review decisions. Continual improvement covers what counts.

Annex A: 93 controls in four themes

Annex A of the 2022 edition holds 93 controls in four themes. The 2013 edition had 114 in 14 domains and nothing was removed in the rewrite. Controls were merged and regrouped by who owns them.

Annex A themes in ISO/IEC 27001:2022 and what each covers
Theme	Controls	What it covers
Organizational	37	Policies, roles, supplier and cloud relationships, threat intelligence, incident management, continuity, legal requirements
People	8	Screening, terms of employment, awareness, disciplinary process, duties after termination, remote working, reporting events
Physical	14	Perimeters, entry, secure areas, equipment siting, cabling, maintenance, secure disposal, clear desk and screen
Technological	34	Endpoints, privileged access, cryptography, secure development, logging, monitoring, backup, data masking, web filtering
Total reference controls	93	Applicability decided by risk treatment

The checklist item here is not "implement 93 controls". It is that every control has a recorded decision, every applicable control traces to a risk or a requirement and carries a status and an owner, and every exclusion has a justification that would survive being read aloud. Excluding a control because you have no on-premises data centre is defensible. Excluding one because it looked difficult is a finding waiting to happen, and the physical controls are where that shows up in remote-first companies that still keep an office.

The Annex A controls page sets out what each theme expects, and the Annex A control selector gives a first pass at applicability. Implementation guidance lives in ISO 27002, which is not itself certifiable.

Before the certification audit

Certification runs in two stages with the same audit team. Stage 1 reads, stage 2 tests, and knowing which questions belong to which stage is the difference between a clean pass and findings that delay the certificate.

What each audit stage asks for
Stage 1, documentation review	Stage 2, effectiveness audit
Scope statement, and whether it matches what you sell	Interviews to see whether the documented process is the one staff follow
Information security policy and supporting policies	Samples of records across the period: access reviews, change approvals, incident tickets
Risk methodology, risk assessment and treatment plan	Evidence that treatment actions were implemented on the dates claimed
Statement of Applicability, including exclusions	Control testing against the applicable controls in the Statement of Applicability
Internal audit plan and reports	Whether findings raised internally were actually closed
Management review minutes	Whether decisions recorded in the review led to anything
Readiness for stage 2, and a date	Nonconformities, graded major or minor, with a window to respond

The gap between stages runs from a few weeks to a few months, and a stage 1 finding that the system has not operated long enough is the usual cause of the longer gap. Evidence samples need three months of operation at the short end. The stage 1 and stage 2 page covers what happens between them, the stage 1 readiness check flags what is missing before you book a date, and a gap assessment does the same job against a longer runway.

The items that fail most often

Interfaces and dependencies missing from clause 4, which makes the scope unverifiable.
A Statement of Applicability where applicable controls trace to no risk.
Objectives that are not measurable, so clause 9 has nothing to measure against.
Internal audit performed by the person who built the system, failing the independence requirement.
Management review minutes missing two or three of the required inputs.
Corrective actions closed without an effectiveness review.
Awareness records covering employees but not contractors.

Each is cheaper to fix before stage 1 than after stage 2. The free tools on this site ask for no email address.

Get quotes for ISO 27001 readiness

Tell us your scope, target date and position on this checklist.

Get matched

Common questions

Do we have to implement all 93 Annex A controls?

No. You have to make and record a decision about all 93. Which ones apply is determined by your risk treatment and by legal, regulatory and contractual requirements, and the Statement of Applicability is where those decisions are written down. Most organizations end up with a large majority applicable, but each exclusion has to rest on a reason that relates to your situation.

Can we do the internal audit ourselves?

Yes, as long as the auditor is independent of the work being audited. In a small company that means somebody from a different function, or an outside party. The person who wrote the policies and built the controls cannot audit them, and that is the most common way this requirement fails. Keep a record of the auditor's training or experience.

How long does the checklist take to work through?

For a company under 100 people starting from documented but informal practice, six to nine months to stage 2 is realistic, and the binding constraint is elapsed time rather than effort. Clause 9 needs an internal audit and a management review to have happened, and clause 8 needs operating history. Neither compresses by adding people.

This directory is published by TrazTech Inc.