ISO/IEC 27001 is the requirements standard for an information security management system, and ISO/IEC 27002 explains how organisations can think about and apply the security controls that support it.
The distinction matters because the two standards are often discussed together but used for different purposes. ISO/IEC 27001 is the certifiable standard: an organisation can be audited against it and awarded certification if its information security management system, or ISMS, meets the requirements. ISO/IEC 27002 is guidance rather than a certifiable standard. It helps security, risk and compliance teams interpret the control set and turn broad control objectives into workable practices.
Together, they give businesses a disciplined way to manage information security risk. ISO/IEC 27001 provides the management system structure: scope, leadership, risk assessment, objectives, controls, performance evaluation and continual improvement. ISO/IEC 27002 provides practical control guidance across areas such as access control, supplier relationships, asset management, logging, incident response and secure configuration. The value is strongest when the organisation treats them as risk-management tools rather than as paperwork for an audit.
Why the Two Standards Are Often Confused
ISO/IEC 27001 and ISO/IEC 27002 both sit within the ISO/IEC 27000 family, and both refer to information security controls. That overlap can make them appear interchangeable, especially to organisations beginning their first formal security programme. In practice, they answer different questions.
ISO/IEC 27001 asks whether the organisation has a functioning management system for information security. It requires risk assessment, risk treatment, documented scope, leadership accountability, internal audits, management review and continual improvement. It also requires a Statement of Applicability, commonly called the SoA, which explains which controls are applicable, why they were selected, whether they have been implemented, and why any controls have been excluded.
ISO/IEC 27002 helps answer what good control implementation can look like. It does not tell every organisation to implement every control in the same way. Instead, it provides guidance that should be interpreted through the organisation’s risk profile, operating model, technology stack, legal obligations and contractual commitments.
This is why a small software company, a regulated financial services firm and a public sector supplier may all use the same standards but produce very different control designs. The standards create a common language; the organisation still has to make defensible decisions.
What Changed in the 2022 Versions
The 2022 updates made the relationship between ISO/IEC 27001 and ISO/IEC 27002 clearer, particularly around Annex A controls. ISO/IEC 27002:2022 reorganised the control guidance into four themes: organisational, people, physical and technological. It also consolidated the control set to 93 controls. ISO/IEC 27001:2022 now aligns Annex A with that updated control structure, which has practical consequences for risk treatment, SoA design and audit evidence.
Before the update, many organisations had control registers, audit workbooks and SoA templates based on the earlier control grouping. Moving to the 2022 structure is not simply a formatting exercise. Control owners may need to revisit how evidence is collected, how responsibilities are assigned, and how older controls map into the revised set. A poorly managed transition can leave teams with duplicate controls, gaps in ownership or an SoA that no longer reflects how security actually operates.
The addition of control attributes in ISO/IEC 27002:2022 also helps organisations view controls through different lenses, such as whether a control is preventive, detective or corrective, or whether it relates to confidentiality, integrity or availability. In practice, this can improve reporting and evidence management because teams can group controls in ways that match risk discussions, audit requests and framework mappings.
The most useful way to approach the 2022 changes is to start with the risk assessment and SoA, then update evidence and ownership around the revised control structure. Re-labelling documents without checking whether controls are operating effectively creates audit risk and gives management a false sense of maturity.
How ISO 27001 and ISO 27002 Work Together
ISO/IEC 27001 begins with context. The organisation defines what is in scope, what information it needs to protect, which interested parties matter, and what legal, regulatory and contractual requirements apply. From there, it assesses information security risks and decides how those risks should be treated.
Controls are selected as part of that risk treatment process. Annex A in ISO/IEC 27001 provides a reference control set, while ISO/IEC 27002 gives implementation guidance for those controls. The SoA becomes the bridge between the two standards. It should show a clear line from business context and risk assessment through to control selection, implementation status and justification.
A common mistake is to treat Annex A as a checklist where every control is marked applicable without meaningful reasoning. That may feel safer, but it often creates problems later. If a control is marked applicable, auditors will expect to see evidence that it has been implemented and is operating. If a control is excluded, the organisation needs a credible justification based on scope and risk. Weak justifications, vague ownership and generic copy-paste wording in the SoA are frequent causes of audit findings.
In many cases, ISO/IEC 27002 is also useful before an organisation is ready for certification. A business may not yet face supplier pressure, tender requirements or board-level demand for ISO/IEC 27001 certification, but it can still use ISO/IEC 27002 to strengthen access control, incident response, supplier due diligence and security awareness. That route is especially practical for smaller organisations building maturity gradually. Certification becomes more valuable when there is an external requirement, a trust objective with customers, or a need for independent assurance.
The Business Case Beyond Certification
ISO/IEC 27001 certification can help demonstrate that an organisation has a structured approach to information security. It is often requested in procurement, outsourcing, cloud services, managed services and regulated supply chains. For customers and partners, certification provides independent assurance that the organisation’s ISMS has been assessed against recognised requirements.
Even so, certification should not be treated as a guarantee of security or regulatory compliance. It shows that a management system has been audited, not that breaches are impossible or that every legal obligation has automatically been met. Organisations still need to understand their own regulatory duties, such as data protection obligations, sector-specific requirements and contractual security commitments.
The internal benefits can be just as important as the certificate. A well-run ISMS clarifies who owns security risks, which controls exist, how incidents are handled, how suppliers are assessed, and how improvements are tracked. It reduces reliance on informal knowledge and helps security decisions survive staff changes, rapid growth and technology change.
For leadership teams, the key decision is whether the organisation needs external certification now, or whether it should first use the standards to build control maturity. If customers, regulators or tenders require independent assurance, ISO/IEC 27001 certification is the logical path. If the immediate problem is inconsistent security practice, unclear ownership or weak controls, ISO/IEC 27002 can guide improvement before the organisation commits to a certification audit.
Scoping and SoA Decisions That Shape the Outcome
Scope is one of the earliest decisions in an ISO/IEC 27001 implementation, and one of the most consequential. A narrow scope may be easier to manage but can look artificial if it excludes systems, teams or suppliers that clearly affect the protected information. An overly broad scope can overwhelm the organisation and produce controls that are difficult to operate consistently.
The most defensible scopes are based on how information actually flows. That means understanding business processes, systems, locations, cloud services, people, suppliers and data types. Asset inventory quality is therefore central. If the organisation does not know where important information resides, who can access it, and which third parties process it, the risk assessment and control design will be weak.
The SoA should then explain the organisation’s control decisions in language that reflects its real environment. For example, a cloud-first organisation may need strong controls around identity management, SaaS administration, endpoint security, backup arrangements, logging, incident response and supplier assurance. A manufacturing organisation may place more emphasis on physical security, operational technology segmentation and continuity arrangements. The standard is consistent, but the implementation should not look identical.
Auditors tend to challenge SoA entries that appear disconnected from risk. A control marked as implemented should be supported by policy, procedure, technical configuration, records, review evidence or operational outputs. A control marked as not applicable should be backed by a reason that makes sense within the scope. “Not relevant” is rarely enough on its own.
What Auditors Look For
The certification audit lifecycle usually begins with Stage 1 and Stage 2 audits, followed by surveillance audits during the certification cycle. Each stage has a different purpose. Understanding that distinction helps organisations prepare evidence without turning the ISMS into a document exercise.
Stage 1 is a readiness review. Auditors look at whether the organisation has defined its scope, established required ISMS documentation, completed risk assessment and risk treatment activity, prepared the SoA, planned internal audits and management review, and reached a level of readiness suitable for Stage 2. It is less about testing every control in depth and more about determining whether the management system is prepared for full assessment.
Stage 2 tests implementation and effectiveness. Auditors sample evidence to see whether the ISMS is operating in practice. They may review access approvals, joiner and leaver records, incident tickets, vulnerability management outputs, supplier assessments, backup test results, awareness records, internal audit findings, management review minutes, risk treatment progress and control monitoring. The evidence needs to show that processes are repeatable, not performed once for the audit.
Surveillance audits then check whether the ISMS continues to operate and improve. Auditors will usually focus on changes since the last audit, corrective actions, internal audit results, management review outputs, risk updates, objectives and measurable improvements. Organisations that treat certification as a one-off project often struggle here because surveillance reveals whether continual improvement is embedded.
A Cloud-First Remote Team Example
Consider a remote software company that uses cloud infrastructure, SaaS collaboration tools and outsourced support services. Its security risks are less about server rooms and more about identity, endpoint protection, cloud configuration, supplier access and incident coordination. ISO/IEC 27001 gives the company the management system structure to assess and govern those risks. ISO/IEC 27002 helps translate relevant controls into day-to-day practice.
Access control might become single sign-on, multi-factor authentication, privileged access reviews and rapid removal of access for leavers. Asset management might focus on laptops, mobile devices, cloud accounts, repositories and data stores rather than only physical hardware. Supplier security might include due diligence for SaaS providers, contract clauses, review of security documentation and clear understanding of shared responsibility in cloud services.
Incident management also needs to reflect remote working. The organisation may need a documented incident playbook, defined communication channels, evidence-preservation guidance and rehearsed roles for technical response, customer communication and regulatory escalation. ISO/IEC 27002 does not prescribe the exact tooling, but it helps the organisation ask better questions about whether the control is suitable and operating.
This example also shows why relying on cloud providers alone is risky. Infrastructure and SaaS providers may offer strong platform controls, but the customer organisation still owns decisions about identity configuration, user access, data classification, monitoring, backup strategy and supplier oversight. Shared responsibility should be reflected in the risk assessment, SoA and evidence library.
Using the Standards with Other Frameworks
Many organisations already work with other security and assurance frameworks, such as SOC 2, NIST CSF or sector-specific control sets. ISO/IEC 27001 and ISO/IEC 27002 can coexist with those frameworks, but duplication becomes a problem if teams manage each requirement in isolation.
A practical approach is to build a control-owner model and evidence library early. One control may support several obligations. For example, an access review record may be useful for ISO/IEC 27001, customer assurance requests and internal governance. A supplier assessment may support ISO/IEC 27001 controls, privacy due diligence and procurement risk management. Mapping controls once and reusing evidence reduces audit fatigue and improves consistency.
The risk is over-mapping. Organisations sometimes create large spreadsheets that connect every framework to every other framework but do not improve control operation. Mapping is valuable only if it helps owners understand responsibilities, collect evidence and identify gaps. The goal is better security governance, not a larger compliance inventory.
Building Capability Around ISO 27001 and ISO 27002
Successful adoption requires more than assigning the project to a compliance lead. Information security management touches IT, HR, legal, procurement, operations, leadership and business owners. Policies and risk registers matter, but they need to be supported by working processes and people who understand their responsibilities.
Training can help when it is tied to the organisation’s role model. A risk owner needs to understand risk acceptance and treatment decisions. A control owner needs to understand evidence, review cycles and exceptions. An internal auditor needs to understand audit planning, sampling and impartiality. A leadership team needs enough knowledge to challenge whether objectives, resources and improvement plans are credible.
Readynez provides ISO training and certification preparation for teams that want structured learning around standards such as ISO/IEC 27001. The training route should be chosen according to responsibility: implementation, audit, governance and operational control ownership require different depths of knowledge.
Practical Next Steps for Businesses
The right starting point depends on the organisation’s maturity and external pressure. A company facing customer certification demands should build a formal ISO/IEC 27001 implementation plan, including scope, risk assessment, SoA, internal audit, management review and certification readiness. A company without immediate certification pressure may begin by using ISO/IEC 27002 to improve priority controls and gather evidence discipline before pursuing certification.
A sensible first move is to define the information, systems, services and locations that matter most. From there, the organisation can assess risks, confirm legal and contractual obligations, identify control gaps and decide whether certification is necessary. This avoids the common mistake of starting with templates before understanding the business context.
Organisations that already operate security controls should resist rebuilding everything from scratch. Existing access reviews, supplier checks, incident tickets, vulnerability scans, awareness records and change approvals may already provide useful evidence. The task is often to connect those activities into a governed ISMS, close the gaps and document decisions clearly.
When teams need broader security training alongside ISO knowledge, Unlimited Security Training can support role-based development across related security disciplines. To discuss a practical training route for ISO certification or security capability building, contact Readynez.
ISO 27001 and ISO 27002 FAQ
Is ISO/IEC 27002 certifiable?
No. ISO/IEC 27002 is guidance for information security controls. ISO/IEC 27001 is the standard organisations can be certified against because it defines the requirements for an information security management system.
What is the main difference between ISO/IEC 27001 and ISO/IEC 27002?
ISO/IEC 27001 sets the requirements for establishing, operating, monitoring and improving an ISMS. ISO/IEC 27002 provides guidance on the controls that can be used to treat information security risks. In simple terms, ISO/IEC 27001 defines the management system, while ISO/IEC 27002 helps with control implementation.
ISO/IEC 27001 helps organisations identify information security risks, choose appropriate controls, assign responsibilities, monitor performance and improve over time. It supports confidentiality, integrity and availability by making security a managed business process rather than a collection of isolated technical measures.
What changed in the 2022 versions?
ISO/IEC 27002:2022 reorganised the control guidance into four themes and 93 controls. ISO/IEC 27001:2022 aligned Annex A with that updated control set. Organisations using earlier versions need to review their SoA, control ownership, evidence model and mappings rather than simply renaming documents.
Can a business use ISO/IEC 27002 without pursuing ISO/IEC 27001 certification?
Yes. An organisation can use ISO/IEC 27002 to improve security controls even if it does not pursue certification. This is useful when the immediate goal is internal maturity, better supplier assurance, improved access control or stronger incident response. Certification becomes more relevant when external assurance is required by customers, tenders, regulators or the board.
What evidence do auditors expect for ISO/IEC 27001?
Auditors usually look for evidence that the ISMS is defined, implemented and improving. This may include risk assessments, the SoA, policies, access reviews, incident records, supplier assessments, internal audit results, management review outputs, corrective actions and operational records showing that controls work in practice.
