ISO 27001 Explained

What Is ISO/IEC 27001?

ISO/IEC 27001 is the international standard for establishing, implementing, maintaining, and continually improving an Information Security Management System (ISMS).

It is jointly published by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC) and developed by ISO/IEC JTC 1/SC 27 (Information security, cybersecurity, and privacy protection). Hence, the reason you’ll often see it written as ‘ISO/IEC’ 27001, but most often it’s referred to simply as ‘ISO 27001‘ – whether you say “2-7-0-0-1” or “27,000 and 1” is up to you, but most say the latter.

If you need a summary of what an ISMS is, then read my guide here: What is an ISMS

The standard’s roots go back to BS 7799, first published by BSI in 1995. It became ISO/IEC 27001 in 2005, with major revisions in 2013 and 2022. The 2022 update reorganised Annex A and consolidated the controls from 114 down to 93.

The latest version is ISO 27001:2022 – meaning it was published in 2022; prior to that, the major revision was 2013. Occasionally, amendments are put out, which might tweak the standard a little, but these are few and far between.

At its core, 27001 provides a risk‑based management framework for protecting information in all forms (digital, paper, verbal; on‑premises, cloud, and third‑party services). It is not a checklist of mandatory technical controls; instead, it requires you to understand your risks and implement appropriate, proportionate controls.

The standard is deliberately scalable and flexible. You can apply a 27001 ISMS to the whole organisation or to a defined scope such as a specific product, service, function, or location—ideal for start‑ups through to complex multinationals. So, it’s important to understand that you tailor it to your business and your risk appetite.

There are a few ISO 27001 mandatory documents that must be included in the clauses, and many recommendations in Annex A (which we’ll come back to).

Certification by an accredited certification body (e.g., UKAS‑accredited in the UK) provides independent assurance.

Certification typically runs on a three‑year cycle with annual surveillance audits. However, the depth, duration, and scope of an audit can vary among auditors, leading to significant differences.

The Benefits of ISO 27001

Different organisations will see different benefits in ISO 27001 certification, but the things that I see as a real benefit are as follows;

• Managing risk systematically by identifying, assessing, treating, and monitoring information risks with clear owners and timescales. I’m afraid that most organisations I engage with have absolutely no structured risk management or desire to really talk about the risks to their data.
• Winning trust with customers, partners, and regulators by demonstrating robust governance and assurance (probably the biggest reason I see as a consultant).
• Improving efficiency by defining processes, roles, and responsibilities rather than relying on ad‑hoc practices. A lot of 27001 is about repeatable process, and as they say, “if it’s not written down, it hasn’t been said”.
• Meeting obligations (contractual, legal, and regulatory, e.g., data protection requirements). 27001 asks you to evaluate these influences and will help you address them to some extent, but it will be up to you to understand and implement them beyond the default ISO 27001 activities. e.g. You don’t automatically get GDPR compliance from 27001, but it’ll help.
• Continuously improving your security posture as threats and the business evolve over time. It’s not one-and-done, so I see organisations really flourish under 27001 over time.

Who is it for? Any organisation that handles information of value—SaaS, professional services, public sector, charities, manufacturers, and more. You can certify a sensible scope rather than the entire enterprise.

What Is an ISMS?

An Information Security Management System (ISMS) is a framework of interrelated policies, processes, roles, controls, and records used to manage information security risks. It goes beyond technology and embeds:

• Governance – leadership, roles, objectives, and accountability.
• Process – risk management, change, incident response, and supplier management.
• Evidence – documented information, monitoring, internal audit, and review.

Typical artefacts include: the information security policy and objectives; risk assessment and treatment methodology; risk register; Statement of Applicability (SoA); control implementation records; incident and business continuity arrangements; internal audit reports; metrics and dashboards; management review minutes; competence and awareness records; and a nonconformity/corrective‑action log.

The CIA Triad (a Helpful Lens)

There’s a basic concept that I tackle on day one, minute one, when I start training organisations about ISO 27001 and how it works. And that’s the concept of the ‘CIA’.

Although not named explicitly in the standard, the Confidentiality–Integrity–Availability (CIA) triad is a useful way to frame information security in terms of:

• Confidentiality – only authorised access to information.
• Integrity – information remains accurate and complete, safeguarded against unauthorised change.
• Availability – information and services are accessible when needed.

In my experience, when talking about ‘security’, organisations are almost always talking and evaluating the ‘confidentiality’ aspect at the expense of the others, but we should consider them all.

Think of the CIA as different aspects of risk evaluation and as lenses through which we should view security.

Different organisations will “tune” these dials according to risk appetite and business needs. For example, a healthcare provider may place a high priority on confidentiality, availability, and integrity because patient safety and data accuracy are critical. In contrast, a manufacturing firm operating industrial systems may prioritise availability above all else to ensure operations continue even during a security incident.

The key is balance—ensuring your controls collectively maintain all three principles in proportion to what matters most to your organisation.

I’ve written more about the CIA Triad here, but while it’s an important concept in information security, it’s not directly referenced in 27001.

The ISO 27001 Clause Structure

Now, ISO 27001 follows the structure used by other ISO management system standards, making integration with, for example, ISO 9001 (quality), ISO 22301 (business continuity), or ISO 27701 (privacy) straightforward.

Each standard is built around ‘Clauses’ or mandatory requirements. Each Clause in the standard explains what is needed for the ISMS to work effectively. Without all of the clause requirements, the ISMS will fail.

• Clauses 1 to 3 are references and links to terminology. Consider it the foreword of the standard.
• 4. Context of the organisation – Asks organisations to understand internal and external issues, identify interested parties, and define the scope of the ISMS.
• 5. Leadership – Organisations must demonstrate top‑management commitment, set policy, assign roles and responsibilities, and promote a security‑conscious culture.
• 6. Planning – This is about performing risk assessment and treatment planning, setting security objectives, and planning changes.
• 7. Support – The ISMS must define and provide resources, ensure competence and awareness, manage communication, and control documented information.
• 8. Operation – To run an effective ISMS, you must plan and control operations, execute risk assessments, and implement risk treatment.
• 9. Performance evaluation – Lays out the requirements around monitoring and measuring performance, conducting internal audits, and holding management reviews.
• 10. Improvement – The final clause addresses nonconformities, asks you to take corrective action, and drive continual improvement.

Risk Management

If you lift the hood and look at the ISO 27001 engine, you’ll see it’s about risk management (per clauses 6 and 8 above).

It effectively asks organisations to do robust risk assessments by looking at various sources (internal and external) and answering the questions that nobody wants to ask, which start, “What if...”

There are several components within the requirements of ISO 27001 that work together to support risk management, including;

• Risk assessment – identify assets, threats, vulnerabilities, and existing controls; evaluate likelihood and impact with a consistent method.
• Risk treatment plan – decide to mitigate, transfer, avoid, or accept; define actions, owners, resources, and deadlines.
• Risk register/log – maintain traceability from risks to treatments and controls; review regularly.
• Statement of Applicability (SoA) – a mandatory document (see below) listing the Annex A controls you have selected (and any you have excluded) with justifications and implementation status. Think of the ISMS as how you manage security, and the SoA as which controls you rely on—and why.

Managing risk is what really tailors 27001 to your business. Every organisation’s risk appetite will differ, so everyone will develop their own risk management approach. Or, if you are one of the lucky ones, your organisation already has a risk approach, then I’d always recommend utilising that – you don’t have to create from scratch or duplicate things where you already have a process.

As risk management is an ongoing task, you don’t have to mitigate and remove all risks to get certified; it’s an ongoing process of review and addressment. But you do need a clear plan and to have made conscious decisions about the risks your organisation faces.

I encourage people, for example, to take the top ten key risks this quarter and put a treatment plan in place for those particular risks, as they pose the greatest danger. Then you pick up the next ten the following quarter, etc.

Annex A Controls and ISO/IEC 27002

The 2022 edition of ISO 27001 includes a section at the back of the standard which lists 93 controls in Annex A.

A control (not to be confused with ‘clause’) is an area of risk assessment that the standard is asking you to consider and respond to.

These controls are grouped into four themes:

1. Organisational (37)
2. People (8)
3. Physical (14)
4. Technological (34)

Annex A sets out the control titles and purposes. The companion guideline ISO 27002 outlines best practices for implementing and evaluating those controls. 27001 tells you what must be addressed; 27002 provides detailed implementation guidance. You are not required to own 27002 to certify, but auditors commonly use it to judge adequacy (i.e. ‘this is what good looks like’).

Examples of controls by theme (non‑exhaustive):

• Organisational: information security policies; roles and responsibilities; acceptable use; supplier relationships; information classification; incident management; backup; logging and monitoring governance.
• People: screening; terms and conditions of employment; awareness and training; disciplinary process; responsibilities after termination.
• Physical: physical entry controls; securing offices, rooms, and facilities; equipment siting and protection; clear desk/clear screen; cabling security; secure disposal.
• Technological: identity and access management; authentication (including MFA); encryption; network security; application security and change management; vulnerability management; anti‑malware; backups and restoration testing.
  

The controls aren’t saying ‘thou must have this level of encryption’ or ‘thou must implement multi-factor authentication’. The controls are there to ask you what you think is an appropriate solution for your business and its risk appetite. So it’ll mandate that you conduct background checks on new employees, but it doesn’t specify the level of checks. A bank, for example, might require all staff to undergo a criminal record check, but a small business might ask for a reference.

This approach applies to all the controls, and those that aren’t ‘applicable’ to your organisation can be marked as such, with an explanation of why.

What is Annex A: The Statement of Applicability?

I mentioned this already, and it’s a big part of ISO 27001, so it’s worth grasping as a concept early.

Annex A (the section at the back of the standard) provides a comprehensive list of 93 controls to manage information security risks. As an organisation, we are asked to document how we meet these controls in the Statement of Applicability (SoA). It’s a major part of ISO 27001 and requires significant time to evaluate and update.

Typically, we create a spreadsheet or document table of the controls and then explain how we meet them. If we think a control doesn’t apply to our organisation, we can say it is ‘not applicable’ (hence the title ‘statement of applicability’).

For example, if your business doesn’t undertake internal development, then those controls might not be applicable.

It is worth noting that while some information security standards, such as NIST 800-53, are prescriptive about the types of firewalls, encryption, and other controls you must use, ISO 27001 requires you to define which controls apply to your organisation and at what level. So, it’s up to you to respond to each control with a justification for how you feel you meet it.

Scope

One of the first things I’d suggest any organisation considers is: Scope.

27001 doesn’t just ask you to consider what’s in and out of scope in terms of assets, but business functions, systems, influences on your scope (both internal and external), who your stakeholders are, regulatory implications, and many more.

I always ask clients, “What are you protecting, and for whom?” This is hugely illustrative when people answer.

You can tailor the scope to a service, product line, or business unit, provided the boundaries and interfaces are clear, and the scope covers the people, processes, technology, and locations where in‑scope information is handled (including remote/home working and cloud services).

I always ask clients to consider the scope and try to keep it as tight as possible. So, it’s important to consider the data you are protecting, and who you are protecting it for. This will inform the system’s processing, the hardware on which the applications run, and the locations of that hardware. It all starts to develop the wider picture of the scope.

Sample scope statement (illustrative):
“The ISMS covers the design, development, hosting, and support of the ExampleCo SaaS platform and related customer support services, including people, processes, and technology used to handle customer data within the UK and EU regions. Activities and systems not directly supporting the SaaS platform are excluded.”

Integration With Other Requirements

There are other standards that ISO 27001 relates to, and supports, including;

• GDPR and data protection: 27001 supports accountability and security of processing (Articles 5 and 32) by providing a structured approach to risk and controls.
• ISO 22301 (BCMS): strengthens availability and recovery; 27001 references continuity expectations for information security.
• ISO 27701 (privacy extension): extends the ISMS into a Privacy Information Management System (PIMS).
• ISO 9001 (quality management): I often meet organisations that already have 9001 and are looking for 27001, and there’s a lot of commonality.
• SOC 2 (assurance report): a different format and market focus; a 27001 ISMS provides an excellent foundation for SOC 2 controls.

Certification in Brief

The certification process for ISO 27001 varies between auditors, but typically, it will follow the following steps;

1. Stage 1 audit – documentation and readiness check. It’s not pass-or-fail as such, but the auditor may say you aren’t ready for stage 2. Typically a single day.
2. Stage 2 audit – effectiveness assessment (interviews, samples, and evidence). This is the real audit and often 2 days.
3. Certificate issued (typically a three‑year cycle) with annual surveillance checks and recertification in year three.

The above is a typical UKAS accreditation path, but a non-accredited auditor (still a valid certificate!) might be just a day of audit.

Common Pitfalls and Tips

I’ve written more about issues and my top tips around ISO 27001 elsewhere, but some key things I would note are;

• Scope too narrow (missing key processes, cloud services, or remote workers) or too broad to manage.
• Treating it as an IT project rather than a management system with leadership and culture.
• Over‑documenting (complexity that people will not follow) or under‑documenting (no consistent method or evidence).
• Vague SoA with weak justifications; keep it specific and traceable to risks.
• No measurement – define a handful of meaningful KPIs (e.g., patch SLA adherence, time to revoke leavers’ access, incident mean time to resolve, and percentage of successful restore tests).
• One‑off activity – 27001 is a continuous activity. The real value comes from ongoing operations, reviews, and improvements. Leave it between audits at your peril.

Key Takeaways

• ISO/IEC 27001 is a risk‑based management standard, not a prescriptive tech checklist.
• An effective ISMS blends governance, process, and technology to protect confidentiality, integrity, and availability.
• The Statement of Applicability is central—linking your risks to the Annex A controls you have selected and why.
• The standard is flexible and scalable; define a sensible scope and keep improving.
• Certification by an accredited body provides trusted, independent assurance.