Written by Alan Parker, ISO 27001 Consultant
Date of Last Revision: 26/4/26

ISO 27001 sets out a clear set of requirements for building, running and improving an Information Security Management System (ISMS). But the standard itself isn’t always easy to read — and it’s not always obvious what’s genuinely mandatory versus what’s guidance.

This page covers every requirement you need to meet to achieve ISO 27001 certification, explained in plain English, with links to more detail where needed.

I’ve written the following guide to build upon the concepts explored in the following articles. If you are new to ISO 27001 entirely, then I recommend you start here;

---

The Two Types of ISO 27001 Requirements

Before diving in, it helps to understand that ISO 27001 requirements come in two distinct forms — and confusing them is one of the most common mistakes organisations make.

The clauses tell you how to run your ISMS. The controls tell you how to secure your information assets. Both matter for certification.

---

The Mandatory Clause Requirements (Clauses 4–10)

Clauses 1 to 3 — References & Background

Clauses 1 to 3 are introductory and don’t contain requirements. Everything from Clause 4 onwards is mandatory. So repeat after me, “I don’t need to learn clauses one to three!”

Clause 4 — Context of the Organisation

You must understand your organisation’s internal and external environment, identify who has a stake in your information security (customers, regulators, partners, employees), and define the scope of your ISMS. This is where you set the foundations for everything that follows, and you’ll keep coming back to it for reference.

Clause 4 asks you to do four things: capture the internal and external issues that affect information security (Clause 4.1); identify your interested parties and what they expect from you (Clause 4.2); document the boundaries and applicability of your ISMS (Clause 4.3); and confirm that you’ve established the ISMS as a genuine management system (Clause 4.4). Of these, the scope statement (4.3) is the artefact auditors examine first – it tells them exactly what they’re auditing.

In my experience, this is the clause organisations rush through and later regret. Almost everyone says, “Everything is in scope!”

A scope that’s too narrow leaves obvious gaps an auditor will spot in five minutes; a scope that’s too broad creates an ISMS that’s impossible to maintain. The other common failure is treating “interested parties” as a tick-box list of customer and regulator names, rather than a genuine analysis of what each one actually expects from your security posture.

Get Clause 4 right, and the rest of the standard becomes much easier; get it wrong, and you’ll be fighting that decision for the rest of the implementation.

Explore Clause 4 and Context of the Organisation→

Clause 5 — Leadership

Senior management must demonstrate a visible commitment to the ISMS. This means establishing a formal Information Security Policy, assigning roles and responsibilities, and ensuring the ISMS gets the resources it needs. ISO 27001 is explicitly a top-down initiative – it cannot be driven by IT alone. In fact, when it’s thrown to IT, or even worse, a junior member of staff to champion, I guarantee project failure on the horizon.

The clause has three sub-clauses: leadership and commitment from top management (5.1); the information security policy itself (5.2); and the assignment of organisational roles, responsibilities and authorities (5.3). The policy must be approved by top management, communicated within the organisation, and made available to interested parties where appropriate.

What auditors look for here is evidence, not statements on intention.

A policy document signed by the CEO is a start; minutes of management reviews showing actual leadership engagement is what they want to see. The most common failure I see is the policy being written by IT, signed by leadership, and then never referenced again.

If your CEO can’t tell an auditor what the policy broadly says when asked, the clause isn’t being met properly, regardless of what’s documented.

How to demonstrate leadership under ISO 27001→

Clause 6 — Planning

This is where you do your risk work, and arguably where the real engineering of the ISMS happens.

You must define a risk assessment methodology, identify and evaluate information security risks, produce a risk treatment plan, and set measurable information security objectives.

Clause 6 splits into three parts: actions to address risks and opportunities (6.1), which contains the risk assessment and risk treatment requirements; information security objectives and planning to achieve them (6.2); and the new sub-clause introduced in 2022, planning of changes (6.3), which asks you to manage changes to the ISMS in a controlled way.

The risk assessment is the engine of the whole standard – everything in Annex A flows from the risks you identify here. You also produce your Statement of Applicability at this stage, listing which Annex A controls you’ve selected, which you’ve excluded, and why.

In my experience, this clause is where organisations either build a real ISMS or build a paper one. A genuine risk assessment tailored to your business will identify a different set of priorities than a generic template, and the controls you implement will look different as a result.

The most common failure is treating the risk register as a one-off compliance document rather than a living tool – I’ve seen risk registers from previous consultants that haven’t been touched in two years, with risks listed that no longer exist and emerging risks completely absent. Auditors will spot this immediately.

Discover how to approach Planning in ISO 27001→

Clause 7 — Support

You must provide the resources needed to operate the ISMS, ensure relevant staff are competent for their information security responsibilities, run security awareness activities, manage internal and external communications, and maintain documented information.

This clause has five sub-clauses covering resources (7.1), competence (7.2), awareness (7.3), communication (7.4) and documented information (7.5). Sub-clause 7.5 is particularly important because it’s where the standard’s documentation requirements live, including how documents are created, controlled, updated and protected.

Where I see organisations stumble most in this area is awareness and competence.

It’s not enough to send everyone an annual e-learning module; auditors want to see that staff actually know what’s expected of them in their specific role. For example, a developer should be able to describe their secure coding obligations; a finance lead should understand their data classification responsibilities.

If awareness is generic, it usually fails its first test under a robust audit.

Learn about Support under ISO 27001→

Clause 8 — Operation

Planning is one thing; Clause 8 requires you to actually implement and operate it.

Risk assessments must be carried out at planned intervals and whenever significant changes occur. Everything you said you’d do in Clause 6 must actually be happening in the organisation.

The clause has three sub-clauses: operational planning and control (8.1), which asks you to plan, implement and control the processes needed to meet your security requirements; information security risk assessment (8.2), the operational execution of your methodology; and information security risk treatment (8.3), the implementation of your treatment plan and the evidence that controls are operating effectively.

This is the clause where Stage 2 audits genuinely live or die. In Stage 1, the auditor checks that your documents say sensible things; in Stage 2, they check that your organisation actually does what those documents claim.

The most common failure pattern I see is a beautifully documented risk assessment methodology that has only been executed once, six months before the audit.

ISO 27001 expects ongoing operation, not a single point-in-time exercise. If your risk register hasn’t been updated in the last quarter, that’s a finding waiting to happen.

Discover ISO 27001 clause 8: Operation→

Clause 9 — Performance Evaluation

You must monitor and evaluate the performance of your ISMS, run internal audits at planned intervals, and conduct a management review at least annually. Both the internal audit and the management review must be formally documented with outputs.

Clause 9 splits into monitoring, measurement, analysis and evaluation (9.1); internal audit (9.2); and management review (9.3). The internal audit must be conducted by someone independent of the area being audited, and the management review must cover specific topics outlined in the standard, including the status of corrective actions, audit results, and changes that could affect the ISMS.

The two issues I tend to see are internal audits that are too superficial (a checklist run-through rather than a genuine examination) and management reviews that are minutes of a meeting that didn’t really happen, or miss the expected inputs/agenda.

A management review in which the minutes record a decision that no one on the leadership team can recall making is a clear sign of paperwork without substance, and it gets flagged. The good news is this clause is one of the easiest to do well once you accept that it needs real engagement from real people, not just documentation.

How Performance Evaluation works under ISO 27001→

Clause 10 — Improvement

When audits find gaps, when incidents happen, or when controls are found to be ineffective, you must take corrective action and document what happened, what you did, and whether it worked. Continual improvement isn’t optional – it’s a core requirement of the standard.

The clause has two sub-clauses: nonconformity and corrective action (10.1), and continual improvement (10.2). The nonconformity process is what auditors will check most closely – they want evidence that issues are recorded, root causes investigated, corrections made, and effectiveness verified.

This is the clause that separates organisations that get value from their ISMS from those that don’t.

Treated properly, Clause 10 is the engine that makes the system improve over time – each audit, each incident, each near-miss feeds learning back into the ISMS. Treated as paperwork, it becomes a corrective-action log that nobody reads. Auditors can usually tell the difference within ten minutes of opening your improvement records.

Explore ISO 27001’s continual improvement cycles→

---

The Annex A Control Requirements

Annex A contains 93 controls across four categories. You must evaluate all 93 and document your decisions in your Statement of Applicability — including justifications for any control you exclude.

The full list of ISO 27001 controls
The Statement of Applicability explained
Use the free Annex A applicability checker

---

The Documentation Requirements

ISO 27001 requires you to produce and maintain specific documented information. Some documents are explicitly named in the standard. Others are implied — you need them to demonstrate compliance, even if the standard doesn’t name them directly.

Core mandatory documents include your ISMS scope, Information Security Policy, risk assessment and treatment documentation, Statement of Applicability, information security objectives, and records of internal audits and management reviews.

ISO 27001 doesn’t give you a nice list of mandatory documents; it hides them in the text (which is a shame, in my opinion), but here’s a summary of what they are.

Document/Record	Clause	Description
Scope of the ISMS	Clause 4.3	Defines the boundaries and applicability of the information security management system (ISMS). The ISMS scope statement specifies where the ISMS applies within the organisation and is a key part of the required documentation for compliance.
Information Security Policy	Clause 5.2	Sets the organisation’s approach to information security and provides a framework for setting objectives.
ISMS Roles & Responsibilities	Clause 5.3	Supports Clause 5.3. ISMS Roles and Responsibilities
Risk Assessment Process and Results	Clause 6.1.2	Documents the criteria, process, and results of risk assessments.
Risk Treatment Process and Plan	Clause 6.1.3	Outlines selected risk treatment options and actions.
Statement of Applicability (SoA)	Clause 6.1.3 d)	Lists selected controls, justifications, implementation status, and exclusions with reasons.
ISMS Objectives	Clause 6.2	The objectives summarise the goals for the forthcoming period and must be documented and communicated
Evidence of Competence	Clause 7.2	Records of training, etc, demonstrating personnel competency in roles affecting information security.
Evidence of Monitoring and Measurement	Clause 9.1	Demonstrates how performance and effectiveness of ISMS controls are monitored and evaluated.
Internal Audit Plan and Reports	Clause 9.2	Contains internal audit processes, schedules, and results.
Management Review Minutes	Clause 9.3	Records outcomes of management review meetings, including key decisions and actions.
Nonconformity and Corrective Action Logs	Clause 10.2	Tracks nonconformities, corrective actions taken, and their effectiveness.
Control of Documented Information	Clause 7.5	Documented Information

It’s important to note that these documents aren’t everything you’ll need to become compliant. These are the minimum; there will be others you need depending on your circumstances and responses to the controls in Annex.

You can pick up the core documents in my free information security toolkit below.

The full list of mandatory documents

---

What ISO 27001 Doesn’t Require

A lot of anxiety around ISO 27001 comes from misunderstanding what the standard actually mandates. Here’s what it doesn’t require:

The standard is deliberately flexible. A two-person startup and a 200-person managed service provider can both be certified — they’ll just have different scopes, risk profiles and control implementations.

---

How Long Does It Take to Meet the Requirements?

For most SMEs, meeting the ISO 27001 requirements and reaching certification readiness takes between 60 and 120 days when approached with focus and the right guidance. The quickest any of my clients has been certified is 22 days (non-accredited). For a UKAS-accredited certification, the realistic minimum is around 70 days.

How to get ISO 27001 certified
ISO 27001 certification costs in the UK

---

What Changed in ISO 27001:2022?

The 2022 update is the first major revision since 2013. The clause structure stayed largely the same, but three things are worth knowing if you are coming to this version as an upgrade;

Annex A was reorganised. The previous 114 controls were consolidated into 93, grouped into four themes – Organisational, People, Physical and Technological. The four-theme structure is much easier to navigate than the old fourteen categories.

Eleven new controls were introduced. They reflect how information security has evolved: Threat Intelligence (5.7), Information Security for Use of Cloud Services (5.23), ICT Readiness for Business Continuity (5.30), Physical Security Monitoring (7.4), Configuration Management (8.9), Information Deletion (8.10), Data Masking (8.11), Data Leakage Prevention (8.12), Monitoring Activities (8.16), Web Filtering (8.23) and Secure Coding (8.28). For most SMEs, the cloud services, data leakage prevention and secure coding controls are the ones that genuinely change how you need to think.

A new sub-clause – 6.3 Planning of Changes. Asks you to manage changes to the ISMS in a controlled way. A small addition, but a sensible one.

The transition deadline of 31 October 2025 has now passed. If you’re certified, you should already be on the 2022 version; if you’re starting fresh, the 2022 standard is the only one to think about.

I do think ISO 27001 is as relevant as ever, and they’ve tried to futureproof it against technological changes, but if I have a concern, it’s in two parts;

1. The standard makes no mention of AI, which is shaping how everyone processes data. Yes, there are generic controls and policies, but it’s something you’ll need to consider.
2. It doesn’t handle shared service/shared responsibility models very well. This is where you might use a platform like AWS, and they handle some of the controls while you handle others – the standard doesn’t really address this.

FAQs