The ISO/IEC 27000 Family of Standards Explained

Dario Fenwick found out the hard way that "ISO 27002" and "ISO 27001" are not interchangeable words for the same certificate.

Dario was VP of Compliance at Northlight Analytics, a 140-person SaaS company that scores fraud risk for mid-market lenders. In the spring of a renewal cycle, Northlight's largest client — a European regional bank — sent over an updated vendor security addendum. Buried in section 4.3 was a single line: "Vendor shall maintain current certification to ISO/IEC 27002." Dario, six months into the role and under pressure to keep an eight-figure contract intact, forwarded the clause to a certification body his predecessor had used for a SOC 2 engagement, asked for a quote on "getting 27002 certified," and got a proposal back within a week. He signed it. Northlight paid a retainer, assigned two full-time engineers to control documentation, and spent eleven weeks building an Annex-A-shaped binder before the lead auditor — on a scoping call, not even the audit itself — gently pointed out that ISO/IEC 27002 is a code of practice, not a management-system standard, and that no certification body on earth issues a "certificate of conformity to 27002" because the standard was never written to be audited against. What the bank almost certainly meant, and what most banks mean when they write that clause, was ISO/IEC 27001 — the standard 27002 exists to support.

By the time the mistake surfaced, Northlight had burned roughly $45,000 in consulting fees and internal engineering time, and — worse — had lost seven weeks of runway against a client-imposed compliance deadline. Dario had to go back to the bank's third-party risk team, admit the error, and negotiate a 90-day extension while Northlight restarted the engagement correctly: an ISO/IEC 27001 Information Security Management System (ISMS), using ISO/IEC 27002 exactly as intended — as the implementation guidance for Annex A controls, not as the certification target itself. The extension was granted, but only after an uncomfortable set of calls, and only because Northlight's CEO personally vouched for the timeline.

Dario's error wasn't stupidity. It was a symptom of a much more common problem: the ISO/IEC 27000 family has more than forty published and in-development documents, they share a numbering scheme that looks almost arbitrary from the outside, and vendors, clients, and even some junior auditors routinely use the numbers interchangeably in conversation. "Get ISO certified" gets said as if there's one door to walk through, when in reality there's one certifiable requirements standard (27001), a shelf of guidance documents that support it, and a smaller set of topic- and sector-specific extensions that layer certifiable scope on top of it. Knowing which is which — before you sign a proposal, budget a project, or promise a client something in writing — is the difference between an eleven-week detour and a straight line to the right outcome.

This article is that map.

Dario's mistake is more common than most compliance leaders like to admit, and it rarely announces itself as clearly as it did for Northlight. More often it shows up quietly: a proposal that scopes the wrong deliverable, a marketing page that claims a certification nobody actually holds, an engineering team that spends a quarter building bespoke incident-response tooling that ISO/IEC 27035 would have given them a head start on for the cost of reading a PDF. The dollar figures vary, but the root cause is nearly always the same one Dario ran into: nobody sat down and mapped the family before committing budget to a number.

Who This Is For

This is for the compliance lead, IT manager, founder, or security practitioner who has heard "27001," "27002," "27005," "27017," "27701," and a half-dozen other numbers used loosely in sales calls, RFPs, or client questionnaires and wants to know, precisely, what each one is, whether it's something you can be audited and certified against, and how it fits with the others. You'll walk away knowing which single standard is the certifiable core, which standards are pure guidance you'll never see a certificate for, which extensions add certifiable scope on top of your existing ISMS, and — critically — which document to reach for the next time someone in a contract negotiation throws a number at you that you don't immediately recognize. This isn't a substitute for reading the standards themselves once you've narrowed down which ones matter to you — it's the orientation that tells you which ones are worth the reading time in the first place.

How the ISO/IEC 27000 Family Is Structured

The ISO/IEC 27000 family (formally the "ISO/IEC 27000 series," maintained jointly by ISO and IEC under Joint Technical Committee 1, Subcommittee 27) is a set of standards that all address information security management, but they don't all do the same job. It helps to think of the family in three concentric layers, all orbiting a single center of gravity.

The core. ISO/IEC 27000 gives you shared vocabulary and a plain-language overview of the whole family. ISO/IEC 27001 is the only standard in the family that states formal, auditable requirements for an Information Security Management System (ISMS) — it's the one you actually get certified against. ISO/IEC 27002 is the companion code of practice: detailed implementation guidance for the security controls that ISO 27001's Annex A merely lists by name.

The ISMS support layer. A second ring of standards exists purely to help organizations run the ISO 27001 management system well: how to implement it (27003), how to measure whether it's working (27004), how to manage the risk process that feeds it (27005), how certification bodies themselves get accredited to audit it (27006), and how to actually conduct an ISMS audit (27007). None of these are certifiable in their own right — they're operating manuals for people already working inside, auditing, or accrediting against the 27001 system.

The extension and topic-specific layer. A third ring narrows the same ISMS approach onto a specific technology, sector, or discipline: cloud services (27017), PII in public clouds (27018), privacy management as a full extension (27701), ICT continuity (27031), incident management (27035), supplier relationships (27036), digital evidence handling (27037), and further out, niche standards for governance (27014), energy (27019), storage (27040), and health informatics (27799). A few of these — most notably 27701 and, in practice, 27017 — can be added to an existing ISO 27001 certificate as a formal extension of scope. Most of the rest are guidance documents your ISMS can reference and apply, with no separate certificate attached.

None of these three layers operate in isolation, and none of them work without ISO/IEC 27001 sitting underneath. You don't implement 27017 instead of 27001, you don't run a risk process under 27005 instead of satisfying Clause 6.1, and you don't get a 27701 certificate without first — or simultaneously — earning a 27001 certificate to attach it to. Every layer past the core exists to make the core standard easier to build, easier to run, or narrower and more specific for a given audience.

Here's that structure as a diagram — 27001 at the center, with the guidance ring and the extension ring both feeding into it.

That diagram is illustrative rather than an exhaustive dependency graph — ISO doesn't publish an official org chart of the series — but it reflects how the family actually gets used in a live ISMS program: one requirements standard in the middle, a support ring that helps you run it, and an extension ring that lets you narrow or broaden certifiable scope for a specific context.

A quick note before we go further: ISO doesn't guarantee that every number in a range is populated, and not every standard in the family reaches a stable published state at the same time — some are still working drafts, some get merged into multi-part structures, and numbering gaps are normal. Treat the ranges above as a rough orientation, not a strict rulebook.

A Quick Word on Where This Family Came From

The 27000 family didn't appear as a single coordinated release — it grew, standard by standard, out of a lineage that started with a UK national standard for information security management, BS 7799, in the 1990s. ISO adopted and renumbered that lineage first as ISO/IEC 17799 and then, in 2005, as the first edition of ISO/IEC 27001, establishing the numbering block the rest of the family has grown into ever since. If you want the fuller story of how a national standard became an international one, and how the 2013 and 2022 revisions reshaped the requirements and Annex A control set along the way, our History and Evolution of ISO 27001 piece covers that timeline in detail.

What matters for this article is the practical consequence of that organic growth: the family wasn't designed top-down with a tidy numbering plan the way a well-organized software API might be. New standards got assigned the next available number in a loosely thematic range as working groups within ISO/IEC JTC 1/SC 27 — the joint technical subcommittee responsible for the series — proposed and developed them over roughly two decades. That's why 27017 (cloud) and 27018 (cloud PII) sit near each other, why 27035 and 27036 (incident management and supplier relationships) are numbered close together, and why some ranges have gaps or standards still moving through drafting stages. Treat gaps in the numbering as normal, not as missing documents you've failed to find.

The Core Three: 27000, 27001, and 27002

Almost every conversation about the family starts with these three documents, and almost every point of confusion I've untangled with a client traces back to blurring the line between them.

ISO/IEC 27000 — Overview and Vocabulary

ISO/IEC 27000 is the family's shared dictionary. It defines the terms used consistently across the whole series — "asset," "risk," "information security event," "top management," "interested party," and dozens more — so that when 27001 says "risk owner" and 27005 says "risk owner," they mean the same thing. It also gives a short, readable overview of how the family fits together, which makes it a genuinely useful first read for anyone new to the topic.

Two things make 27000 unusual in the family: it is not certifiable (there's nothing to audit — it's reference material), and it is free. ISO publishes it at no cost specifically because shared vocabulary is a public good for the standard to function; every other standard in the series is a paid publication. If you're onboarding a new compliance hire or trying to get a skeptical engineering team fluent in the language auditors use, 27000 is the cheapest, fastest way to do it — and it pairs well with an internal glossary of ISO 27001 terminology so your team has both the formal definitions and the practitioner explanations in one place.

ISO/IEC 27000 also gets revised periodically to stay in sync with terminology changes elsewhere in the family — most recently keeping pace with the 2022 refresh of 27001 and 27002 — so if your team is working from a copy someone downloaded years ago, it's worth confirming you're citing current terminology rather than a superseded edition before you drop a definition into a policy document. PentesterWorld's own ISO 27001 Glossary of Terms mirrors this same vocabulary in plain language for teams who want a quick lookup without opening the standard itself.

ISO/IEC 27001 — ISMS Requirements (the Certifiable Standard)

ISO/IEC 27001 is the only standard in the entire 27000 family that an accredited certification body can audit you against and issue a certificate for. Everything else in this article exists to support, extend, or explain some part of what 27001 requires. The standard itself has two halves: the main body (Clauses 4 through 10), which sets out mandatory management-system requirements — context, leadership, planning, support, operation, performance evaluation, and improvement — and Annex A, a reference list of 93 security controls across four themes (organizational, people, physical, and technological) that you select from and justify in your Statement of Applicability based on your risk assessment.

This is the anchor of the family for a simple reason: certification bodies, auditors, regulators, and clients treat "ISO 27001 certified" as a specific, verifiable claim with teeth — a third party has confirmed, through a structured audit, that your ISMS meets the standard's requirements and that you've operated it long enough to produce evidence. No other document in the family carries that same weight on its own. If you're building institutional understanding of the standard from the ground up, the ISMS core concepts explained is the right starting point before layering in the rest of the family.

Something worth flagging for anyone new to the family: certification is granted against a defined scope, not against "the whole company" by default. Two organizations can both hold valid ISO/IEC 27001 certificates that cover very different footprints — one covering a single product line or data center, another covering the entire enterprise — which is exactly why experienced vendor-risk teams ask to see the certificate's scope statement, not just the logo on a slide deck. A certificate that excludes your most important product line is technically valid and practically useless to a client evaluating that product.

ISO/IEC 27002 — Information Security Controls (Not Certifiable)

ISO/IEC 27002 is where Dario's contract went wrong, and it's worth being blunt about why: 27002 is a code of practice, not a management-system specification. It takes the same 93 controls that appear by name only in ISO 27001's Annex A and, for each one, gives you a purpose statement, implementation guidance, and additional notes on how organizations typically apply it. It also adds five attributes to every control — control type, the information security properties it supports (confidentiality, integrity, availability), the cybersecurity concepts it maps to (Identify, Protect, Detect, Respond, Recover), operational capabilities, and security domains — which is genuinely useful for tagging and reporting but is guidance metadata, not an auditable requirement.

Because 27002 describes how you might satisfy a control rather than whether you must have one, there is no "ISO 27002 certificate." Certification bodies audit your ISMS against ISO 27001's clauses and your chosen Annex A controls; they use 27002 the way you should — as a reference for what "good" looks like for a given control — not as a target of its own. For a control-by-control walkthrough of how the two standards divide labor, see ISO 27001 vs ISO 27002: Understanding the Difference, and for the complete control set at a glance, our Annex A cheat sheet covering all 93 controls is the fastest reference to keep on hand while you read 27002's guidance for each one.

The 2022 edition of 27002 also reorganized the control set from the older 2013 structure's fourteen categories down to four themes, added eleven genuinely new controls, and introduced the five-attribute tagging system mentioned above — a change significant enough that teams still working from a 2013-era binder should treat a refresh as overdue, not optional, since your Statement of Applicability needs to reference the current structure to pass a Stage 2 audit cleanly.

"I tell every new client the same thing in the kickoff call: 27001 is the exam, 27002 is the study guide. Nobody gets a diploma for owning the study guide." — Renata Achebe, Lead ISMS Auditor, Kestrel Assurance Partners

The relationship among these three is worth internalizing before you go any further into the family: 27000 gives you the words, 27001 gives you the rules, and 27002 gives you the how-to manual for the controls those rules point at. Every other standard in the series attaches to one or more of these three in a supporting role.

The ISMS Support Standards: 27003–27007

Once you're actually running an ISO 27001 program, a second ring of standards becomes relevant — not because you'll be certified against any of them, but because each one answers a specific operational question that 27001 raises without fully answering itself. Think of these as the operating manuals for the people building, measuring, auditing, and accrediting the ISMS.

ISO/IEC 27003 — ISMS Implementation Guidance

ISO/IEC 27003 walks through ISO 27001's Clauses 4–10 in sequence and offers practical, non-mandatory guidance for satisfying each one — how to define scope realistically, what a leadership commitment actually looks like in practice, how to structure objectives so they're measurable. It's the standard I hand to a first-time implementation lead who has read 27001 itself and still isn't sure what a compliant "context of the organization" document should contain. It doesn't add requirements; it translates the sometimes terse language of the requirements standard into workable steps, complementing structured roadmaps like our implementation roadmap from gap analysis to certification. I've watched teams shave real weeks off a first-time build simply by working through 27003's guidance on Clause 4 scoping before touching a single control — getting scope wrong early cascades into rework everywhere downstream, and 27003 exists specifically to prevent that.

ISO/IEC 27004 — Monitoring, Measurement, Analysis, and Evaluation

ISO 27001's Clause 9.1 requires you to monitor and measure the effectiveness of your ISMS and controls, but it doesn't tell you how to design a metrics program. ISO/IEC 27004 fills that gap: it covers how to select what to measure, how to build measurement constructs (base measures, derived measures, indicators), and how to structure a monitoring program that produces evidence an auditor can actually evaluate rather than a wall of dashboards nobody trusts. Organizations that skip this thinking tend to show up to Stage 2 audits with either no metrics or metrics nobody can explain the derivation of — both are avoidable with a half-day workshop grounded in this standard. A metrics program built around 27004's structure typically lands somewhere between eight and fifteen tracked indicators for a mid-size ISMS — enough to demonstrate the system is actively monitored without drowning the management review team in numbers nobody acts on.

ISO/IEC 27005 — Information Security Risk Management Guidance

ISO/IEC 27005 is the risk management companion to 27001's Clause 6.1 requirements, and it's one of the most frequently referenced standards in the family because risk assessment is where most ISMS programs live or die. It doesn't mandate a specific methodology — you're free to build your own — but it lays out the process architecture: risk identification, analysis, evaluation, treatment, acceptance, communication, and monitoring, in a cycle that maps cleanly onto 27001's planning clause. For the full mechanics of how the two standards interact, see ISO 27005 and ISO 27001: Information Security Risk Management Guidance. It also sits comfortably alongside the broader enterprise risk discipline in Integrating ISO 31000 with ISO 27001 Risk Management — 31000 handles risk management at the whole-organization level, while 27005 narrows that same thinking specifically to information security. If your team is still assembling the mechanics of a working risk process, our ISO 27001 Risk Register Template gives you a structured starting point that already reflects 27005's process stages. Because 27005 is method-agnostic, it works equally well whether your organization prefers a qualitative heat-map approach or a more quantitative, loss-exposure-based model — the standard cares that your process is consistent and repeatable, not which scoring convention you chose.

ISO/IEC 27006 — Requirements for Certification Bodies

ISO/IEC 27006 is aimed at an audience most ISMS implementers never read directly: the certification bodies themselves. It sets the competence, impartiality, and procedural requirements a certification body must meet to be accredited to issue ISO 27001 certificates in the first place. You'll rarely need to open this document as an implementer, but understanding that it exists explains why certification bodies behave the way they do — mandatory audit-day calculations based on headcount and complexity, strict separation between consulting and certifying arms of the same firm, and rigid surveillance-audit cadences all trace back to 27006's requirements on the certification body, not to 27001 itself. It's worth a glance before you shortlist auditors; see How to Choose an ISO 27001 Certification Body for what accreditation under 27006 should mean in practice when you're vetting proposals. It's also the reason certification bodies can't simultaneously consult on your ISMS build and certify it — 27006's independence requirements treat that combination as an unacceptable conflict of interest, which is worth knowing before you assume your implementation consultant can also serve as your auditor.

ISO/IEC 27007 — Guidelines for ISMS Auditing

ISO/IEC 27007 extends the general management-system auditing principles of ISO 19011 specifically to information security management systems. It gives both internal auditors and external certification auditors a consistent methodology for planning audits, sampling evidence, interviewing control owners, and writing findings. If your internal audit function has ever produced a report that reads like a compliance checklist rather than a risk-informed assessment, 27007 is usually the missing ingredient — it pushes auditors toward evaluating whether controls are effective, not just present.

"27007 changed how our internal audit team writes findings. We went from 'control 8.8 exists' to 'control 8.8 exists but the vulnerability scan cadence doesn't match the risk register's stated frequency' — and that second sentence is the one that actually gets budget approved." — Colm Vasquez, Head of Internal Audit, Fenbrook Logistics Group

The Extension and Topic-Specific Standards

The third ring of the family takes the same ISMS logic and narrows it onto a specific technology, sector, or discipline. A handful of these function as genuine extensions of certifiable scope; most are guidance documents you apply within your existing ISMS without a separate certificate. Getting this distinction right matters commercially — clients increasingly ask for 27017 or 27701 by name, and knowing whether that's a scope extension or a guidance reference changes what you promise them.

ISO/IEC 27017 — Cloud Services Security Controls

ISO/IEC 27017 gives cloud-specific implementation guidance for a subset of Annex A controls, plus a small number of cloud-only controls that don't exist in the base standard — things like clarifying the division of security responsibilities between a cloud service provider and a cloud service customer, and virtual machine hardening guidance. In practice, most certification bodies treat 27017 as an extension you can add to an existing ISO 27001 certificate scope statement, so clients see it listed alongside 27001 rather than as a document with its own free-standing certification scheme. If you're a SaaS or platform business fielding cloud security questionnaires, our guide on ISO 27001 for Cloud Service Providers covers how 27017 typically gets layered onto a base ISMS. The standard also clarifies a point that trips up a lot of first-time cloud customers: security responsibility in a cloud relationship is shared, not simply outsourced, and 27017 spells out which controls sit with the provider, which sit with the customer, and which are genuinely joint.

ISO/IEC 27018 — Protection of PII in Public Clouds

ISO/IEC 27018 narrows further: it's a code of practice specifically for organizations acting as PII processors in public cloud environments — think of it as the privacy-in-the-cloud companion to 27017's general cloud security guidance. It addresses things like consent handling for cloud-processed personal data, sub-processor transparency, and data return or deletion at contract termination. Unlike 27701, 27018 is guidance only — there's no independent certification scheme for it, though some certification bodies will issue an attestation of conformity alongside a 27001/27017 audit as a value-added service. Organizations wrestling with cloud PII obligations often move directly to 27701 instead, since it offers an actual certifiable pathway. 27018's most practically useful contribution is often overlooked: guidance on notifying customers before their data is used for anything beyond the contracted service, which maps directly onto the kind of sub-processor and secondary-use questions that increasingly show up in enterprise data processing addenda.

ISO/IEC 27701 — Privacy Information Management System (PIMS)

ISO/IEC 27701 is the most significant standard in the extension ring, and the one most frequently confused with a "GDPR certification" (no such official certification exists — 27701 supports privacy program maturity and can help demonstrate accountability, but it does not itself certify GDPR compliance). Structurally, 27701 works by adding privacy-specific requirements and controls on top of an existing ISO 27001/27002 base — you cannot implement 27701 standalone; it requires a functioning ISMS to attach to. It splits its additional guidance between organizations acting as PII controllers and those acting as PII processors, which maps well onto how GDPR defines those same two roles. Because 27701 extends a certifiable standard using a defined, auditable requirements structure, certification bodies do issue certificates against it — almost always as an extension to an existing ISO 27001 certificate rather than a standalone one. This makes it one of the few members of the extension ring that behaves like the core standard: real requirements, real audits, real certificates. Structurally, 27701 mirrors 27001 and 27002's own clause and control numbering, then layers additional PIMS-specific requirements and guidance on top — a deliberate design choice that keeps the learning curve manageable for teams who already know their way around the base ISMS, rather than asking them to learn an entirely separate framework for privacy.

ISO/IEC 27031 — ICT Readiness for Business Continuity

ISO/IEC 27031 provides guidance for the ICT-specific components of business continuity: recovery time and recovery point objectives for technology systems, resilience architecture, and readiness testing. It's a natural companion to Annex A's business continuity controls, and teams building out disaster recovery capability alongside their ISMS often use it to structure the technical half of a continuity program. See Business Continuity and ICT Readiness: ISO 27001 Controls 5.29–5.30 for how the Annex A controls and this guidance standard divide the work. Where general business continuity planning worries about people, facilities, and process, 27031 stays narrowly focused on whether the technology stack itself can actually recover within the timeframes the business has committed to — a distinction that matters once you're negotiating recovery time objectives with infrastructure teams who need numbers, not intentions.

ISO/IEC 27035 — Information Security Incident Management

ISO/IEC 27035 (published in multiple parts covering principles and process, and incident response operations) gives detailed guidance for building an incident management capability — detection, triage, classification, response, and post-incident learning. It's the standard most internal audit teams reach for when Annex A's incident management controls turn up a finding that the underlying process, not just the policy document, is immature. Our breakdown of Incident Management Under ISO 27001: Controls 5.24–5.28 references the same process stages 27035 formalizes. The standard is genuinely useful even outside a certification context, because "we have an incident response policy" and "we have a tested, muscle-memory incident response process" are very different claims, and 27035's process architecture is what turns the first into the second.

ISO/IEC 27036 — Supplier Relationships / Third-Party Security

ISO/IEC 27036 (also published in multiple parts) addresses information security in supplier and third-party relationships — pre-contract due diligence, security clauses in agreements, and ongoing monitoring of supplier performance. It's especially relevant for organizations with complex vendor ecosystems or ICT supply chains, and it pairs directly with Supplier Relationship Security: ISO 27001 Controls 5.19–5.23. Any organization that has ever discovered a critical fourth-party dependency during an incident postmortem will find 27036's supply-chain guidance sobering reading. It's particularly relevant for the ICT supply chain specifically — software components, managed service providers, and outsourced development shops — where the standard's guidance goes further than most generic vendor-risk questionnaires in probing how deep a customer's visibility into a supplier's own sub-suppliers should reasonably go.

ISO/IEC 27037 — Digital Evidence Handling

ISO/IEC 27037 provides guidelines for the identification, collection, acquisition, and preservation of digital evidence — the kind of forensic rigor that matters if an information security incident might end up in litigation, a regulatory inquiry, or law enforcement referral. Most organizations never need to open this standard until the day they do, at which point having pre-established evidence-handling procedures aligned to 27037 is the difference between evidence that holds up and evidence that gets challenged on chain-of-custody grounds.

"We didn't think about 27037 until a terminated employee's laptop became part of an actual legal dispute. Our IT team's instinct was to just image the drive and move on — turns out chain-of-custody documentation is the part that matters in court, and that's exactly what 27037 is built around." — Simone Okwuosa, Director of IT Security, Halvern Manufacturing Co.

A Few Steps Further Out: Sector and Domain-Specific Standards

Beyond the standards above, the family extends into a longer tail of narrower, sector-specific documents. These are worth knowing by name even if you'll rarely need to open them: ISO/IEC 27014 addresses governance of information security at the board and executive level; ISO/IEC 27019 adapts the control set for process control systems in the energy utility industry; ISO/IEC 27040 covers storage security specifically (encryption at rest, storage media sanitization, SAN/NAS-specific risks); and ISO/IEC 27799 applies information security management guidance to the health informatics sector, working alongside — not replacing — health-specific regulation. None of these are certification targets in their own right; they narrow the same 27001/27002 thinking onto a governance level or an industry vertical.

When One Number Means Several Documents

A few standards in this family aren't single documents at all — they're published in multiple parts, each covering a different slice of the same topic. This trips up anyone searching for "the" text of 27035 or 27036 and finding several results instead of one.

None of this changes how you use the standards day to day — you still reference whichever part is relevant to your situation — but it explains why a quick search sometimes turns up a document with a dash and a second number attached instead of a single tidy standard, and why procurement teams occasionally buy the wrong part by mistake and then wonder why the content doesn't match what a consultant described.

Certifiable vs. Guidance: The Distinction That Actually Matters

If you take one table away from this article, make it this one. Every expensive mistake I've seen with the 27000 family — Dario's included — comes from treating a guidance document as if it were a certification target, or vice versa.

The pattern: exactly one standard in the family (27001) is certifiable on its own, and exactly one more (27701) is certifiable strictly as an extension of an existing 27001 certificate. 27017 occupies a gray zone — ISO itself doesn't publish a standalone 27017 certification scheme, but the accreditation ecosystem has converged on treating it as an addable scope statement on a 27001 certificate, so in commercial practice it functions like a light extension. Every other standard discussed in this article is guidance, full stop — useful, sometimes essential, but never something a certification body will hand you a certificate for on its own.

"The question I ask every prospective client who says 'we need to get 27002 certified' or '27005 certified' is simple: who told you that? Nine times out of ten it's a line item copied from a template RFP nobody proofread. We fix the language before we ever open a proposal." — Renata Achebe, Lead ISMS Auditor, Kestrel Assurance Partners

Which Standard for Which Need: A Decision Table

Use this as a quick-reference when you're not sure which document actually answers the question in front of you.

Cost and Effort Snapshot: Layering Standards Onto an Existing ISMS

Every number in this article costs something different to act on — in licensing fees for the document itself, in internal effort to apply its guidance, and, for the two certifiable members of the family, in audit fees. The figures below are illustrative ranges drawn from the kind of engagements described in this article's case studies, not published ISO pricing or a formal rate card — treat them as a planning gut-check, not a quote.

The pattern worth internalizing: guidance standards cost you internal time and nothing else, while the two certifiable extensions add incremental audit fees on top of your existing certification cost — usually far less than building a standalone certification from zero, which is exactly the math that made Verdant Ledger's extension approach in the second case study below the right call.

"Clients ask me constantly whether adding 27701 doubles their audit cost. It doesn't — you're extending scope on an existing management system, not building a second one from the ground up. Budget for a meaningful bump, not a second invoice the size of the first." — Bram Achterberg, Accreditation and Scheme Manager, Nordwave Certification Group

When Each Standard Actually Enters Your Program

Timing matters almost as much as selection. Pulling a guidance standard in too early wastes effort on detail you're not ready to act on; pulling it in too late means rebuilding work you already did without it.

This is a rough sequence, not a rigid gate system — mature organizations loop back through risk assessment and control implementation continuously rather than moving through these phases once. But for a first-time implementation, this ordering avoids the most common trap I see: reaching for extension standards like 27701 before the base ISMS under 27001 is stable enough to extend.

How the Whole Family Supports ISO 27001

It's worth stepping back and stating the relationship plainly, because it's easy to lose the thread across fourteen standard numbers: everything in this article except 27001 itself is either infrastructure for building and running an ISO 27001 ISMS, or a way of narrowing that same ISMS onto a specific technology or discipline. Nothing in the supporting or extension rings replaces the core requirement — you can't substitute a thorough reading of 27005 for an actual risk assessment that satisfies Clause 6.1, and you can't claim cloud security maturity via 27017 guidance without an underlying 27001-conformant ISMS to attach it to.

This matters practically in two ways. First, when a client questionnaire or RFP cites a standard by number, your first move should be to check whether that number is even certifiable (using the table above) before you commit to a scope or a budget — Dario's $45,000 lesson, generalized. Second, when you're scoping your own ISMS build, the supporting standards aren't optional reading for extra credit; they're where the practical "how" lives that 27001's terser, more legally-flavored requirements language leaves implicit. A team that reads only 27001 and skips 27003, 27004, and 27005 tends to build a technically compliant but operationally fragile ISMS — passable at Stage 2, but exhausting to sustain into year two and three.

Common Confusions, Cleared Up

One confusion sits outside the table above because it's not a mix-up within the family but a mix-up across families entirely: treating SOC 2 as if it were another member of the ISO/IEC 27000 series. It isn't — SOC 2 is a US-originated attestation framework built around the AICPA's Trust Services Criteria, unrelated to ISO's numbering scheme, and while it addresses similar territory to ISO/IEC 27001 for a similar buyer audience, the two aren't interchangeable in a contract clause any more than 27002 and 27001 are. If you're deciding between them — or trying to explain to a client why you hold one and not the other — ISO 27001 vs SOC 2: Which One Do You Need? walks through that decision on its own terms.

Case Studies: The Family in Practice

Case Study 1: Northlight Analytics Recovers From a Certification Mismatch

After the $45,000, seven-week detour described at the start of this article, Dario Fenwick's team restarted with a properly scoped ISO/IEC 27001 program, using 27002 exactly as intended — as implementation guidance for the Annex A controls in their Statement of Applicability. Because Northlight's engineering documentation from the false start wasn't wasted (much of the control evidence gathered during the misdirected 27002 effort was reusable once mapped correctly to Annex A), the corrected program reached Stage 2 audit in 5 months rather than the originally quoted 7, and Northlight's bank client accepted the certificate as satisfying the original contract clause. Dario's post-mortem change: every future client contract clause referencing an ISO standard now gets checked against a one-page internal reference sheet — built directly from the certifiable-vs-guidance table earlier in this article — before anyone signs a statement of work.

Case Study 2: A Payments Platform Adds 27017 and 27701 as Extensions

Verdant Ledger, a 300-person payments infrastructure company, held ISO/IEC 27001 certification for two years before its enterprise sales team started losing deals to a competitor who could answer cloud security and privacy questionnaires with named ISO extensions rather than narrative explanations. Rather than starting new, standalone certification projects, Verdant Ledger's compliance lead worked with their existing certification body to add ISO/IEC 27017 cloud controls and ISO/IEC 27701 privacy requirements as extensions to their existing ISMS scope at the next surveillance audit cycle — avoiding a second Stage 1/Stage 2 process entirely. The additional audit time added roughly 30% to the surveillance audit's duration and a proportional fee increase, but produced two new named certifications in nine months rather than what would have been a 12–14 month standalone build for either one.

"Once we had 27001 as the base, adding 27017 and 27701 felt like renovating a house we already owned instead of buying two new ones. The foundation — risk assessment, management review, internal audit — was already built. We just extended the walls." — Priya Nandakumar, CISO, Verdant Ledger

Case Study 3: A Healthcare Software Vendor Uses Guidance Standards Without Seeking Certification

Halvern Manufacturing Co.'s healthcare software subsidiary needed to mature its incident response and evidence-handling capability after a near-miss security event exposed gaps in how the IT team preserved logs and endpoint images. Rather than pursuing any new certification, the security director used ISO/IEC 27035 to redesign the incident management lifecycle and ISO/IEC 27037 to formalize evidence-handling procedures — both purely as internal guidance documents, with zero certification cost, layered onto their existing ISO/IEC 27001 ISMS. Eight months later, an actual incident (a terminated employee's suspicious data access) was handled with defensible chain-of-custody documentation that held up when legal counsel reviewed it.

"Nobody asked us if we were '27035 certified' — that's not even a real thing to ask. What mattered was that when we actually needed disciplined evidence handling, we weren't inventing the process live during a legal dispute." — Simone Okwuosa, Director of IT Security, Halvern Manufacturing Co.

Case Study Comparison: Three Different Relationships With the Family

Northlight, Verdant Ledger, and Halvern Manufacturing represent three distinct ways organizations engage with the 27000 family — a cautionary mismatch, a deliberate scope extension, and a guidance-only maturity play — and it's worth seeing them side by side before moving on.

Three different starting points, three different objectives, and three legitimate ways to use the same family — which is really the point of this whole article: there's no single "right" set of standards to hold, only the right standards for what you're actually trying to prove to a client, a regulator, or your own leadership team.

A Quick Verification Checklist Before You Cite a Standard in Writing

Before any contract clause, marketing claim, or budget request references a standard by number, run it through this five-step check. It would have saved Northlight Analytics $45,000.

Five questions, and the whole thing takes under an hour to run through with your certification body before a proposal gets signed. Dario's version of this checklist didn't exist in week one of his engagement; it exists at Northlight now, permanently, in every future vendor contract review.

The Strategic Opportunity Hiding in This Confusion

Here's the part most compliance teams miss: the same confusion that cost Dario Fenwick $45,000 is a sales advantage waiting to be claimed. Most of your competitors' sales and compliance teams are just as fuzzy on the difference between "certifiable" and "guidance" as the vendor risk analyst who wrote your client's contract clause. An organization that can, in a single confident paragraph, correctly explain that it holds ISO/IEC 27001 certification, applies ISO/IEC 27002 controls guidance, extends its scope with ISO/IEC 27017 and 27701 where relevant, and references 27005 for its risk methodology — precisely, without hedging — reads as materially more mature to a procurement or vendor-risk team than one that says "yes we're ISO compliant" and hopes nobody asks a follow-up question. Fluency in this family isn't academic; it's a differentiator in every enterprise sales cycle where security posture gets scored.

It also changes how you budget. Teams that understand the family up front don't buy extensions speculatively (Verdant Ledger didn't need 27017 or 27701 until client demand justified it) and don't misdirect spend at non-certifiable standards (Northlight's $45,000 lesson). Knowing exactly what each standard does — and, just as importantly, what it doesn't do — turns the family from a source of contract-clause anxiety into a toolkit you deploy deliberately, standard by standard, as your business actually needs it.

That deliberateness compounds over time. A three-year-old ISMS run by a team fluent in this family tends to look meaningfully different from one run by a team that's still treating every ISO number as interchangeable jargon: fewer emergency scoping calls before big renewals, fewer surprise budget requests when a client asks for an extension by name, and a security narrative that holds up under a sophisticated buyer's questioning instead of falling apart at the second follow-up question.

Whether you're just starting to map out your first ISO/IEC 27001 ISMS or deciding whether this year's roadmap should include a 27701 or 27017 extension, PentesterWorld's Complete ISO 27001 Implementation Guide eBook and ISO 27001 vs SOC 2 vs NIST CSF Comparison Guide eBook can help you move from "which standard do we need" to "certified and defensible" without a $45,000 detour of your own, and our Clauses 4–10 Cheat Sheet keeps the base ISO 27001 requirements at your fingertips while you layer in whichever extensions this article pointed you toward. If your next step is validating that your technical controls will actually hold up under an auditor's scrutiny — not just on paper — our penetration testing and security assessment services are built to stress-test exactly the kind of evidence Annex A controls require, before an external auditor finds the gap for you.