ISO/IEC 27001:2022 is the current standard guiding how organizations approach requirements, Annex A changes, and audit evidence. Last updated: June 2026.
Information security governance is being reshaped by cloud adoption, distributed suppliers, regulatory scrutiny, and the need to prove that controls work in practice. ISO/IEC 27001:2022 responds to that environment by focusing less on static security paperwork and more on a managed system of risk decisions, evidence, accountability, and continual improvement.
ISO/IEC 27001:2022 is the international requirements standard for an information security management system, usually called an ISMS. It defines what an organisation must establish, operate, monitor, review, maintain, and improve to manage information security risk in a controlled and auditable way.
The standard should not be confused with ISO/IEC 27002:2022. ISO/IEC 27001 sets the certifiable requirements, while ISO/IEC 27002 provides implementation guidance for information security controls. In practice, organisations use ISO/IEC 27001 to structure the management system and ISO/IEC 27002 to interpret and implement the controls selected through risk treatment.
What ISO 27001 requires in practice
ISO/IEC 27001 is built around clauses 4 to 10, supported by Annex A. Clauses 4 to 10 describe the management system: scope, leadership, planning, support, operation, performance evaluation, and improvement. Annex A provides a reference set of controls that may be selected when they are relevant to the organisation’s risks.
This distinction matters because certification is not achieved by adopting every control as a checklist. Auditors expect to see that the organisation understands its context, defines a coherent ISMS scope, assesses risks consistently, selects controls for defensible reasons, and keeps evidence that the system is operating. A control may be excluded, but the exclusion must be justified in the Statement of Applicability.
A common implementation mistake is to start with a technology inventory and then try to wrap the ISMS around it. A better scoping approach begins with the business boundary: which services or processes are in scope, which locations or regions are covered, which assets and systems support those processes, and which third parties influence the security outcomes. Explicit exclusions should be documented with a rationale, because unclear exclusions often create audit friction later.
- Processes: the products, services, departments, or business activities covered by the ISMS.
- Locations: the offices, sites, data centres, countries, or remote-working arrangements included in scope.
- Assets and systems: the applications, cloud services, infrastructure, repositories, endpoints, and information assets supporting the scoped processes.
- Parties: the subsidiaries, suppliers, outsourced providers, contractors, and partners that affect information security obligations.
Clauses 4 to 10 explained with audit evidence
Clause 4 requires the organisation to understand its context, interested parties, and ISMS scope. Auditors usually sample evidence such as a scope statement, a list of interested parties, legal and contractual obligations, and records showing how business context influences security requirements. A strong scope is specific enough to be audited and broad enough to cover the services the organisation is asking customers and stakeholders to trust.
Clause 5 covers leadership, policy, and responsibilities. The organisation must show that top management is accountable for the ISMS rather than treating it as a documentation task delegated entirely to IT or compliance. Typical evidence includes an approved information security policy, assigned roles and responsibilities, management communications, resourcing decisions, and records showing that security objectives are aligned with business priorities.
Clause 6 addresses planning, including actions to manage risks and opportunities, information security risk assessment, risk treatment, and measurable objectives. Auditors look for a risk assessment methodology, a risk register with scoring rationale, risk treatment decisions, approved risk owners, and objectives that can be monitored. The most common weakness is inconsistency: risks are scored one way in the methodology but treated differently in the register without explanation.
Clause 7 deals with support, including resources, competence, awareness, communication, and documented information. Evidence often includes competence records, awareness materials, communication plans, document control records, and proof that staff understand relevant security responsibilities. Training records alone are rarely enough; auditors may also interview employees to check whether awareness has reached day-to-day work.
Clause 8 is about operation. The organisation must operate the risk assessment and risk treatment process, control planned changes, and manage outsourced processes where relevant. Auditors commonly sample recent risk assessments, treatment plan updates, change records, supplier records, incident records, and evidence that selected controls are actually in use rather than only documented.
Clause 9 requires performance evaluation through monitoring, measurement, analysis, evaluation, internal audit, and management review. Useful evidence includes internal audit plans and reports, metrics, management review minutes, corrective actions, and decisions made by leadership. Practical KPIs should be simple enough to maintain, such as time to close high risks, percentage of overdue risk treatments, control test failure rate, incident response exercise completion, and supplier review completion.
Clause 10 focuses on improvement, including nonconformities, corrective action, and continual improvement. Auditors expect to see that issues are investigated, root causes are addressed, actions are assigned, and effectiveness is reviewed. A corrective action log with dates and owners is useful, but the stronger evidence is a visible link between a problem, the chosen fix, and a later check showing whether the fix worked.
Annex A in the 2022 standard
Annex A changed significantly in the 2022 revision. Instead of the 2013 structure of 14 control domains, the 2022 version groups controls into four themes: organisational, people, physical, and technological. The revised control set also aligns more closely with ISO/IEC 27002:2022 and reflects modern security concerns such as threat intelligence, cloud service use, data leakage prevention, monitoring activities, and secure coding.
The four-theme model helps organisations discuss controls in a way that mirrors how security work is actually managed. Organisational controls include governance, policies, supplier relationships, threat intelligence, and information security in project management. People controls address awareness, screening, responsibilities during employment, and termination or change of employment. Physical controls cover secure areas, equipment protection, and physical access. Technological controls include identity, access control, logging, malware protection, cryptography, vulnerability management, backup, network security, and cloud-related controls.
Annex A is not a separate checklist to complete after the ISMS is finished. It is connected to the risk treatment process. The organisation assesses information security risks, decides how to treat them, selects relevant controls from Annex A or elsewhere, and records those decisions in the Statement of Applicability. ISO/IEC 27002:2022 can then be used as guidance for implementing the selected controls, but it does not replace the requirement to justify why controls are included or excluded.
In cloud and SaaS environments, Annex A selection needs particular care. A provider may operate parts of the infrastructure, but the customer usually remains responsible for configuration choices, access governance, data classification, monitoring, user lifecycle management, and supplier oversight. The shared-responsibility model should therefore be reflected in the risk register, supplier reviews, control ownership, and the Statement of Applicability.
The Statement of Applicability and risk treatment plan
The Statement of Applicability, often shortened to SoA, is one of the most important documents in an ISO/IEC 27001 implementation. It explains which Annex A controls are applicable, whether they are implemented, why they were included, and why any controls were excluded. It also connects the risk treatment process to the control environment, which is why auditors examine it closely.
The risk treatment plan is different. It records how the organisation intends to address identified risks, who owns the actions, what deadlines apply, and how progress will be tracked. The SoA explains the control position; the treatment plan manages the work needed to reach or maintain that position.
For example, a SaaS company may identify a high risk around unauthorised administrative access to its production platform. The treatment plan might assign actions to improve privileged access review, strengthen multi-factor authentication enforcement, and formalise logging review. The SoA would then mark relevant technological and organisational controls as applicable, describe their implementation status, and link the decision back to the access risk and operational environment.
A weak SoA often reads like a copied list of controls with “applicable” marked throughout. A stronger SoA provides concise reasoning. Where a control is excluded, the explanation should be credible in the context of scope, risk, contractual duties, and business operations. Where a control is included but not fully implemented, the gap should be visible in the treatment plan rather than hidden.
Transitioning from ISO 27001:2013 to 2022
Transition work should begin with a gap assessment against the 2022 requirements and Annex A structure. The organisation should compare its existing ISMS clauses, risk methodology, SoA, control descriptions, policies, and evidence records with the revised standard. The goal is to understand what has changed in the management system and what has changed in the control set.
A frequent transition trap is over-migrating the old 2013 control families into the new structure without reconsidering risk. Because the 2022 controls are reorganised and updated, mapping is useful but not sufficient. New or more explicit areas such as threat intelligence, cloud service use, configuration management, ICT readiness for business continuity, data masking, data leakage prevention, monitoring activities, web filtering, and secure coding need to be assessed against the organisation’s actual environment.
Policy refresh is also important. Organisations often update the SoA but leave supporting policies, procedures, supplier templates, incident processes, and awareness materials aligned to the previous control structure. That creates confusion during audits because staff may describe one way of working while documents refer to another. Transition should therefore include document alignment, control owner confirmation, evidence sampling, and internal audit before the external audit takes place.
An anonymised example illustrates the trade-off. A mid-size SaaS firm transitioning to the 2022 version initially tried to map every 2013 control into a new spreadsheet and treat the exercise as administrative. The gap assessment showed that the larger issue was cloud governance: supplier responsibility, privileged access review, logging, and secure development evidence were spread across teams. By reframing the transition around risk ownership and evidence, the firm reduced audit ambiguity and created a SoA that reflected how the service was actually operated.
Implementation roadmap for a working ISMS
A practical implementation begins with scope and governance, not templates. The organisation should agree the ISMS boundary, confirm leadership accountability, identify interested parties, and define the policies and roles needed to manage the system. This early work prevents the ISMS from expanding uncontrollably into every system and supplier before the organisation has decided what certification should cover.
The next step is risk assessment. The methodology should define criteria for likelihood, impact, risk acceptance, ownership, and review frequency. Once risks are assessed, treatment decisions can be made and controls selected. The SoA and treatment plan should then be created together so that control decisions, implementation work, and risk ownership remain consistent.
Implementation should be evidence-led. If access reviews are selected as a control, the organisation should define who performs them, how often they occur, what systems are covered, how exceptions are handled, and where records are stored. The same principle applies to supplier reviews, vulnerability management, incident response, backup testing, security awareness, logging, and management review.
Internal audit should take place after the ISMS has operated long enough to produce real evidence. It should test whether the organisation follows its own process, whether the process meets ISO/IEC 27001 requirements, and whether records are complete. Organisations building internal capability often use structured ISO training to clarify implementation roles; Readynez provides ISO training options for teams that need a guided route through standards and certification preparation.
How auditors read the evidence
Auditors generally work through sampling. They do not check every ticket, every supplier record, or every access review. Instead, they select examples across departments, systems, time periods, and risk areas to test whether the ISMS is designed properly and operating consistently.
This sampling approach means isolated good examples are not enough. If one access review is complete but another is missing approvals, the auditor will look for whether the difference is understood and managed. If risk treatment actions are overdue, the issue is not automatically a failure, but the organisation should be able to explain ownership, escalation, and management awareness.
Evidence should be retained in the systems where work happens where possible. For instance, change approval may live in a service management platform, supplier review in a procurement workflow, and incident response in a security operations tool. The ISMS does not need to duplicate every record, but it should make evidence retrievable and controlled.
Competence is also part of evidence. Clause 7 expects people performing work under the ISMS to be competent for their responsibilities. Ongoing security competence can be developed through role-based learning, internal briefings, exercises, and external training, and some organisations use Unlimited Security Training to maintain broader capability across security and compliance teams.
Common mistakes that weaken certification readiness
The first common mistake is treating ISO/IEC 27001 as a document production project. Documentation matters, but the evidence must show that risk assessment, control operation, performance evaluation, and improvement are happening. A well-written policy cannot compensate for missing risk ownership or untested incident procedures.
The second mistake is allowing the scope to remain vague. Phrases such as “all information systems” or “company operations” may sound broad and reassuring, but they often create uncertainty about locations, subsidiaries, cloud environments, suppliers, and support functions. A precise scope gives auditors and internal teams a clearer basis for deciding what evidence is relevant.
The third mistake is separating the SoA from operational reality. If the SoA says logging and monitoring are implemented, the organisation should be able to show what is logged, who reviews alerts, how exceptions are handled, and how monitoring supports risk treatment. If the SoA says supplier controls are applicable, supplier selection and review records should be available.
The fourth mistake is assuming certification proves compliance with every legal or regulatory obligation. ISO/IEC 27001 can support regulatory governance and demonstrate a structured approach to information security risk, but it does not guarantee compliance with data protection law, contractual obligations, sector regulation, or regulator expectations. Organisations handling personal data should align their ISMS with applicable data protection requirements and relevant guidance from bodies such as the ICO, NCSC, and ENISA where appropriate.
Making ISO 27001 useful after certification
Certification is a milestone, but the value of ISO/IEC 27001 depends on how well the ISMS supports decisions after the audit. A useful ISMS helps leadership understand which risks remain high, which controls are failing, which suppliers need attention, and where investment is justified. It also gives operational teams a common way to document and improve security work.
The most effective next step is to compare the organisation’s current ISMS evidence against clauses 4 to 10 and the 2022 Annex A themes, then close the gaps that affect risk decisions rather than polishing documents first. If a team wants to discuss ISO certification training options or the skills needed to support an implementation, it can contact Readynez for a practical conversation.
FAQ
What is ISO 27001 and why is it important?
ISO/IEC 27001 is an international standard for establishing, operating, monitoring, reviewing, maintaining, and improving an information security management system. It is important because it gives organisations a structured way to manage information security risk and demonstrate that governance, controls, evidence, and improvement are in place.
What are the main requirements of ISO 27001?
The main requirements are found in clauses 4 to 10. They cover organisational context, leadership, planning, support, operation, performance evaluation, and improvement. Organisations must also use Annex A as a control reference when producing the Statement of Applicability, based on their risk treatment decisions.
How does Annex A work in ISO 27001:2022?
Annex A provides a reference set of information security controls grouped into organisational, people, physical, and technological themes. Organisations select applicable controls through risk treatment and justify inclusion or exclusion in the Statement of Applicability. ISO/IEC 27002:2022 provides guidance for implementing those controls.
What evidence do auditors expect for ISO 27001?
Auditors typically sample evidence such as the ISMS scope, risk methodology, risk register, Statement of Applicability, risk treatment plan, policies, competence records, internal audit reports, management review minutes, incident records, supplier reviews, and control operation records. They look for consistency between the documented system and actual practice.
How should an organisation transition from ISO 27001:2013 to 2022?
The transition should start with a gap assessment against the 2022 clauses and Annex A structure. Organisations should remap controls, reassess risks, update the Statement of Applicability, refresh policies and procedures, address new or clearer control areas such as threat intelligence and cloud service use, and run an internal audit before the external transition audit.
How often should an organisation review its ISO 27001 ISMS?
An organisation should review the ISMS at planned intervals and whenever significant business, technology, supplier, regulatory, or risk changes occur. Annual review is common, but high-risk environments may require more frequent risk reviews, control checks, supplier reviews, internal audits, and management reporting.
