< Previous standard ^ Up a level ^ Next standard >
ISO/IEC 27002:2022 — Information security, cybersecurity and privacy protection — Information security controls (third edition)
“This document provides a reference set of generic information security controls including implementation guidance. This document is designed to be used by organisations: (a) within the context of an information security management system (ISMS) based on ISO/IEC27001; (b) for implementing information security controls based on internationally recognized best practices; (c) for developing organisation-specific information security management guidelines.”
[Source: ISO/IEC 27002:2022]
ISO/IEC 27002 is a popular international standard describing a generic selection of ‘good practice’ information security controls, typically used to mitigate unacceptable risks to the confidentiality, integrity and availability of information.
Its lineage stretches back more than 30 years to the precursors of BS 7799.
ISO/IEC 27002 is an advisory document, a recommendation rather than a formal specification such as ISO/IEC 27001. Organisations are advised to identify and evaluate their own information risks, selecting and applying suitable information security controls to mitigate unacceptable risks using ISO/IEC 27002 and other relevant standards and sources for guidance.
Like governance and risk management, information security management is a broad topic with ramifications for all organisations. Information security, and hence ISO/IEC 27002, is relevant to all types of organisation including commercial enterprises of all sizes (from one-man-bands up to multinational giants), not-for-profits, charities, government departments and quasi-autonomous bodies - in fact any organisation that handles and depends on information. The specific information risks and hence control requirements differ in detail but there is a lot of common ground, for instance most organisations need to address information risks relating to their employees plus contractors, consultants and third party suppliers of various information and IT services such as cloud computing.
The standard is explicitly concerned with information security, meaning the security of all forms of information (e.g. computer data, documentation, knowledge and intellectual property) and not just IT/systems/network/cyber security.
The standard lays out a ‘reference set’ of 93 generic information security controls and implementation guidance, categorised into 4 clauses based around these ‘themes’:
- organisational controls - a large and misleadingly-named catch-all group of 37 controls that don’t fit neatly into the remaining themes;
- People controls - 8 controls involving or relating to people e.g. individuals’ behaviors, activities, roles and responsibilities, terms and conditions of employment etc.;
- Physical controls - 14 tangible controls to secure tangible [information] assets;
- Technological controls - 34 controls involving or relating to technologies, IT in particular.
The 93 controls are each tagged with one or more values from each of 5 ‘attributes’ so they can be grouped or selected in other ways too:
- Control type: preventive, detective and/or corrective;
- Information security properties: confidentiality, integrity and/or availability;
- Cybersecurity concepts: identify, protect, detect, respond and/or recover;
- Operational capabilities: governance, asset management, information protection, human resource security, physical security, system and network security, application security, secure configuration, identity and access management, threat and vulnerability management, continuity, supplier relationships securit, legal and compliance, information security event management, and information security assurance.
- Security domains: governance and ecosystem, protection, defence and resilience.
This makes the standard even more complicated but reflects these complexities:
- A given control may have several applications (e.g. backups help protect against malware, hacks, bugs, accidents, mechanical breakdowns, fires etc., and can include deputies and multi-skilled replacements for critical people, and alternative suppliers/sources of necessary information services, as well as data backups);
- Any given application or situation typically requires several controls (e.g. malware can be mitigated using backups, awareness, antivirus, network access controls plus IDS/IPS, authentication, patching, testing, system integrity controls etc., while avoiding infection can be a powerful approach if bolstered with controls such as policies and procedures, blacklisting etc.);
- Many of the controls we commonly consider (e.g. backups) are not atomic, being composed of several smaller elements or pieces (e.g. backups involve strategies, policies and procedures, software, hardware, testing, incident recovery, physical protection of backup media etc.).
Some of the themes and attributes are arbitrarily assigned: for example, a commercial card access lock on a building entrance may fall into any, arguably all four of the themes listed above, but if it and other such controls were covered several times, the standard would become unwieldy. More likely, it would be categorised as a physical control, possibly with references to other elements.
Organisations can define their own attributes as well.
Relationship to ISO/IEC 27001
An Information Security Management System as specified in ISO/IEC 27001 is a systematic approach to managing information risks, including the multitude of information security controls required to mitigate unacceptable risks, and other risk treatments such as avoidance.
ISO/IEC 27001 Annex A summarises the information security controls from [the second edition of] ISO/IEC 27002 on the basis that they are generally applicable good practices, worth considering. However, organisations are free to implement whichever controls they feel are appropriate for their information risks, and may prefer/need different controls, even entirely different control suites [such as the new third edition of ISO/IEC 27002]. In practice, most organisations that adopt ISO/IEC 27001 also use Annex A and hence ISO/IEC 27002 as a general framework or structure for their controls, making various changes as necessary to suit their specific information risk treatment requirements.
Status of the standard
The first edition was published in 2005.
The second edition was published in 2013.
The completely restructured and updated third edition was published in February 2022.
There are officially 21 fewer controls in the third edition than the second despite adding 11 new controls. Several second edition controls have been updated or merged. The actual control count is far higher (a few hundred) if you distinguish all the ‘atomic controls’ mentioned in or implied by the details.
During the multi-year revision project, more than 10,000 comments were submitted by about 200 experts representing standards bodies around the globe, requiring a massive editorial effort to collate them, discuss, draft, review and eventually accept various amendments. The team of 3 editors have done a fantastic job, keeping this project on track.
An amendment to ISO/IEC 27001 will replace Annex A with one that aligns with the 2022 version of ISO/IEC 27002, some time this year.
Other ISO27k standards based on ISO/IEC 27002 will also need to be updated in due course. Given the extensive changes in ‘27002, it will take SC 27 some time to work through them all, so the rough plan is first to update 27009, 27011 and 27017, then 27000, 27003, 27019 and 27103, followed by 27004, 27008, 27010 and the rest. 27701 and 27799 are conspicuously absent from the list at this point, but SC 27’s plans are hard to fathom.
ISO/IEC 27002 ISMS implementation guides
Note: these currently refer to the second edition & need to be updated.
A collection of ISMS implementation guidelines and sample documents is available to download in the free ISO27k Toolkit, and implementation tips are sprinkled liberally throughout our ISO27k FAQ.
ISO/IEC 27003 provides generic ISMS implementation guidance, focusing on the management system rather than the security controls.
There are also a few ‘sector-specific’ ISMS implementation guidelines i.e. ISO/IEC 27011 for the telecomms sector, ISO 27799 for healthcare and ISO/IEC 27019 for the energy utilities sector.
In my considered opinion, one of the most distinctive, innovative and valuable features of the original Shell policy manual, the UK DTI Code of Practice/DISC standard PD003 and British Standard BS 7799 was that they explicitly addressed information security, recommending approaches and controls to secure information in any form - not just computer data, systems, apps, networks and technologies. The focus was clearly on protecting the intangible, vulnerable and valuable information content.
Over the years since ISO/IEC adopted it as an international standard, it has gradually evolved into a tech-centric IT, ICT or cyber-security standard. The third edition of ‘27002 continues along the same trajectory, as indicated by the relative proportions of the blobs on the diagram above.
The third edition misses numerous opportunities to encourage users to consider their “information risks” in order to determine whether various controls are even needed to avoid or mitigate the risks, and if so what controls are appropriate, taking account of their effectiveness, costs, value, reliability etc. It is as if the controls laid out in the standard are not merely good practices worth considering under various circumstances, but required or mandatory to the extent that not implementing them might perhaps be considered inept, unprofessional or bad practice. There is a subtle presumption that most if not all the controls should be employed by all organisations, regardless of the diversity of organisations in scope and their differing information risks.
I miss the ‘control objectives’ from BS 7799: these succinctly explained what the controls were expected to achieve, giving them a business-related purpose that was readily interpreted in the particular context of an individual organisation. If management accepted that an objective was valid, the controls were worth considering not in the sense of being obligatory or even recommended, so much as examples of the kinds of things that could be put in place to achieve the objective. In the third edition, the risk-based control objectives have become watered-down and often self-serving ‘purposes’, with little to no explicit reference to the organisation’s information risks that the suggested controls are supposed to mitigate - a retrograde step as far as I’m concerned ... potentially presenting an opportunity to fill in the gaps (watch this space!). However, some experts complained of ‘challenging conversations’ between auditors and management: I suspect the underlying issue there was a failure to understand the true nature of information risk and risk treatment options.
While the restructured standard is readable and usable on paper, the tagging and cross-linking strongly of controls favours database applications (even something as simple as Excel) allowing users to filter or select and sort the controls by whatever criteria or questions they pose - for instance, “Which physical security controls are relevant to privacy?” or “What preventive controls do not involve technology?”. Given a suitable database application, the sequence is almost irrelevant compared to the categorisation, tagging and description of the controls. It will be interesting to see how this turns out.
I am dismayed that the standard has been infected with the “cyber” virus, almost immediately creating problems of definition and interpretation. Some contributors want the standard to cover both information security and cybersecurity controls, implying that they consider those to be distinct domains, while others first want to understand the differences before classifying controls ... and I must say I‘m in the second group. What is the meaning and scope of “cybersecurity”, in fact? Let’s start there, eh, SC 27, before jumping aboard the bandwagon!
Similarly, the committee hopes to resolve confusion over the meaning of “policy” in the second edition by distinguishing three variants or hierarchical levels in the third edition:
- “Information security policy” is the overall, high-level corporate policy at the peak of the classical policy pyramid, approved by ‘top management’;
- “Topic-specific policy” is the term for mid-level policies e.g. topic-specific policies on access control and clear desk and clear screen” (the latter sounds, to me, more like a rule than a mid-level policy ... and indeed, as expressed by the project team, the topic-specific policy concept includes guidelines and rules, making this layer a blend, transition or link between the upper and lower levels). These will be aligned with and support the high level policy, approved by ‘the appropriate management level’, and [within reason] may be adapted/interpreted locally by departments, business units etc. where their specific contexts (information risks, security requirements, business situations, locations etc.) differ from the overall corporate context;
- “Rule” is the lowest, most detailed/specific level, defined as an “accepted principle or instruction that states the organisation’s expectations on what should be done, what is allowed or not allowed” (I’m not sure an organisation, per se, can ‘expect’ anything, or should have expectations on rather than of something: in a corporate context, rules are generally imposed by management on behalf of the organisation and its stakeholders ... but this definition has been a bone of contention on the project so, assuming the compromise is generally accepted, it’s good enough. Time to move on!).
< Previous standard ^ Up a level ^ Next standard >