ISO 27001 vs ISO 27002: What's the Difference and Why Does It Matter?

If you've spent any time researching ISO 27001, you've almost certainly come across ISO 27002 somewhere along the way. Maybe an auditor mentioned it. Maybe a consultant referred to it. Maybe you just stumbled across it and assumed it was the same thing with a different number.

It isn't.

The confusion is understandable, but it matters. And if you're in the middle of an ISO 27001 implementation, or about to start one, knowing the difference will save you a lot of unnecessary work.

Two documents, one job between them

ISO 27001 is the standard. It's the one your organisation gets certified against. It sets out the requirements for an Information Security Management System (ISMS) and defines what you must do to achieve certification. When a customer asks if you're ISO 27001 certified, this is the document that determines whether the answer is yes or no.

ISO 27002 is something different. It's a guidance document. It provides implementation advice for the controls referenced in Annex A of ISO 27001. It explains what those controls mean, how you might implement them, and gives you examples of how to apply them in practice.

Think of it this way. ISO 27001 tells you what you need to achieve. ISO 27002 is the reference guide you can use to figure out how to get there.

One sets requirements. The other offers suggestions.

Why does this confusion cause problems?

Here's where it gets frustrating in practice, and I see this regularly.

Auditors will sometimes cite ISO 27002 guidance as if it were a requirement from ISO 27001. It isn't. If an auditor tells you that you must implement a control in a specific way because ISO 27002 says so, the right response is to ask them to show you where that requirement appears in ISO 27001. If they can't point to it in the standard, it isn't a requirement.

The other pattern I see is consultants using ISO 27002 guidance to over-engineer controls beyond what the business actually needs. ISO 27002 is comprehensive by design. It covers a lot of ground. But comprehensive guidance is not the same as mandatory implementation. The question is always whether the control is appropriate for your organisation based on your risk assessment, not whether it appears in a guidance document.

ISO 27001 is clear on this point. Controls in Annex A need to be considered and either implemented or formally excluded with a justification. How you implement them is largely up to you, informed by your context and your risks.

What ISO 27002 is actually useful for

This isn't a criticism of ISO 27002. It's a useful document when used properly.

If you're implementing a control and you're not sure what good looks like, ISO 27002 is a sensible reference point. It gives you a structured way to think through your approach and can help you identify things you might have missed. For organisations with less security experience internally, it fills in gaps.

The important thing is to treat it as guidance, not gospel. Use it to inform your thinking, not to dictate your implementation.

The practical takeaway

If you're working toward ISO 27001 certification, you need to focus on ISO 27001. That's the document your auditor will assess you against. ISO 27002 is there to help you implement, not to add requirements that don't exist.

If someone in your process is citing ISO 27002 as a hard requirement, ask them to show you where that sits in ISO 27001. Push back politely but firmly. It's a fair question and a good consultant or auditor should welcome it.

Get the standard right first. Use the guidance document where it's helpful. Don't let the two get conflated into something more complicated than it needs to be.

If you're planning an ISO 27001 implementation and want a straightforward approach that focuses on real security outcomes rather than compliance theatre, get in touch with the Vorago team.