The 2022 edition of ISO/IEC 27001 has been published, and the Japanese edition, JIS Q 27001:2023, was issued on 20 September 2023. The transition deadline from the 2013 edition was 31 October 2025 and has passed. For any organisation certifying now, there is only one target: the 2022 edition.
So why does the difference still matter? Because material written against the old edition is still everywhere. Legacy internal procedures, books on the shelf, articles ranking well in search, questions on security check sheets sent by customers, excerpts of other companies' Statements of Applicability — these are frequently written in 2013-edition control numbers and fourteen-category vocabulary.
Build your documents from a source you did not realise was outdated, and you end up citing control references that no longer exist, or mixing four themes with fourteen categories in the same document. This article sets out the differences so that does not happen.
Disclaimer: This article is general information. The authoritative texts are ISO/IEC 27001 (JIS Q 27001) itself and the publications of the accreditation and certification bodies. Base actual decisions on those.
Where Things Stand
| Date | Event |
|---|---|
| 2013 | ISO/IEC 27001:2013 published (Japanese edition JIS Q 27001:2014) |
| 2022 | ISO/IEC 27001:2022 published |
| 20 September 2023 | JIS Q 27001:2023 published — the Japanese 2022 edition |
| 31 October 2025 | Transition deadline from the 2013 edition. Passed |
| Now | New certifications and recertifications alike target the 2022 edition |
Three practical consequences:
- If you are considering certification: build against the 2022 edition from the start. There is no reason to consult the 2013 edition
- If you already hold certification: transition is complete. Surveillance and recertification audits run against the 2022 edition
- In either case: check whether the reference material in your hands predates the change
See What Is an ISMS for the overview.
Annex A Restructured: 114 to 93
The largest change is Annex A. The 114 controls of the 2013 edition became 93 in 2022, described as:
| Category | Count | Description |
|---|---|---|
| Updated | 58 | Carried over with revised wording and scope |
| Merged | 24 | Several former controls consolidated into one |
| New | 11 | Added in the 2022 edition |
| Total | 93 |
The reduction does not mean the requirements got lighter. Overlapping controls were consolidated, and modern concerns (cloud, threat intelligence, data leakage prevention) were added. The practical workload is, if anything, larger by the eleven new controls.
The eleven new controls
| Reference | Control | What it means in practice |
|---|---|---|
| A.5.7 | Threat intelligence | Collect and analyse threat information relevant to you and feed it into your controls |
| A.5.23 | Information security for use of cloud services | Define a process and security requirements covering selection, use, and exit |
| A.5.30 | ICT readiness for business continuity | Make ICT recovery objectives and means concrete within the BCP |
| A.7.4 | Physical security monitoring | Where you hold facilities, consider continuous monitoring via cameras and sensors |
| A.8.9 | Configuration management | Define hardware, software, and service configurations and control changes to them |
| A.8.10 | Information deletion | Delete information no longer needed — paired with defined retention periods |
| A.8.11 | Data masking | Mask or pseudonymise production data used in development and testing |
| A.8.12 | Data leakage prevention | Detect and prevent exfiltration of sensitive information |
| A.8.16 | Monitoring activities | Monitor networks, systems, and applications for anomalies |
| A.8.23 | Web filtering | Restrict access to malicious sites |
| A.8.28 | Secure coding | Apply secure coding principles where development occurs |
Six of the eleven are technological controls (A.8). For healthcare SaaS companies that build and run their own product, that is where the real additional work sits. See Annex A 2022: 93 Controls Across Four Themes and Reading the 34 Technological Controls.
Fourteen Categories Become Four Themes
The 2013 Annex A ran from A.5 to A.18 — fourteen categories. The 2022 edition restructures them into four themes.
| 2013 category (A.5–A.18) | Where it mainly lands in 2022 |
|---|---|
| A.5 Information security policies | Organizational (A.5) |
| A.6 Organization of information security | Organizational (A.5) / People (A.6) |
| A.7 Human resource security | People (A.6) |
| A.8 Asset management | Organizational (A.5) / Technological (A.8) |
| A.9 Access control | Organizational (A.5) / Technological (A.8) |
| A.10 Cryptography | Technological (A.8) |
| A.11 Physical and environmental security | Physical (A.7) |
| A.12 Operations security | Technological (A.8) |
| A.13 Communications security | Technological (A.8) |
| A.14 System acquisition, development and maintenance | Technological (A.8) |
| A.15 Supplier relationships | Organizational (A.5) |
| A.16 Information security incident management | Organizational (A.5) |
| A.17 Information security aspects of business continuity | Organizational (A.5) |
| A.18 Compliance | Organizational (A.5) |
The 2022 structure:
| Theme | Reference | Controls |
|---|---|---|
| Organizational | A.5 | 37 |
| People | A.6 | 8 |
| Physical | A.7 | 14 |
| Technological | A.8 | 34 |
This is where reference collisions cause accidents. "A.8" meant asset management in 2013 and means technological controls in 2022. "A.9 Access control" does not exist in the 2022 edition at all. When reading older material, confirm the edition before quoting any reference.
The table above gives approximate destinations only. Because controls were merged and split, many do not map one to one; consult the correspondence tables in the standard itself for precision.
Attributes
The 2022 Annex A assigns attributes to each control, so controls can be viewed across several dimensions.
| Attribute | Example values |
|---|---|
| Control type | Preventive / detective / corrective |
| Information security properties | Confidentiality / integrity / availability |
| Cybersecurity concepts | Identify / protect / detect / respond / recover |
| Operational capabilities | Governance, asset management, information protection, human resource security, physical security, system and network security, and others |
| Security domains | Governance and ecosystem / protection / defence / resilience |
Crucially, using attributes is optional. There is no obligation to add attribute columns to the SoA, and not using them does not affect conformity.
They are worth using when you want to:
- Expose thin detection coverage — classifying by control type reveals a portfolio skewed towards prevention
- Explain coverage to executives across confidentiality, integrity, and availability
- Map to other frameworks — the identify/protect/detect/respond/recover axis connects readily
For a first certification with limited capacity, skipping attributes is reasonable. See How to Write a Statement of Applicability.
Changes in the Main Text (Clauses 4–10)
Smaller than the Annex A restructure, but a few points require documents or processes to be rebuilt.
| Clause | Main change | Practical impact |
|---|---|---|
| 4 Context | Clarified that you determine which interested-party requirements will be addressed through the ISMS; determining the processes needed for the ISMS and their interactions is made explicit | The interested-parties register needs a column for "addressed via the ISMS?" |
| 5 Leadership | No substantive change | — |
| 6 Planning | Wording reorganised so that controls determined for risk treatment are compared against Annex A to verify nothing necessary was omitted; objectives must be monitored, communicated, and documented; 6.3 planning of changes is new | The SoA is built risk → controls → Annex A verification. A procedure for planned ISMS changes is needed |
| 7 Support | No substantive change (communication requirements tidied) | — |
| 8 Operation | Clarified establishment of process criteria and control to those criteria, control of planned changes and review of unintended changes, and control of externally provided processes, products and services | Change records become effectively mandatory |
| 9 Performance evaluation | 9.2 and 9.3 subdivided; "changes in needs and expectations of interested parties" added explicitly to management review inputs | Add a field to the minutes template |
| 10 Improvement | Order swapped: 10.1 continual improvement, 10.2 nonconformity and corrective action | Update cross-references inside your documents |
Clause-by-clause detail: Clause 4: Context, Clause 5: Leadership, Clause 6: Planning, Clause 7: Support, Clause 8: Operation, Clause 9: Performance Evaluation, Clause 10: Improvement.
Reading Old-Edition Material Safely
| Situation | What goes wrong | What to do |
|---|---|---|
| Legacy internal procedures | References like "in accordance with A.12 Operations security" buried in the text | Full-text search the references and replace with 2022 numbering; update theme names too |
| Books and web articles | Chapter structure built on fourteen categories; old numbering | Check publication date and target edition. Treat anything before October 2022 as old-edition |
| Another company's SoA as a model | A 114-row format with old references | Use the structure as a model; do not reuse the numbers |
| A customer's check sheet follows the old edition | Questions like "regarding access control under A.9…" | Map to the 2022 control and answer — and state in your response that you did so |
| Checking a supplier's certificate | The certificate cites the old standard | Certificates citing the old edition may still look current; verify the edition and the expiry date |
| Reusing an old risk assessment | Control column carries old references | Reuse the risk content, but rebuild the control linkage |
The fourth row deserves particular care. Security check sheets sent by customers are often reused without updating. Answering in old numbering leaves your response inconsistent with your own documents; a single line noting the mapping saves later queries. See Security Check Sheets for Vendors.
New Controls That Bite Hardest in Healthcare
A.5.23 Information security for use of cloud services
Putting medical information in the cloud means defining selection criteria, contractual security requirements, the responsibility split, and data return and deletion on exit. This overlaps with what Japan's three-ministry guidelines require of cloud use, so covering both in one procedure is efficient. See Cloud Security for Medical Institutions and Shared Responsibility in AI EMR Security Design.
A.8.10 Information deletion / A.8.11 Data masking
Retention periods for medical information and reliable deletion afterwards map directly onto these two. And copying production medical data into development or test environments is the textbook practice that A.8.11 forces you to revisit. Defining pseudonymisation and masking procedures lets you comply without slowing development.
A.8.16 Monitoring activities
Medical information systems need more than log collection — they need anomaly detection. The question is not only whether you record who viewed what and when, but whether you detect access patterns that differ from normal. See Reviewing EMR Access Logs.
A.8.28 Secure coding
If you build healthcare products yourself, this brings coding standards, review, static analysis, and dependency management into scope. See Security by Design for Medical Systems.
All four are demanded by both the guidelines and the ISMS. See Integrating ISMS Documents with the Three-Ministry Guidelines and Japan's Three-Ministry Guidelines.
Conclusion
- The transition deadline (31 October 2025) has passed. New certifications and recertifications alike target the 2022 edition; migration is no longer a live topic
- The diff still matters because internal documents, books, web articles, and customer check sheets written against the old edition remain in circulation
- Annex A went from 114 to 93: 58 updated, 24 merged, 11 new. The count fell through consolidation, not relaxation
- Fourteen categories became four themes (organizational 37, people 8, physical 14, technological 34). Old A.8 and A.9 mean different things now — always confirm the edition before citing a reference
- Attributes are optional. No obligation to add them to the SoA; useful for exposing weak detection coverage
- In the main text, new 6.3 planning of changes, clarified change control in 8.1, the added management review input in 9.3, and the reordering of clause 10 are what affect practice
- Six of the eleven new controls are technological. In healthcare, A.5.23 cloud, A.8.10 deletion, A.8.11 masking, A.8.16 monitoring, and A.8.28 secure coding carry the most weight
Pottech supports ISMS certification with a focus on healthcare. Our procedure, register, and training templates are built on the 2022 edition, so you do not start by translating old-edition material. We also work through which of the eleven new controls genuinely apply to you.
See ISMS Certification Support for scope and pricing, or contact us if you want a view on whether your existing documents align with the 2022 edition.
References and Sources
- Information Management System Accreditation Center (ISMS-AC)
- On the transition to ISO/IEC 27001:2022 | ISMS-AC
- ISO/IEC 27001 Information security management systems | ISO
- Japanese Industrial Standards Committee
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: for the exact correspondence of merged and split controls, consult the mapping tables included in the standard. The formal handling of the transition is governed by the publications of the accreditation and certification bodies.