TL;DR
ISO/IEC 27001 is the standard you certify against. ISO/IEC 27002 is a reference for building the controls it names, not a checklist to work through. Pick your controls from a risk assessment first, then use ISO/IEC 27002 to help design them.
What trips people up
Teams new to ISO/IEC 27001 often work through ISO/IEC 27002 line by line and build a control for every entry. That produces a heavier, more expensive ISMS than the organization’s risk profile calls for. It still has to pass an audit that judges relevance, not volume.
This guide covers using ISO 27002 to prepare for ISO 27001 certification. Good ISO 27001 preparation keeps controls anchored to your own risk assessment, not to the guidance’s table of contents.
Sources: ISO/IEC 27001:2022 · ISO/IEC 27002:2022 · DNV
ISO/IEC 27001 certifies you. ISO/IEC 27002 does not.
An auditor certifies your organization against ISO/IEC 27001. Nobody gets certified against ISO/IEC 27002. DNV explains that “ISO/IEC 27002 is not a certifiable standard but is a comprehensive guidance document”. DNV recommends using it “as a reference for selecting and implementing controls within the ISMS based on ISO 27001’s requirements”.
That distinction sounds academic until you watch a team build its whole security program by reading ISO/IEC 27002 top to bottom. That is not how the standard works. It answers a question you ask only after your risk assessment tells you which controls you need. For the full relationship between the two documents, see our comparison of ISO 27001 and ISO 27002.
Why 93 controls is not a to-do list
ISO/IEC 27001’s own Clause 6.1.3 tells you how to use Annex A. It does not say implement everything. You determine the controls you need from your risk treatment. Then you compare that list against Annex A to check for anything obvious you missed. Annex A works as a cross-check, not a set of assignments.
A hospital, a SaaS company, and a five-person accounting firm carry different risks, different assets, and different regulatory obligations. The same 93 controls cannot be the right answer for all three. Working through ISO/IEC 27002 without a risk assessment first answers the wrong question: which of these should we build. The right question is which risks do we have.
What the checklist approach costs you
Teams without a risk assessment to anchor their decisions end up debating implementation details instead of security outcomes. Should this control be technical or procedural. Does this need its own policy. What will the auditor expect. Is this one mandatory.
None of those questions has a fixed answer, because ISO/IEC 27002 leaves room for judgment. Answering them one at a time, without a risk assessment to settle the argument, adds cost and delay. The organization still ends up unsure whether it built the right thing.
What good looks like
A control gets built because a named risk in the risk register requires it, and the record says which risk. A control that exists only because it appeared in ISO/IEC 27002 is the one an auditor questions first.
Four steps to use ISO/IEC 27002 the right way
Understand your context
Goal: know what the ISMS has to protect before you pick a single control.
List your business activities, information assets, technology environment, regulatory obligations, and existing security capabilities. This is Clause 4 work, and it comes before Annex A, not after.
Run a real risk assessment
Goal: a named, ranked list of risks, not a general sense of concern.
Identify the risks that matter to your organization and decide how to treat each one. This list, not ISO/IEC 27002’s table of contents, is what should drive every control decision that follows.
Design controls for your environment
Goal: a control that fits your risk, not a control copied from the guidance.
Once you know the risk, ISO/IEC 27002 becomes useful. Ask what addresses this specific risk in this specific environment, not what the standard lists as an option.
Build something your team will run
Goal: controls that survive contact with daily operations, not just an audit.
A control nobody follows protects nothing, whatever it looks like on paper. Design for the people who will operate it, and confirm it produces evidence you can show an auditor.
Why this should not sit with IT alone
IT teams build the technical half of an ISMS well. The other half covers governance, risk treatment, policy, legal and regulatory obligations, internal audit, and management review. That work needs compliance and risk expertise that a technical team does not always carry. Handing the whole ISMS to IT tends to reproduce the checklist problem in a different form: strong technical controls, thin governance around them.
An experienced compliance lead sorts the same 93 controls into a shorter, more useful set of questions. The lead asks what your risk assessment requires, what is practical to operate, and what evidence an auditor will ask to see.
Doing this in Canada and the United States
Certification bodies in both countries audit the same way. They are accredited by the Standards Council of Canada or by ANAB in the United States. Both are signatories to the IAF Multilateral Recognition Arrangement. Whichever one reviews your ISMS, the question stays the same. Does each control address a risk you identified, not how many entries from ISO/IEC 27002 you worked through? A certificate issued on either side of the border carries the same weight abroad for that reason.
Frequently asked questions
What is the main difference between ISO/IEC 27001 and ISO/IEC 27002?
ISO/IEC 27001 is the certifiable standard. It sets the requirements for an ISMS and is what an auditor certifies you against. ISO/IEC 27002 is a reference document that explains how to implement security controls, and it carries no certification of its own.
Why shouldn’t you use ISO/IEC 27002 as an implementation checklist?
ISO/IEC 27002 does not know your risks, your assets, or your regulatory obligations. Working through it top to bottom builds controls your risk assessment never asked for. That adds cost without matching the security work to your risk profile.
Does implementing more controls make an organization more secure?
No. An effective ISMS addresses identified risks with appropriate controls. A larger number of controls that do not map to a named risk adds cost and complexity without a matching security benefit.
How should an organization decide which controls to implement?
Through a risk assessment. ISO/IEC 27001 Clause 6.1.3 has you determine your controls from that assessment. You then check the result against Annex A for anything obvious you missed. Annex A is the cross-check, not the starting point.
Does ISO/IEC 27002 offer certification?
No. ISO/IEC 27002 is not a certifiable standard. Certification runs against ISO/IEC 27001, which references Annex A and, through it, the guidance in ISO/IEC 27002.
Should IT alone be responsible for ISMS implementation?
No. An ISMS covers governance, risk management, policy, legal and regulatory obligations, internal audit, and management review, alongside the technical controls IT builds. That spread of work needs compliance and risk expertise as well as technical skill.
Key takeaways
- ISO/IEC 27001 is certifiable. ISO/IEC 27002 is guidance, and nobody gets certified against it.
- Annex A is a cross-check against your risk assessment, per Clause 6.1.3, not a checklist to complete.
- 93 controls across 4 themes are all optional until a named risk requires one.
- Building controls straight from ISO/IEC 27002 without a risk assessment adds cost and still risks the wrong controls.
- An ISMS needs compliance and governance expertise alongside IT, not IT alone.
- Certification bodies in Canada and the United States both judge controls against risk, not against checklist completion.
Build controls from risk, not from a table of contents
Nank.ai runs ISO 27001 programs for companies in Canada and the United States. It starts with the risk assessment that should drive every control decision after it.