ISO/IEC 27001 is the international standard for Information Security Management Systems (ISMS). Certification tells customers, regulators and insurers that you manage information security systematically rather than reactively. This guide walks through the implementation lifecycle, the documents auditors actually ask for, and the mistakes that add months to a first certification.
What ISO 27001 Requires
The standard has two parts, and confusing them is the most common starting error.
Clauses 4–10 are the certifiable content: context, leadership, planning, support, operation, performance evaluation, and improvement. These define how you run the ISMS — risk-based, documented, continually improved. An organisation with excellent security controls and no management system will fail certification.
Annex A is a reference set of 93 controls in four themes — organisational, people, physical, technological. You perform a risk assessment, select the controls that address your identified risks, implement them, and document the result. You are not required to implement all 93.
The 2022 revision reorganised Annex A from 114 controls in 14 domains into 93 in four themes, and added controls including threat intelligence, information security for cloud services, data leakage prevention, monitoring activities, and secure coding.
Step-by-Step Implementation
1. Define Scope and Context
Decide what the ISMS covers — one product, one region, or the whole organisation. Narrow scope certifies faster; too narrow and customers will notice the certificate does not cover the service they buy.
Document interested parties and their requirements: customers with contractual security terms, regulators, employees, suppliers. This feeds the risk assessment and gets tested at Stage 1.
The scope statement appears on the certificate. Write it so it is honest and so it answers the question a prospect will ask.
2. Conduct a Risk Assessment
Identify risks to the confidentiality, integrity and availability of information within scope. Assess likelihood and impact on defined scales — see our guide to risk matrices — and produce a risk treatment plan mapping each risk to the controls that modify it.
Two requirements catch people out. The methodology must be documented and repeatable, so a second assessor reaches comparable results. And accepted risks must be justified and approved by someone with the authority to accept them.
3. Produce the Statement of Applicability
The SoA lists every Annex A control with a decision: included (and why, and how implemented) or excluded (and why). It is the document auditors work from, and it must reconcile with the risk treatment plan.
Exclusions are entirely legitimate — an organisation with no in-house development can exclude secure coding controls. Unjustified exclusions, or exclusions that contradict what you do, are findings.
4. Implement Controls and Build Evidence
Document how each selected control is implemented: policies, procedures, technical measures, and who owns it.
This is where most programmes struggle, and the problem is not implementation but evidence. A control that operates but produces no retained artefact cannot be demonstrated. For each control, decide up front what the evidence is, how often it is produced, and where it is retained — access review records, change approvals, training completion, incident tickets, supplier assessments.
Evidence collected on a schedule is cheap. Evidence reconstructed before an audit is expensive, and for surveillance audits covering a past period it may not be reconstructable at all.
5. Operate the Management System
Certification tests the system, so the system has to have run:
- Internal audit covering the ISMS, on a programme, by someone independent of what they audit.
- Management review at planned intervals, with the inputs the standard specifies and documented outputs.
- Nonconformities and corrective actions raised, root-caused, and tracked to closure.
- Monitoring and measurement of control effectiveness against defined metrics.
- Awareness and training with records.
Auditors will ask for the last internal audit report, the last management review minutes, and the corrective action log. If those do not exist, the audit stops there.
6. Certification: Stage 1 and Stage 2
Stage 1 is a documentation and readiness review — scope, policies, SoA, risk assessment, and evidence that internal audit and management review have run. Findings here are usually recoverable before Stage 2.
Stage 2 tests implementation and effectiveness. The auditor samples controls and asks for evidence, follows threads from risks to controls to evidence, and interviews control owners. Owners who cannot describe their own control are a common finding.
Certification runs a three-year cycle with annual surveillance audits and recertification at the end.
Realistic Timelines
For an organisation starting without a management system, first certification typically takes six to twelve months. The constraint is rarely control implementation; it is accumulating enough operating history — an internal audit, a management review, and a few months of evidence — before Stage 2 can find anything to sample.
Programmes that compress below six months usually do so by narrowing scope, not by moving faster.
Where First Attempts Go Wrong
- Treating Annex A as the standard. Clauses 4–10 are what gets certified; a control checklist with no management system fails.
- A risk assessment written for the auditor. If it was produced in one workshop and never revisited, it shows.
- SoA that contradicts reality. Controls marked implemented that owners have never heard of.
- No internal audit. The single most common reason Stage 2 is deferred.
- Evidence in personal drives and email. It exists, but it cannot be produced on demand or retained defensibly.
- Scope written for convenience. A scope that excludes the thing customers care about produces a certificate nobody accepts.
How GRC Software Helps
A GRC platform addresses the parts that do not scale manually:
- One place for risks, controls, policies and evidence, with the linkages an auditor traverses.
- The SoA generated from the risk treatment plan, so the two cannot drift apart.
- Scheduled evidence collection, with owners notified and overdue items escalated, so controls are demonstrated continuously.
- Internal audit and corrective actions in the same system as the controls they concern.
- An audit trail showing who did what and when.
The larger gain is multi-framework. Because ISO 27001 overlaps heavily with SOC 2, GDPR and DORA, one control library mapped across all of them means a control is tested once and the evidence counts everywhere — see our information security frameworks page.
For a platform supporting ISO 27001, SOC 2 and GDPR from one control set, see GRC Cloud and Audit Management, or request a demo.