Companies that begin implementing an ISMS often come across two very similar terms: ISO/IEC 27001 and ISO/IEC 27002. This naturally leads to an important question: are these two different standards, two stages of implementation, or simply different names for the same document?
The confusion is understandable. Both standards relate to information security, both are used in information security management projects, and both are frequently mentioned in discussions about ISO 27001 audits and ISO 27001 certification. However, their purpose is different.
Understanding this distinction is important not only for information security specialists, but also for managers, internal auditors, IT leaders, and everyone involved in implementing ISO 27001 in practice. A correct understanding affects the structure of documents, the logic of information security risk assessment, and ultimately the maturity of the ISMS.
What ISO 27001 and ISO 27002 Mean in Simple Terms
Put simply, ISO 27001 answers the question “what must be included in an information security management system”, while ISO 27002 answers the question “how information security controls can be implemented in practice.”
ISO/IEC 27001 is the standard that contains the formal requirements for an ISMS. It is the standard used for certification. If a company wants to undergo an external audit and obtain a certificate, it will be assessed against ISO 27001.
ISO/IEC 27002 is not a certification standard. It is practical guidance. It helps organizations understand the meaning of controls and choose appropriate security measures based on their risks, processes, and business specifics.
In other words:
- ISO 27001 sets out the requirements for the system;
- ISO 27002 provides guidance on how to apply controls.
This is the key distinction. One of the most common mistakes is to treat ISO 27002 as a mandatory checklist that must be implemented in full. In practice, that is not the right approach.
Why Companies Need Both Standards
For businesses, the difference between ISO 27001 and ISO 27002 is not theoretical. It is highly practical.
ISO 27001 is needed to build a managed system: to define context, roles, responsibilities, the information security policy, the approach to risk, internal audit procedures, improvement activities, and incident management.
ISO 27002 is needed so that the organization does not stop at general wording. It helps explain what security controls may look like in a real company. It is especially useful when dealing with access management, backups, logging, supplier management, remote work, cloud services, and other practical aspects of implementation.
Put simply, ISO 27001 provides the framework, while ISO 27002 helps fill that framework with working content.
How ISO 27002 Relates to ISO/IEC 27001 and the ISMS
The link between these standards is especially clear in the logic of Annex A of ISO 27001 and in the Statement of Applicability, or SoA.
Under ISO 27001, an organization must:
- carry out an information security risk assessment;
- determine how risks will be treated;
- select applicable controls;
- justify which controls are applied and which are not.
This is where ISO 27002 becomes especially helpful in practice. It provides explanations for the controls and helps organizations interpret and implement them in a practical rather than purely formal way.
For example, if a company includes an access control item in its SoA, simply naming the control is not enough. The organization must understand what real processes should sit behind it: who grants access, who approves it, how rights are reviewed, how access is revoked when someone leaves, and how contractor access is controlled.
This is where ISO 27002 is particularly useful: it translates a short control statement into practical implementation logic.
What Matters in Practice
In practice, ISO 27001 and ISO 27002 do not work as interchangeable documents. They work together.
The correct logic usually looks like this:
- The company defines the scope of the ISMS and the requirements of interested parties.
- It carries out an information security risk assessment.
- It determines which risks need to be treated.
- It selects the appropriate security controls.
- It records those choices in the Statement of Applicability.
- It implements the related processes, roles, documents, and performance controls.
If an organization skips the risk assessment stage and moves straight to “implementing controls from ISO 27002,” the result is almost always a formal system. Controls appear on paper, but it is unclear why they were selected, which risks they address, and whether they are proportionate to the business.
A mature approach is to use ISO 27002 as a practical tool after risk analysis, not instead of it.
Typical Mistakes and Weak Points
One of the most common mistakes is to assume that ISO 27001 is “about documents” and ISO 27002 is “about IT settings.” In reality, both standards are broader than that.
An ISMS is not only about technical protection. It also includes processes, people, suppliers, awareness, allocation of responsibilities, change management, and incident response.
Another common mistake is trying to implement every control without exception. This usually overloads the system, creates unnecessary bureaucracy, and often brings little real value to the organization’s information security.
Companies also often:
- fail to link the SoA to real risks;
- use template wording without adapting it to the business;
- confuse the mandatory requirements of ISO 27001 with the guidance provided by ISO 27002;
- describe controls on paper without embedding them into actual processes;
- underestimate the role of leadership and process owners.
What Is Reviewed During an ISO 27001 Audit
During an ISO 27001 audit, auditors are usually less interested in whether the company has read ISO 27002 and more interested in whether the ISMS has been built in a justified and consistent way.
They typically look at the following:
- whether there is a clear logic for risk assessment;
- whether the selected controls match the nature of the risks;
- whether the Statement of Applicability reflects real practice;
- whether employees understand their responsibilities;
- whether access management, incident management, change management, and supplier management processes are actually working;
- whether the system is being kept up to date.
If an organization has used ISO 27002 in a meaningful way, this is usually visible. The controls do not look random, the documents are not disconnected from practice, and the ISMS appears to be operational rather than purely formal.
Practical Recommendations
If you are just starting to implement ISO 27001, it is useful to follow a simple logic.
First, build the foundation of the ISMS: define the scope, information security policy, roles, risk assessment methodology, objectives, and key processes.
Then use ISO 27002 as a working guide when selecting and developing controls in more detail. This is especially useful when preparing the SoA and creating rules for access management, asset handling, supplier management, incident response, and cloud services.
It is also worth checking three important questions:
- does the company understand which controls it actually needs;
- can each significant control be linked to a specific risk;
- are these measures followed in real operations, and not just described in documents?
Final Thoughts
The difference between ISO 27001 and ISO 27002 is fundamental, but in practice the two standards complement each other.
ISO 27001 is the standard that sets out the formal requirements for an ISMS and is the basis for ISO 27001 certification. ISO 27002 is guidance that helps organizations choose and apply information security controls properly.
To put it very simply: ISO 27001 sets the rules of the game, and ISO 27002 helps you play by those rules effectively.
For businesses, this means the following: building an ISMS based only on the general requirements of ISO 27001, without practical work on the controls, is often not enough. But using ISO 27002 without the risk-based logic of ISO 27001 is also a mistake. A mature approach emerges when an organization uses both standards together: one as the foundation of the system, the other as a practical tool for filling it out and improving it.