ISO 27001 vs ISO 27002: what each one requires

ISO 27001 vs ISO 27002: which one an audit tests

A customer, contract or regulator has asked for ISO 27001, and the next question is whether you also need ISO 27002. The short answer is that ISO/IEC 27001:2022 is the certifiable requirements standard, and ISO/IEC 27002:2022 is non-certifiable guidance for the 93 Annex A controls. An auditor tests your organization against the requirements of 27001, including the clauses on context, leadership, planning, support, operation, evaluation and improvement, and checks whether the Annex A controls you selected are implemented and working. You do not certify to 27002. You use it as a reference for how to implement a control well.

What this means in practice depends on three documents you own: your information security risk assessment, your scope, and your Statement of Applicability. The risk assessment decides which risks matter. The scope decides which systems, sites and services the management system covers. The Statement of Applicability records which Annex A controls you apply, which you exclude with a reason, and how each applied control is implemented. Section 27002 then supplies the implementation guidance for each control, which helps you write a defensible procedure. Ask your implementation partner or internal team to show, for each control, the 27002 guidance they followed and where the resulting evidence lives.

The organization owns its controls and the decisions behind them. An implementation partner can prepare systems, procedures and evidence, but only an accredited certification body can issue a certificate after an independent audit. Confirm the certification body's accreditation before you sign, and ask it how it will audit against the control attributes and purposes introduced in the 2022 edition. Clear ownership of the Statement of Applicability is the most reliable way to avoid paying for a certificate that does not match what your organization actually does.

What each document asks for and whether it can be certified

ISO 27001 sets the requirements an organization must meet to be certified, and ISO 27002 explains how to implement the controls that ISO 27001 lists. The cards below separate what can be audited from what is advisory, and show how the risk assessment and Statement of Applicability connect the two.

ISO 27001 clauses 4 to 10

These clauses set the management system requirements: context, leadership, planning, support, operation, performance evaluation and improvement. An organization must meet every one of them in full to be certified, and an auditor tests each against documented evidence. Clauses 4 to 10 are certifiable, so a gap in any of them can produce a nonconformity even when the Annex A controls look sound. Check that the management system work, not only the technical controls, is in place before the audit.

Annex A of ISO 27001

Annex A is a normative list of 93 controls in four themes: organizational, people, physical and technological. Each control is drawn from ISO/IEC 27002:2022, and the standard makes the list binding in the sense that an organization must address each control or justify its exclusion. Certification assesses whether the controls you select are implemented and effective, not whether you adopted the whole list.

ISO 27002 control guidance

ISO/IEC 27002:2022 gives implementation guidance for each Annex A control, including purpose and how to put it into practice. ISO states that ISO/IEC 27002 cannot itself be certified, so no body can issue a certificate against it. Auditors use it as a reference for what good implementation looks like, but it does not add requirements of its own. Read it to design controls, and expect auditors to test the outcome rather than the guidance text.

The Statement of Applicability

The Statement of Applicability records which Annex A controls the organization applies, which it excludes, and why, with the status of each. It is the document auditors read first to see how the controls connect to the organization's risks. Exclusions need a clear reason tied to the risk assessment, because an unjustified exclusion is a common audit finding. Ask your certification body early what format and level of justification it expects.

The risk assessment

The risk assessment identifies information security risks to the organization and determines the risk treatment needed, and this drives which controls apply. ISO/IEC 27002 notes that not all of its controls are applicable to all organizations and that additional controls may be needed for specific risks. A control chosen without a risk behind it has no clear reason to exist. Confirm that your risk methodology is documented and that the Statement of Applicability traces each control back to it.

Sector and organization-specific guidelines

ISO/IEC 27002 can serve as the basis for guidelines written for a sector or a single organization, such as a bank, a hospital or a cloud provider. These guidelines add detail on how to apply controls in that setting. They are not certifiable on their own and do not replace the ISO 27001 requirements or the Annex A list. Use them to explain how you implement a control, and confirm with your certification body that the guidelines fit inside your certified scope.

Why ISO 27002 cannot be certified, and what an auditor checks instead

ISO/IEC 27002 cannot be certified because it is a reference set of generic information security controls with implementation guidance, not a management system standard. No organization is certified against it. The certifiable document is ISO/IEC 27001:2022, which sets the requirements for an information security management system (ISMS) and points to the Annex A controls, whose content is drawn from 27002. Microsoft's compliance documentation makes the same distinction when it names 27001 as the audit vehicle. Buyers who ask for a "27002 certificate" are asking for something that does not exist, and a supplier offering one should be questioned on what it actually covers.

The guidance in 27002 also makes clear why certification sits with the management system. ISO/IEC 27002 states that an information security policy can only maintain risk, whereas compliance with that policy can modify risk. An assessor therefore looks for evidence that people follow the policy and that the chosen control operates, not for the policy text alone. The same guidance says not all of its controls can apply to every organization and that additional controls may be needed for specific risks. This is why the organization, not the standard, decides which controls apply.

An auditor tests the Annex A controls listed in the organization's Statement of Applicability (SoA) against the scope the organization stated, and checks that each selected control is implemented and effective. The assessor may use 27002 as a reference for what sound implementation looks like, but the finding is about the organization's own systems and records. Before the audit, confirm with your certification body how it will treat 27002 guidance in its reports, and check that every exclusion in your SoA has a justification the auditor can follow.

How organizations use ISO 27002 in three different situations

When a team implements an Annex A control for the first time, ISO/IEC 27002 supplies the implementation guidance for that control. Start by reading the 27002 entry for the control, then turn its guidance into four decisions the organization records: who owns the control, which procedure runs it, which tool performs it and which evidence proves it ran. The 27002 text is generic, so the team narrows it to its own systems and risks.

Owner: Name one accountable role for the control, such as the identity lead for an access control, and record it in the control register.
Procedure: Write a short, dated procedure that states the trigger, the steps and the exception path, using the 27002 guidance as the checklist of topics to cover.
Tooling: Select the system that enforces the control, such as a self-hosted identity provider or a logging pipeline, and confirm it can produce the records the procedure needs.
Evidence: Define the artifact an assessor will sample, such as exported access reviews or change tickets, and set where it is stored and how long it is kept.
Test run: Execute the control once end to end and keep the output, so the first evidence sample is a real operating record.

Before closing the control, confirm that the owner, procedure, tool and evidence all match the wording of the Statement of Applicability entry.

Which reference to use for which job

This table compares four common starting points for building an ISO 27001 control set, from working directly through ISO/IEC 27002 guidance to relying on a consultant's control set. Read each row for what the option produces and what you still need to confirm with your certification body before the Statement of Applicability is final.

Option	When it fits	What it produces and what it does not do
Working from 27002 guidance control by control	Teams that want to understand the intent behind each Annex A control before choosing how to meet it, or that must justify implementation choices to an auditor.	Produces implementation decisions and written rationale for each Annex A control. It does not replace the Statement of Applicability, and 27002 itself cannot be certified.
Internal control library mapping each Annex A control to owners and evidence	Organizations with a named owner for each control area and an evidence store they already maintain, where the assessor will need to trace each control to a person and a record.	Produces a traceable register of control owners, procedures and evidence locations. It does not prove the controls operate; the certification body samples evidence over time to test that.
Using a GRC tool's ISO 27001 library as a starting point	Teams that want a structured checklist and task workflow quickly, and that will adapt the library's wording to their own risks and systems.	Produces a populated control list, tasks and reminders. Library text is generic, so confirm that the tool's content matches your scope, and confirm with the certification body which tool outputs they accept as evidence. No tool holds an ISO 27001 certification on your behalf.
Relying on a consultant's control set	Organizations without in-house ISMS experience that need a control set delivered, with the consultant's role limited to preparation and the organization accepting ownership of each control.	Produces a control set and documentation drafted by the consultant. The organization still owns the controls, approves the Statement of Applicability and must operate the controls. Confirm the consultant's independence from the certification body and the handover of ownership in writing.

What the 2022 edition changed in the Annex A controls and attributes

The 2022 edition replaced a control set that was large and grouped by objective with a much tighter one. According to IAF MD 26:2023, the 2013 edition carried 114 controls across 14 clauses, while the 2022 Annex A lists 93 controls in four themes. Of the 93, 11 controls are new, 24 merge earlier controls and 58 are updated. For a certification team, the practical effect is that a 2013 control number and its wording rarely map one to one, so an existing Statement of Applicability built on the old numbering needs to be rewritten rather than relabeled. The same document sets the deadline that matters most for planning: all certifications to ISO/IEC 27001:2013 had to expire or be withdrawn by 31 October 2025, the end of the 36-month transition period.

The bigger structural change is that each control now carries attributes and a purpose. ISO/IEC 27002:2022 explains this in its Annex A, *Using attributes*, and provides Annex B, which corresponds its controls to the 2013 edition. Attributes such as control type, information security properties, cybersecurity concepts and operational capabilities let an organization filter and group controls for its own risk treatment, instead of reading them only by theme. Use Annex B as the starting point when you migrate evidence from old control references, then check each mapping against the 2022 text rather than trusting a third-party table.

Confirm attribute values against the current published tables before you tag your own controls. The March 2022 corrected version of ISO/IEC 27002 moved the attribute value #information_security_assurance for control 5.22 from the Security domains column to the Operational capabilities column. Any internal register, GRC library or evidence index that copied the February 2022 values will be wrong for that control. Ask your tool vendor or consultant which version of the standard their libraries were built from, and record the version in your Statement of Applicability so an auditor can see which tables you used.

How to turn 27002 guidance into control evidence an auditor can test

This sequence moves an organization from its risk picture to a Statement of Applicability, then from the 27002 guidance for each control to dated evidence that an independent certification body can sample and test before the audit.

Confirm scope and the risk assessment
The organization sets the boundary of its ISMS, covering the business units, locations, systems and suppliers in scope, and identifies the information security risks inside that boundary. Leadership owns this step, with risk owners reviewing the results. ISO/IEC 27005:2022 is one supported reference for the risk method, though the organization may choose another documented approach. The step is done when the scope statement and a risk register with agreed risk criteria and treatment decisions are approved and dated.
Select Annex A controls in the Statement of Applicability
Using the risk treatment decisions, the organization selects the Annex A controls it needs, drawn from the 93 controls in four themes. Each control that is excluded needs a documented justification, and any controls not in Annex A that the risks require are added with their own description. The selections, justifications and current implementation status are recorded in the Statement of Applicability. The step is done when every Annex A control is marked as applicable or excluded, with a reason, and the document has been approved by management.
Read the 27002 guidance for each control
For each applicable control, the team reads the implementation guidance in ISO/IEC 27002:2022, which explains the purpose and typical measures for that control. The guidance is not a checklist that must be copied, since ISO states that not all of its guidance applies to every organization and that additional controls may be needed for specific risks. The output is a short note per control that records which parts of the guidance apply to this organization and which do not, with the reason.
Write the implementation for each control
The control owner writes how the control operates in this environment. The write-up names an accountable owner, the procedure people follow, and the technical setting that enforces it, such as an access rule, a logging configuration or a backup schedule. Where the control depends on a tool, the configuration is referenced by name. The step is done when every applicable control has a named owner and an implementation record that a person outside the team could follow.
Collect dated evidence for each control
The team gathers records that show the implementation actually runs, such as configuration exports, access reviews, audit logs, change and incident tickets, training completions and signed management reviews. Each item needs a date, a source system and an owner, so an assessor can see when the control operated. Evidence should be captured on a routine basis rather than assembled at audit time. The step is done when each control has at least one dated artifact that maps back to its implementation record.
Check evidence against the Statement of Applicability
Before the certification body arrives, the team walks the Statement of Applicability line by line and confirms that each applicable control has an implementation record and evidence covering the audit period. Gaps, outdated documents and controls whose stated implementation does not match the configuration are logged and fixed or corrected in the SoA. Ask the implementation partner or internal reviewer to sample a few controls as an assessor would. The step is done when the SoA, implementation records and evidence agree and the open gaps are recorded with owners.

Common mistakes when organizations treat 27002 as a checklist

ISO/IEC 27002 gives control guidance, not requirements, so most failures come from using it as a shopping list. The six pitfalls below share one root cause: the organization has not tied each control to its own risk assessment, owners and evidence, and an auditor will test exactly that link.

Copying 27002 wording into policies

Organizations often paste the guidance text from ISO/IEC 27002 into their policies unchanged. The standard itself says a policy can only maintain risk, and that compliance with the policy is what modifies it, so a policy that restates generic guidance does not show that risk was treated. Check that each policy names the risks it addresses, the people who operate it, and the systems it applies to, and that the wording reflects your environment rather than the generic set.

Claiming certification to 27002

ISO/IEC 27002 cannot be certified, so no certification body will issue a certificate against it. Certification is to ISO/IEC 27001, which requires an ISMS and relies on 27002 for control implementation guidance. Check that marketing, customer questionnaires and contracts refer to ISO/IEC 27001 certification, and that any reference to 27002 describes it as guidance used to implement controls.

Excluding Annex A controls without justification

Annex A is normative, and the Statement of Applicability must record which of its 93 controls apply and why others are excluded. Teams often drop controls such as physical or supplier controls because they seem irrelevant, without linking the decision to the risk assessment. Check that every exclusion has a written reason tied to a risk, and that the reason survives a review by someone who did not make the decision.

Implementing controls with no owner or evidence

A control that exists only in a document has no operator and no proof it runs. Assessors look for who performs the control, how often, and what record shows it happened, such as an access review export, a change ticket or a backup restore log. Check that each implemented control has a named owner, a defined frequency and a stored evidence location before the audit begins.

Ignoring sector and customer requirements

ISO/IEC 27002 states that its controls are generic, that not all of them apply to every organization, and that additional controls may be needed for specific risks. Regulators, banks, health providers and large customers often add their own requirements on top. Check contracts, sector rules and customer security schedules for obligations that the generic control set does not cover, and record how each one is met.

Treating a consultant's library as an audit-ready ISMS

Some consultants sell a pre-written control library mapped to ISO/IEC 27002. A library is a starting point, but an ISMS also needs a risk assessment, a Statement of Applicability, internal audits, management review and corrective actions that run over time. Check whether the library includes an operating process, owners and evidence routines, and whether the implementation partner is separate from the certification body that will audit the work.

Questions buyers ask about ISO 27001 and ISO 27002

Do we need to buy and implement ISO 27002 to get ISO 27001 certified?

No. ISO 27001 is the certifiable requirements standard, and it does not oblige you to buy or follow ISO/IEC 27002 word for word. Annex A of ISO/IEC 27001:2022 lists 93 controls in four themes, and those controls are taken from ISO/IEC 27002:2022, which gives implementation guidance for each one. Many organizations buy 27002 because it explains what each control is meant to achieve and how others implement it, which makes the Statement of Applicability easier to write. Treat it as a reference you consult when you design and document controls, not as a checklist you must pass. Your risk assessment decides which Annex A controls apply and whether you need controls beyond them.

Can our organization be certified to ISO 27002?

No. ISO states that ISO/IEC 27002:2022 cannot itself be certified to, and Microsoft's compliance documentation makes the same point: 27002 is not a management standard. The certifiable vehicle is ISO/IEC 27001:2022, which requires an information security management system (ISMS) meeting clauses 4 to 10 and the applicable Annex A controls. Certification is issued by an accredited certification body after an independent audit. Be cautious with any vendor or consultant who offers a 27002 certificate, because no accredited body issues one.

Does the auditor test us against ISO 27002 or ISO 27001?

The auditor tests against ISO/IEC 27001:2022. The audit assesses whether your ISMS meets the requirements of clauses 4 to 10, whether your Statement of Applectability is justified, and whether the Annex A controls you selected are implemented and operating. ISO/IEC 27002 is used as the reference for how controls can be implemented, so auditors may read it to understand intent, but a gap against 27002 guidance on its own is not a nonconformity. Ask your certification body how it applies 27002 during the audit before you start, since practice can differ in the details.

How much effort does mapping Annex A to our own controls take, and what drives it?

The effort depends on how many controls you already run, how many systems and sites are in scope, and how well your existing documentation matches the control attributes. Three factors matter most. First, the number of Annex A controls you select and justify in the Statement of Applicability, since the 2022 edition contains 93 controls, with 11 new, 24 merged and 58 updated compared with 2013. Second, the state of your evidence: an existing policy set and logs make mapping faster than building them. Third, how many of your own internal control frameworks you need to reconcile. Ask any provider to estimate effort from a written scope that lists sites, systems, existing documents and the number of controls to be mapped, and to state which items are one-time and which must be refreshed each year.

Can our own team do the Annex A mapping without outside help?

Yes, if someone on the team understands both the risk assessment and the controls well enough to justify each decision. Many teams start by reading the 2022 Annex A control titles and attributes, then drafting a Statement of Applicability that links each applicable control to the risk treatment it supports. Outside help is most useful for a second opinion on scope, for technical implementation of controls on infrastructure, and for collecting evidence in a form the auditor will accept. Whichever route you choose, the organization owns the controls and the decisions. An implementation partner prepares systems and evidence, and only an independent certification body issues the certificate.

What should we ask a consultant about their use of ISO 27002?

Ask how they will use 27002 to design and document each control, and how that guidance will be tied to your risk assessment rather than copied into policies. Ask whether they will produce the Statement of Applicability and justify exclusions, and who on your side must approve those decisions. Ask which parts of the work they will hand over as working documents, such as procedures, configuration records and evidence queries, and whether your staff will be able to run them afterwards. Confirm that they do not issue certificates or audit reports, and that they will not also serve as your certification body. Request a written scope listing deliverables, assumptions and the controls covered before work begins.

Which parts of ISO 27002 should we read first?

Start with the introduction, which explains that a control is a measure that modifies or maintains risk, and that an information security policy only maintains risk while compliance with it modifies risk. Then read the guidance for the Annex A controls that your risk assessment has flagged as relevant. ISO notes that not all controls apply to all organizations and that additional controls may be needed for specific risks, so do not assume a full read of all 93 controls is required. The current third edition is dated February 2022, with a corrected version in March 2022, so confirm you hold that version when you cite it.

How DeployOpen prepares systems and evidence for the Annex A controls

DeployOpen works on the implementation side of ISO 27001 and the ISO 27002 guidance that shapes each Annex A control. We prepare self-hosted systems and the evidence they produce inside your own infrastructure, while the organization owns its controls and an independent certification body decides certification.

How we scope

We agree a written scope listing which Annex A controls, systems and sites the engagement covers before work starts.
Engagements are fixed-scope, so deliverables and timelines are confirmed in writing before any build begins.
We confirm which controls the organization will implement itself, which need its policy owners, and which need outside input.

How we build

We configure self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks to run the agreed controls.
We map each control to its implementation guidance in ISO/IEC 27002 and record how the system meets the stated control purpose.
We test configurations against the control intent and document gaps so your team can decide how to close them.

How we hand over

We deliver documented configurations, runbooks and evidence collection outputs that your team can show to an assessor.
We leave control ownership, Statement of Applicability entries and policy approval with your named owners for their own review.
We walk your team through where each piece of evidence lives so they can answer an auditor's questions without us.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial handover.
Retainers can cover updates to controls and evidence as your systems change between certification audit cycles.
Any question about certification outcomes, accreditation or audit findings goes to your independent certification body, which we do not replace.

ISO 27001 vs ISO 27002: requirements versus control guidance