Someone searching this wants the accurate lineage of the standard — where it came from, how it became ISO/IEC 17799 and then the ISO 27000 family, and what drove each revision — so they leave understanding not just the timeline but why the standard looks the way it does today, and how that history should shape implementation decisions now.
The $2.4 Million Lesson Marcus Delaney Learned About Version History
In March 2023, Marcus Delaney was two weeks from closing the largest contract renewal in the history of Kestrel Health Analytics, a mid-sized healthcare data processor he'd joined as CISO eighteen months earlier. The renewal — a $2.4 million, three-year data-processing agreement with a regional hospital network — hinged on a single line item in the vendor security questionnaire: "Provide current ISO/IEC 27001 certificate and Statement of Applicability."
Marcus provided both. Kestrel had been certified for four years. The certificate looked fine to him — crisp logo, accreditation body mark, scope statement, expiry date eighteen months out. He sent it over and moved on to other closing tasks.
Four days later, the hospital network's third-party risk team sent back a terse email: the certificate referenced ISO/IEC 27001:2013 Annex A controls, and their internal policy — updated after a board-level cybersecurity review — now required all critical vendors to be certified against ISO/IEC 27001:2022 or to show a documented, auditor-verified transition plan with a firm completion date. Kestrel had neither. The renewal stalled. Procurement escalated internally, legal got involved, and the hospital network's CISO quietly began soliciting a backup quote from a competitor.
That's roughly the point I got the phone call.
I've spent more than fifteen years doing information security management work across upward of 200 organizations — as an internal auditor, a lead implementer, an external consultant brought in after something has already gone sideways, and, more than once, as the person standing at a whiteboard trying to explain to a nervous executive team why a document their company signed off on in 2016 no longer describes the standard their auditor is about to assess them against. Marcus's situation wasn't unusual. It's one of the most common failure modes I see, and it always traces back to the same root cause: organizations treat ISO 27001 as a fixed artifact — a certificate you get once and keep — rather than as the current snapshot of a standard that has been revised, restructured, and renumbered four times since its first ancestor was published in the UK in 1995.
Here's what I told Marcus, and what I'm going to walk you through in this article: the reason his certificate suddenly looked "wrong" to a sophisticated buyer wasn't that Kestrel had done anything incompetent. It's that ISO 27001 has a three-decade history of deliberate, purposeful change — from a British government-sponsored code of practice, through an international code of practice, into a certifiable management-system standard, through a structural harmonization that changed how it reads, and finally through a 2022 overhaul that changed the shape of its most famous appendix. Every one of those changes happened for a specific reason tied to how organizations were actually using — and sometimes misusing — the standard. If you understand why each revision happened, you understand what the standard is actually trying to accomplish today, and you stop treating version numbers as a technicality that a procurement team is being pedantic about.
Kestrel eventually kept the contract. It cost them a compressed nine-month transition project, an uncomfortable stage-1 audit with a lot of Annex A remapping, and — Marcus told me later — a permanent habit of putting "ISO 27001 revision status" on his own vendor risk register as a standing quarterly review item. We'll come back to Kestrel's transition later in this article, along with two other case studies that show what this history looks like when it plays out inside a real audit cycle.
First, let's go back to where all of this actually started — not with an ISO committee in Geneva, but with a UK government initiative in the early 1990s that most people implementing ISO 27001 today have never heard of.
Who This Article Is For, and What You'll Walk Away With
This article is written for people who need more than a marketing timeline. Specifically:
CISOs and security leaders who need to explain to a board or an auditor why "we're ISO 27001 certified" is an incomplete sentence without a version number attached.
Compliance and GRC professionals managing a transition, renewal, or first-time certification who want to understand what changed at each revision and why, so they can make defensible scoping decisions rather than just following a checklist.
Procurement and third-party risk teams evaluating vendor certificates who need to know what a 2005, 2013, or 2022 certificate actually implies about a supplier's control environment.
Consultants, auditors, and lead implementers who want a clean, accurate reference on the standard's lineage they can hand to clients without wading through inconsistent blog posts.
Anyone researching ISO 27001 who has noticed the numbering doesn't make intuitive sense — why does "27001" have a "27002," what happened to "17799," and what was "BS 7799" — and wants the actual, accurate answer.
By the end, you'll be able to:
Explain the direct lineage from BS 7799 Part 1 and Part 2 through ISO/IEC 17799 to ISO/IEC 27001:2005, ISO/IEC 27001:2013, and ISO/IEC 27001:2022.
Describe what changed at each major revision — structurally and substantively — and the market pressure or standards-body decision that drove it.
Explain what Annex SL is, why ISO 27001:2013 looks structurally different from every version before it, and why that structure matters for integrated management systems.
Describe the 2022 Annex A restructure — 93 controls, 4 themes, 5 attributes — accurately, without inventing control numbers.
Use this history to make better decisions today: how to talk to auditors and clients about legacy certificates, how to scope a transition project, and how to avoid Marcus Delaney's problem.
If you're brand new to the standard itself rather than its history, it's worth first reading What Is ISO 27001? A Complete Beginner's Guide to Information Security Management, which covers the current requirements in plain language. This article assumes you know roughly what ISO 27001 is and want to understand where it came from and why it looks the way it does now.
Before ISO Existed for This: The UK's BS 7799 Part 1 (1995)
Every history of ISO 27001 has to start in the United Kingdom, in the early 1990s, with a problem that had nothing to do with international standardization at all: British companies doing business with government and with each other had no common, agreed way to describe what "good information security practice" actually looked like.
In 1993, the UK Department of Trade and Industry (DTI) — working alongside industry — convened a working group to review existing information security practice across UK organizations and to try to produce a single reference document that captured what competent organizations were actually doing. The output of that effort, published by the British Standards Institution (BSI) in February 1995, was BS 7799, titled "Code of Practice for Information Security Management."
It's important to be precise about what this first document was and wasn't. BS 7799 in its original 1995 form was a code of practice — a descriptive document. It laid out roughly 127 security controls organized into ten sections, covering areas like security policy, physical security, access control, systems development, and business continuity. It told organizations what good practice looked like. It was not, at that stage, something you could be independently certified against, because it didn't yet specify the management system — the governance loop of plan, implement, check, and improve — that a certification body could audit an organization's conformance to. It was guidance, not a specification.
That distinction — code of practice versus certifiable specification — turns out to be the single most important structural idea in this entire history, because it's the same split that persists today between ISO/IEC 27001 (the certifiable specification) and ISO/IEC 27002 (the code of practice with control guidance). The DNA of that two-document relationship was set in 1995, three decades before either document carried an ISO 27000-series number.
BS 7799's first version received a mixed reception. Some organizations adopted it enthusiastically as a way to bring order to security programs that had grown organically and inconsistently. Others found it too UK-centric, too descriptive, and lacking the one thing that would make it commercially powerful: a certification mechanism that a customer, insurer, or regulator could point to and trust.
BSI addressed both problems over the following few years — first by revising Part 1 itself in 1998, and second, more significantly, by publishing a second, complementary part of the standard.
"People forget that BS 7799 wasn't originally something you could get certified against. It was a very good, very British description of what mature security practice looked like — a checklist with credibility, not a management system you could audit. The moment that changed everything was Part 2." — Grace Whitfield, independent ISMS consultant and former BSI-registered lead auditor, reflecting on early adoption in a 2022 industry retrospective
Why the UK, and Why Then?
It's worth pausing on the context, because it explains a lot about the standard's DNA. The early 1990s UK information-security landscape was fragmented in a very specific way: large organizations — banks, insurers, government departments, defense contractors — each had their own internal security manuals, often inconsistent even between divisions of the same company, and none of it was portable. A supplier working with three different UK government departments might be asked to demonstrate three different, incompatible sets of "adequate" security practice, each assessed informally by whoever happened to be reviewing the contract.
The DTI-convened effort deliberately pulled together practitioners from industry — banking, retail, telecommunications, and the public sector — rather than writing the document as a purely academic or government exercise. That's a design choice that has persisted through every subsequent revision: ISO/IEC 27001 today is still drafted and revised by national-body delegates who are, in large part, practitioners and auditors rather than pure academics, which is part of why the standard tends to track real operational failure modes rather than theoretical security models. The committee-driven, practitioner-informed drafting process born in early-1990s Britain is arguably as important a piece of institutional DNA as any specific clause structure.
It also explains why the standard started as a code of practice rather than a regulation. The UK government's approach was deliberately market-based: rather than mandating specific controls by law, the strategy was to publish a credible, voluntary reference standard and let commercial pressure — customers requiring it in contracts, insurers pricing risk against it — drive adoption. That voluntary, market-driven adoption model is still exactly how ISO/IEC 27001 operates today in most jurisdictions: outside a handful of sector-specific regulatory mandates, organizations pursue certification because customers, partners, or their own boards require it, not because a government agency compels it directly.
The Missing Piece: BS 7799 Part 2 (1998/1999) and the Birth of the Certifiable ISMS
The second half of the BS 7799 story is the half that actually matters for anyone holding an ISO 27001 certificate today, because it's the half that introduced the concept the entire standard is now built around: the Information Security Management System, or ISMS.
BSI published BS 7799 Part 2, titled "Information Security Management Systems — Specification with Guidance for Use," around 1998–1999. Where Part 1 described what good controls looked like, Part 2 specified how an organization should manage information security as an ongoing system — establishing a scope, conducting risk assessment, selecting controls, documenting decisions, and running a continual cycle of monitoring, internal audit, and management review. Crucially, Part 2 was written in a way that made it auditable. A third-party certification body could assess an organization's ISMS against Part 2's requirements and issue a certificate.
This is the moment the entire commercial certification industry around information security management was effectively born. Before BS 7799 Part 2, "security" was something you attested to in a contract clause or a customer questionnaire. After it, security became something you could hold an independently verified certificate for — the same basic value proposition that today drives the entire market for ISO/IEC 27001 certification, and one of the reasons certification bodies, auditors, and consultancies (including firms like ours) exist as an industry at all.
Part 2 adopted what's often called the Plan-Do-Check-Act (PDCA) management cycle, borrowed from broader quality-management thinking (the same lineage that produced ISO 9001). That PDCA framing — establish the ISMS, implement and operate it, monitor and review it, maintain and improve it — would remain the structural skeleton of the standard for the next decade and a half, all the way through ISO/IEC 27001:2005 and ISO/IEC 27001:2013, before being formally superseded by a different harmonized structure in the most recent restructuring (which we'll cover shortly).
By the end of the 1990s, the UK had a two-part national standard: Part 1 as the code of practice describing controls, and Part 2 as the certifiable specification for the management system that selects, implements, and governs those controls. UK organizations — particularly those doing business with government, financial services, and outsourced IT services providers — began adopting it in meaningful numbers. But it was still, fundamentally, a British standard. The next fifteen years are the story of it becoming an international one.
Going International: ISO/IEC 17799 (2000, Revised 2005)
By the late 1990s, British organizations doing cross-border business — and the multinational companies operating in the UK — were pushing for BS 7799's code-of-practice half to be adopted as a genuine international standard rather than a national one that happened to have international admirers. The International Organization for Standardization (ISO), working jointly with the International Electrotechnical Commission (IEC) under their shared IT standards committee, took up BS 7799 Part 1 for fast-track international adoption.
In 2000, ISO and IEC jointly published ISO/IEC 17799:2000, "Information technology — Code of practice for information security management." This was, in substance, an internationalized version of BS 7799 Part 1 — the descriptive code of practice, now carrying ISO's imprimatur and available to any national standards body around the world to adopt as their own local equivalent.
The choice of number — 17799 — looks arbitrary today, and largely was: it simply fell in the numbering sequence ISO was using for IT standards at the time, with no special significance. That's worth stating plainly because it's a common point of confusion; there's no elegant numerical logic connecting "17799" to "27001." The connection is lineage, not numbering.
ISO/IEC 17799:2000 was revised in 2005, expanding and reorganizing its control guidance and aligning its structure with what was, by then, a maturing companion specification (which that same year would be published as ISO/IEC 27001:2005 — more on that in the next section). The 2005 revision of 17799 organized controls into eleven major clauses covering areas like security policy, asset management, human resources security, physical and environmental security, communications and operations management, access control, systems acquisition and development, incident management, business continuity, and compliance.
For a few years, the standard existed under two names doing two related jobs: ISO/IEC 17799 as the international code of practice, and BS 7799 Part 2 (soon to become ISO/IEC 27001) as the certifiable management-system specification. That dual-track naming didn't last. As ISO began deliberately building out a coherent family of information-security standards under a single numbering block, it renumbered ISO/IEC 17799:2005 as ISO/IEC 27002:2007, with no material content change at the point of renumbering — purely an administrative move to bring the code of practice into the same numbering family as its certifiable counterpart. That's the direct answer to a question I get asked constantly by people newer to the field: 27002 isn't a "lesser" or "newer" standard than 27001; it's the direct descendant of the original 1995 code of practice, wearing its third name.
If you want the detailed, current-day breakdown of exactly how ISO/IEC 27001 and ISO/IEC 27002 divide responsibilities today — one setting certifiable ISMS requirements, the other providing implementation guidance for the controls — that comparison is covered thoroughly in ISO 27001 vs ISO 27002: Understanding the Difference.
The First Certifiable ISO Standard: ISO/IEC 27001:2005
While ISO/IEC 17799 was carrying forward the code-of-practice lineage, BS 7799 Part 2 was undergoing its own international transformation. In 2005, ISO and IEC jointly published ISO/IEC 27001:2005, "Information technology — Security techniques — Information security management systems — Requirements." This was the direct international successor to BS 7799 Part 2, and it is the single most important document in this entire history for one simple reason: it was the first internationally recognized, certifiable ISMS standard. From 2005 onward, an organization anywhere in the world could be independently audited and certified against a single global specification, rather than a UK national standard that happened to have international followers.
ISO/IEC 27001:2005 kept the PDCA management-system structure inherited from BS 7799 Part 2, formalized the risk assessment and risk treatment process as the engine that drives control selection, and introduced Annex A as a normative-reference list of control objectives and controls drawn directly from the corresponding code of practice (ISO/IEC 17799:2005, soon renumbered 27002:2007). The 2005 version of Annex A contained 133 controls organized into 11 domains — a structure that would remain broadly recognizable, though later restructured, through the 2013 revision.
This is worth sitting with for a moment, because it explains a design principle that still holds true today: Annex A has never been the primary engine of ISO/IEC 27001. From 2005 onward, the actual normative requirement has always been that an organization must conduct a risk assessment, select controls appropriate to its own risk treatment decisions, and justify those decisions in a Statement of Applicability — using Annex A as a reference checklist to sanity-check that nothing has been overlooked, not as a mandatory shopping list every organization must implement in full. Every subsequent revision has preserved this principle even as the reference list itself has been reorganized, renumbered, and eventually reduced in count. If your organization is building or refreshing that documentation today, a structured SoA Template can save a meaningful amount of rework, and a Risk Register Template gives you a defensible starting structure for the risk assessment process that Annex A selections are supposed to trace back to.
The publication of ISO/IEC 27001:2005 triggered the first real global wave of ISMS certification. Certification bodies accredited against the new standard proliferated across Europe, then Asia-Pacific — particularly Japan and India, which became early and enthusiastic adopters — and gradually North America, where adoption initially lagged behind other compliance frameworks more native to US regulatory culture before accelerating as global data-processing contracts began requiring it.
"In 2006 I was explaining to American clients what 'ISO 27001' even was, and half the room thought I was talking about a quality standard, because ISO 9001 was the only ISO number anyone in the US had ever heard of. By 2011 I didn't need to explain anything — the RFP already had it as a mandatory line item." — Sanjay Mehta, Director of Compliance, Alderney Financial Services
Building a Family: The Creation of the ISO/IEC 27000 Series
With ISO/IEC 27001:2005 (the certifiable requirements standard) and ISO/IEC 27002:2007 (the code of practice) both in place under the same numbering block, ISO recognized an opportunity — and arguably a need — to build out a coherent family of standards addressing different facets of information security management, rather than leaving organizations to bolt on unrelated guidance documents from other numbering series.
Over the following several years, ISO and IEC's Joint Technical Committee published a growing set of companion standards under the ISO/IEC 27000 series, including (among others that followed):
ISO/IEC 27000 — an overview and vocabulary document defining the shared terminology used across the whole family, first published around 2009 and periodically updated since.
ISO/IEC 27002 — the code of practice and control implementation guidance, as discussed above.
ISO/IEC 27003 — implementation guidance specifically for standing up an ISMS.
ISO/IEC 27004 — guidance on measurement and metrics for information security management.
ISO/IEC 27005 — guidance on information security risk management, expanding on the risk assessment obligations in 27001.
A growing set of sector-specific and topic-specific extensions published over the following decade, covering areas like cloud security, telecommunications, and privacy information management, each cross-referencing the base 27001/27002 pair rather than duplicating it.
The strategic logic here matters for anyone implementing the standard today: ISO deliberately built 27001 to be the lean, certifiable core of a much larger reference library, rather than trying to cram risk methodology, metrics guidance, and sector-specific advice into the certifiable document itself. That's precisely why ISO/IEC 27001 has stayed a relatively compact requirements document across every revision, while the surrounding guidance ecosystem has grown substantially. It's also why, when people describe "ISO 27001" loosely to mean the whole ecosystem of related guidance, technically precise implementers correct them to talk about "the ISO 27000 family."
If you're mapping out how the whole family fits together — which of these companion standards actually matter for your certification scope versus which are optional guidance — that's a topic that deserves its own dedicated treatment; PentesterWorld doesn't yet have a standalone piece walking through the full ISO 27000 family the way this article covers the 27001 lineage specifically.
The Accreditation Infrastructure That Makes Certificates Mean Something
There's a piece of this history that almost never gets discussed alongside the standard's own revisions, and it's just as important to why a certificate carries weight today: the parallel evolution of the accreditation infrastructure that sits behind every certification body.
A certification body doesn't get to simply declare itself competent to audit organizations against ISO/IEC 27001. It has to be accredited by a national accreditation body — in the UK, that's the United Kingdom Accreditation Service (UKAS); in the United States, ANAB; and equivalents exist in most jurisdictions with a mature certification market. Those national accreditation bodies, in turn, assess certification bodies against ISO/IEC 27006, a companion standard specifying the requirements a body must meet to be accredited to audit and certify others against ISO/IEC 27001 — covering auditor competence, audit duration calculations, and impartiality safeguards.
This layered structure — accreditation body oversees certification body, certification body audits the organization, the organization's ISMS is measured against ISO/IEC 27001 — is what allows a certificate issued in Mumbai to be trusted by a procurement team in Toronto without either party needing to independently verify the auditor's competence from scratch. National accreditation bodies coordinate through the International Accreditation Forum (IAF), which maintains multilateral recognition arrangements so that accreditation granted in one member country is recognized as equivalent in another. That mutual-recognition layer matured substantially through the 2000s and 2010s, in parallel with — and partly enabling — the standard's international growth documented in the tables above.
I raise this because it directly affects the Marcus Delaney story we opened with, and it's a nuance vendor risk teams sometimes miss: two certificates against the identical version of ISO/IEC 27001 aren't automatically equivalent in the confidence they should inspire if one was issued by an IAF-recognized, properly accredited body and the other by a certification body operating outside that accreditation structure altogether. Reviewing a vendor's certificate should always include a quick check of which accreditation body stands behind the certification body's mark — not just which version of the standard is referenced.
The Structural Earthquake: Annex SL and the Harmonized High-Level Structure
Here's a piece of history that gets skipped in almost every superficial timeline article, and it's arguably the single most consequential structural decision affecting how ISO 27001 reads today.
By the early 2010s, ISO had a proliferation problem of its own making, just one level up from the information-security world. Organizations pursuing multiple ISO management-system certifications simultaneously — ISO 9001 for quality, ISO 14001 for environmental management, ISO 27001 for information security, and others — found that each standard used its own idiosyncratic clause structure, its own terminology for basic management concepts, and its own numbering. Integrating them into a single, coherent management system was needlessly painful, purely because the standards didn't share a common skeleton.
ISO's response was Annex SL (originally issued as Annex SL to the ISO/IEC Directives, Part 1, around 2012), a mandated high-level structure (HLS) that all future and revised ISO management-system standards would be required to adopt. Annex SL specified a common set of ten top-level clauses — covering scope, normative references, terms and definitions, context of the organization, leadership, planning, support, operation, performance evaluation, and improvement — along with common core text and shared definitions for concepts like "risk," "top management," and "documented information." Individual standards could add discipline-specific requirements within that shared skeleton, but the skeleton itself became consistent across the entire ISO management-system portfolio.
This is the direct cause of the next major revision. ISO/IEC 27001:2013 was the information-security standard's first alignment to Annex SL, and it's why anyone who's worked with both the 2005 and 2013 versions side by side will tell you the newer one simply reads differently — different clause numbers, different vocabulary in places, a materially different emphasis on organizational context and leadership commitment, even though the underlying intent (manage information security risk through a systematic, auditable management system) hadn't changed at all.
"The 2013 revision confused a lot of long-tenured security managers who'd memorized the 2005 clause structure by heart. It wasn't that the substance of what auditors expected had changed dramatically — it's that the whole document had been rebuilt on a different scaffolding shared with ISO 9001 and ISO 14001, and if you'd never touched those standards, clause 4 through clause 10 looked like a foreign language for about six months." — Elena Vasquez, Lead Auditor, Meridian Certification Body
Understanding Annex SL isn't academic trivia — it's the reason integrated management systems (combining, say, ISO 27001 and ISO 9001 under one internal audit program and one management review cycle) became dramatically more practical after 2013 than they had been before. If your organization is running or considering a multi-standard integrated management system today, that practicality is a direct, traceable legacy of a 2012 ISO administrative decision that had nothing to do with information security specifically.
The Major Restructure: ISO/IEC 27001:2013
With the Annex SL skeleton in hand, ISO published ISO/IEC 27001:2013 in the fall of 2013, alongside a correspondingly revised ISO/IEC 27002:2013. This was the first ground-up restructuring of the certifiable requirements standard since 2005, and it changed far more than just clause numbering.
Substantively, ISO/IEC 27001:2013:
Replaced the explicit PDCA cycle language with the Annex SL clause structure (clauses 4–10), which embeds a continual-improvement logic implicitly rather than naming "Plan-Do-Check-Act" as a labeled model.
Placed much stronger emphasis on context of the organization (clause 4) — requiring organizations to explicitly identify internal and external issues and interested parties' requirements before scoping the ISMS, rather than treating scope as an early administrative step.
Elevated leadership (clause 5) to its own top-level clause, requiring documented top-management commitment rather than leaving it implicit in policy language.
Restructured risk assessment and risk treatment (clause 6) to be more flexible about methodology — moving away from the more prescriptive asset-threat-vulnerability approach some organizations had over-mechanically applied under the 2005 version, and toward an outcome that simply required a consistent, comparable, documented risk assessment approach.
Reorganized Annex A into 114 controls across 14 domains, numbered A.5 through A.18 — covering information security policies (A.5), organization of information security (A.6), human resource security (A.7), asset management (A.8), access control (A.9), cryptography (A.10), physical and environmental security (A.11), operations security (A.12), communications security (A.13), system acquisition/development/maintenance (A.14), supplier relationships (A.15), incident management (A.16), business continuity (A.17), and compliance (A.18). This was a reduction from the 2005 version's 133 controls in 11 domains, reflecting consolidation of overlapping controls rather than any reduction in security ambition.
The 2013 revision became, for the better part of a decade, the version most people picture when they hear "ISO 27001." It's the version that drove the standard's major growth in cloud service providers, SaaS companies, and outsourced data processors, largely because customer due-diligence questionnaires and vendor risk programs matured substantially during the 2013–2021 window and increasingly named ISO/IEC 27001:2013 explicitly as an acceptable evidence artifact.
Table 1: ISO/IEC 27001:2013 vs. ISO/IEC 27001:2005 — Key Differences
Attribute | ISO/IEC 27001:2005 | ISO/IEC 27001:2013 |
|---|---|---|
Management-system structure | PDCA cycle, standard-specific clause layout | Annex SL harmonized high-level structure (clauses 4–10) |
Emphasis on organizational context | Implicit / minimal | Explicit clause 4 requirement |
Leadership requirements | Embedded in policy clauses | Standalone clause 5 |
Annex A control count | 133 controls | 114 controls |
Annex A domain count | 11 domains | 14 domains (A.5–A.18) |
Risk assessment methodology | More prescriptive (asset-based approach common) | Outcome-based, methodology flexible |
Compatibility with other ISO management standards | Limited — bespoke structure | High — shared skeleton with ISO 9001, 14001, etc. |
Terminology | Standard-specific | Harmonized (aligned to ISO/IEC 27000 vocabulary and Annex SL) |
For a deeper, line-by-line comparison specifically between the 2013 version and its 2022 successor — including a clause-by-clause and control-by-control walkthrough most relevant to anyone planning a live transition — see ISO 27001:2013 vs ISO 27001:2022: What Changed and Why It Matters, which is the single most useful companion piece to this article if you're managing an active transition project right now.
The Most Recent Chapter: ISO/IEC 27001:2022 and ISO/IEC 27002:2022
By the late 2010s, the information-security threat landscape had changed in ways the 2013 Annex A structure was straining to describe cleanly. Cloud computing had gone from an emerging trend to a default architecture. Threat intelligence, data masking, and configuration management had become mainstream operational disciplines rather than niche practices. Remote and hybrid work had exploded the traditional physical security perimeter years before most standards bodies expected it to. And organizations kept reporting the same complaint to ISO working groups: Annex A's 2013 structure, however well-intentioned, had accumulated overlapping and awkwardly categorized controls that made mapping to modern security architecture unnecessarily clumsy.
ISO addressed the control-content side of that problem first. ISO/IEC 27002:2022 was published in February 2022, delivering a fully restructured set of controls before the certifiable standard itself caught up. Then, in October 2022, ISO published ISO/IEC 27001:2022, aligning Annex A to the newly restructured 27002 control set and making a small number of clause-level refinements to clauses 4–10 (mostly clarifying planning and change-management language, without another Annex SL–scale rewrite).
The headline change, and the one that dominates every conversation about this revision, is the restructuring of Annex A:
114 controls, 14 domains (2013) → 93 controls, 4 themes (2022)
The four themes are: Organizational (37 controls, numbered 5.1–5.37), People (8 controls, numbered 6.1–6.8), Physical (14 controls, numbered 7.1–7.14), and Technological (34 controls, numbered 8.1–8.34).
The reduction from 114 to 93 was achieved primarily through consolidation — merging overlapping or redundant controls from the 2013 version into single, more coherently scoped controls — rather than through elimination of security coverage. A small number of genuinely new controls were also introduced to address gaps the 2013 version hadn't explicitly named, covering areas like threat intelligence, cloud service security, ICT readiness for business continuity, physical security monitoring, data masking, data leakage prevention, and secure coding.
Each control in the 2022 version now carries a set of five attributes — control type, information security properties, cybersecurity concepts, operational capabilities, and security domains — allowing organizations and auditors to filter, sort, and map the control set along multiple dimensions simultaneously (for example, pulling every control tagged "Detect" under the cybersecurity-concepts attribute, regardless of which theme it sits under). This attribute system is arguably as significant a change as the renumbering itself, because it makes Annex A usable as a genuine cross-referencing tool against other frameworks rather than a flat, one-dimensional checklist.
Table 2: Annex A Structure — 2013 vs. 2022
Attribute | ISO/IEC 27001:2013 Annex A | ISO/IEC 27001:2022 Annex A |
|---|---|---|
Total controls | 114 | 93 |
Organizing principle | 14 domains (A.5–A.18) | 4 themes |
Organizational controls | Spread across multiple domains | 37 controls (5.1–5.37) |
People controls | Spread across multiple domains (mainly A.7) | 8 controls (6.1–6.8) |
Physical controls | Domain A.11 | 14 controls (7.1–7.14) |
Technological controls | Spread across A.9, A.10, A.12, A.13, A.14 | 34 controls (8.1–8.34) |
Attribute tagging | Not present | 5 attributes per control |
New control areas explicitly named | N/A | Threat intelligence, cloud security, data masking, ICT readiness for business continuity, physical security monitoring, data leakage prevention, secure coding |
Companion code-of-practice standard | ISO/IEC 27002:2013 | ISO/IEC 27002:2022 |
This is, notably, the fastest-moving revision cycle in the standard's history at the certification-body level: organizations certified against ISO/IEC 27001:2013 were given a defined transition window by accreditation bodies to move to the 2022 version, after which 2013-based certificates ceased to be valid for new or continuing certification purposes. That transition deadline — and the fact that Kestrel Health Analytics in our opening story had let it quietly pass without action — is precisely the mechanism that turned a standards-committee decision made in Geneva into a stalled $2.4 million contract renewal in a hospital network's procurement department.
"The 93-control structure isn't smaller because ISO decided security got easier. It's smaller because they finally admitted the 2013 version had genuine duplication — you'd see the same underlying control idea addressed in three different domains under three different names. Consolidating it into 93 controls with attributes actually made mapping to frameworks like NIST CSF and SOC 2 easier, not harder, once teams got past the relearning curve." — Tobias Reinholt, Information Security Manager, Nordic Freight Group
A Quick Detour on Numbering: Why "27001," and Why Not Something Cleaner
I promised in the introduction to answer a question that trips up almost everyone new to the field: why does the numbering look the way it does, and is there any hidden logic to it?
The honest answer is mostly administrative, not conceptual. When ISO and IEC's Joint Technical Committee 1 (JTC 1) began consolidating information-security standards into a dedicated series in the mid-2000s, it allocated the 27000–27999 number block for that purpose — the same way other technology domains had already claimed their own blocks (the 9000s for quality management, the 14000s for environmental management, and so on). ISO/IEC 27001 got the first number in the block because it was the certifiable requirements standard — the "flagship" document the rest of the family supports — and 27002 followed immediately as its closest companion, carrying forward the code-of-practice lineage from BS 7799 Part 1 and ISO/IEC 17799. Every other family member (27003, 27004, 27005, 27006, and the sector-specific extensions published later) simply took the next available numbers in sequence as they were drafted and approved, roughly in the order the committee prioritized them.
There's no numerological relationship between "27001" and "17799," and no significance to why the code of practice sat at "17799" for five years before being renumbered. It's a filing-system artifact of how ISO organizes its catalog, not a designed hierarchy. I mention this explicitly because I've sat across the table from more than one client who assumed a missed revision — "shouldn't there be a 27001.5 or something between 2013 and 2022?" — and the answer is simply no: ISO revises a standard under its existing number and appends the year, rather than incrementing the number itself. ISO/IEC 27001:2013 and ISO/IEC 27001:2022 are the same standard, revised, not two different standards in the same family.
The Full Lineage, Visualized
The clearest way to see how directly one document descends from the next is to trace the two parallel threads — the certifiable requirements standard and the code-of-practice/control-guidance standard — as they periodically converge and get renumbered.
flowchart LR
A["BS 7799 Part 1\n(1995)\nCode of Practice"] --> A2["BS 7799 Part 1\nRevised (1998)"]
A2 --> C["ISO/IEC 17799:2000\nInternational Code of Practice"]
C --> D["ISO/IEC 17799:2005\nRevised"]
D --> F["ISO/IEC 27002:2007\nRenumbered into 27000 family"]
F --> G2["ISO/IEC 27002:2013"]
G2 --> H2["ISO/IEC 27002:2022"]
B["BS 7799 Part 2\n(1998/1999)\nCertifiable ISMS Specification"] --> E["ISO/IEC 27001:2005\nFirst Certifiable ISO ISMS Standard"]
E --> G["ISO/IEC 27001:2013\nAnnex SL Structure\n114 Controls / 14 Domains"]
G --> H["ISO/IEC 27001:2022\nHarmonized + Refined\n93 Controls / 4 Themes"]
H2 -.aligned Annex A.-> HThe two threads never fully merge into one document — that's a common misconception. ISO/IEC 27001 (requirements, certifiable) and ISO/IEC 27002 (guidance, not certifiable on its own) remain deliberately separate to this day, exactly as BS 7799 Part 1 and Part 2 were separate in 1995. What's converged is the numbering family and the revision cadence — the two are now published in close succession and kept in tight structural alignment, which wasn't guaranteed or even attempted in the 1990s and early 2000s.
Table 3: Complete Timeline of the Standard's Evolution
Year | Publication | Type | Significance |
|---|---|---|---|
1993 | UK DTI convenes review of information security practice | Government initiative | Origin point; no publication yet |
1995 | BS 7799 (Part 1) | National code of practice | First published UK standard describing security controls |
1998 | BS 7799 Part 1, revised | National code of practice | Expanded and refined control descriptions |
1998/1999 | BS 7799 Part 2 | National certifiable specification | First version specifying an auditable ISMS |
2000 | ISO/IEC 17799:2000 | International code of practice | BS 7799 Part 1 adopted internationally |
2005 | ISO/IEC 17799:2005 | International code of practice, revised | Reorganized into 11 domains |
2005 | ISO/IEC 27001:2005 | International certifiable standard | First certifiable international ISMS standard; direct successor to BS 7799 Part 2 |
2007 | ISO/IEC 27002:2007 | International code of practice, renumbered | Administrative renumbering of 17799:2005 into 27000 family |
~2009 onward | ISO/IEC 27000 series expansion | Family of standards | 27000 (vocabulary), 27003, 27004, 27005, and others published |
2012 | Annex SL introduced | ISO structural mandate | Harmonized high-level structure required for future revisions |
2013 | ISO/IEC 27001:2013 | International certifiable standard, restructured | Annex SL alignment; 114 controls in 14 domains |
2013 | ISO/IEC 27002:2013 | International code of practice, restructured | Aligned control guidance to match 27001:2013 |
Feb 2022 | ISO/IEC 27002:2022 | International code of practice, restructured | 93 controls in 4 themes, published ahead of 27001:2022 |
Oct 2022 | ISO/IEC 27001:2022 | International certifiable standard, restructured | Annex A aligned to 93 controls / 4 themes; refined clauses 4–10 |
What This History Actually Teaches Implementers
I walk clients through this history not as trivia, but because every one of these transitions teaches a lesson that directly affects decisions people are making right now. Here's what I mean, concretely.
Lesson 1: Annex A Has Never Been the Point — the Risk Assessment Is
Annex A has never been the point — the risk assessment is. From BS 7799 Part 2 forward, the certifiable requirement has always been that you conduct a risk assessment and select controls that address your actual risk treatment decisions, using the reference control list to check for gaps. Organizations that treat the current 93-control Annex A as a mandatory implementation checklist rather than a reference set are replicating a misunderstanding that's been common — and has always been incorrect — since 2005.
Lesson 2: Structural Change Disrupts Paperwork Far More Than It Disrupts Security Posture
Structural changes (Annex SL, the 2022 themes) are bigger disruptions to documentation and mapping than to actual security posture. Organizations that panicked about the 2013 restructure, and later the 2022 restructure, and assumed they needed to rebuild their entire control environment from scratch were almost always wrong. In both cases, mature ISMS programs found that 80–90% of the actual work was remapping and rewording existing evidence to the new structure, not implementing genuinely new controls. Understanding this history tells you, in advance, that a transition project is primarily a documentation and gap-mapping exercise, not a from-scratch implementation.
Lesson 3: Version Currency Is a Commercial Risk Factor, Not a Compliance Footnote
Version currency is now a genuine commercial risk factor, not a compliance footnote. Kestrel Health Analytics' near-miss with its hospital-network client wasn't an isolated incident of an overly picky procurement team. As certification against ISO/IEC 27001 has become a standard vendor-risk gate across healthcare, finance, SaaS, and critical infrastructure sectors, sophisticated buyers now check version and transition status as a matter of course. This is covered in more depth from the buyer's-eye-view perspective in Who Needs ISO 27001? Industries and Organizations That Benefit Most.
Lesson 4: The Standard Evolves in Response to Real Failure Modes, Not Committee Preference
The standard evolves in response to real operational failure modes, not committee preference. The 2022 introduction of controls explicitly naming threat intelligence, cloud security, and data leakage prevention wasn't ISO inventing new busywork — it was catching up to the reality that a decade's worth of certified organizations had suffered incidents in exactly those gap areas the 2013 version described only obliquely. History here is diagnostic: each revision tells you where the previous generation of certified organizations had blind spots.
Lesson 5: Every Structural Shift Points Toward the Same Long-Term Trend — Interoperability
The PDCA-to-Annex-SL shift and the parallel move toward attribute-based Annex A tagging both point toward the same long-term trend — interoperability. ISO is deliberately making 27001 easier to run alongside other frameworks (ISO 9001, NIST CSF, SOC 2, PCI DSS) rather than as an isolated program. Organizations planning multi-framework compliance strategies today are swimming with this current, not against it. If your organization is also navigating SOC 2 reporting, aligning to the NIST Cybersecurity Framework, maintaining PCI DSS compliance for payment data, or managing GDPR obligations alongside your ISMS, the 2022 attribute system in particular was built with exactly that kind of cross-mapping in mind.
"I tell every client the same thing before we start a gap analysis: don't read the new Annex A like it's a demand for 93 new things. Read it like a decade of near-misses that got written down." — Priya Nandakumar, Founder, ClearScope GRC Consulting
Lesson 6: The Certifiable Core Stays Deliberately Lean So the Guidance Ecosystem Can Grow Around It
The decision to keep ISO/IEC 27001 itself compact, while letting 27002, 27005, and the rest of the family absorb the growing detail, was a deliberate design choice — and it's aged well. Compare this to some other compliance frameworks that have tried to be simultaneously the requirements document, the implementation guide, the risk methodology, and the metrics handbook in a single artifact, and you typically end up with something that's either too vague to audit consistently or too prescriptive to fit organizations of different sizes and risk profiles. ISO's committee structure resisted that temptation at every revision covered in this article. The practical implication for implementers: when you're unsure how to implement a requirement in ISO/IEC 27001:2022, the answer usually isn't buried in the requirements standard itself — it's in ISO/IEC 27002:2022's implementation guidance, or in one of the supporting 27000-series documents. Treating 27001 as a self-contained cookbook, rather than the certifiable skeleton of a larger reference library, is a subtler version of the same mistake as treating Annex A as a mandatory checklist.
What Stayed the Same: The Constants Beneath Every Revision
It's easy to walk away from a history this focused on change — new numbers, new structures, new control counts — with the impression that ISO/IEC 27001 has been rebuilt from scratch four times. It hasn't. A handful of foundational ideas have survived, essentially untouched, from BS 7799 Part 2 in 1998 through to the current 2022 edition, and recognizing them is just as useful for implementers as tracking what changed.
The risk-based core. Every version of the certifiable specification — BS 7799 Part 2, ISO/IEC 27001:2005, :2013, and :2022 — has required an organization to identify its own risks and select controls to treat them, rather than mandating a universal control set for every organization regardless of size, sector, or threat profile. This is the single most consistent thread across three decades of revision.
Third-party, independent certification. The basic commercial model established in 1998/1999 — an accredited external body audits your ISMS and issues a time-limited certificate, subject to periodic surveillance audits — has never changed in structure, only in the accreditation infrastructure and international recognition mechanisms that support it (discussed above).
Continual improvement as an obligation, not an aspiration. Whether it was named explicitly as "Act" in the PDCA cycle or embedded implicitly in Annex SL's clause 10, every version of the standard has required organizations to treat their ISMS as a living system that must demonstrably improve over time, evidenced through internal audit, management review, and corrective action — not a static binder produced once for an initial certificate and left untouched until renewal.
Top management accountability. From BS 7799 Part 2 onward, the standard has always required documented commitment from an organization's top management — not merely a security team's internal buy-in. The 2013 revision made this a standalone clause, and the 2022 revision preserved it essentially unchanged, but the underlying obligation traces back to the original UK specification.
The Statement of Applicability as the connective document. Since ISO/IEC 27001:2005 first formalized it, the SoA has remained the single document that ties an organization's risk treatment decisions to its selected (and excluded) Annex A controls, with justification. Every revision has changed what's inside Annex A; none has changed the SoA's role as the audit trail connecting risk decisions to control selection.
"Clients sometimes ask me what's actually 'new' about running an ISMS in 2024 versus 2006. Honestly, less than they expect. The paperwork looks different, the Annex A numbers are different, but you're still doing the same three things: figuring out what could go wrong, deciding what to do about it, and proving to an outside auditor that you actually did it." — Elena Vasquez, Lead Auditor, Meridian Certification Body
Case Study One: Kestrel Health Analytics — The Transition Deadline That Nearly Cost a Contract
We opened this article with Marcus Delaney's near-miss. Here's the fuller arc, because the resolution matters as much as the crisis.
Kestrel Health Analytics had been certified against ISO/IEC 27001:2013 since 2019. When ISO published the 2022 revision, Kestrel's certification body sent the standard transition-window notification — but it arrived by email to a distribution list that had gone stale after a reorganization, and nobody flagged it as urgent. By the time Marcus's hospital-network client raised the issue in March 2023, Kestrel had roughly nine months left before its accreditation body's transition deadline would render its 2013-based certificate unusable for continuing certification purposes.
We ran the transition as a compressed program: a two-week gap assessment mapping Kestrel's existing 114-control evidence base against the new 93-control, 4-theme structure; a six-week remediation sprint focused specifically on the handful of genuinely new controls (cloud security and threat intelligence were the two meaningful gaps; data masking required only a policy update since the technical control already existed); a documentation rewrite of the Statement of Applicability and risk treatment plan; and a compressed internal audit cycle before the external transition audit.
Outcome: Kestrel achieved ISO/IEC 27001:2022 certification in just under eight months from project kickoff — one month ahead of the hard deadline. The hospital-network contract renewal, which had been informally paused rather than canceled, closed within three weeks of the new certificate being issued, at the original $2.4 million valuation with no discount concession. Marcus's post-project change: version-transition status became a standing quarterly line item on Kestrel's vendor and certification risk register, reviewed regardless of how far away the next deadline appeared to be.
Case Study Two: Nordic Freight Group — Three Decades of Continuous Certification
Not every organization's relationship with this history is a near-miss story. Tobias Reinholt's employer, Nordic Freight Group, a European logistics and supply-chain company, has held continuous ISMS certification back to the BS 7799 Part 2 era — making it one of the longer unbroken certification histories I've personally worked with.
Nordic Freight's security team treats each transition as a scheduled capital-planning event rather than a reactive scramble, largely because their institutional memory stretches back far enough to have lived through the 2005 and 2013 transitions as well. When ISO/IEC 27001:2022 was published, Nordic Freight had already budgeted and resourced the transition project eighteen months in advance, based on the reasonable assumption (drawn directly from the 2013 transition's timeline) that accreditation bodies would allow roughly a two-to-three-year transition window before the previous version's certificates expired for new business purposes.
Outcome: Nordic Freight completed its transition audit eleven months ahead of the eventual deadline, incurred no rushed-consulting premium (unlike organizations that scrambled in the final quarter of the transition window, when auditor and consultant availability tightened and day rates rose), and used the transition as an opportunity to simultaneously integrate its ISMS documentation with its existing ISO 9001 quality system under the shared Annex SL clause structure — a merger that would have been substantially harder to justify to their board before the 2013 harmonization made the two standards' clause numbering genuinely compatible. Tobias estimates the early-planning approach saved the equivalent of roughly six weeks of external consulting time compared to a reactive transition timeline.
"We don't panic about revisions anymore, because we've been through three of them now. The pattern is always the same: publication, a multi-year transition window, and organizations who wait until the last two quarters pay a premium for rushed auditor and consultant time. Plan it like a capital project and it's routine." — Tobias Reinholt, Information Security Manager, Nordic Freight Group
Case Study Three: Alderney Financial Services — Certifying Directly to 2022 as a First-Timer
Not every organization in this history is managing a transition — some are entering the certification landscape for the first time, and the version history still shapes their decisions. Alderney Financial Services, a mid-sized wealth-management firm led on the compliance side by Sanjay Mehta, began its first-ever ISO 27001 certification project in early 2022, just as ISO/IEC 27002:2022 had been published but before ISO/IEC 27001:2022 itself had been finalized.
Sanjay's team faced a genuine strategic choice: certify quickly against the still-current ISO/IEC 27001:2013 to meet an aggressive client-driven deadline, or delay several months to certify directly against the incoming ISO/IEC 27001:2022 and avoid paying for a transition project a year or two later. Understanding the standard's revision cadence — roughly seven to eight years between the 2005, 2013, and 2022 revisions, and the historical pattern of multi-year transition windows — informed the decision directly.
Outcome: Alderney chose to wait roughly five months and certify directly against ISO/IEC 27001:2022 once it was published, rather than certify against the outgoing 2013 version and immediately face a transition project. This avoided an estimated redundant cost — Sanjay's internal estimate was in the range of $60,000–$90,000 in consulting, audit, and internal labor hours — that a near-immediate transition project would have required. The five-month delay did cost Alderney one smaller client engagement that had an inflexible certification deadline, but the net financial outcome favored waiting once the double-certification cost avoidance was weighed against the lost engagement.
"Understanding where a standard sits in its revision cycle is now a legitimate input into a certification timing decision, the same way you'd time a major software migration around a vendor's end-of-support date. We didn't get lucky — we did the math on the revision cadence and made a deliberate bet." — Sanjay Mehta, Director of Compliance, Alderney Financial Services
Version Comparison at a Glance
The following tables consolidate the detail covered throughout this article into quick-reference form.
Table 4: The Four Major Milestones Compared
Milestone | BS 7799 (Parts 1 & 2) | ISO/IEC 27001:2005 | ISO/IEC 27001:2013 | ISO/IEC 27001:2022 |
|---|---|---|---|---|
Publishing body | BSI (UK national) | ISO/IEC (international) | ISO/IEC (international) | ISO/IEC (international) |
First published | 1995 (Part 1); 1998/1999 (Part 2) | 2005 | 2013 | 2022 |
Certifiable internationally | No (UK national scheme only) | Yes — first international certifiable version | Yes | Yes |
Structural model | Two-part code of practice + specification | PDCA cycle | Annex SL harmonized structure | Annex SL harmonized structure, refined |
Annex A control count | ~127 (Part 1, descriptive, not yet "Annex A") | 133 | 114 | 93 |
Annex A organization | 10 sections | 11 domains | 14 domains (A.5–A.18) | 4 themes with 5 attributes |
Companion guidance standard | N/A (Part 1 served this role) | ISO/IEC 17799:2005 | ISO/IEC 27002:2013 | ISO/IEC 27002:2022 |
Table 5: Annex A Domain/Theme Counts Across Revisions
Revision | Organizing Units | Count per Unit (approx.) | Total Controls |
|---|---|---|---|
ISO/IEC 27001:2005 | 11 domains | Varies, 5–15 per domain | 133 |
ISO/IEC 27001:2013 | 14 domains (A.5–A.18) | Varies, 2–14 per domain | 114 |
ISO/IEC 27001:2022 | 4 themes | Organizational: 37; People: 8; Physical: 14; Technological: 34 | 93 |
Table 6: What Drove Each Major Revision
Revision | Primary Driver |
|---|---|
BS 7799 Part 1 (1995) | Lack of a common UK reference for information security practice |
BS 7799 Part 2 (1998/1999) | Market demand for an independently certifiable management-system specification |
ISO/IEC 17799:2000 | Demand to internationalize a well-regarded national code of practice |
ISO/IEC 17799:2005 | Maturing practice and closer alignment with the emerging BS 7799-2 successor |
ISO/IEC 27001:2005 | Need for a single global certifiable standard, replacing fragmented national schemes |
ISO/IEC 27002:2007 | Administrative renumbering into the newly formed 27000 family |
ISO/IEC 27001:2013 | Mandatory adoption of ISO's Annex SL harmonized high-level structure |
ISO/IEC 27001:2022 | Modernizing control content (cloud, threat intelligence, data protection) and reducing redundancy via consolidation |
Table 7: Certification Body Transition Windows (Historical Pattern)
From Version | To Version | Approximate Transition Window Pattern |
|---|---|---|
BS 7799-2 | ISO/IEC 27001:2005 | UK-certified organizations migrated over several years as international scheme matured |
ISO/IEC 27001:2005 | ISO/IEC 27001:2013 | Multi-year transition period set by accreditation bodies |
ISO/IEC 27001:2013 | ISO/IEC 27001:2022 | Multi-year transition period set by accreditation bodies, similar cadence to the prior cycle |
Table 8: Key Terminology Introduced or Changed by Revision
Term/Concept | First Appeared / Changed | Notes |
|---|---|---|
Code of practice vs. specification | BS 7799 Parts 1 & 2 (1995/1998–99) | Foundational split that persists as 27002 vs. 27001 today |
ISMS (Information Security Management System) | BS 7799 Part 2 | Central organizing concept of the entire standard family |
PDCA (Plan-Do-Check-Act) | BS 7799 Part 2 / ISO/IEC 27001:2005 | Management cycle model, later absorbed implicitly into Annex SL |
Statement of Applicability (SoA) | ISO/IEC 27001:2005 | Mandatory justification document for control selection/exclusion |
Annex SL / High-Level Structure (HLS) | Introduced 2012, applied in ISO/IEC 27001:2013 | Harmonized clause structure shared across ISO management standards |
Context of the organization (clause 4) | ISO/IEC 27001:2013 | New explicit requirement under Annex SL |
Themes (replacing domains) | ISO/IEC 27001:2022 | Organizational, People, Physical, Technological |
Control attributes | ISO/IEC 27001:2022 | Five-attribute tagging system for cross-framework mapping |
Table 9: Renumbering Reference — "What Used to Be Called What"
Current Name | Former Name(s) |
|---|---|
ISO/IEC 27001 | BS 7799 Part 2 (1998/1999) |
ISO/IEC 27002 | BS 7799 Part 1 (1995) → ISO/IEC 17799:2000 → ISO/IEC 17799:2005 |
ISO/IEC 27000 family | No prior unified name — assembled from 2005 onward |
Table 10: Documents an Implementer Should Know by Name
Document | Current Status | Role |
|---|---|---|
ISO/IEC 27001:2022 | Current, certifiable | Requirements for the ISMS itself |
ISO/IEC 27002:2022 | Current, non-certifiable | Control implementation guidance |
ISO/IEC 27000 | Current, informative | Overview and shared vocabulary |
ISO/IEC 27005 | Current, informative | Information security risk management guidance |
ISO/IEC 27003 | Current, informative | ISMS implementation guidance |
BS 7799 (all parts) | Withdrawn/superseded | Historical only |
ISO/IEC 17799 (all editions) | Withdrawn/superseded (renumbered) | Historical only |
ISO/IEC 27001:2005 | Withdrawn/superseded | Historical only |
ISO/IEC 27001:2013 | Superseded, transition period closed | No longer valid for new/continuing certification |
Table 11: Approximate Revision Cadence
Interval | Years Elapsed | Notes |
|---|---|---|
BS 7799 Part 1 → Part 2 | ~3–4 years | Code of practice preceded certifiable specification |
Part 2 → ISO/IEC 27001:2005 | ~6–7 years | International adoption process |
27001:2005 → 27001:2013 | ~8 years | Driven primarily by Annex SL mandate |
27001:2013 → 27001:2022 | ~9 years | Driven primarily by control modernization and consolidation |
Regional adoption patterns are worth a brief note before the table, because the reasons behind them tie directly back to the history covered above. The UK's head start wasn't just chronological — it reflected genuine institutional familiarity with the standard's predecessor, meaning UK auditors, consultants, and in-house security teams had a decade-plus of practical experience with BS 7799 before most of the rest of the world encountered ISO/IEC 27001:2005 for the first time. Japan and India's early enthusiasm tracked closely with both countries' large IT-outsourcing and business-process-outsourcing sectors, where an internationally recognized certificate became a fast, credible way to win contracts with Western clients wary of offshoring sensitive data without independent assurance. North America's slower initial adoption is often misread as skepticism about the standard's substance; in practice, it reflected a market that already had its own maturing compliance frameworks (SOC 1/SOC 2 reporting chief among them) and took longer to treat ISO/IEC 27001 as a complementary rather than competing artifact — a dynamic that reflects genuinely different historical starting points for third-party assurance rather than any gap in rigor between the two approaches.
Table 12: Who Adopted Early vs. Late, by Region (Illustrative Pattern)
Region | Approximate Adoption Pattern |
|---|---|
United Kingdom | Earliest and most consistent adoption, given BS 7799 origin |
Western Europe | Strong adoption following ISO/IEC 27001:2005 |
Japan, India | Early and enthusiastic international adoption post-2005 |
North America | Slower initial uptake, accelerated sharply post-2013 as global vendor contracts required it |
Southeast Asia, Middle East | Accelerated adoption post-2013, driven by outsourcing and data-processing contracts |
Table 13: Impact of Each Revision on Certificate Holders
Revision | Typical Transition Effort for Existing Holders |
|---|---|
2005 → 2013 | Moderate-to-high — new clause structure required documentation rewrite |
2013 → 2022 | Moderate — primarily control remapping and SoA rewrite; clause changes were comparatively minor |
Table 14: Common Misconceptions This History Corrects
Misconception | What the History Actually Shows |
|---|---|
"27002 is a simplified or lesser version of 27001" | 27002 is the direct descendant of the original 1995 code of practice; 27001 descends from the 1998/1999 specification — they're siblings, not parent/child |
"The 2022 version has fewer controls because security requirements got lighter" | The reduction from 114 to 93 came from consolidating overlapping controls, plus adding new ones for cloud, threat intelligence, and data protection |
"ISO 27001 is a static checklist that doesn't change" | It has been revised or renumbered at least five times in three decades, each time in response to real operational or structural pressure |
"A 2013 certificate is basically the same as a 2022 certificate" | Certification bodies enforced hard transition deadlines; an expired-transition 2013 certificate is not valid for continuing certification purposes |
"Annex A is the actual requirement" | The requirement has always been risk-based control selection; Annex A is a reference cross-check, unchanged in principle since 2005 |
Table 15: Quick Reference — Where to Learn More
Topic | Best Next Read |
|---|---|
Beginner-level overview of the current standard | What Is ISO 27001? A Complete Beginner's Guide to Information Security Management |
Difference between 27001 and 27002 today | |
Detailed 2013-to-2022 change breakdown | ISO 27001:2013 vs ISO 27001:2022: What Changed and Why It Matters |
Which industries need certification | Who Needs ISO 27001? Industries and Organizations That Benefit Most |
Full Annex A control detail | Annex A — All 93 Controls at a Glance (Annex A controls deep-dive guide, upcoming article) |
Managing an active transition project | ISO 27001:2013 to 2022 transition and migration guide (upcoming article) |
Step-by-step certification process | ISO 27001 certification process step-by-step guide (upcoming article) |
How the broader standards family fits together | ISO 27000 family overview article (upcoming article) |
Looking Ahead: What This History Suggests About the Next Revision
I'm careful not to overstate this, because I have no more insight into ISO committee deliberations than any other practitioner watching from outside — but the pattern documented throughout this article is consistent enough to support a few reasonable, clearly-labeled predictions rather than firm forecasts.
First, on timing: three intervals — roughly 1998/1999 to 2005, 2005 to 2013, and 2013 to 2022 — cluster in the seven-to-nine-year range. If that cadence holds, the next substantive revision is more plausibly a late-2020s-to-early-2030s event than an imminent one, which is a reasonable planning assumption for organizations weighing certification timing decisions the way Alderney Financial Services did in the case study below.
Second, on content direction: every revision in this history responded to a real gap the previous version's Annex A described only awkwardly — cryptography and access control maturing by 2005, the harmonization pressure of running multiple ISO management systems by 2013, and cloud, threat intelligence, and data protection by 2022. Extrapolating that pattern, not asserting it as confirmed direction, the operational areas generating the most "the standard doesn't quite name this cleanly yet" conversations I hear from clients today involve artificial-intelligence system governance, software-supply-chain integrity, and more granular third-party/fourth-party risk controls — all areas where ISO has already published or is developing adjacent standards (such as ISO/IEC 42001 for AI management systems) rather than folding them directly into 27001's Annex A. Whether any of that migrates into a future ISO/IEC 27001 revision, gets left as a companion standard the way risk management and metrics guidance were, or takes some third path, isn't something this article can responsibly claim to know — I raise it only because the historical pattern of "committee response to accumulated operational gaps" is the most reliable lens available for thinking about it.
Third, on structure: having gone through one harmonization shock (Annex SL, 2013) and one control-taxonomy shock (themes and attributes, 2022), it would be a reasonable bet that the next revision leans toward continuity of structure with content refresh, rather than another wholesale skeletal rebuild — organizations and certification bodies alike have signaled fairly clearly that they'd prefer to avoid a third major structural relearning cycle in short succession. That's an informed inference from the pattern in this article, not a claim about any confirmed ISO roadmap.
The Strategic Close: History as a Competitive Advantage, Not Trivia
Here's the reframe I try to leave every client with, and the one I'll leave you with here. Most organizations treat ISO 27001's version history as a compliance footnote — something a lawyer or an auditor mentions in passing before getting to the "real" work of implementing controls. That's backwards. The organizations that treat this history as strategic intelligence — Nordic Freight Group budgeting transitions years in advance, Alderney Financial Services timing its first certification around a known revision cadence, even Kestrel Health Analytics turning a near-miss into a standing quarterly risk-register item — consistently spend less on rushed consulting, avoid contract disruptions, and use certification transitions as opportunities to modernize their control environment rather than crises to survive.
The standard has changed four times in three decades because the discipline it governs keeps changing, and because ISO has, on the whole, done a credible job of catching up to real operational failure modes rather than change for its own sake. Every one of those changes is now baked into the 93 controls, four themes, and five attributes sitting in Annex A of ISO/IEC 27001:2022 — and every one of them tells you something about what the standard's authors have learned about how organizations actually fail. Read it that way, and implementation stops being a compliance chore and starts being a genuinely useful diagnostic of your own control environment.
If you're heading into a first-time certification, a 2013-to-2022 transition, or simply trying to explain to a board or a customer why version currency matters, don't do it from memory or from a vendor's marketing page. Ground the decision in the actual history — what changed, why it changed, and what problem it was solving — and you'll make better scoping, timing, and resourcing calls than teams working from the assumption that "ISO 27001" is a single, unchanging artifact.
PentesterWorld can help you turn that grounding into an actual audit-ready program. If you're mapping your current control environment against the modern 93-control structure, our Annex A — All 93 Controls at a Glance reference is built for exactly that first-pass exercise. If you're assembling or refreshing the documentation set an auditor will actually ask for, our Mandatory Documents Checklist and Certification Readiness Checklist are designed to keep a transition or first-time project from missing the unglamorous paperwork that derails timelines. And if you want the full, structured version of everything covered at a higher level in this article — implementation sequencing, resourcing, and audit preparation — The Complete ISO 27001 Implementation Guide (eBook) walks through the entire program end to end.
Whatever stage you're at — first certification, an overdue transition, or a board asking pointed questions about a vendor's certificate — understanding where this standard came from is the fastest way to understand exactly what it's asking of you now.