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

ISO/IEC 27002 is the international guidance document that describes a reference set of information security controls and explains, for each one, what it is for and how it can be put into practice. Security teams, auditors, IT and cloud engineers, developers and compliance staff use it as a practical companion when they build or improve an information security management system, or when they simply want a well-organised, widely recognised catalogue of good security practice. After this tutorial you will be able to find your way around its 93 controls and four themes, use control attributes to build your own views of the catalogue, connect the guidance to risk treatment and ISO/IEC 27001, and turn a control into working practice with evidence an auditor can follow.

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

Course overview

Edition and status: The current edition is ISO/IEC 27002:2022, the third edition, titled "Information security, cybersecurity and privacy protection – Information security controls". It was published in February 2022 by ISO and IEC through their joint technical committee ISO/IEC JTC 1/SC 27, and it replaced the 2013 edition. No amendment and no newer edition had been published when this was checked. ISO reviews every standard at least every five years, so a systematic review of this edition is expected around 2027; check the ISO catalogue page for the latest status before you rely on it. Verified 2026-10-29 (the ISO catalogue page blocks automated access, so the status was confirmed from published secondary descriptions of the standard and from the alignment of later standards with it).

Who this is for: engineers, system administrators, cloud and platform teams, developers, security analysts, internal auditors, quality and compliance staff, and project or product managers who keep hearing "we follow ISO 27002" and want to know what that actually means. It is also useful if your company is working towards ISO/IEC 27001 certification and you have been asked to "own" a few controls.

Prerequisites: none. A general idea of everyday security measures such as passwords, backups, access rights and firewalls helps, but every term is explained when it first appears. Knowing what a management system is will make Lesson 4 easier; the tutorial explains it briefly.

By the end of this tutorial:

You will be able to explain what ISO/IEC 27002 is, why it is guidance rather than a set of requirements, and how it relates to ISO/IEC 27001.
You will be able to describe the layout of the 2022 edition: the four themes, the 93 controls and the fixed layout of each control.
You will be able to use the five attribute types and their values to filter and group controls for a specific audience or purpose.
You will be able to show how controls are chosen through risk treatment and recorded, and how the guidance is then used to implement them.
You will be able to explain how use of the guidance is assessed in practice, and why no organisation can be certified against ISO/IEC 27002 itself.
You will be able to apply the guidance to a realistic organisation, from a risk to an implemented, evidenced control.
You will be able to compare ISO/IEC 27002 with neighbouring standards and frameworks such as ISO/IEC 27005, ISO/IEC 27017, NIST CSF 2.0, NIST SP 800-53 and the CIS Controls.

Lesson 1 – Origins, purpose and scope

Why a catalogue of controls exists

Every organisation that handles information faces the same basic question: which security measures should we have, and how good do they need to be? Without a shared reference, each company invents its own answer. Security managers then argue from personal experience, auditors from their own checklists, and suppliers from whatever their last customer asked for. The result is gaps in some places, wasted effort in others, and endless questionnaires that all ask the same things in different words.

A common catalogue of controls solves part of this problem. A control is any measure that changes a risk: a policy, a process, a rule, a technical setting, a physical barrier or a habit people follow. If many organisations describe their controls using the same names and the same organisation of topics, they can compare notes, train staff with shared material, answer customer questions more easily and give auditors a familiar map. ISO/IEC 27002 is the most widely used catalogue of this kind at international level.

A short history

The roots of ISO/IEC 27002 go back to the early 1990s, when a code of practice for information security management was developed in the United Kingdom with input from government and large companies. It became the British Standard BS 7799 in 1995. The international community adopted that code of practice as ISO/IEC 17799 in 2000 and revised it in 2005. In 2007 it was renumbered ISO/IEC 27002 so that it would sit inside the ISO/IEC 27000 family next to ISO/IEC 27001. A second edition followed in 2013, organised into 14 control clauses with 114 controls.

The third edition, published in 2022, is a major rework rather than a light update. It regrouped the controls into four themes, reduced the number to 93 by merging related ones, added 11 controls for topics that had become important (such as threat intelligence, cloud services and secure coding), and introduced attributes – tags that let you sort and filter the controls in different ways. The title also changed: earlier editions were called a "code of practice", while the 2022 edition is simply about "information security controls", and the wider family name now includes cybersecurity and privacy protection.

What the standard is for

ISO/IEC 27002 gives a reference set of generic information security controls together with implementation guidance. It is meant for organisations of every type and size: companies, public bodies and non-profit organisations, from a ten-person start-up to a multinational. The document describes three typical ways to use it:

within an information security management system (ISMS) based on ISO/IEC 27001, as the source of guidance for selecting and implementing controls;
to implement commonly accepted security controls even without a formal ISMS, for example to raise the baseline of a small company;
as a starting point for developing organisation-specific or sector-specific guidelines, which is exactly what several other standards in the family do for cloud services, health, energy or telecommunications.

What it is not

It is important to understand from the start that ISO/IEC 27002 is guidance. Its statements use "should", not "shall". It does not tell you that you must implement any particular control, and it does not set a minimum security level. Nothing in it is a requirement that an auditor can raise a nonconformity against on its own. The decision about which controls are needed comes from your own risk assessment, your legal and contractual obligations, and your business needs. ISO/IEC 27002 then helps you understand each control and implement it well. This is why you will often hear people say that ISO/IEC 27001 tells you what management system you need and ISO/IEC 27002 helps with how to implement the controls.

The guidance is also not specific to any technology, product or vendor. It talks about malware protection, not about a particular product; about logging, not about a particular log platform. That neutrality is what keeps it usable for a decade, but it also means you always need to translate it into your own environment.

Lesson 2 – Key concepts and vocabulary

ISO/IEC 27002 relies on vocabulary that is shared across the ISO/IEC 27000 family. The official definitions live in ISO/IEC 27000 and in clause 3 of ISO/IEC 27002 itself; the explanations below are in plain words.

Information security – keeping information protected so that it stays confidential, accurate and complete, and available when needed. It covers information in any form: digital, printed, spoken or held in people's heads.
Confidentiality – information is only disclosed to people, systems or processes that are authorised to see it.
Integrity – information is accurate and complete and has not been changed in an unauthorised or accidental way.
Availability – information and the systems that hold it can be used by authorised people when they need them.
Control – a measure that maintains or modifies risk. Controls include policies, procedures, guidelines, practices, organisational structures, technical tools and physical measures.
Information security risk – the effect of uncertainty on information security objectives, usually expressed as the combination of how likely an unwanted event is and how bad its consequences would be.
Risk treatment – the decision on what to do about a risk: reduce it with controls, avoid the activity, share it with another party, or accept it knowingly.
Information security management system (ISMS) – the managed set of policies, processes, roles, resources and controls an organisation uses to keep information security risk under control and improve over time. ISO/IEC 27001 specifies its requirements.
Theme – one of the four groups into which the 2022 edition sorts its controls: organizational, people, physical and technological.
Attribute – a label attached to each control that describes it from a particular point of view, such as whether it prevents or detects problems. Attributes are written as hashtags, for example #Preventive.
Purpose – the short statement, given for every control in the 2022 edition, of why the control exists and which risk it addresses.
Information and other associated assets – the information itself plus anything that stores, processes or carries it, such as devices, software, services and facilities. The 2022 edition uses this phrase instead of simply "assets".
Statement of Applicability (SoA) – a document required by ISO/IEC 27001 listing the controls an organisation considers necessary, why, whether they are implemented, and why any reference control has been excluded.
Topic-specific policy – a policy on one subject, such as access control or backup, that sits under the overall information security policy and is approved at an appropriate level of management.

Controls are broader than technology

Many newcomers picture "security controls" as firewalls and antivirus software. ISO/IEC 27002 deliberately takes a wider view. A screening check before someone is hired, a clause in a supplier contract, a clear-desk rule, a documented operating procedure and a review by an independent party are all controls. In fact, the largest of the four themes is the organizational one. The reason is simple: most security failures involve people, processes or suppliers as much as technology, and a purely technical programme leaves those gaps open.

Guidance language

Because ISO/IEC 27002 is guidance, read its "should" statements as recommendations that a competent organisation would normally consider. You may adapt them, implement them partly, or choose a different control that achieves the same purpose, as long as your decision is reasoned and recorded. The purpose statement of each control is your best friend here: if your alternative meets the purpose, you are within the spirit of the guidance.

Lesson 3 – Structure of the standard

The overall layout

The 2022 edition has a short introductory part and a long main part. Clauses 1 to 4 explain the scope, the normative references, the terms and abbreviations, and how the document is organised. Clauses 5 to 8 contain the controls, one clause per theme. Two informative annexes complete the document: Annex A explains how to use attributes and gives the attribute values assigned to every control, and Annex B provides tables that map the 2022 controls to those of the 2013 edition and back.

Figure 1 – The 2022 edition puts its 93 controls into four theme clauses and explains attributes and the 2013 mapping in two annexes.

The four themes

The themes are defined by what a control mainly acts on. The rule is easy to remember:

People controls (clause 6, 8 controls) concern individual people: screening, terms of employment, awareness and training, disciplinary process, responsibilities after leaving or changing role, confidentiality agreements, remote working and reporting of security events.
Physical controls (clause 7, 14 controls) concern physical objects and places: perimeters, entry, offices and facilities, physical security monitoring, protection against environmental threats, clear desk and clear screen, equipment, storage media, supporting utilities, cabling and secure disposal or reuse of equipment.
Technological controls (clause 8, 34 controls) concern technology: endpoint devices, privileged access, authentication, malware protection, vulnerability and configuration management, backup, logging and monitoring, network security, cryptography, secure development and testing, change management and more.
Organizational controls (clause 5, 37 controls) are everything else: policies, roles, segregation of duties, threat intelligence, asset inventory, classification, access control rules, supplier and cloud security, incident management, continuity, legal and privacy obligations, and independent review.

Controls are numbered by clause and position: 5.1 is the first organizational control, 8.34 the last technological one. The numbering in ISO/IEC 27001:2022 Annex A follows the same scheme with an "A." prefix, so A.8.13 in ISO/IEC 27001 and 8.13 in ISO/IEC 27002 are the same control, Information backup. This one-to-one alignment is deliberate and very practical: the short statement in ISO/IEC 27001 tells you what the control is, and the matching entry in ISO/IEC 27002 explains it in depth.

The layout of every control

Each of the 93 controls follows the same pattern, which makes the document easy to scan once you know it:

A control title, the short name of the control.
An attribute table showing the hashtag values of the control for each of the five attribute types.
The control itself, a brief description of what should be in place.
The purpose, explaining why the control is implemented.
The guidance, describing how the control can be implemented, often with lists of topics to consider.
Other information, with explanatory notes, legal or technical considerations and references to related standards.

Figure 2 – Every control has the same six-part layout, so readers always find the "what", the "why" and the "how" in the same place.

The purpose element is new in the 2022 edition and very useful. In earlier editions controls were grouped under objectives; now each control carries its own reason. When you need to decide whether a partial or alternative implementation is acceptable, you test it against the purpose.

Attributes: five ways to look at the same control

Grouping 93 controls into four themes is only one possible view. A security operations team may want to see all detective controls; a risk manager may want everything that protects integrity; a team that reports using the NIST Cybersecurity Framework may want controls sorted by its functions. The 2022 edition therefore tags every control with values from five attribute types:

Control type – when the control acts relative to an incident: #Preventive, #Detective or #Corrective.
Information security properties – which property it helps preserve: #Confidentiality, #Integrity, #Availability.
Cybersecurity concepts – the five concepts also used in ISO/IEC TS 27110 and in the functions of the NIST Cybersecurity Framework: #Identify, #Protect, #Detect, #Respond, #Recover.
Operational capabilities – the practitioner's area the control belongs to. There are 15 values, such as #Governance, #Asset_management, #Identity_and_access_management, #Threat_and_vulnerability_management, #Continuity and #Supplier_relationships_security.
Security domains – four broad areas: #Governance_and_Ecosystem, #Protection, #Defence and #Resilience.

Figure 3 – Five attribute types tag every control, so the same catalogue can be filtered by timing, property, concept, capability or domain.

A control usually carries several values within one attribute type. Threat intelligence (5.7), for example, is tagged as preventive, detective and corrective, because good intelligence helps you avoid attacks, spot them and respond to them. Annex A explains that attributes are a tool, not a requirement: you can ignore them, use only some, or create your own attribute types – for instance one that marks which controls apply to a particular product line or which ones a specific regulator cares about.

What changed from the 2013 edition

If you meet older documentation, it helps to know the main differences. The 2013 edition had 114 controls in 14 clauses (numbered 5 to 18). The 2022 edition has 93 controls in four themes. Of these, 11 are new, 24 were formed by merging two or more older controls, and 58 were carried over with updated wording or guidance. The new controls are 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). Annex B gives the full mapping so that teams can carry their old work across instead of starting again.

Lesson 4 – How it works in practice

Where the guidance fits in an ISMS

ISO/IEC 27002 is most often used inside an ISMS that follows ISO/IEC 27001. ISO/IEC 27001 is a requirements standard: it says an organisation must understand its context, set a scope, get leadership commitment, assess and treat risks, run its processes, measure performance and improve. During risk treatment it requires the organisation to determine the controls it needs, compare them with the reference list in its Annex A so that nothing necessary is overlooked, and produce a Statement of Applicability. ISO/IEC 27002 supports every step in which controls are chosen, designed, implemented and checked.

Figure 4 – Risk drives which controls are needed; ISO/IEC 27002 guides how they are implemented, and results feed the next round of risk assessment.

Step 1 – Understand the risks first

The single most important habit is to start from risk, not from the catalogue. List the information that matters, where it lives and who handles it; identify what could go wrong; estimate likelihood and impact; and decide which risks need treatment. ISO/IEC 27005 gives detailed guidance on this process. When you know that, for example, your biggest risks are ransomware on file servers and leakage of customer data through misconfigured cloud storage, you know which parts of ISO/IEC 27002 deserve the most attention.

Step 2 – Determine the controls

For each risk that you decide to reduce, identify controls that would bring it down to an acceptable level. Controls may come from your own ideas, from industry rules, from customer contracts, or from ISO/IEC 27002. Then compare your list with the 93 reference controls. This comparison is a safety net: it reveals things you forgot, such as information deletion when contracts end or clock synchronisation for useful logs. If a reference control is not needed, record why – for example, "no physical offices; staff work remotely, so physical entry controls for offices are not applicable; data centre controls are covered by the cloud provider's assurance reports".

Step 3 – Use attributes to organise the work

Attributes help you split the work sensibly. A security operations lead can filter for #Detective controls and #Information_security_event_management to see what the monitoring function owns. A head of infrastructure can take #System_and_network_security and #Secure_configuration. A chief information security officer reporting to a board that thinks in NIST CSF functions can group the same controls by cybersecurity concept. One catalogue, several views, no duplicated spreadsheets.

Step 4 – Design and implement each control

For each selected control, read the purpose and the guidance and design an implementation that fits your environment. A good control design answers six questions: what exactly is done, by whom, how often or on what trigger, using which tools, with which records as evidence, and how you will know whether it works. The guidance often lists topics that a policy or procedure should cover; treat those lists as prompts for your own design, not as text to paste.

Many controls need a supporting document. The 2022 edition expects an overall information security policy plus topic-specific policies where appropriate, such as access control, backup, cryptography, secure development or supplier security. Keep these short, practical and owned by someone who can actually enforce them.

Step 5 – Assign roles

Controls fail when nobody owns them. Typical roles are:

a control owner who is accountable for the control working, usually a manager in the area concerned (HR for screening, IT operations for backups, procurement for supplier agreements);
an operator who performs the control day to day;
the information security function, which coordinates, advises and maintains the overall picture;
top management, which approves policies, provides resources and accepts residual risks;
internal audit or another independent party, which checks whether controls are designed and working as intended.

Step 6 – Measure, review and improve

A control that was configured once and never looked at again tends to decay. Decide how each important control will be monitored: a backup restore test each quarter, a monthly review of privileged accounts, a dashboard of patch compliance, a sample check of supplier assessments. Feed the results into management review and the next risk assessment. When incidents happen, ask which control failed or was missing and update your design. Control 5.27 on learning from incidents and control 5.35 on independent review exist precisely to keep this loop turning.

Using the guidance without an ISMS

Not every organisation needs or wants a formal ISMS. A small company can still use ISO/IEC 27002 as a structured checklist of good practice: pick the controls that address its main risks, implement them sensibly, and review them yearly. The guidance does not depend on certification. The main thing you lose without an ISMS is the management discipline – risk assessment, objectives, internal audit and management review – that keeps controls relevant over time.

Lesson 5 – Assessment, certification and compliance

No certification against ISO/IEC 27002 itself

Organisations cannot be certified to ISO/IEC 27002. Because it contains guidance and recommendations rather than requirements, there is nothing objective for a certification body to test conformity against. Accredited certification exists for ISO/IEC 27001, the ISMS requirements standard, and ISO/IEC 27002 enters the picture because the Annex A controls of ISO/IEC 27001 are drawn from it. When a company says it is "ISO 27002 compliant", treat it as a claim that it has used the guidance, not as an independently certified status, and ask what evidence supports it.

Some training organisations offer personnel courses and certificates on ISO/IEC 27002. These attest that an individual has studied the standard; they say nothing about whether any organisation has implemented it.

How auditors use the guidance in an ISO/IEC 27001 audit

In an ISO/IEC 27001 certification audit, the auditor checks the ISMS requirements and samples the controls listed in the Statement of Applicability. Auditors do not raise nonconformities for "not following ISO/IEC 27002 guidance", because the guidance is not mandatory. They do, however, use it as a reference for what a reasonable implementation looks like. If your SoA says that logging (8.15) is implemented, an auditor may ask what events you log, how logs are protected against tampering, how long they are kept and who reviews them – questions that come straight from the topics the guidance discusses. A reasoned design that meets the control's purpose is fine even if it differs from the guidance; an unexplained gap is what causes trouble.

Assessing control effectiveness

Whether you are an internal auditor, a consultant or a team doing a self-assessment, the same basic approach works for any control:

Design review – does the documented control address the purpose and the risks it was selected for? Are responsibilities, frequency and evidence defined?
Implementation check – does the control exist in reality? Inspect configurations, observe the process, interview the people who run it.
Operating effectiveness – has it worked consistently over a period? Sample records: tickets, review sign-offs, restore test results, training completion data.
Outcome – is the risk actually lower? Look at incidents, near misses, metrics and trends.

Many organisations use a simple maturity-style rating for each control, such as "not implemented, partly implemented, implemented, measured and improved". Note that ISO/IEC 27002 does not define such a scale; it is an organisation's own choice. Guidance on auditing controls is available in companion documents of the family, such as ISO/IEC TS 27008 on assessing information security controls and ISO/IEC 27007 on auditing management systems.

Compliance with laws, regulations and contracts

Several controls address legal and contractual obligations directly: identifying applicable legal, statutory, regulatory and contractual requirements (5.31), intellectual property rights (5.32), protection of records (5.33), privacy and protection of personal data (5.34) and compliance with the organisation's own policies (5.36). Implementing ISO/IEC 27002 does not automatically make you compliant with any law. It gives you a structured way to identify obligations and to build the controls and evidence that regulators and customers expect. Many regulators and customer questionnaires refer to ISO/IEC 27001 and 27002, so a well-documented control set saves a great deal of repeated effort.

Mapping to other frameworks

Because the controls are generic, they map reasonably well to other frameworks. The cybersecurity-concept attribute already lines up with the five functions of NIST CSF version 1.1; NIST CSF 2.0, published in 2024, added a sixth function, Govern, which corresponds broadly to controls tagged with the governance capability or domain. Published crosswalks also relate ISO/IEC 27002 controls to NIST SP 800-53 and to the CIS Controls. Mappings are approximations: two controls with similar names may differ in depth or emphasis, so always read both sides before claiming coverage.

Lesson 6 – Worked example

The organisation

Brightline Freight Software is a fictional company with 220 employees in two offices. It sells a cloud-hosted shipment tracking platform to logistics firms and retailers. The platform runs on a major public cloud, its developers ship code several times a day through a CI/CD pipeline, and customer support staff can see shipment and contact data for millions of parcels. Two large customers have asked for ISO/IEC 27001 certification within a year, and a new US customer wants the security programme described in NIST CSF terms.

Step 1 – Scope and risks

The new security lead, Amara, agrees with management that the ISMS scope will cover the tracking platform, its development and operations, customer support and the supporting corporate IT. A two-day risk workshop with engineering, support, HR, legal and finance produces a risk register. The top risks are:

unauthorised access to customer shipment data through stolen developer or support credentials;
leakage of personal data through support staff exporting reports to personal storage;
ransomware or destructive error affecting production data, with slow recovery;
vulnerable code or third-party libraries reaching production;
a critical cloud or software supplier failing or being compromised.

Step 2 – Determining and cross-checking controls

For each risk the team lists controls. For stolen credentials they choose stronger authentication, tighter privileged access and better monitoring. In ISO/IEC 27002 terms, these are secure authentication (8.5), privileged access rights (8.2), access rights (5.18), identity management (5.16) and monitoring activities (8.16). For leakage by support staff they pick classification of information (5.12), acceptable use (5.10), data leakage prevention (8.12), awareness training (6.3) and data masking (8.11) in the support tool. For ransomware and errors: information backup (8.13), protection against malware (8.7), ICT readiness for business continuity (5.30) and redundancy (8.14). For vulnerable code: secure development life cycle (8.25), secure coding (8.28), security testing (8.29), management of technical vulnerabilities (8.8) and change management (8.32). For suppliers: the group of controls 5.19 to 5.23, including cloud services.

Amara then walks through all 93 reference controls with the team. The cross-check reveals gaps nobody had raised: there is no process to delete customer data when contracts end (8.10), server clocks are not synchronised so logs from different systems are hard to correlate (8.17), and nobody collects threat intelligence about attacks on logistics platforms (5.7). These controls are added. Two controls are judged not applicable in their full form – the company hosts nothing in its own data centre, so most equipment-siting guidance applies only to the offices – and the justification is written into the Statement of Applicability.

Step 3 – Building attribute views

Amara loads the selected controls and their attributes into a simple spreadsheet. She creates three views. The first groups controls by operational capability and assigns an owner per capability: the platform lead owns secure configuration and system and network security, the HR manager owns human resource security, the procurement manager owns supplier relationships security. The second view filters for #Detective and #Corrective controls; it becomes the scope of the small security operations function. The third groups controls by cybersecurity concept and, with a governance group added, becomes the basis of the NIST CSF style summary for the US customer. She also adds one attribute of her own, #Customer_facing, marking controls that customers ask about in questionnaires, so answers can be reused.

Step 4 – Implementing one control in depth

Take data leakage prevention (8.12). Reading its purpose, the team notes that the aim is to detect and prevent unauthorised disclosure and extraction of information by people or systems. The guidance points them towards identifying which information needs protection, the channels through which it could leak and the measures that fit each channel. Their design:

What: block export of full customer data sets from the support tool; mask phone numbers and addresses by default; allow full export only through an approved, logged request.
Who: the support team lead approves exceptions; the platform team maintains the technical rules; the security function reviews alerts weekly.
Tools: the support tool's role settings, the cloud provider's storage access logs and the endpoint management agent that blocks uploads to unapproved personal storage.
Evidence: configuration screenshots and exported settings, the exception request tickets, weekly alert review notes.
Measure: number of blocked export attempts, number of approved exceptions and time to close alerts, reported monthly.

The team writes a one-page topic-specific policy on handling customer data in support, and the awareness training (6.3) for support staff explains why exports are restricted and how to request an exception. Linking the people control to the technical one matters: staff who understand the reason are less likely to look for workarounds.

Step 5 – Checking and improving

After three months, an internal auditor samples ten exception requests and finds two without recorded approval. The root cause is that a manager approved them in chat instead of in the ticket. The process is changed so that the export button only works after the ticket status shows approval. In the same review, a restore test reveals that one database backup could be restored but took nine hours, far beyond the recovery objective agreed with customers. The team adds a faster restore method and updates the continuity plan. Both findings go into the management review and the next risk assessment.

Step 6 – Certification

Ten months after the start, an accredited certification body carries out the two-stage ISO/IEC 27001 audit. The auditors review the SoA, sample controls and ask detailed questions about logging, supplier assessments and the data leakage design. They raise one minor nonconformity about incomplete records of awareness training for new starters, which the company corrects. Brightline is certified to ISO/IEC 27001; its use of ISO/IEC 27002 shows in the quality of its control designs and evidence, not in a separate certificate.

What the example teaches

The example shows the core pattern: risks lead to controls, the full catalogue acts as a safety net, attributes divide the work and create the views different audiences need, and each control is turned into a concrete design with an owner, evidence and a measure. It also shows that controls from different themes work together – a technical rule, a policy, training and a supplier contract often address one risk jointly.

Lesson 7 – Relationship to other standards and frameworks

ISO/IEC 27002 sits in the middle of a large family. Understanding its neighbours helps you pick the right document for each question.

Standard or framework	Owner	What it is	Relationship to ISO/IEC 27002
ISO/IEC 27001:2022	ISO/IEC JTC 1/SC 27	Requirements for an information security management system; certifiable	Its Annex A lists the same 93 controls in brief; ISO/IEC 27002 gives the guidance behind them
ISO/IEC 27005:2022	ISO/IEC JTC 1/SC 27	Guidance on managing information security risks	Produces the risk picture that decides which ISO/IEC 27002 controls are needed
ISO/IEC 27017 and ISO/IEC 27018	ISO/IEC JTC 1/SC 27	Codes of practice for cloud services and for protecting personal data in public clouds	Take the ISO/IEC 27002 controls as a base and add cloud-specific guidance and extra controls
ISO/IEC 27701	ISO/IEC JTC 1/SC 27	Requirements and guidance for a privacy information management system	Adds the management of personal data (PII); its privacy controls complement the security controls of ISO/IEC 27002
NIST Cybersecurity Framework 2.0	NIST (USA)	Outcome-based framework of six functions: Govern, Identify, Protect, Detect, Respond, Recover	The cybersecurity-concept attribute aligns with its functions; often used together for reporting
NIST SP 800-53 Rev. 5	NIST (USA)	Detailed catalogue of security and privacy controls, widely used in US government	Similar purpose with more detailed, more prescriptive controls; crosswalks exist
CIS Critical Security Controls v8.1	Center for Internet Security	Prioritised set of technical safeguards with implementation groups	Narrower and more technical; useful to prioritise the technological controls of ISO/IEC 27002

Sector-specific extensions

Several standards apply the ISO/IEC 27002 control set to a particular sector. ISO 27799 does this for health information, ISO/IEC 27019 for the energy utility industry and ISO/IEC 27011 for telecommunications organisations. Each keeps the general control structure and adds sector guidance. After the 2022 reorganisation, these companion documents have been, or are being, revised so that they follow the new numbering; when you use one, check which edition of ISO/IEC 27002 it is based on.

Choosing the right document

Use ISO/IEC 27001 when you need a management system and a certificate; ISO/IEC 27002 when you need to understand and implement controls; ISO/IEC 27005 when you need a robust risk method; the cloud and privacy codes when those topics dominate; NIST CSF when you need a concise, outcome-based way to talk to executives or US partners; NIST SP 800-53 when you work with US federal systems or need very detailed control statements; and the CIS Controls when you want a prioritised technical starting point. These are not competitors so much as layers, and mature organisations often map one set of controls to several frameworks at once.

Common pitfalls and best practices

Common pitfalls

Treating the catalogue as a checklist to complete. Teams try to implement all 93 controls to the same depth, burn out, and still miss the risks that matter most. The catalogue is a reference; risk decides priorities.
Claiming "certified to ISO 27002". There is no such certification for organisations, and customers or auditors who know the family will lose trust in other claims too.
Copying guidance text into policies. Policies that repeat generic guidance do not describe what your organisation actually does, are hard to follow and may also infringe copyright.
Ignoring the non-technical themes. Programmes led only by IT often neglect screening, supplier agreements, disciplinary processes or physical security, which then become audit findings or real incidents.
Keeping a 2013-based control list after the move to 2022. Old numbering and missing new controls such as configuration management or secure coding cause confusion with auditors and customers.
Controls without owners or evidence. A control that nobody owns and that leaves no records cannot be shown to work, even if it does.

Best practices

Start from risk and use the catalogue as a safety net. Determine controls from risks first, then compare with all 93 to find gaps.
Read the purpose before the guidance. It tells you what the control is trying to achieve and helps you judge alternative designs.
Use attributes to create views for each audience. Owners, security operations, executives and customers need different cuts of the same control set; add your own attributes where helpful.
Design every control with owner, frequency, tools, evidence and a measure. This makes controls auditable and keeps them alive.
Combine controls across themes. Pair technical measures with policy, training and supplier terms that address the same risk.
Review regularly and learn from incidents. Test controls, sample evidence, and feed results into management review and the next risk assessment.

Summary and key takeaways

ISO/IEC 27002:2022 is a guidance document with a reference set of 93 information security controls and implementation advice; it uses "should", not "shall".
The controls are grouped into four themes – organizational (37), people (8), physical (14) and technological (34) – and numbered to match ISO/IEC 27001 Annex A.
Each control has a title, attribute table, control statement, purpose, guidance and other information; the purpose is the test for any alternative design.
Five attribute types – control type, information security properties, cybersecurity concepts, operational capabilities and security domains – let you filter and group controls, and you can add your own.
Controls are chosen through risk treatment, compared with the full catalogue so nothing is missed, and recorded in the Statement of Applicability.
Organisations are certified against ISO/IEC 27001, not ISO/IEC 27002; auditors use the guidance as a reference for reasonable implementation.
Good implementation means owners, evidence, measures and regular review, with technical, people, physical and organizational controls working together.
Neighbours such as ISO/IEC 27005, the cloud and privacy codes, NIST CSF, NIST SP 800-53 and the CIS Controls complement rather than replace it.

Reflection questions

Pick one of your organisation's top three information risks. Which ISO/IEC 27002 controls, from at least two different themes, would you combine to treat it, and why?
Choose a control that your team already operates. How would you describe its owner, frequency, tools, evidence and measure, and which of these is currently weakest?
Which attribute view would be most useful for your manager or for your main customer, and what extra attribute of your own would you create?
Find a reference control that you think does not apply to your organisation. How would you justify that decision to an auditor in two or three sentences?
If a supplier tells you it "complies with ISO 27002", which questions and pieces of evidence would you ask for before relying on that statement?