Most organisations pursuing ISO 27001 certification know roughly what it is — a standard for building an Information Security Management System — but stall on the same question: where do we actually start?
The standard itself is 30 pages of requirements written in management-system language. Annex A lists 93 controls across four themes. The documentation requirements alone span a dozen mandatory documents. And unlike a technical security audit, ISO 27001 requires the organisation to demonstrate that its security posture is continuously managed, not just configured once and forgotten.
This guide turns the standard into a practical roadmap. It covers the full implementation journey in eight phases — from scoping and gap analysis through internal audit, management review, and certification — with the complete Annex A controls checklist, the mandatory documentation list, gap analysis scoring templates, audit preparation checklists, and a comparison with SOC 2 and NIST CSF so you can decide which frameworks to pursue simultaneously.
Whether you are starting from zero or have a partially implemented ISMS and need to close the gaps before a certification audit, this guide gives you the specific deliverables required at each phase.
- ISO 27001 structure — clauses, Annex A, and the PDCA cycle
- Gap analysis — measuring where you are today
- Eight-phase implementation roadmap
- Risk assessment and treatment
- ISO 27001 Annex A controls — all 93 explained
- ISO 27001 implementation checklist
- Mandatory documentation — complete list
- Audit preparation — Stage 1 and Stage 2
- ISO 27001 vs SOC 2 vs NIST CSF — which to pursue
- Frequently asked questions
ISO 27001:2022 has two parts: the main body (Clauses 4–10) which defines the management system requirements, and Annex A which lists the 93 security controls the ISMS can draw from. Understanding this structure before implementation prevents the most common mistake — treating ISO 27001 as a controls checklist rather than a management system.
| Clause | Title | What it requires | Key deliverable |
|---|---|---|---|
| 4 | Context of the organisation | Define internal/external issues, interested parties, and the ISMS scope | Scope statement; stakeholder register; context document |
| 5 | Leadership | Top management commitment; information security policy; assigned roles | IS Policy signed by CEO/board; RACI chart |
| 6 | Planning | Risk assessment methodology; risk treatment plan; Statement of Applicability (SoA) | Risk register; Risk Treatment Plan; SoA |
| 7 | Support | Resources, competence, awareness, communication, documented information | Training records; document control procedure; communications plan |
| 8 | Operation | Execute risk treatment plan; manage operational security; control third parties | Operational procedures; supplier security agreements; change management records |
| 9 | Performance evaluation | Monitoring and measurement; internal audit programme; management review | KPI reports; internal audit reports; management review minutes |
| 10 | Improvement | Nonconformity management; corrective actions; continual improvement | Nonconformity log; corrective action records; improvement register |
| Annex A | Information security controls | 93 controls across 4 themes — select applicable ones and justify exclusions in the SoA | Statement of Applicability (SoA) — the central compliance document |
ISO 27001 is built on the Plan-Do-Check-Act (PDCA) cycle. Certification is not the finish line — it is the beginning of a continuous improvement process. Auditors return annually for surveillance audits and every three years for recertification. Organisations that treat implementation as a project with an end date fail their first surveillance audit. The ISMS must demonstrate ongoing operation: regular risk reviews, management review meetings with documented minutes, internal audits conducted on schedule, and corrective actions closed within agreed timeframes.
A gap analysis is the essential first step — measuring the distance between your current security posture and ISO 27001 requirements. It tells you where to invest implementation effort, provides a realistic timeline and cost estimate, and creates the baseline against which your progress is measured. Most organisations are surprised by how much of ISO 27001 they already satisfy informally — the work is often formalising and documenting existing practices rather than building everything from scratch.
| Score | Level | Definition | Typical evidence |
|---|---|---|---|
| 0 | Not implemented | Requirement is not addressed at all | No policy, no control, no awareness |
| 1 | Ad-hoc | Addressed informally — dependent on individuals, not documented | People "know" the practice; nothing written down; no consistency |
| 2 | Defined | Written policy or procedure exists; not consistently followed | Policy document exists; training may not have occurred; monitoring absent |
| 3 | Managed | Implemented consistently; monitored; records kept | Procedures followed; KPIs tracked; audit trails exist; responsible owner assigned |
| 4 | Optimising | Continuously improved; benchmarked; integrated into business processes | Regular effectiveness reviews; improvements documented; metrics trend positive |
| Clause / Area | Current score (0–4) | Target score | Gap | Priority | Owner |
|---|---|---|---|---|---|
| 4 — Context | __ | 3 | __ | __ | __ |
| 5 — Leadership & Policy | __ | 3 | __ | __ | __ |
| 6 — Risk Assessment | __ | 3 | __ | __ | __ |
| 7 — Support / Training | __ | 3 | __ | __ | __ |
| 8 — Operations | __ | 3 | __ | __ | __ |
| 9 — Monitoring / Audit | __ | 3 | __ | __ | __ |
| 10 — Improvement | __ | 3 | __ | __ | __ |
| A.5 — Organisational | __ | 3 | __ | __ | __ |
| A.6 — People | __ | 3 | __ | __ | __ |
| A.7 — Physical | __ | 3 | __ | __ | __ |
| A.8 — Technological | __ | 3 | __ | __ | __ |
- No IS policy
- No formal risk process
- No asset inventory
- No incident procedure
- No supplier security clauses
- Timeline: 15–18 months
- Policies exist, not enforced
- Risk reviews ad-hoc
- Partial asset register
- Incident log, no formal process
- Some supplier contracts
- Timeline: 10–14 months
- Controls implemented
- Documentation gaps
- Monitoring inconsistent
- No internal audit yet
- No management review
- Timeline: 6–9 months
- Controls implemented + evidenced
- Documentation complete
- Internal audit done
- Management review held
- Corrective actions closed
- Timeline: 3–6 months
ISO 27001 Clause 5 requires visible top management commitment — not a rubber stamp, but evidence of ongoing involvement. The board or CEO must sign the IS Policy, approve resources (budget and headcount), participate in management reviews, and be identifiably involved in security decision-making. Auditors probe this; a policy signed two years ago and never reviewed is a nonconformity.
- Appoint an Information Security Manager or CISO with explicit authority and budget
- Define the ISMS scope — which parts of the organisation, which locations, which services. Scope exclusions must be justified and cannot exclude areas where risks originate that affect in-scope areas.
- Identify interested parties: customers (may require certification), regulators (GDPR, FCA, etc.), suppliers, investors, and insurers
- Draft a business case with timeline, budget estimate, and expected business benefits (contract wins, insurance premium reduction, regulatory compliance)
- Select an accredited certification body and request quotations — the choice of CB affects the audit style and Stage 1 timing
Conduct the structured gap analysis from Section 2. Score every clause and every Annex A control group against the 0–4 maturity scale. Assign each gap an owner, a remediation action, an effort estimate, and a target completion date. The output is your implementation project plan — typically managed in a spreadsheet or project management tool with weekly status reviews.
- Interview department heads to understand current security practices (often better than assumed)
- Review existing policies, procedures, contracts, and technical controls
- Map existing technical controls to Annex A controls — many organisations have 60–70% of Annex A covered technically but lack documentation
- Produce a gap analysis report with findings, risk ratings, and a prioritised remediation plan
- Agree on the implementation timeline with management — build in buffer for competing priorities
ISO 27001 does not prescribe a risk methodology — it requires that you define one and apply it consistently. The risk assessment must identify information assets, identify threats and vulnerabilities affecting each asset, assess the likelihood and impact of each risk, calculate a risk level, and determine a treatment option for each risk (treat, tolerate, transfer, or terminate).
- Define the risk assessment methodology: scoring scale (3×3, 5×5), asset-based or scenario-based, likelihood and impact definitions
- Build the asset inventory: information assets (data, documents), hardware, software, services, people, and facilities within scope
- For each asset: identify threats (unauthorised access, malware, human error, natural disaster), vulnerabilities (weak passwords, unpatched software, no backups), and existing controls
- Calculate residual risk after existing controls; compare to the organisation's risk appetite/acceptance criteria
- For risks above the acceptance threshold: select Annex A controls to treat them; record in the Risk Treatment Plan
- Risk owners (asset owners) must accept residual risk in writing — this is a key audit evidence point
The Statement of Applicability is the document that maps all 93 Annex A controls to your organisation — for each control, stating whether it is applicable, the justification for inclusion or exclusion, and the implementation status. It is the single most scrutinised document in a certification audit. A control excluded without a valid justification is a finding. A control marked "implemented" without evidence is a finding.
- For each of the 93 Annex A controls: applicable (Yes/No) → justification → implementation status → evidence reference
- Exclusion justifications must be risk-based: "we have no remote workers therefore A.6.7 (remote working) does not apply" — acceptable. "We decided not to implement this" — not acceptable.
- Every control selected in the Risk Treatment Plan must appear as applicable in the SoA
- The SoA must be approved by management and version-controlled
- Update the SoA whenever the risk assessment changes — the two documents must stay aligned
This is the longest phase — implementing all controls selected in the SoA and producing the documentation required to evidence them. The mandatory documentation list is covered in Section 7. Beyond mandatory documents, you will need operational procedures for each significant control area: access control, patch management, backup, incident response, change management, supplier management, and business continuity.
- Implement technical controls: MFA for all privileged access, endpoint protection, encryption, network segmentation, vulnerability scanning programme, logging and monitoring
- Write operational procedures for each control area — one page is sufficient for simple controls; complex processes need flowcharts and decision trees
- Implement security awareness training and record completion for all staff
- Add security clauses to supplier contracts; conduct supplier risk assessments for critical suppliers
- Establish a patch management process with defined SLAs (CRITICAL: 48h, HIGH: 7d, MEDIUM: 30d)
- Create and test an incident response plan — run a tabletop exercise and document it
ISO 27001 requires evidence of operation — not just that controls exist, but that they have been operating for a period. Auditors expect to see records spanning at least three months before the certification audit: vulnerability scan results, patch records, access review logs, training records, incident logs (even if empty), change management records, and backup test results. The ISMS must be running, not just documented.
- Run monthly vulnerability scans and document remediation
- Conduct quarterly access reviews — review all privileged accounts and remove unnecessary access
- Test backup restoration and document the test result with date, person responsible, and outcome
- Review and update the risk register at least quarterly
- Record all security incidents (including near-misses) in the incident log
- Produce security KPI reports for management — even if metrics are imperfect initially
A complete internal audit cycle covering all clauses and all applicable Annex A controls must be completed before the certification audit. The internal audit must be conducted by someone independent of the area being audited — an internal auditor trained in ISO 27001 auditing, or an external consultant. Following the internal audit, a management review meeting must be held with senior management, covering the mandated agenda items from Clause 9.3.
- Create an internal audit programme covering all clauses and Annex A control groups — can be conducted in multiple smaller audits over 2–3 months
- Internal auditors must be competent — send at least one person on a Lead Auditor or Internal Auditor course
- Every finding from the internal audit must have a corrective action with a root cause analysis and a verification step
- Management review agenda must cover: audit results, security incidents, risk register status, SoA status, objectives progress, customer feedback, supplier performance, and improvement opportunities
- Management review minutes must be retained as documented evidence — this is a mandatory document
The certification audit has two stages. Stage 1 is a documentation review (typically remote or on-site for one day) where the auditor checks that your ISMS is designed correctly — scope, SoA, risk assessment, policies, and documentation are complete and coherent. Stage 2 is an effectiveness audit (typically on-site, one to three days) where the auditor samples evidence that controls are actually operating as documented. Non-conformities found in Stage 2 must be closed — with evidence — before the certificate is issued. Full details are in Section 8.
- Stage 1 checklist: SoA complete and approved; risk register current; all mandatory documents present; internal audit complete; management review held; corrective actions closed
- Stage 2 evidence: auditor will sample — pull specific records, interview staff, walk through specific processes
- Major nonconformity: a requirement of the standard is not met — must be closed before certification. Minor nonconformity: isolated gap — corrective action plan agreed, can close after certification
- Certificate is valid for three years with annual surveillance audits in years 1 and 2
| Option | Definition | When to use | ISO 27001 requirement |
|---|---|---|---|
| Treat (Mitigate) | Implement controls to reduce likelihood or impact below the acceptance threshold | Risk is above appetite and controls are cost-effective relative to the risk | Select Annex A controls; document in RTP and SoA; evidence implementation |
| Tolerate (Accept) | Acknowledge the risk and accept it without additional controls | Residual risk is below appetite OR cost of control exceeds risk value | Risk owner must formally accept in writing; record in risk register; review periodically |
| Transfer (Share) | Move financial impact to a third party — cyber insurance or contractual liability | Risk cannot be cost-effectively mitigated; insurance is available and covers the scenario | Document the transfer mechanism; confirm coverage; residual risk after transfer must be assessed |
| Terminate (Avoid) | Cease the activity that creates the risk entirely | Risk is unacceptable and no cost-effective treatment exists; activity is not essential | Document the decision and rationale; update scope if necessary |
ISO 27001:2022 reorganised Annex A into four themes (replacing the 14 clauses of the 2013 version) and added 11 new controls. The 93 controls are not all mandatory — you select the applicable ones based on your risk assessment and justify any exclusions in the Statement of Applicability.
| Control | Title | What it requires | Typical evidence |
|---|---|---|---|
| A.5.1 | Policies for information security | IS policy defined, approved by management, communicated, reviewed annually | Signed IS policy with version history; distribution records; annual review minutes |
| A.5.2 | Information security roles and responsibilities | All IS roles defined; responsibilities assigned; conflicts of interest managed | RACI chart; job descriptions; org chart with IS roles |
| A.5.3 | Segregation of duties | Conflicting duties separated to reduce fraud/error risk | Role matrix showing segregated functions; access control evidence |
| A.5.4 | Management responsibilities | Management actively directs staff to apply IS policies | Management communications; disciplinary procedure referencing IS |
| A.5.5 | Contact with authorities | Relationships maintained with law enforcement, regulators, CERT | Contact list; records of liaison; NCA/NCSC registration if applicable |
| A.5.6 | Contact with special interest groups | Membership in security forums; threat intelligence sharing | Membership records; threat intel subscriptions (ISAC, NCSC alerts) |
| A.5.7 | Threat intelligence ⭐NEW | Collect and analyse threat intelligence relevant to the organisation | Threat intel subscription; monthly threat briefings; risk register updates from intel |
| A.5.8 | Information security in project management | IS requirements considered in all projects from inception | Project methodology including security gate; DPIA process; security sign-off records |
| A.5.9 | Inventory of information and assets | All information assets inventoried and owned | Asset register with owner, classification, and location for each asset |
| A.5.10 | Acceptable use of information and assets | Policy on acceptable use of information assets; communicated to staff | Acceptable use policy; signed acknowledgement records |
| A.5.11 | Return of assets | Employees and contractors return assets on termination | Offboarding checklist; return receipt; device wipe records |
| A.5.12 | Classification of information | Information classified by sensitivity; classification scheme defined | Data classification policy; classification labels on documents and systems |
| A.5.13 | Labelling of information | Information labelled according to classification scheme | Labelling procedure; DLP rules aligned to classification labels |
| A.5.14 | Information transfer | Rules for transferring information — email, file sharing, physical media | Data transfer policy; encryption requirements; approved transfer tools |
| A.5.15 | Access control | Access control policy; principle of least privilege; need-to-know | Access control policy; quarterly access reviews; role-based access matrix |
| A.5.16 | Identity management | Full identity lifecycle management from provisioning to de-provisioning | Joiner/mover/leaver process; provisioning and de-provisioning records |
| A.5.17 | Authentication information | Password policy; MFA for privileged access; secret management | Password policy; MFA enrollment records; PAM tool evidence |
| A.5.18 | Access rights | Regular review of access rights; removal of unnecessary access | Quarterly access review records; joiner/mover/leaver audit |
| A.5.19 | Information security in supplier relationships | IS requirements in supplier contracts; supplier risk assessed | Supplier security policy; contract clauses; supplier risk register |
| A.5.20 | Addressing IS within supplier agreements | Specific IS requirements in each supplier agreement | Contract templates with security clauses; signed supplier agreements |
| A.5.21 | Managing IS in the ICT supply chain | IS requirements addressed through the ICT supply chain | Software provenance checks; SBOM; supplier audit rights |
| A.5.22 | Monitoring, review and change of supplier services | Regular monitoring of supplier IS performance; change management | Annual supplier reviews; SLA reports; change notification records |
| A.5.23 | IS for use of cloud services ⭐NEW | Policy for acquiring, using, and exiting cloud services securely | Cloud security policy; cloud provider risk assessment; data residency controls |
| A.5.24 | IS incident management planning | Incident management process planned and communicated | Incident response plan; communication templates; escalation matrix |
| A.5.25 | Assessment and decision on IS events | Process to assess IS events and classify them as incidents | Triage procedure; classification criteria; incident log |
| A.5.26 | Response to IS incidents | Documented response procedures; roles and responsibilities clear | IRP with response playbooks; post-incident review records |
| A.5.27 | Learning from IS incidents | Root cause analysis; improvements implemented after incidents | Post-incident review reports; corrective actions closed; lessons learned log |
| A.5.28 | Collection of evidence | Evidence collected and preserved in a forensically sound manner | Evidence handling procedure; chain of custody records; forensic tool list |
| A.5.29 | IS during disruption | IS maintained or rapidly restored during disruption | BCP with IS requirements; BC test records; recovery time objectives |
| A.5.30 | ICT readiness for business continuity ⭐NEW | ICT continuity planned, implemented, tested, and monitored | DR plan; RTO/RPO defined; DR test records with results |
| A.5.31 | Legal, statutory, regulatory and contractual requirements | All IS-related legal requirements identified; compliance maintained | Legal register; GDPR compliance records; contract review process |
| A.5.32 | Intellectual property rights | Procedures for protecting IPR and ensuring licensed software use | Software asset management; licence tracking; IP policy |
| A.5.33 | Protection of records | Records protected from loss, destruction, falsification; retention periods defined | Records management policy; retention schedule; backup and disposal records |
| A.5.34 | Privacy and protection of PII | Privacy and PII protection in accordance with applicable legislation | Privacy policy; DPIA records; data processing agreements; GDPR compliance evidence |
| A.5.35 | Independent review of IS | ISMS reviewed independently at planned intervals | Internal audit reports; external review records (pentest, third-party audit) |
| A.5.36 | Compliance with policies, rules and standards | Managers review compliance within their area regularly | Compliance review records; management attestations; exception register |
| A.5.37 | Documented operating procedures | Operating procedures for IS activities documented and available | Procedure library; version control records; access to procedures confirmed |
| Control | Title | What it requires | Typical evidence |
|---|---|---|---|
| A.6.1 | Screening | Background checks on candidates per legal requirements and job risk | HR screening policy; background check records; criminal record check consent |
| A.6.2 | Terms and conditions of employment | IS responsibilities included in employment contracts | Contract template with IS clauses; NDA records; signed contracts |
| A.6.3 | IS awareness, education and training | All staff receive IS awareness training; role-specific training for IS roles | Training platform; completion records; phishing simulation results; annual refresh |
| A.6.4 | Disciplinary process | Formal disciplinary process for IS policy violations | Disciplinary policy referencing IS; HR records of IS-related cases |
| A.6.5 | Responsibilities after termination or change | IS responsibilities communicated and enforced after employment ends | Offboarding checklist; NDAs; post-termination access revocation records |
| A.6.6 | Confidentiality or non-disclosure agreements | NDAs in place for staff and third parties with access to sensitive information | NDA templates; signed NDA register |
| A.6.7 | Remote working | Policy and controls for remote working to protect information accessed remotely | Remote working policy; VPN/MFA records; clear screen/desk policy; equipment policy |
| A.6.8 | IS event reporting | All staff know how to report IS events; reporting is easy and encouraged | Reporting channel (email, hotline, ticket); awareness training; reported events log |
| Control | Title | What it requires |
|---|---|---|
| A.7.1 | Physical security perimeters | Physical boundaries defined for areas containing sensitive information or equipment |
| A.7.2 | Physical entry | Secure areas protected by entry controls; visitors logged and escorted |
| A.7.3 | Securing offices, rooms and facilities | Physical security applied to offices; sensitive areas separately secured |
| A.7.4 | Physical security monitoring ⭐NEW | Premises continuously monitored for unauthorised physical access |
| A.7.5 | Protecting against physical and environmental threats | Protection from fire, flood, earthquake, explosion; environmental controls in server rooms |
| A.7.6 | Working in secure areas | Rules for working in secure areas — no unauthorised recording, clean desk |
| A.7.7 | Clear desk and clear screen | Clear desk policy for sensitive documents; screen lock enforced |
| A.7.8 | Equipment siting and protection | Equipment sited to minimise environmental risk and unauthorised access |
| A.7.9 | Security of assets off-premises | Off-site assets (laptops, mobiles) protected; policy for off-site use |
| A.7.10 | Storage media | Media managed through acquisition, use, transport, and secure disposal |
| A.7.11 | Supporting utilities | Electricity, water, HVAC protect equipment from failure; UPS and generator |
| A.7.12 | Cabling security | Power and data cabling protected from interception and interference |
| A.7.13 | Equipment maintenance | Equipment maintained per manufacturer recommendations; records kept |
| A.7.14 | Secure disposal or re-use of equipment | Equipment verified free of sensitive data before disposal or re-use |
| Control | Title | What it requires |
|---|---|---|
| A.8.1 | User endpoint devices | Policy and controls for user endpoint devices (laptops, mobiles, BYOD) |
| A.8.2 | Privileged access rights | Privileged access allocated, monitored, and reviewed; principle of least privilege |
| A.8.3 | Information access restriction | Access to information restricted per access control policy |
| A.8.4 | Access to source code | Source code access restricted; read/write access logged; code reviews enforced |
| A.8.5 | Secure authentication | Strong authentication for all systems; MFA where risk warrants it |
| A.8.6 | Capacity management | Resources monitored; capacity planned; performance issues addressed before failure |
| A.8.7 | Protection against malware | Anti-malware controls implemented and updated; user awareness on malware risks |
| A.8.8 | Management of technical vulnerabilities | Vulnerability information obtained; exposure assessed; patches applied per SLA |
| A.8.9 | Configuration management ⭐NEW | Secure configurations established, documented, and maintained for all technology |
| A.8.10 | Information deletion ⭐NEW | Information deleted when no longer required per retention policy and legal obligations |
| A.8.11 | Data masking ⭐NEW | Data masking applied to PII and sensitive data in non-production environments |
| A.8.12 | Data leakage prevention ⭐NEW | DLP measures applied to systems, networks, and endpoint devices |
| A.8.13 | Information backup | Backup copies maintained; tested regularly; stored securely; restoration verified |
| A.8.14 | Redundancy of information processing facilities | Redundancy implemented to meet availability requirements; failover tested |
| A.8.15 | Logging | Event logs generated; protected; reviewed; retained per policy |
| A.8.16 | Monitoring activities ⭐NEW | Networks, systems, and applications monitored for anomalous behaviour |
| A.8.17 | Clock synchronisation | Clocks of all systems synchronised to authoritative time source (NTP) |
| A.8.18 | Use of privileged utility programs | Use of utility programs with privileged access restricted and logged |
| A.8.19 | Installation of software on operational systems | Software installation on production systems controlled; unauthorised software prevented |
| A.8.20 | Networks security | Networks managed and controlled to protect information in systems and applications |
| A.8.21 | Security of network services | Security features of network services identified; implemented; monitored |
| A.8.22 | Segregation of networks | Groups of services, users, and systems segregated on networks |
| A.8.23 | Web filtering ⭐NEW | Web access managed to protect systems from malware and inappropriate content |
| A.8.24 | Use of cryptography | Cryptography policy; encryption key management; approved algorithms |
| A.8.25 | Secure development life cycle | Security integrated into SDLC; security requirements in design; secure coding |
| A.8.26 | Application security requirements | IS requirements for all applications identified and specified |
| A.8.27 | Secure system architecture and engineering principles | Secure engineering principles applied in design and implementation |
| A.8.28 | Secure coding ⭐NEW | Secure coding principles applied; code reviewed for vulnerabilities |
| A.8.29 | Security testing in development and acceptance | Security testing defined and performed in development; acceptance testing includes security |
| A.8.30 | Outsourced development | IS requirements for outsourced development; code review; contractual controls |
| A.8.31 | Separation of development, test and production environments | Development, test, and production environments separated; no production data in dev/test |
| A.8.32 | Change management | Changes to information systems managed via formal change management process |
| A.8.33 | Test information | Test data selected, protected, and controlled; no live PII in test environments |
| A.8.34 | Protection of information systems during audit testing | Audit tests and access to systems agreed with management; minimise disruption |
- ✓Clause 4 — Scope defined and documented — written scope statement specifying what is included and excluded, with justification for exclusions. Management approved and signed.
- ✓Clause 5 — Information Security Policy signed by top management — policy references the standard, is appropriate to the organisation, includes commitment to continual improvement. Communicated to all staff and available to interested parties.
- ✓Clause 6 — Risk assessment completed using documented methodology — all assets within scope assessed; risks identified, analysed, and evaluated; risk register produced and reviewed by risk owners.
- ✓Clause 6 — Risk Treatment Plan produced and approved — every risk above the acceptance threshold has a treatment option and selected Annex A controls. Risk owners have formally accepted residual risks.
- ✓Clause 6 — Statement of Applicability (SoA) completed — all 93 Annex A controls covered; applicable/not applicable decision; justification for each; implementation status; evidence reference. Management approved.
- ✓Clause 7 — IS objectives defined and measurable — at least 3–5 security objectives with owners, KPIs, timelines, and resources allocated. Reviewed at management review.
- ✓Clause 7 — Competence and awareness evidence — all staff completed IS awareness training with records; IS roles have documented competence requirements; training records retained.
- ✓Clause 8 — All SoA-selected controls implemented and operational — not just documented. Each control has been running for at least three months with records. Evidence available for each.
- ✓Clause 9 — Internal audit completed covering all clauses — conducted by independent, competent auditor. All findings have corrective actions. Major findings closed before Stage 2.
- ✓Clause 9 — Management review meeting held and minuted — all mandatory agenda items from Clause 9.3 covered. Management decisions recorded. Minutes retained as documented evidence.
- ✓Clause 10 — Corrective action process documented and in use — nonconformity log exists; at least one or two corrective actions recorded (even minor ones) to demonstrate the process works. Root cause analysis completed.
- ✓A.5.9 — Asset inventory complete — every information asset (systems, data stores, applications, physical equipment) inventoried with an assigned owner, classification, and location.
- ✓A.5.15–5.18 — Access control implemented and reviewed — user access provisioned on a need-to-know basis; privileged access separately controlled; quarterly access reviews with records.
- ✓A.5.19–5.22 — Supplier security agreements in place — all critical suppliers have security clauses in contracts; at least annual supplier security review conducted; records kept.
- ✓A.5.24–5.28 — Incident management process operational — IRP documented, staff trained, incident log exists (even if few entries), at least one tabletop exercise conducted and documented.
- ✓A.8.8 — Vulnerability management programme running — regular scans conducted; results reviewed; patches applied per defined SLAs; records of remediation maintained.
- ✓A.8.13 — Backup tested and restoration verified — backups taken per policy; at least quarterly restoration test performed; test results documented with date, RTO result, and any failures.
- ✓A.8.15 — Logging in place and logs reviewed — security-relevant events logged; logs protected from tampering; log review process defined (manual or SIEM); retention period enforced.
- ✓A.6.3 — Security awareness training with records — all staff completed annual training; phishing simulation results documented; role-specific training for IS staff; records retained for audit.
- ✓All mandatory documents present (see Section 7 for full list)
- ✓Document control procedure in place — version control, approval, review dates, distribution
- ✓Supporting operational procedures written for all significant control areas
- ✓Evidence records organised and retrievable — auditor will ask for specific records on the day
- ✓All document authors and owners identified; documents reviewed within past 12 months
| Document | Clause | Contents | Review frequency |
|---|---|---|---|
| ISMS Scope | 4.3 | Boundaries of the ISMS; inclusions and exclusions with justification | When scope changes |
| Information Security Policy | 5.2 | Management commitment; security objectives; roles; review commitment | Annual minimum |
| Risk Assessment Methodology | 6.1.2 | How risks are identified, analysed, and evaluated; scoring scales defined | When methodology changes |
| Risk Register | 6.1.2 | All identified risks with likelihood, impact, existing controls, residual risk, owner, treatment decision | Quarterly minimum |
| Risk Treatment Plan | 6.1.3 | Selected controls for each treated risk; responsible persons; target dates; current status | As risks change |
| Statement of Applicability (SoA) | 6.1.3 | All 93 Annex A controls; applicable/not applicable; justification; implementation status; evidence ref | Annual; when risk register changes |
| IS Objectives | 6.2 | Measurable IS objectives; owners; timelines; how progress is measured | Annual review |
| Competence Evidence | 7.2 | Competence requirements for IS roles; CVs; certificates; training records | On change of role |
| Awareness Training Records | 7.3 | Evidence all staff completed IS awareness training; dates; content | Annual |
| Communication Plan | 7.4 | What IS information is communicated, to whom, when, and how | Annual |
| Document Control Procedure | 7.5 | How documents are created, approved, reviewed, distributed, and retained | Annual |
| Operational Planning Records | 8.1 | Evidence that operational processes are planned and controlled | Continuous |
| Supplier Agreements | 8.1, A.5.19 | Signed contracts with security clauses for all critical suppliers | On renewal |
| IS Performance Results / KPIs | 9.1 | Security metrics tracked over time; trend analysis; management reporting | Monthly or quarterly |
| Internal Audit Programme | 9.2 | Audit schedule; scope for each audit; auditor assignments | Annual |
| Internal Audit Reports | 9.2 | Findings from each audit; evidence reviewed; nonconformities identified; auditor name | Per audit |
| Management Review Minutes | 9.3 | Attendees; all mandatory agenda items covered; decisions and actions recorded | Annual minimum |
| Nonconformity and Corrective Action Log | 10.1 | All nonconformities; root cause analysis; corrective actions; verification of closure | Continuous |
| Incident Log | A.5.24–5.27 | All IS events and incidents; classification; response actions; lessons learned | Continuous |
The Stage 1 audit reviews whether your ISMS is designed correctly. The auditor checks that all mandatory documents exist, are coherent with each other, cover the declared scope, and demonstrate management commitment. A Stage 1 finding does not fail the certification — it identifies issues to resolve before Stage 2. Common Stage 1 findings include: SoA not referencing the risk register, scope statement excluding areas where risks originate, IS policy not signed by the correct level of management, and risk methodology not defining risk acceptance criteria.
Stage 2 tests whether controls are actually operating as documented. The auditor samples evidence — asks to see specific records, interviews random staff members (not just the IS Manager), walks through processes, and checks technical controls. The audit is evidence-driven: if a control is implemented but undocumented, it may as well not exist for audit purposes. Common Stage 2 nonconformities include: access reviews documented but not covering all systems, patches applied but records not retained, training completed but records incomplete, incident log exists but no evidence of post-incident review.
| Type | Definition | Impact on certification | Response required |
|---|---|---|---|
| Major nonconformity | A requirement of the standard is absent or systematically failed | Certificate cannot be issued until closed with evidence | Root cause analysis + corrective action + evidence of closure within agreed timeframe (typically 90 days) |
| Minor nonconformity | Isolated gap or isolated failure; system is substantially in place | Certificate can be issued; must be closed before next surveillance audit | Corrective action plan submitted within 30 days; evidence of closure by surveillance audit |
| Opportunity for improvement (OFI) | Suggestion from auditor — not a finding against the standard | No impact on certification | Consider and respond; no obligation to implement |
ISO 27001, SOC 2, and NIST CSF are the three most common information security frameworks organisations encounter. They overlap significantly in intent but differ in structure, geographic recognition, third-party involvement, and what evidence they produce. Many organisations pursue multiple frameworks simultaneously — understanding their relationship helps avoid duplication of effort.
- International standard — recognised globally
- Third-party certification — accredited CB issues certificate
- Prescriptive management system + 93 Annex A controls
- Certificate valid 3 years + annual surveillance
- Strong in EMEA, APAC, government, enterprise procurement
- Best for: UK/EU/APAC market access, regulated sectors, supply chain
- US-originated — dominant in North American SaaS market
- CPA firm audit — produces a report, not a certificate
- Five Trust Service Criteria: Security, Availability, Confidentiality, Processing Integrity, Privacy
- Type I: point-in-time design review. Type II: 6–12 month operational period
- Best for: US SaaS companies, tech startups, US enterprise customers
- More flexible — define your own controls within the criteria
- US government framework — voluntary, no certification
- Six functions: Govern, Identify, Protect, Detect, Respond, Recover
- Self-assessment — produces a profile, not a certificate or report
- Required for US federal contractors; widely referenced in US regulation
- Best for: US federal supply chain, internal security programme structuring
- No third-party cost — use as internal roadmap with any framework
| Factor | ISO 27001 | SOC 2 Type II | NIST CSF 2.0 |
|---|---|---|---|
| Geographic recognition | Global — strongest in EU, UK, APAC, Middle East | Dominant in North America; growing globally | US-centric; referenced internationally |
| Third-party audit | Yes — accredited certification body (BSI, Bureau Veritas, LRQA, etc.) | Yes — CPA firm (AICPA-licensed) | No — self-assessment only |
| Output | ISO 27001 certificate (3-year validity) | SOC 2 Type II report (annual) | CSF Profile — no certificate or report |
| First-time cost (mid-size org) | £25,000–£80,000 (implementation + audit) | $40,000–$100,000 (audit fee alone) | £0–£15,000 (internal effort + optional consultant) |
| Timeline to first certification | 9–18 months | 6–12 months (after controls in place for audit period) | N/A — continuous process |
| Prescriptiveness | High — 93 specific controls in Annex A | Medium — criteria with flexibility in control design | Low — framework for structuring your programme |
| Best combined with | ISO 27701 (privacy), SOC 2 (US market), Cyber Essentials (UK baseline) | ISO 27001 (global recognition), HIPAA (healthcare) | ISO 27001 (structure), CMMC (US defence), FedRAMP |
⚡ Start your ISO 27001 journey — first five actions
- Get leadership commitment in writing this week — ISO 27001 cannot succeed without it. Draft a one-page memo from the CEO or board authorising the ISMS project, allocating a budget, and naming an IS Manager. Circulate it to all staff. This is not bureaucracy — it is the evidence the auditor will look for first. Without a signed IS Policy from top management, Stage 1 fails immediately regardless of how good your technical controls are.
- Conduct the gap analysis using the scoring template in Section 2 — score every clause (4–10) and every Annex A theme (A.5–A.8) on the 0–4 scale. Be honest. The output tells you your realistic implementation timeline and where to concentrate effort. Most organisations discover they are at a 2–2.5 average — controls exist informally but documentation and monitoring are weak. That translates to approximately 10–14 months to certification. ISO 27001 overview →
- Build your asset inventory and start the risk assessment — the risk register is the engine of the whole ISMS. Everything else (the SoA, the RTP, the control selection) flows from it. Start by listing every system, application, data store, and physical location in scope. Then for each asset: who owns it, what is the most sensitive data it holds, what happens to the business if it is compromised or unavailable. This conversation surfaces risks that no automated tool finds.
- Write the Statement of Applicability early — it drives the whole programme — go through all 93 Annex A controls and make the applicable/not applicable decision. For your first pass, mark everything applicable unless you have a clear reason for exclusion. The SoA then becomes your implementation to-do list. As you implement each control, update the status column and add the evidence reference. By the time you submit to the auditor, the SoA should tell the entire implementation story.
- Connect ISO 27001 to your existing security programme — ISO 27001 does not exist in isolation. MFA (A.5.17) connects to your identity strategy. Vulnerability management (A.8.8) connects to your patch programme. Incident response (A.5.24–5.28) connects to your SOC. Network segmentation (A.8.22) connects to your infrastructure. Map your existing controls to Annex A before building new ones — you will find most of the technical work is already done. MFA guide → | Network segmentation → | Incident response → | Vulnerability management →
Implementation timelines depend heavily on the starting gap score. An organisation scoring 0–1 (starting from scratch with no formal security programme) typically takes 15–18 months to reach certification. An organisation scoring 2 (informal controls exist but undocumented) typically takes 10–14 months. An organisation scoring 3 (controls implemented, documentation and monitoring weak) typically takes 6–9 months. These timelines assume consistent resource allocation — the most common cause of timeline slippage is competing business priorities pulling the IS Manager back to operational work. A dedicated project manager or external consultant who manages implementation as their primary responsibility reduces timelines by 20–30%.
Total cost has two main components: implementation cost (internal effort plus optional consultant) and certification body audit fees. For a small organisation (50–100 staff), implementation typically costs £15,000–£40,000 in consultant fees if using external help, plus internal staff time. Certification body audit fees range from £3,000–£8,000 for Stage 1 and Stage 2 combined for a small organisation, up to £15,000–£25,000 for a larger organisation requiring more audit days. Annual surveillance audit fees are typically 30–50% of the initial audit cost. Total first-year cost for a mid-size organisation (200–500 staff) with external consultant support: approximately £40,000–£80,000. The ROI case typically rests on: contract wins unlocked by certification (one enterprise contract often pays for the certification programme), cyber insurance premium reduction (typically 10–20%), and avoided breach costs.
The Statement of Applicability is the central compliance document of an ISO 27001 ISMS. It covers all 93 Annex A controls and for each states: whether it is applicable to your organisation (yes or no); the justification for inclusion or exclusion; the implementation status (planned, partially implemented, fully implemented); and a reference to the evidence. The SoA is the bridge between your risk assessment and your control set — every control selected in the Risk Treatment Plan must appear as applicable in the SoA, and every applicable control must be linked to a risk or legal/contractual obligation. Auditors examine the SoA in Stage 1 to verify coherence between the risk register, RTP, and control selection. Exclusion justifications must be substantive — "we don't think this applies" is not sufficient; "we have no remote workers therefore A.6.7 does not apply" is acceptable.
No — but all 93 must be considered and documented in the Statement of Applicability. Controls can be excluded where they are genuinely not applicable to your organisation — a company with no physical office space can exclude physical security controls if it operates fully remotely; a software company with no manufacturing can exclude some production-specific controls. However, exclusions must be justified with a risk-based rationale and the exclusion must not leave the corresponding risk unaddressed. In practice, the vast majority of organisations will find 80–90 of the 93 controls applicable. The 11 new controls added in the 2022 update (threat intelligence, cloud security, secure coding, data masking, etc.) are applicable to almost every modern organisation.
ISO 27001 is the certifiable standard — it specifies the requirements for an ISMS and what an organisation must do to achieve certification. Annex A of ISO 27001 lists the 93 controls by name with a brief description. ISO 27002 is the supporting guidance standard — it provides detailed implementation guidance for each of the 93 controls, with recommended control objectives, implementation advice, and examples. You are certified against ISO 27001; ISO 27002 is a reference guide consulted when implementing controls. Both were updated simultaneously in 2022 (ISO 27001:2022 and ISO 27002:2022). Purchasing ISO 27002 is recommended for the IS Manager during implementation — it provides the practical detail that ISO 27001 itself does not include.
The certificate is valid for three years, subject to passing annual surveillance audits. Year 1 surveillance audit (approximately 12 months after certification) covers a sample of clauses and Annex A controls — typically one-third of the scope. Year 2 surveillance audit covers another one-third. The Year 3 recertification audit is a full re-audit comparable to the original Stage 2. Between audits, the ISMS must continue operating: management reviews held, internal audits conducted, risk register updated, incidents managed and reviewed, and corrective actions maintained. The most common reason for failing a surveillance audit is treating the ISMS as a project that finished at certification rather than an ongoing management system. Organisations that build ISMS activities into the operational calendar (quarterly risk reviews, monthly KPI reporting, annual internal audit) pass surveillance audits without significant remediation effort.