ISO/IEC 27001:2022: the ISMS, 93 Annex A controls and certification

What ISO/IEC 27001 is

The full title is Information security, cybersecurity and privacy protection - Information security management systems - Requirements.^[1] The word Requirements matters: requirements in the main body of the standard can be used as audit and certification criteria.

The standard traces its roots to the British BS 7799. The first edition under the number ISO/IEC 27001 was published in 2005, followed by the 2013 edition and the current 2022 edition. The 2022 revision aligned the management-system structure and terminology and comprehensively reworked Annex A in line with ISO/IEC 27002:2022.^[1][3]

The standard is technology-neutral and sector-neutral. That is deliberate: its requirements must work for a small service company as well as for a large organization operating cloud environments, data centres, OT or complex supply chains. Specific measures are expected to follow from risk and from requirements applicable to the organization.

ISO/IEC 27001 is not a configuration manual. Detailed guidance on the 93 controls is provided by ISO/IEC 27002:2022.^[3] Information security risk management is developed further in ISO/IEC 27005:2022.^[4]

Why organizations implement an ISMS

The first reason is operational. Formal risk assessment, asset and risk ownership, acceptance criteria and an audit cycle expose dependencies that can otherwise remain invisible.

The second reason is contractual. A certificate may be a condition for participation in a procurement process or a supplier-qualification requirement. In such cases, the exact certification scope matters more than the logo of the certification body.

The third reason is evidentiary. A functioning ISMS organizes documentation, decisions and records needed during regulatory inspections or customer audits. It does not mean that the certificate substitutes for an assessment against a specific law.

What changed in 2022

The most visible change is Annex A. The 2013 edition contained 114 controls in 14 categories. The 2022 edition contains 93 controls in four groups.^[3]

The lower number does not mean that protection was removed. Some previous controls were merged or reorganized, and 11 controls are new compared with the earlier catalogue.

The new controls address 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.^[3]

ISO/IEC 27002:2022 also introduced attributes that allow controls to be classified from different perspectives, including control type, information-security properties and cybersecurity functions.^[3] Attributes help filter and map the catalogue; they are not a new set of certification obligations.

Amendment 1:2024 - climate change

ISO/IEC 27001:2022/Amd 1:2024 added to the clauses on organizational context and interested parties a requirement to consider whether climate change is a relevant issue and whether interested parties have related requirements.^[1]

This does not oblige every ISMS to create a separate climate programme. The organization must be able to show that the issue was considered in the context of its activities. Relevant examples may include energy availability, environmental conditions for infrastructure, supplier resilience or the risk of physical disruption.

Clauses 4-10

Clauses 1-3 cover scope, normative references and terminology. Management-system requirements are found in clauses 4-10.

Clause 4 - Context of the organization

The organization identifies relevant internal and external issues, interested parties and their requirements, and defines the ISMS scope. A poorly defined scope can leave the certificate covering something different from the service customers actually care about.

Clause 5 - Leadership

Top management is responsible for the direction of the system, the information security policy, and roles and responsibilities. An ISMS cannot be only an IT-department project.

Clause 6 - Planning

This covers actions addressing risks and opportunities, information security risk assessment, risk treatment, security objectives and planning of changes. It is also where the Statement of Applicability (SoA) is produced.

Clause 7 - Support

This covers resources, competence, awareness, communication and documented information.

Clause 8 - Operation

The organization plans and controls the processes needed to meet requirements, performs risk assessments and implements the risk-treatment plan.

Clause 9 - Performance evaluation

This includes monitoring, measurement, analysis and evaluation, internal audit and management review. The standard requires planned intervals but does not impose one universal calendar. ISO/IEC 27004:2016 remains the published standard supporting measurement, while in 2026 its successor is already at DIS stage.^[10] ISMS auditing is supplemented by ISO 19011:2026 and ISO/IEC 27007:2020; the latter is also under revision.^[11][12]

Clause 10 - Improvement

This covers continual improvement and the handling of nonconformities and corrective action.

Risk assessment and treatment

The standard does not prescribe a single scoring method. The organization must establish and apply a process that produces consistent, valid and comparable results. It must define risk-acceptance criteria and criteria for performing assessments.^[1]

The process should identify risk owners, analyse consequences and likelihood, determine levels of risk and compare them with established criteria. Whether the scale is 1-5 or 1-10 matters less than whether the same situation assessed again with the same method produces a comparable result.

Risk treatment may involve reducing risk, avoiding it, changing how it is shared, or consciously accepting it. Control selection does not end with Annex A: an organization may use other controls where its risks or requirements call for them.

Statement of Applicability - SoA

The SoA is one of the central ISMS documents. It contains the necessary controls, justification for their inclusion, information on implementation, and justification for exclusions of Annex A controls.^[1]

Annex A is not a checklist that must be implemented blindly in full. The organization compares its selected controls with the Annex A catalogue to verify that it has not omitted something necessary. Excluded controls require justification, but exclusion itself is not a defect.

The SoA should remain aligned with the current risk assessment, risk-treatment plan, ISMS scope and actual implementation status. The worst approach is to declare all 93 controls implemented merely to avoid explaining exclusions.

Internal audit and management review

Internal audit is intended to provide information on whether the ISMS conforms to the requirements of the organization and to ISO/IEC 27001 and whether it is effectively implemented and maintained.^[1] The audit programme should take account of the importance of processes and the results of previous audits.

Auditors should maintain objectivity and impartiality. This does not automatically require outsourcing, but a person should not review their own ongoing work in a way that undermines the independence of conclusions.

Management review is a top-management decision process informed by data on system performance: audit results, progress against objectives, changes in context, risk, nonconformities and opportunities for improvement. A signature under a presentation is not a substitute for documented decisions.

Certification

Certification is a voluntary third-party assessment. Competence requirements for bodies auditing and certifying management systems are addressed by ISO/IEC 17021-1, while requirements specific to ISMS certification are developed in ISO/IEC 27006-1.^[7] In Poland, accredited bodies can be verified through the Polish Centre for Accreditation.^[8]

A typical cycle includes an initial audit in two stages, followed by surveillance audits and recertification within the certification cycle. The exact amount of audit time depends on scope, number of locations, complexity, changes and the rules of the certification body. There is no honest universal price or number of days that applies to every organization.

Nonconformities are classified and handled according to the certification programme and the rules of the certification body. The important point is not the label itself but the need for correction, cause analysis and corrective action proportionate to the finding.

Cost and implementation time

The cost of an ISMS depends first on the starting point. An organization that already has identity management, backups, monitoring, vulnerability management, supplier management and documented responsibilities faces a different effort from an organization building those capabilities from scratch.

Budgets should separate organizational work, technical security implementation and the independent cost of certification. Tools purchased because of the risk assessment are security costs, not merely certification costs.

The same applies to time. The schedule depends on scope, availability of process owners, the number and severity of gaps in the starting state, and the time needed to gather evidence that controls actually operate. Giving one number of months without those assumptions creates false precision.

Related standards in the 27000 family

ISO/IEC 27002:2022 develops the controls and their application.^[3] ISO/IEC 27005:2022 addresses information security risk management.^[4] ISO/IEC 27003:2017 remains a published ISMS guidance standard, but in 2026 it is under revision and its current description relates to ISO/IEC 27001:2013.^[9]

ISO/IEC 27017:2026 provides guidance on controls for cloud services and replaced the 2015 edition.^[5] ISO/IEC 27018:2025 addresses protection of personally identifiable information in public cloud services where the cloud provider acts as a processor.^[6] ISO/IEC 27701:2025 is a standalone privacy information management system standard and can be used independently, while still integrating well with ISO/IEC 27001.^[13]

Business continuity is developed by a separate standard, ISO 22301, described on its own page.

ISO/IEC 27001 and KRI, KSC/NIS2, GDPR and DORA

KRI has a specific legal structure. Section 19(3) describes a route by which the requirements of section 19(1) and (2) may be deemed satisfied through an ISMS and related processes based on specified Polish Standards from the 27000 family. It is not, however, a requirement to obtain certification.

KSC, after implementation of NIS2, requires regulated entities to maintain defined capabilities for risk management, monitoring, incident handling, continuity, supply-chain security and other measures. ISO/IEC 27001 can provide structure and evidence, but conformity with the standard is not equivalent to compliance with KSC.

The GDPR requires risk-appropriate technical and organizational measures and accountability. An ISMS can support demonstration of some of these obligations, but it does not determine lawful bases for processing, data-subject rights, transparency duties or international transfers.

DORA imposes its own requirements for digital operational resilience in the financial sector, including incidents, testing and ICT third-party risk. An ISO/IEC 27001 certificate can be one item of evidence but does not replace obligations arising directly from DORA and its level-two acts.

Common mistakes

• A scope designed for audit convenience rather than the actual service.
• An SoA declaring controls that the organization cannot evidence.
• Risk assessment written to justify a predetermined answer.
• No clear risk owners or action deadlines.
• An ISMS treated as an IT project without management decisions.
• Internal audits conducted in a way that undermines objectivity.
• Documentation updated only immediately before an audit.
• No evidence of control effectiveness despite extensive policies.
• Treating the certificate as the end goal rather than the outcome of a functioning system.

10 questions before certification

1. Does the ISMS scope match the services the organization actually wants covered by assurance?
2. Has the policy been approved by management and communicated to the people it affects?
3. Are roles, asset owners and risk owners unambiguous?
4. Does the risk-assessment method produce repeatable results?
5. Does the risk-treatment plan have owners, deadlines and approval?
6. Does the SoA reflect the real implementation status?
7. Is there evidence that controls operate, not merely procedures saying they should?
8. Has internal audit been performed objectively and its findings documented?
9. Did management review result in decisions?
10. Are corrective actions closed and re-verified?