ISO 27001 Readiness: The 12-Step Checklist for Information Security Compliance

Ninety-three controls. Four themes. Ten management clauses. That is what ISO/IEC 27001:2022 actually asks of you — and none of it is optional if certification is the goal. Most organizations that fail their Stage 1 audit don't fail because their security is weak. They fail because their readiness process was unstructured: evidence scattered across drives, controls implemented but undocumented, and a scope statement nobody can defend under questioning.

This is the checklist version of what a readiness project should look like, mapped to the actual clauses and Annex A control set — not a generic "cybersecurity best practices" list repackaged with an ISO label.

Why ISO 27001:2022 Changed the Game

The 2022 revision restructured Annex A from 14 control categories down to 4 themes, and cut the control count from 114 to 93 (11 were merged, one was split, and 11 new controls were added — covering things like threat intelligence, cloud security, and data masking). If your readiness plan is still built around the 2013 structure, it's out of date. The current structure is:

• Organizational controls — 37 controls (A.5.1–A.5.37): policies, roles, supplier relationships, incident management, legal and contractual obligations.
• People controls — 8 controls (A.6.1–A.6.8): screening, terms of employment, awareness training, disciplinary process, remote working.
• Physical controls — 14 controls (A.7.1–A.7.14): secure areas, equipment siting, media disposal, clear desk/clear screen.
• Technological controls — 34 controls (A.8.1–A.8.34): access control, cryptography, logging, malware defenses, secure development.

Clauses 4 through 10 of the standard define the management system itself — context of the organization, leadership, planning, support, operation, performance evaluation, and improvement. Annex A doesn't stand alone; it exists to satisfy the risk treatment decisions made under Clause 6.1.3. An auditor will ask you to trace a control back to a risk, and a risk back to your Statement of Applicability. If that chain breaks, the finding is yours.

The 12-Step Readiness Checklist

1. Define the scope, in writing, before anything else. Clause 4.3 requires a documented ISMS scope statement — which business units, locations, systems, and data types are in and out. A vague scope ("our cloud infrastructure") is the single most common reason auditors send readiness assessments back for rework.

2. Run a formal risk assessment (Clause 6.1.2). Identify information security risks against confidentiality, integrity, and availability. This has to be a repeatable methodology, not a one-time workshop — auditors will ask how often it's reviewed.

3. Build the Statement of Applicability (SoA). For each of the 93 Annex A controls, document whether it applies, why, and how it's implemented. Controls marked "not applicable" need a justification an auditor would accept, not just a checkbox.

4. Write the risk treatment plan (Clause 6.1.3). Map each identified risk to a treatment decision — accept, avoid, transfer, or mitigate — and to the specific Annex A control(s) doing the mitigating.

5. Assign ownership at the control level, not the department level. "IT owns technological controls" is not evidence of governance. Auditors expect a named individual accountable for each control's operation and evidence.

6. Implement the People controls first. A.6.3 (awareness training) and A.6.1 (screening) are cheap to implement and frequently the first thing sampled in an audit interview. Gaps here are disproportionately damaging relative to how easy they are to close.

7. Stand up logging and monitoring (A.8.15, A.8.16). Auditors will ask to see log retention policies and evidence that anomalous activity is actually reviewed — not just that logs exist.

8. Document supplier and third-party security (A.5.19–A.5.23). This is one of the most expanded areas in the 2022 revision. If you rely on cloud providers or subprocessors, you need contractual security clauses and a process for assessing their risk, not just a vendor list.

9. Run an internal audit (Clause 9.2) before the external one. This is a mandatory clause requirement, not a nice-to-have. It should surface nonconformities you fix before the certification body does.

10. Hold a management review (Clause 9.3). Top management has to formally review ISMS performance, including audit results and risk assessment outcomes, with minutes as evidence.

11. Close nonconformities through a documented corrective action process (Clause 10.1). Every finding — internal or external — needs root cause analysis and evidence of closure, not just a fix.

12. Assemble the evidence pack before Stage 1, not during it. Every control needs traceable evidence: the policy, the implementation record, and the review log. Scrambling to find this mid-audit is the most common cause of delayed certification.

Stage 1 vs. Stage 2: What Each Audit Actually Checks

Certification bodies run ISO 27001 audits in two stages, and conflating them is a common planning mistake. Stage 1 is a documentation review — the auditor checks that your ISMS scope, policies, risk assessment, and SoA exist, are internally consistent, and cover the requirements of Clauses 4–10. It's largely a desk exercise, but it's also where scope ambiguity and missing mandatory documents get flagged, and those findings push out your Stage 2 date. Stage 2 is the operational audit: the auditor samples evidence that controls are actually running as documented — pulling access logs, interviewing control owners, checking whether the internal audit and management review actually happened on the schedule you documented. A clean Stage 1 buys you nothing if Stage 2 can't find the evidence trail. Treat the two stages as sequential gates, not one combined event, and budget separate preparation time for each.

How Long Realistic Readiness Takes

For an organization with no existing ISMS, a realistic first-time certification timeline runs 4 to 9 months from kickoff to Stage 2, depending on scope size and how much of the Annex A control set already exists informally (most organizations already have some access control and backup practices — the gap is usually documentation, ownership, and evidence, not the underlying technical control). Organizations that compress this timeline successfully tend to do two things differently: they assign a single accountable owner for the whole readiness project rather than splitting it across departments, and they build the evidence trail as controls are implemented rather than reconstructing it retroactively before the audit. The retroactive approach is where most of the wasted effort in a readiness project actually goes.

The Part Nobody Tells You: Evidence Management Is the Actual Bottleneck

Every step above assumes you can produce evidence on demand, mapped to the specific control and risk it satisfies. In practice, this is where readiness projects stall. Evidence lives in shared drives, Slack threads, and someone's inbox. By the time Stage 1 arrives, nobody can find the version of the access control policy that was actually in effect during the audit period, let alone tie it to the risk assessment that justified it.

This is a project management problem before it's a security problem. A 93-control Annex A implementation, run manually across spreadsheets, means 93 separate threads to keep current — each with its own owner, evidence, and review cadence. Add supplier reviews, recurring access recertifications, and annual policy re-approvals, and the manual version of this quickly exceeds what one compliance function can track reliably.

Ready to see what an auto-generated compliance tracker looks like for your organization?

RegentComply.ai generates audit-ready evidence packs mapped to your specific regulatory framework — in hours, not weeks. Request a demo →

For GRC Consultants Running Multiple ISO 27001 Engagements

If you're a fractional CISO or GRC consultant managing this checklist across several clients simultaneously, the math gets worse fast: 93 controls × however many clients, each with a different scope, different SoA, and different audit calendar. Rebuilding the same control-to-risk-to-evidence structure from scratch for every new engagement is where billable hours disappear into template work instead of advisory work.

GRC consultants: stop rebuilding compliance frameworks from scratch. consult.regentcomply.ai lets you auto-generate client-ready compliance trackers for any framework — without going through your client's IT or procurement. Sign up directly and deliver faster, more structured engagements from day one.

The Bottom Line

ISO 27001:2022 certification is a documentation and traceability exercise built on top of a genuine security program. The technical controls matter, but most Stage 1 failures trace back to structure: a scope that doesn't hold up, an SoA that doesn't map to real risk decisions, or evidence that can't be produced on request. Build the readiness project around the 12 steps above, in order, and the certification audit becomes a formality rather than a discovery process.

Sources: ISO/IEC 27001:2022, Information security, cybersecurity and privacy protection — Information security management systems — Requirements, International Organization for Standardization.