ISO/IEC 27001: ISO/IEC 27001 – Tutorial (about 60 minutes)

ISO/IEC 27001 is the international standard that sets out what an organisation must do to run an information security management system (ISMS): a managed, risk-based way of protecting the confidentiality, integrity and availability of information. Companies of every size use it to organise their security work and, very often, to obtain a certificate that customers and regulators recognise. After this tutorial you will be able to explain how the standard is built, how an ISMS is designed and operated, how certification works, and how to avoid the mistakes that make many first attempts fail.

Free tutorial · about 60 minutes · 7 lessons · 5 diagrams · then a 25-question knowledge check and a certificate.

Course overview

Edition and status: The current edition is ISO/IEC 27001:2022 (third edition, published October 2022 by ISO and IEC through their joint technical committee ISO/IEC JTC 1/SC 27), together with Amendment 1:2024 (published February 2024), which adds climate-change considerations to clauses 4.1 and 4.2. No newer edition has been published; certificates are issued against the 2022 edition including its amendment, and the transition period for certificates based on the older 2013 edition ended on 31 October 2025. Several companion standards in the ISO/IEC 27000 family are being revised to align with the 2022 edition. Verified 2026-10-28.

Who this is for: engineers, IT and cloud operations staff, developers, project managers, quality and compliance professionals, and anyone who has been told "we are going for ISO 27001" and wants to understand what that really means. It is also useful for people who will be interviewed by an auditor and want to know what the auditor is looking for.

Prerequisites: none. A general idea of what security controls are (passwords, backups, firewalls, access rights) is helpful but not required. Every term is defined when it first appears.

By the end of this tutorial:

You will be able to explain the purpose of ISO/IEC 27001 and the difference between a management system and a list of security controls.
You will be able to describe the ten-clause structure of the standard and say what clauses 4 to 10 require at a high level.
You will be able to walk through the information security risk assessment and risk treatment process, including the Statement of Applicability.
You will be able to describe how Annex A is organised into four themes and how it is used as a cross-check rather than a checklist.
You will be able to outline the certification journey, from stage 1 and stage 2 audits to surveillance and recertification.
You will be able to apply the standard to a realistic organisation and recognise common pitfalls in scope, risk and evidence.
You will be able to compare ISO/IEC 27001 with related standards and frameworks such as ISO/IEC 27002, ISO/IEC 27005, NIST CSF and SOC 2.

Lesson 1 – Origins, purpose and scope

Why a management system for security?

Most organisations already do some security: they install antivirus, set up firewalls, run backups and ask people to choose strong passwords. The trouble is that these measures are often chosen by habit or by whoever shouted loudest after the last incident. Nobody can say whether they protect the things that matter most, whether they still work, or who is responsible when something changes. Security becomes a pile of tools instead of a discipline.

ISO/IEC 27001 answers this problem by treating information security as something to be managed, in the same way an organisation manages quality, finance or safety. Instead of prescribing a fixed set of technologies, it requires the organisation to understand its situation, decide which risks to information are significant, choose controls to deal with them, check that those controls work, and keep improving. The result is called an information security management system, or ISMS. The ISMS is not a piece of software; it is the combination of policies, processes, roles, records and controls that together keep information security under deliberate control.

A short history

The ideas behind ISO/IEC 27001 started in the United Kingdom in the 1990s with British Standard BS 7799, which had a code of practice for security controls and, later, a second part describing a management system that could be certified. These two parts became international standards. The code of practice turned into ISO/IEC 17799 and was later renumbered ISO/IEC 27002. The management-system part became ISO/IEC 27001, first published in 2005. A second edition followed in 2013, adopting the common structure that ISO uses for all its management system standards. The third edition, published in 2022, kept the same requirements structure with modest wording changes and replaced the control list in Annex A with the reorganised set from ISO/IEC 27002:2022. In 2024 a short amendment added climate change to the issues an organisation must consider.

The standard is published jointly by the International Organization for Standardization (ISO) and the International Electrotechnical Commission (IEC). The work is done by subcommittee 27 of their joint technical committee on information technology (JTC 1/SC 27), which is responsible for the whole 27000 family. Because the text is copyrighted, you buy the standard from ISO or your national standards body; this tutorial explains its content in its own words.

What the standard covers and what it does not

ISO/IEC 27001 is a requirements standard. Its main clauses use the word "shall", which means an organisation claiming conformity must meet them, and an auditor can check whether it does. It applies to any organisation regardless of type, size or sector: a ten-person software start-up, a hospital, a bank, a government department or a factory. It covers information in every form, not only digital data, so paper records, conversations and knowledge in people's heads are also in view.

The standard deliberately does not tell you which firewall to buy, how long your passwords must be or which encryption algorithm to use. Those decisions follow from your own risk assessment. It also does not require you to implement every control it lists; it requires you to determine which controls are necessary and to justify your choices. This flexibility is the source of the standard's wide adoption, and also the source of most misunderstanding, as we will see in the pitfalls section.

Why organisations adopt it

Organisations usually adopt ISO/IEC 27001 for a mix of reasons. Customers, especially large enterprises and public bodies, frequently ask suppliers for a certificate before sharing data with them. Certification reduces the number of long security questionnaires a company has to answer, because one independent audit can stand in for many customer reviews. Regulators in several sectors and countries refer to the standard or accept it as evidence of good practice. Internally, the ISMS gives leadership a clear picture of security risk and a way to make proportionate decisions about spending. Finally, the discipline of measuring and reviewing tends to reveal weaknesses before attackers do.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 27001 relies on terms defined in ISO/IEC 27000, the overview and vocabulary standard of the family, and in the common text shared by all ISO management system standards. You do not need to memorise official definitions, but you do need to understand what each idea means in practice. The explanations below are written in plain language.

Information security – keeping information confidential, accurate and complete, and available when needed. These three properties are often abbreviated as the CIA triad.
Confidentiality – only authorised people, systems or processes can see the information. A leaked customer list is a loss of confidentiality.
Integrity – information is accurate and complete and has not been altered in an unauthorised way. A tampered invoice bank account number is a loss of integrity.
Availability – information and systems can be used by authorised parties when they need them. A ransomware attack that locks every file is mainly a loss of availability.
Information security management system (ISMS) – the slice of how an organisation is run that deals with information security: the policies, roles, processes and records used to set up, run, check and keep improving security, with decisions driven by risk.
Interested party – anyone, inside or outside the organisation, whose interests touch the ISMS or who can influence it, including people who only think they are affected: customers, regulators, staff, shareholders, suppliers. The everyday word is stakeholder.
Scope – the boundaries of the ISMS: which parts of the organisation, which locations, which services, products, processes and technology are covered. A certificate is only valid for the stated scope.
Risk – ISO's management system standards define it very briefly as the "effect of uncertainty on objectives". In information security it is usually expressed as a combination of how likely an event is and how bad its consequences would be.
Risk owner – the named person who answers for a particular risk and has the power to decide what is done about it. Risk owners approve treatment plans and accept the remaining risk.
Risk treatment – the process of deciding what to do about a risk: reduce it with controls, avoid the activity, share it with another party, or knowingly retain it.
Residual risk – the risk that remains after treatment. Residual risk must be understood and formally accepted by the risk owners.
Control – anything the organisation puts in place to keep a risk at its current level or change it. Controls can be policies, procedures, technical mechanisms, physical barriers or practices.
Annex A – the normative annex at the end of ISO/IEC 27001 that lists reference information security controls. It is used to check that no necessary control has been overlooked.
Statement of Applicability (SoA) – a document listing the necessary controls, why each is included, whether it is implemented, and why any Annex A control has been excluded. It is one of the most important ISMS records.
Documented information – any information the organisation has to keep under control, whatever it is stored on: a wiki page, a ticket, a spreadsheet or paper. The term replaced the older split between "documents" and "records".
Nonconformity – a failure to meet a requirement, whether of the standard, of the organisation's own policies, or of a legal or contractual obligation.
Corrective action – action to remove the cause of a nonconformity so that it does not happen again, as opposed to simply fixing the immediate symptom.
Continual improvement – making the ISMS better, again and again, so that it stays fit for purpose, sufficient and effective as the organisation changes.

Two further ideas tie the vocabulary together. First, the ISMS is risk-based: almost every decision traces back to the risk assessment. Second, it is evidence-based: the standard repeatedly asks for documented information so that the organisation, and an auditor, can see that the system actually works rather than merely existing on paper.

Lesson 3 – Structure of the standard

The harmonized structure

Every modern ISO management system standard, whether it deals with quality (ISO 9001), environment (ISO 14001), business continuity (ISO 22301) or artificial intelligence (ISO/IEC 42001), follows the same high-level skeleton. ISO calls this the harmonized structure; it is defined in Annex SL of the ISO/IEC Directives, which is why people often just say "Annex SL", and its earlier version was called the high-level structure. It gives every such standard the same ten clause titles and much shared core text, which makes it easier to run several management systems as one integrated system.

Clauses 0 to 3 are introductory: an introduction, the scope of the standard itself, normative references (ISO/IEC 27000 for vocabulary) and terms and definitions. The requirements live in clauses 4 to 10. After them comes Annex A, the list of reference controls, followed by a bibliography.

Figure 1 – The requirement clauses 4 to 10 form a cycle of planning, operating, evaluating and improving, with Annex A used to check the chosen controls.

Clause by clause, in plain words

Clause 4 – Context of the organisation. Before deciding anything about security, the organisation must understand itself. It identifies internal and external issues that affect what the ISMS needs to achieve (since the 2024 amendment, this explicitly includes considering whether climate change is relevant). It identifies interested parties and their requirements, such as contractual security obligations or data protection law, and decides which of those requirements the ISMS will address. It then defines the scope of the ISMS, taking into account interfaces and dependencies with activities performed by other organisations, and it establishes, implements, maintains and improves the ISMS itself.

Clause 5 – Leadership. Top management must show active commitment: making sure the security policy and objectives fit the strategy, integrating ISMS requirements into business processes, providing resources, communicating why security matters and supporting other managers. Top management establishes an information security policy and assigns roles, responsibilities and authorities, including who reports on ISMS performance.

Clause 6 – Planning. This is the heart of the standard. The organisation plans how to address risks and opportunities for the ISMS. It defines and applies an information security risk assessment process, with criteria for accepting risks and for performing assessments, designed so that repeated assessments produce consistent, valid and comparable results. It defines and applies a risk treatment process that selects treatment options, determines the necessary controls, compares them with Annex A, produces the Statement of Applicability, formulates a risk treatment plan and obtains risk owners' approval. It also sets information security objectives, measurable where practicable, and plans how to achieve them. The 2022 edition added a requirement that changes to the ISMS be carried out in a planned manner.

Clause 7 – Support. The ISMS needs resources, competent people, awareness among everyone who works under the organisation's control, planned internal and external communication, and properly controlled documented information (created, reviewed, approved, distributed, protected, retained and disposed of in a managed way).

Clause 8 – Operation. Here the plans are carried out. The organisation plans, implements and controls the processes needed to meet its security requirements, including processes, products or services provided externally that are relevant to the ISMS. It performs risk assessments at planned intervals and whenever significant changes occur, and it implements the risk treatment plan, keeping records of the results.

Clause 9 – Performance evaluation. The organisation decides what to monitor and measure, how, when and by whom, and analyses the results. It runs an internal audit programme to check that the ISMS conforms both to its own requirements and to the standard, and that it is effectively implemented. Top management reviews the ISMS at planned intervals, considering inputs such as audit results, changes in context, feedback from interested parties, risk assessment results and opportunities for improvement.

Clause 10 – Improvement. The organisation continually improves the ISMS and, when a nonconformity occurs, reacts to it, evaluates the need to eliminate its cause, implements corrective action, reviews the effectiveness of that action and keeps records. In the 2022 edition, continual improvement appears as 10.1 and nonconformity and corrective action as 10.2, the reverse of the 2013 ordering; the content is essentially the same.

The Plan-Do-Check-Act idea

Many people map clauses 4 to 10 onto the Plan-Do-Check-Act (PDCA) cycle: clauses 4 to 7 plan and prepare, clause 8 does, clause 9 checks and clause 10 acts. The current edition does not name PDCA explicitly, and the organisation is free to use any improvement model, but the mapping is a helpful way to remember that the ISMS is a loop rather than a one-time project.

Annex A in the 2022 edition

Annex A lists 93 reference controls, grouped into four themes. The previous edition had 114 controls in 14 domains; the 2022 revision merged many of them, renamed others and introduced 11 new ones. Annex A is normative, meaning the organisation must compare its chosen controls against it, but it is not a mandatory list to implement in full. Each control in Annex A is stated very briefly, usually in one sentence; detailed implementation guidance lives in the companion standard ISO/IEC 27002.

Figure 2 – Annex A of the 2022 edition groups its 93 reference controls into four themes, each with typical subject areas.

The four themes are easy to remember because they describe what each control acts on. Organizational controls (37) concern policies, roles, asset management, information classification, supplier relationships, cloud services, incident management, business continuity and legal compliance. People controls (8) cover screening, terms of employment, awareness and training, disciplinary process, responsibilities after leaving, confidentiality agreements, remote working and event reporting. Physical controls (14) protect perimeters, entry, offices, equipment, cabling, storage media and the workplace. Technological controls (34) handle endpoint devices, privileged access, authentication, malware protection, vulnerability and configuration management, backup, logging, monitoring, network security, cryptography and secure development.

The eleven new controls added in 2022 reflect how security practice has changed: threat intelligence, information security for use of cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering and secure coding. If you see these topics in an ISMS, you are looking at one built for the current edition.

ISO/IEC 27002:2022 also introduced optional attributes for each control, such as control type (preventive, detective, corrective), security property (confidentiality, integrity, availability) and cybersecurity concept (identify, protect, detect, respond, recover). Attributes are not requirements of ISO/IEC 27001, but they help organisations filter and map controls, for example when aligning with the NIST Cybersecurity Framework.

Lesson 4 – How it works in practice

Implementation steps

The standard does not prescribe a project plan, but most successful implementations follow a similar path. Understanding the path helps you see how the clauses connect.

Secure leadership commitment. Top management agrees why the organisation wants an ISMS, appoints someone to coordinate it (often called the ISMS manager or information security officer) and commits resources. Without this, every later step stalls.
Understand context and define scope. Workshops identify internal and external issues, interested parties and their requirements, then a scope statement is written. The scope must be meaningful: if customers care about a SaaS platform, excluding the platform team would make the certificate worthless.
Write the top-level policy and set roles. A short information security policy states direction and commitment. Roles such as risk owners, asset owners and the ISMS coordinator are assigned in writing.
Define the risk method. The organisation documents how it will identify, analyse and evaluate risks: the scales for likelihood and consequence, how they combine, and the criteria for accepting a risk.
Assess risks. Teams identify what could go wrong with the confidentiality, integrity and availability of information within scope, who owns each risk, how likely and severe it is, and how it ranks against the criteria.
Treat risks and produce the SoA. For each unacceptable risk, the owner chooses a treatment and the necessary controls. The controls are compared with Annex A, the Statement of Applicability is produced and a risk treatment plan describes who will do what by when.
Implement controls and supporting processes. Policies, procedures and technical measures are put in place; people are trained; documents are controlled.
Operate and measure. The ISMS runs for a period, generating records: access reviews, incident tickets, backup tests, supplier assessments, metrics against objectives.
Audit and review. An internal audit checks conformity and effectiveness, then top management holds a management review and decides on improvements.
Improve. Nonconformities are corrected and their causes removed; the cycle continues.

The risk process in more detail

Because almost everything in the ISMS depends on risk decisions, it is worth looking closely at the risk process. ISO/IEC 27001 states what the process must achieve; ISO/IEC 27005 gives detailed guidance on how to do it.

Figure 3 – The risk assessment and treatment process: criteria, identification, analysis, evaluation, treatment, Annex A comparison and owner approval, repeated over time.

Risk criteria. Before assessing anything, the organisation decides how it will measure risk and what level it is willing to accept. A common approach uses a five-point scale for likelihood and a five-point scale for consequence and multiplies them, but the standard does not require any particular formula. What matters is that the criteria are written down and applied consistently, so two people assessing the same situation reach similar conclusions.

Identification. Risks are identified in relation to losing confidentiality, integrity or availability of information within the scope. Some organisations start from an inventory of assets and list threats and vulnerabilities for each; others start from business processes or from event scenarios. Since the 2013 edition, the standard does not insist on an asset-based method, although most organisations still keep an inventory of information and related assets because Annex A's asset-management controls call for one.

Analysis and evaluation. For each risk, the potential consequences and realistic likelihood are assessed, giving a risk level. That level is compared with the acceptance criteria and the risks are prioritised.

Treatment. Four broad options exist. The organisation can modify the risk with controls that reduce likelihood or consequence; avoid it by stopping the risky activity; share it with another party, for example through insurance or an outsourcing contract (the accountability does not disappear); or retain it by accepting it knowingly. Most risks are modified.

Necessary controls and Annex A. The organisation designs or selects the controls it needs from any source: its own experience, industry frameworks, vendor guidance or Annex A. It then compares its list with Annex A to make sure nothing necessary has been missed. Annex A is a safety net, not the starting point and not the finishing line. An organisation may need controls that are not in Annex A at all, such as a specific fraud check in a payment process, and it can add them.

Statement of Applicability. The SoA records the necessary controls, the justification for including each, whether each is implemented, and the justification for excluding any Annex A control. Auditors use the SoA as a map of the ISMS, so it must stay consistent with the risk assessment and with reality.

Risk treatment plan and approval. The plan sets out the actions, responsibilities, resources and timing needed to implement the controls. Risk owners approve the plan and accept the residual risks. This step matters: it makes clear that risk decisions are business decisions, taken by people with authority, not technical guesses by the security team.

Roles and artefacts

The standard does not mandate job titles, but typical roles include top management (sets direction, approves policy, conducts management review), an ISMS coordinator or chief information security officer (runs the system day to day), risk owners (decide on treatment and accept residual risk), asset or process owners (operate controls), internal auditors (independent of the work they audit) and every employee (follows policy, reports events).

The standard explicitly asks for a set of documented information. Among the items an auditor will expect to see are: the ISMS scope; the information security policy; the risk assessment and risk treatment processes; the Statement of Applicability; the risk treatment plan; information security objectives; evidence of competence; operational planning information; results of risk assessments and risk treatment; monitoring and measurement results; the internal audit programme and audit results; management review results; and records of nonconformities and corrective actions. In addition, the organisation must keep any other documented information it decides is necessary for the ISMS to be effective, such as procedures for incident handling or access management. Small organisations often need far less paperwork than they fear; the test is whether the documentation is useful and sufficient, not whether it is long.

Living with the ISMS

Once implemented, the ISMS should become part of normal management. Risk assessments are repeated at planned intervals and when significant changes happen, such as moving to a new cloud provider, acquiring a company or launching a new product. Metrics are reported regularly. Internal audits are spread across the year. Management review is held at least once a year in most organisations. Incidents and near-misses feed back into the risk assessment. When the ISMS works well, staff experience it as "how we run things" rather than as an annual audit ritual.

Lesson 5 – Assessment, certification and compliance

Conformity versus certification

An organisation can implement ISO/IEC 27001 and claim conformity without a certificate. Many do this to structure their security programme. However, the main reason the standard is so widely known is that conformity can be independently certified. Certification means an accredited certification body has audited the ISMS and confirmed it meets the requirements for the stated scope.

ISO and IEC write the standard but do not certify anyone. Certification is carried out by independent certification bodies (also called registrars). To give certificates international credibility, those bodies are themselves accredited by national accreditation bodies, such as UKAS in the United Kingdom, ANAB in the United States, DAkkS in Germany or NABCB in India. Accreditation bodies assess certification bodies against ISO/IEC 17021-1 (general requirements for bodies auditing management systems) and the ISO/IEC 27006 series (additional requirements specific to ISMS certification). Certificates from unaccredited bodies exist, but customers and regulators generally give them less weight, so it is wise to check the accreditation mark and verify certificates in the issuing body's register.

The certification audit

Figure 4 – The certification lifecycle: readiness, two-stage initial audit, a three-year certificate with yearly surveillance, then recertification.

Stage 1 reviews the ISMS design and the organisation's readiness. The auditor examines the scope, policy, risk method, risk assessment results, SoA, internal audit and management review, and plans the stage 2 audit. Stage 1 findings tell the organisation what must be fixed before stage 2. Depending on the certification body's planning, stage 1 may take place on site, remotely or as a mix of both.

Stage 2 evaluates whether the ISMS is actually implemented and effective. Auditors interview staff at different levels, sample records, observe controls and trace a risk from assessment to control to evidence. They do not check every control everywhere; they sample, so the organisation must be able to produce evidence on request for any part of the scope.

Findings. Certification bodies typically classify nonconformities as major (a requirement is not met or a systemic failure casts doubt on the ISMS achieving its outcomes) or minor (an isolated lapse that does not undermine the system). They may also record observations or opportunities for improvement. Major nonconformities must be corrected and verified before a certificate can be issued; minor ones need an accepted corrective action plan. The exact grading rules belong to the certification body's procedures, which follow the accreditation requirements.

The certificate and the three-year cycle. A certificate is normally valid for three years. Surveillance audits take place at least once a year in the two intervening years and look at a sample of the ISMS, always including management review, internal audit, corrective actions and changes. Before the three years end, a recertification audit reviews the whole system again. A certificate states its scope; always read it, because a certificate with a narrow scope may not cover the service you care about.

Transitions between editions

When a new edition of the standard is published, accreditation rules set a transition period. For the 2022 edition, existing certificates against the 2013 edition had to be transitioned by 31 October 2025; certificates that were not transitioned by then are no longer valid. The 2024 amendment did not require a separate transition project, but auditors now expect organisations to have considered whether climate change is a relevant issue for their ISMS, even if the conclusion is that it has little effect.

Compliance in a wider sense

ISO/IEC 27001 is a voluntary standard. It is not a law, and having a certificate does not by itself prove compliance with legislation such as data protection or sector-specific cybersecurity rules. However, the ISMS is a natural home for managing legal obligations: clause 4 asks for interested parties' requirements, which include legal and regulatory ones, and Annex A contains controls on identifying legal requirements, protecting personal data and records, and independent review of security. Many organisations use their ISMS as the backbone for meeting multiple obligations at once.

Certification of people

People are not certified to ISO/IEC 27001; organisations are. Training providers offer personal qualifications such as "ISO/IEC 27001 Lead Implementer" or "Lead Auditor", and some of these are themselves accredited against personnel-certification standards. They can be valuable for careers, but they are separate from the organisational certificate and are not issued by ISO.

Lesson 6 – Worked example

To see how the pieces fit, follow a fictional company, Brightlane Health Analytics, through its first ISMS. Brightlane has 140 staff in two offices and fully remote engineers. It sells a cloud-hosted analytics platform to clinics, which upload appointment and billing data containing personal information. A large hospital group has said it will only sign a contract if Brightlane holds an ISO/IEC 27001 certificate within a year.

Step 1 – Leadership and context

The chief executive sponsors the project and appoints the head of platform engineering as ISMS manager, with a small budget and a steering group including the chief operating officer, head of customer success and the data protection officer. A context workshop identifies issues such as rapid growth, dependence on one public cloud provider, a shortage of security staff, data protection law in the countries where clinics operate, and rising ransomware attacks on healthcare. On the climate question added by the 2024 amendment, the team notes that extreme weather could affect the availability of its cloud region and of staff in one office; they record this as a relevant but moderate issue that feeds the continuity risk.

Interested parties include clinics (who require confidentiality and uptime), patients (whose data is processed), regulators, the hospital group (which has contractual security requirements), staff and the cloud provider. For each, the team records the relevant requirements and which of them the ISMS will address.

Step 2 – Scope

The first draft scope covered only "the analytics platform production environment". The ISMS manager realises this is too narrow: engineers who deploy code, support staff who access customer data and the HR process that onboards staff all affect the platform's security. The final scope is: "The development, operation and support of the Brightlane analytics platform, including the people, processes, offices and cloud infrastructure that support it." Finance's internal accounting system is excluded, with the interface (it receives no customer data) documented.

Step 3 – Policy, roles and risk method

Management approves a two-page information security policy. Each department head becomes risk owner for risks in their area. The risk method uses five-level scales for likelihood and impact; any risk scoring 12 or more out of 25 must be treated, and risks below that may be accepted by the risk owner with a short justification.

Step 4 – Risk assessment

Workshops with engineering, support, HR and facilities produce 48 risks. Three examples show the variety:

An attacker uses a phished support engineer's password to log in to the admin console and export clinic data. Likelihood 4, impact 5, score 20, owner: head of customer success.
A faulty database migration corrupts billing data and backups are found to be incomplete. Likelihood 3, impact 4, score 12, owner: head of platform engineering.
A laptop with unencrypted local exports is stolen from a café. Likelihood 3, impact 4, score 12, owner: chief operating officer.

Step 5 – Treatment, Annex A and the SoA

For the phishing risk the owner chooses to modify the risk. Controls selected: phishing-resistant multi-factor authentication for all admin access, restricting the admin console to managed devices, just-in-time privileged access with approval, logging of data exports with alerts, and targeted awareness training for support staff. For the migration risk: change management with peer review, automated restore tests each week, and configuration management of database settings. For the laptop risk: full-disk encryption, a rule against local exports of customer data, data leakage prevention on endpoints and a remote-wipe capability.

The team then compares its controls with Annex A. It finds it has nothing for secure disposal of old office equipment, no defined approach to threat intelligence, and no process to check supplier security beyond the cloud provider. These gaps are added. Physical controls for a data centre are marked not applicable because Brightlane has no data centre; the SoA explains that physical hosting is provided by the cloud provider and is covered by the supplier and cloud-services controls instead. The completed SoA lists every Annex A control with its status and justification, plus two extra controls of Brightlane's own, including a clinical-data anonymisation check before data is used for analytics development.

The risk treatment plan schedules the work over six months. Each risk owner signs off the plan and the expected residual risk. For one risk, a dependency on a single cloud region, the owner decides to retain the residual risk for this year because a multi-region design is too costly now; the acceptance and reasoning are recorded and set for review in twelve months.

Step 6 – Implement and operate

Engineering rolls out the technical controls. HR adds screening and confidentiality agreements to onboarding. All staff complete awareness training, and the support team completes extra exercises. Document control is set up in the company wiki with owners, versions and approval history. Objectives are set and measured monthly: for example, all admin accounts covered by phishing-resistant authentication by month four; weekly restore tests passing; critical vulnerabilities fixed within an agreed number of days.

Step 7 – Check, act and certify

After three months of operation, an internal auditor from a partner firm audits the ISMS. She finds that access reviews for the admin console happened but nobody recorded who approved the removals, and that two new engineers had not completed training. Corrective actions fix the records process and link training completion to account activation. The management review considers audit results, metrics, incidents (one minor misdirected email), changes in context and resource needs, and approves budget for a security engineer.

The certification body's stage 1 audit raises a concern that the risk method does not say how often risks are reassessed. The method is updated. At stage 2, auditors interview the support team about export alerts, sample access reviews, check restore-test evidence and trace the phishing risk from the register through the SoA to the authentication configuration. They raise one minor nonconformity: a supplier contract lacks a security clause. Brightlane submits a corrective action plan, and the certificate is issued for the agreed scope. The hospital group checks the certificate in the certification body's register and confirms the scope covers the platform it is buying.

A year later the surveillance audit focuses on changes: Brightlane has added a new data pipeline, so the auditors check that the risk assessment was updated before it went live. The ISMS is now part of the way the company works.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27001 rarely stands alone. Knowing its neighbours helps you choose the right tool and avoid duplicating work.

Figure 5 – ISO/IEC 27001 sits at the centre of the 27000 family: vocabulary feeds it, guidance standards help implement it, sector standards extend it, ISO/IEC 27006 governs its audits and the privacy standard can be run alongside it.

Within the family, ISO/IEC 27000 provides the overview and vocabulary. ISO/IEC 27002 gives guidance on each control, including purpose, guidance and attributes; it is a guidance document (earlier editions were titled a code of practice) and cannot be certified on its own. ISO/IEC 27003 explains how to meet the ISMS requirements clause by clause. ISO/IEC 27004 helps with monitoring and measurement. ISO/IEC 27005 explains information security risk management in depth. Sector and topic extensions include ISO/IEC 27017 (cloud security controls), ISO/IEC 27018 (protection of personal data in public clouds) and ISO/IEC 27019 (energy utilities). ISO/IEC 27701 covers privacy information management; its first edition was written as an extension of ISO/IEC 27001, while its current edition is a standalone management system standard that can still be run together with an ISMS. ISO/IEC 27006 sets requirements for bodies that audit and certify ISMSs.

Outside the family, several frameworks overlap with ISO/IEC 27001 and are often used alongside it.

Standard or framework	Owner	What it is	Relationship to ISO/IEC 27001
ISO/IEC 27002	ISO/IEC JTC 1/SC 27	Guidance on implementing security controls, with control attributes	Same control set as Annex A, with much more detail; used for implementation, not certified on its own
ISO/IEC 27005	ISO/IEC JTC 1/SC 27	Guidance on information security risk management	Explains how to perform the risk assessment and treatment that clauses 6 and 8 require
NIST Cybersecurity Framework 2.0	US National Institute of Standards and Technology	Voluntary outcome-based framework with six functions (Govern, Identify, Protect, Detect, Respond, Recover)	Not a certifiable standard; often used to communicate maturity, and its outcomes can be mapped to ISO/IEC 27001 controls
SOC 2	AICPA (American Institute of CPAs)	An attestation report by an independent CPA firm on controls against the Trust Services Criteria	Produces an auditor's report, not a certificate; common in North American SaaS. Many companies hold both and reuse evidence
ISO 22301	ISO/TC 292	Requirements for a business continuity management system	Same harmonized structure; complements the availability side of an ISMS and can be integrated with it
ISO/IEC 42001	ISO/IEC JTC 1/SC 42	Requirements for an artificial intelligence management system	Same structure and risk-based approach; organisations with AI products often extend their ISMS processes to cover it
ISO 9001	ISO/TC 176	Requirements for a quality management system	Shares clauses 4 to 10 structure; document control, audit and management review can be run as one integrated system

The practical lesson is that ISO/IEC 27001 provides the management system, while other documents provide controls, guidance or reporting formats. A company can run one ISMS and map its controls to NIST CSF outcomes, SOC 2 criteria, cloud-specific guidance and legal requirements, using one set of evidence for many purposes.

Common pitfalls and best practices

Common pitfalls

Treating Annex A as a checklist. Teams start by working through the 93 controls instead of assessing risk. The result is generic controls that do not match real threats, and an SoA whose justifications are just "best practice".
Scope that is too narrow or too vague. A tiny scope makes certification easy but the certificate useless to customers; a vague scope makes the audit unpredictable and evidence hard to collect.
Security team owns every risk. When technical staff accept risks on behalf of the business, decisions lack authority and risks are mis-prioritised. The standard expects named risk owners with real accountability.
Documentation written for the auditor. Long policies copied from templates that nobody reads or follows create nonconformities, because auditors check whether practice matches the paper.
A once-a-year ritual. If risk assessments, internal audits and reviews happen only in the weeks before an audit, the ISMS does not reflect reality and surveillance audits become stressful.
Fixing symptoms, not causes. Re-training one person after a mistake without asking why the process allowed it leaves the same nonconformity to recur.
Ignoring suppliers and cloud services. Much risk now sits with providers; an ISMS that stops at the company's own network misses it.

Best practices

Start from business objectives. Tie the ISMS to what the organisation needs to protect and why, so leadership sees it as enabling the business.
Keep the risk method simple and repeatable. A clear scale applied consistently beats an elaborate model nobody can reproduce.
Make evidence a by-product of work. Use ticketing, version control and automation so that records of reviews, changes and tests are created naturally.
Write short, specific policies. One page that people understand is more effective than twenty that they ignore.
Use independent, competent internal auditors. They should not audit their own work, and they should sample evidence as a certification auditor would.
Measure what matters. Choose a handful of objectives and metrics linked to top risks, and review them regularly with management.
Integrate with other management systems. Share document control, audit and management review with quality, continuity or privacy programmes to reduce overhead.

Summary and key takeaways

ISO/IEC 27001:2022, with Amendment 1:2024, is the current requirements standard for an information security management system; certificates against the 2013 edition are no longer valid.
An ISMS is a management system, not a product: policies, roles, processes, records and controls that keep information security under deliberate control.
Clauses 4 to 10 follow the harmonized structure shared by ISO management system standards, forming a cycle of planning, operation, evaluation and improvement.
Risk assessment and treatment drive control selection; Annex A is a cross-check of 93 reference controls in four themes, not a mandatory checklist.
The Statement of Applicability links risks, controls, implementation status and justifications, and is central to every audit.
Risk owners, not only the security team, approve treatment plans and accept residual risk.
Certification is performed by accredited certification bodies through stage 1 and stage 2 audits, followed by yearly surveillance and recertification every three years.
The standard works best when integrated with related frameworks such as ISO/IEC 27002, ISO/IEC 27005, NIST CSF, SOC 2 and other ISO management systems.

Reflection questions

Think of an organisation you know. What would a meaningful ISMS scope look like for it, and which interested parties would care most about that scope?
Pick one risk to information in your work. How would you describe its likelihood and consequence, who should own it, and which treatment option would you choose?
Which Annex A controls would you expect to be excluded in a fully remote company with no offices, and how would you justify those exclusions?
If an internal audit found that access reviews are done but not recorded, what corrective action would remove the cause rather than just the symptom?
Your company already has a SOC 2 report. How would you reuse its evidence for ISO/IEC 27001, and what would you still need to add?