ISO 27002:2022 in 2026: 93 controls, 4 groups, attributes and implementation guidance

What ISO 27002 is: its relationship with 27001

The full title is Information security, cybersecurity and privacy protection - Information security controls ^[1]. The name is informative here: the document imposes no requirement that has to be proven, but describes what each control consists of and how it can be implemented.

The relationship with ISO 27001 comes down to one distinction. ISO 27001 sets out how to build and maintain an information security management system, and its Annex A lists 93 controls in one sentence each. ISO 27002 takes the same list and, for each item, adds a purpose, implementation guidance and context. Only 27001 is certified; there is no such thing as a certificate of "conformity with ISO 27002".

One small point is worth clearing up at once, because a great many documents blur it. The A-prefixed numbering - A.5, A.6, A.7, A.8 - comes from Annex A of ISO 27001. ISO 27002 itself numbers the same controls as clauses 5 to 8, without the prefix. The correspondence is one to one, so in practice both conventions point to the same thing, but internal documentation is better off sticking to one. In the rest of this article we use the Annex A notation, because it is more common in Polish implementations.

Where it came from

The standard has its roots in the British BS 7799 of the 1990s. In 2000 its first part reached ISO as ISO/IEC 17799; in 2005 it was updated to align with the newly published ISO/IEC 27001:2005; and in 2007 it was renumbered to ISO/IEC 27002 to fit into the 27000 series. The 2013 edition brought a substantial content update, and the 2022 edition the structural rebuild described below.

Status and place in regulation

The standard is international, developed jointly by ISO and IEC, and entirely voluntary. No rule mandates its use. There is, however, one exception worth noting, because it is often described imprecisely: the Polish KRI regulation, in § 19(3), names PN-ISO/IEC 27002 as one of the standards whose application allows the requirements for an information security management system to be treated as met. That is a presumption of conformity, not a mandate.

Neither the Polish KSC act nor the NIS2 directive contains such a reference - they name areas of security, not standards. ISO 27002 is useful there as evidential material during an inspection, but not as a legal basis.

What it is actually used for

Most often it serves as an implementation manual: a team takes a control from Annex A, reads the corresponding 27002 clause and designs its own procedure on that basis. The second typical use is auditing, where the standard is the reference point for judging whether a control was implemented properly or merely described. The third is gap analysis, because a catalogue of 93 items provides a ready checklist to compare against reality. Beyond that it serves as training material and as a shared vocabulary in conversations with suppliers, where citing a specific control number is more precise than a descriptive contractual requirement.

Changes in the 2022 edition

The 2022 reorganisation abandoned the thematic split in favour of a split by who or what delivers the control. The previous edition grouped 114 controls into fourteen chapters devoted in turn to access control, cryptography, physical security and so on. The current edition has four groups: organisational (37 controls), people (8), physical (14) and technological (34).

The change from 114 to 93 does not mean anything was given up. No control was removed - some were merged because they addressed the same issue from two sides, and some were reworded. The practical consequence is that an organisation migrating from the 2013 edition does not have to hunt for what fell out, only to map the old items onto the new.

Eleven new controls

The new items answer what changed in practice between 2013 and 2022: the cloud, working with data at scale, and a more mature approach to detection.

1. A.5.7 Threat intelligence - obtaining and using information about threats.
2. A.5.23 Information security for use of cloud services. The control itself is short; the expansion is in ISO/IEC 27017 ^[9], and an independent control catalogue for cloud is the Cloud Controls Matrix ^[12].
3. A.5.30 ICT readiness for business continuity - readiness of systems to support continuity.
4. A.7.4 Physical security monitoring - monitoring of physical areas.
5. A.8.9 Configuration management.
6. A.8.10 Information deletion - deleting information once it is no longer needed.
7. A.8.11 Data masking.
8. A.8.12 Data leakage prevention.
9. A.8.16 Monitoring activities - monitoring activity in systems and on the network.
10. A.8.23 Web filtering.
11. A.8.28 Secure coding.

Four of them - threat intelligence, monitoring activities, leakage prevention and secure coding - are the ones most often skipped, because they require a working process rather than a document.

Attributes as a second axis of description

The second novelty is attributes: metadata assigned to each control across five dimensions - control type, the information property protected, the function in NIST CSF terms, the operational capability and the security domain. They do not change the content of the controls, but they let the catalogue be viewed from different angles - filtering everything that serves detection, say, or counting what share of the portfolio concerns the supply chain. Detail follows below.

The structure of a control: statement, purpose, guidance

Each of the 93 controls is described to the same schema, made up of four parts and a table of attributes. The uniformity is deliberate: an auditor knows where to look, and an implementation team can reuse the same layout in its own documentation.

The first part is the control itself - one normative sentence saying what is to be done. For A.8.13, on backups, it reads: "Backups of information, software and systems shall be maintained and regularly tested in accordance with the agreed topic-specific policy on backup". That sentence usually goes straight into the statement of applicability.

The second is the purpose, explaining what the control protects against. For backups it is terse: "To enable recovery from loss of data or systems". The third, and largest, is the implementation guidance. For A.8.13 it covers backup scope and frequency, retention period, restore testing, protection against modification, storage away from the primary location, encryption, and documentation of procedures and roles. The fourth part, other information, gives context and cross-references to other standards.

That structure explains why ISO 27001 alone is not enough to implement anything. The sentence about backups sounds obvious until somebody has to answer what "regularly tested" means and how to prove it.

Attributes: five dimensions of description

Attributes are an optional but very practical addition. The standard proposes five dimensions, and an organisation may add its own.

Control type

Distinguishes preventive, detective and corrective controls. The split is not exclusive: a backup prevents data loss and simultaneously allows the effects of an incident to be undone, so it carries two types at once. A sensible control portfolio has all three - a preponderance of preventive controls with no detective ones describes an organisation that will not learn what got past it.

Information security properties

The classic triad: confidentiality, integrity and availability. This dimension is often the most instructive in a review, because it exposes the usual tilt towards confidentiality at the expense of integrity - there is usually plenty of encryption and access control, and far less in the way of detecting unauthorised modification.

Cybersecurity concepts in NIST CSF terms

A mapping to the functions of the NIST Cybersecurity Framework ^[4]: identify, protect, detect, respond and recover. Thanks to it the same control portfolio can be presented to the board in CSF language without maintaining two separate registers.

Operational capabilities

The most detailed dimension, covering fifteen categories matching the areas a team works in: 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 security, legal and compliance, information security event management, and information security assurance. This dimension is the best fit for assigning controls to owners.

Security domains

Four strategic domains: governance and ecosystem, protection, defence and resilience. They work well in board-level reporting, where the proportion between them matters more than individual items.

The practical value of attributes shows in three tasks: filtering the catalogue by a chosen perspective, reporting coverage by domain, and mapping onto other models including the CIS Controls ^[5]. In each of those uses attributes replace a hand-maintained crosswalk table, which in most organisations goes out of date after the first review.

A.5 Organisational controls (37)

The largest group, covering what an organisation establishes and enforces at the level of rules: policies, roles, information classification, access control, supplier relationships, incident handling, business continuity and legal compliance. The overview below keeps the order of the standard.

A.5.1 to A.5.8 Policies, roles and governance

• A.5.1 Policies for information security - an overarching policy plus topic-specific ones, for instance on cryptography or access control. See the information security policy.
• A.5.2 Information security roles and responsibilities - roles assigned by name, not to a department.
• A.5.3 Segregation of duties - separating duties whose combination allows abuse to go undetected.
• A.5.4 Management responsibilities - management's duty to enforce the rules.
• A.5.5 Contact with authorities - established contacts with authorities, including the CSIRT and the data protection authority.
• A.5.6 Contact with special interest groups - participation in industry information exchange.
• A.5.7 Threat intelligence (new) - obtaining, analysing and using threat information.
• A.5.8 Information security in project management - security requirements in projects from the outset.

A.5.9 to A.5.14 Assets and information

• A.5.9 Inventory of information and other associated assets - an asset inventory with owners.
• A.5.10 Acceptable use - rules for acceptable use of assets.
• A.5.11 Return of assets - return of assets on change or termination.
• A.5.12 Classification of information - classification by sensitivity.
• A.5.13 Labelling of information - labelling in line with the classification.
• A.5.14 Information transfer - rules for transferring information internally and externally.

A.5.15 to A.5.18 Access control

• A.5.15 Access control - the rules for granting access.
• A.5.16 Identity management - managing identities across the whole lifecycle.
• A.5.17 Authentication information - handling passwords and other authentication data.
• A.5.18 Access rights - granting, reviewing and revoking rights.

A.5.19 to A.5.23 The supply chain

• A.5.19 Information security in supplier relationships - rules for working with suppliers.
• A.5.20 Addressing information security within supplier agreements - security terms in contracts.
• A.5.21 Managing information security in the ICT supply chain - risk from further links in the chain.
• A.5.22 Monitoring, review and change management of supplier services - ongoing oversight of the supplier.
• A.5.23 Information security for use of cloud services (new).

A.5.24 to A.5.30 Incidents and continuity

• A.5.24 Information security incident management planning and preparation.
• A.5.25 Assessment and decision on information security events - assessing events and deciding how to classify them.
• A.5.26 Response to information security incidents - responding in line with the procedure.
• A.5.27 Learning from information security incidents.
• A.5.28 Collection of evidence - preserving evidential material.
• A.5.29 Information security during disruption - maintaining security while disrupted.
• A.5.30 ICT readiness for business continuity (new) - readiness of systems to recover. See ISO 22301.

A.5.31 to A.5.37 Compliance and documentation

• A.5.31 Legal, statutory, regulatory and contractual requirements - identifying legal requirements.
• A.5.32 Intellectual property rights - including software licensing.
• A.5.33 Protection of records - protecting records against loss and alteration.
• A.5.34 Privacy and protection of PII - protection of personal data; the point of contact with the GDPR, and for cloud expanded in ISO/IEC 27018 ^[10].
• A.5.35 Independent review of information security.
• A.5.36 Compliance with policies, rules and standards - checking that your own rules are followed.
• A.5.37 Documented operating procedures.

A.6 People controls (8)

The smallest group, covering the whole employment cycle - from screening a candidate to the obligations that survive somebody's departure. Implementing it almost always requires cooperation with HR, which is often the hardest part.

• A.6.1 Screening - verifying identity, references, experience and qualifications, to the extent the law permits and proportionately to the role.
• A.6.2 Terms and conditions of employment - security duties written into the contract, together with a confidentiality undertaking.
• A.6.3 Information security awareness, education and training - training on induction and periodically, with attendance documented. See security awareness.
• A.6.4 Disciplinary process - the process for somebody who breached the rules.
• A.6.5 Responsibilities after termination or change of employment - return of assets, revocation of rights, continuing confidentiality.
• A.6.6 Confidentiality or non-disclosure agreements - with staff, contractors and suppliers.
• A.6.7 Remote working - rules for working away from the premises, securing devices and connections.
• A.6.8 Information security event reporting - a reporting channel simple enough that somebody will actually use it.

A.7 Physical controls (14)

The group covers three layers: perimeters and entry control, the environmental resilience of premises, and protection of the equipment and media themselves - including when they leave the site. In organisations using an external data centre some of these controls are delivered by the provider, which has to be documented rather than assumed.

• A.7.1 Physical security perimeters - defined boundaries of protected areas.
• A.7.2 Physical entry - entry control, for instance by card or biometrics.
• A.7.3 Securing offices, rooms and facilities.
• A.7.4 Physical security monitoring (new) - monitoring of areas: CCTV, alarms, an entry log.
• A.7.5 Protecting against physical and environmental threats - fire, flood and power failure.
• A.7.6 Working in secure areas.
• A.7.7 Clear desk and clear screen.
• A.7.8 Equipment siting and protection - placement reducing the risk of being overlooked or damaged.
• A.7.9 Security of assets off-premises, including laptops.
• A.7.10 Storage media - managing media across their whole lifecycle.
• A.7.11 Supporting utilities - power, cooling and other supporting services.
• A.7.12 Cabling security - protection of power and data cabling.
• A.7.13 Equipment maintenance - servicing without losing control of the data.
• A.7.14 Secure disposal or re-use of equipment - retirement with permanent data removal.

A.8 Technological controls (34)

The second largest group and the one easiest to implement halfway. It covers endpoints and permissions, protection against malware and vulnerabilities, logging and monitoring, cryptography, network security and the whole software development lifecycle.

A.8.1 to A.8.6 Devices, permissions and capacity

• A.8.1 User endpoint devices. See hardening.
• A.8.2 Privileged access rights - restricting and overseeing privileged accounts.
• A.8.3 Information access restriction.
• A.8.4 Access to source code.
• A.8.5 Secure authentication, including multi-factor.
• A.8.6 Capacity management.

A.8.7 to A.8.14 Protection, backups and resilience

• A.8.7 Protection against malware.
• A.8.8 Management of technical vulnerabilities. See vulnerability scanning.
• A.8.9 Configuration management (new) - managing configuration and detecting drift.
• A.8.10 Information deletion (new) - deleting information once the need has ended.
• A.8.11 Data masking (new), particularly in non-production environments.
• A.8.12 Data leakage prevention (new).
• A.8.13 Information backup - backups together with restore testing.
• A.8.14 Redundancy of information processing facilities.

A.8.15 to A.8.19 Logging and monitoring

• A.8.15 Logging.
• A.8.16 Monitoring activities (new) - monitoring activity and detecting anomalies. See SOC 24/7.
• A.8.17 Clock synchronisation, without which log correlation loses its meaning.
• A.8.18 Use of privileged utility programs - controlling tools that bypass safeguards.
• A.8.19 Installation of software on operational systems.

A.8.20 to A.8.24 Network and cryptography

• A.8.20 Networks security.
• A.8.21 Security of network services.
• A.8.22 Segregation of networks.
• A.8.23 Web filtering (new).
• A.8.24 Use of cryptography, together with key management.

A.8.25 to A.8.34 Development and testing

• A.8.25 Secure development life cycle.
• A.8.26 Application security requirements.
• A.8.27 Secure system architecture and engineering principles.
• A.8.28 Secure coding (new).
• A.8.29 Security testing in development and acceptance. See penetration testing.
• A.8.30 Outsourced development - oversight of development contracted out.
• A.8.31 Separation of development, test and production environments.
• A.8.32 Change management.
• A.8.33 Test information - protecting data used for testing.
• A.8.34 Protection of information systems during audit testing.

Relationships with the NIST CSF, CIS Controls and OWASP

ISO 27002 does not operate in a vacuum and in practice almost always sits alongside other models. It is worth understanding how it differs from them, because trying to replace one with another ends in duplicated work.

The NIST Cybersecurity Framework 2.0 ^[4] operates at a higher level of generality. It organises security into six functions - govern, identify, protect, detect, respond and recover - and does not descend to implementation instructions. That is why the two complement each other well: the CSF as the frame for a conversation with the board, ISO 27002 as the executing layer. The mapping between them is built into the standard's attributes, so it does not have to be created by hand.

The CIS Critical Security Controls ^[5] go the other way - they are more technical and explicitly prioritised, split into implementation groups. The Center for Internet Security publishes a mapping of its controls onto ISO 27002, so an organisation can use CIS as the order of work and ISO as the structure of its documentation.

The OWASP Top 10 ^[6] has a far narrower scope: it is a list of the most serious categories of web application weakness, not a catalogue of organisational controls. In ISO 27002 it corresponds roughly to what falls under A.8.28 and the neighbouring development lifecycle controls. Treating OWASP as an alternative to ISO 27002 is a frequent misunderstanding - it is a tool for a different job.

NIST SP 800-53 ^[11] is the largest catalogue of those mentioned, running to over a thousand items with enhancements. It was written for the US federal administration and outside that context is often excessive, but it is useful as a source of detail where the ISO guidance is terse.

A mature organisation usually does not choose one model but assigns each a different role: ISO 27001 and 27002 as the basis of the management system and any certification, the NIST CSF as the reporting language, the CIS Controls as the implementation order, OWASP for the application layer, and the law - the KSC act, NIS2, the GDPR - as obligations none of those models replaces.

Implementation in practice

Implementing the whole catalogue from scratch usually takes a mid-sized organisation nine to eighteen months - an observation from our projects, not a figure from the standard. Order matters more here than pace, because some controls are a precondition for others working sensibly. You cannot, for instance, sensibly restrict access to information nobody has classified.

A staged approach works. First comes the foundation: policy, roles, asset inventory, information classification and basic access control rules. Then day-to-day protection - multi-factor authentication, oversight of privileged accounts, malware protection, vulnerability management, backups and staff training. The third stage is detection capability: logging, monitoring, threat intelligence and physical area monitoring. The fourth covers response and recovery, meaning incident handling and business continuity. The last concerns the areas needing the most maturity: supplier management, security in the software development lifecycle, data masking and leakage prevention.

Within a stage, the order should follow from risk analysis rather than from completeness of the list. ISO/IEC 27005 ^[8] structures risk assessment, and ISO/IEC 27003 ^[7] gives guidance on implementing the management system itself. Beyond risk, sensible criteria are the regulatory obligations that have to be met anyway, and the dependencies between controls.

The division of responsibility rarely lines up with the group structure of the standard, and that is the commonest source of bottlenecks. Coordination usually falls to whoever owns the management system, but people controls need HR, physical controls need facilities, technological controls need IT, and the supplier and compliance controls need legal. Without agreeing owners at the start, the project stalls on the items nobody regards as theirs.

The commonest implementation mistakes

The problems below recur in audits regardless of the size of the organisation.

1. Implementing all 93 controls with no risk analysis. Expensive and often misdirected. The standard does not require the full set - it requires the choices to be justified, and the statement of applicability is where that justification is recorded.
2. A policy exists, the control does not work. The classic gap between documentation and practice. An auditor checks evidence of operation, not the fact that a document was approved.
3. Working only from Annex A of ISO 27001. One-sentence descriptions are not enough to design a control or to defend it during an audit.
4. Skipping the controls added in 2022. What is usually missing is threat intelligence, monitoring activities, leakage prevention and secure coding - the ones needing a process rather than a document.
5. Handling the supply chain formally. A contract clause without actual verification of the supplier does not deliver A.5.19 to A.5.22.
6. Backups with no restore test. A.8.13 requires regular testing, not merely taking backups. It is the most frequently recorded nonconformity in that group.
7. No segregation of duties in a small organisation. Where one person grants rights, uses them and reviews the logs, none of those actions is independently verified. The answer is often moving the review outside the IT team rather than hiring another person.
8. Monitoring limited to the technical layer. A.8.16 also covers anomalies in user behaviour, such as unusual logins or a sudden spike in downloads.
9. Default configurations despite A.8.9. Without a reference point there is no way to detect drift from the intended state.
10. A.5.34 detached from data protection law. Personal data protection described only in the management system documentation, with no procedure for handling data subject requests and no impact assessment, does not survive an inspection by the supervisory authority.