ISO 27001:2013の認証は2025年10月31日で失効しました。 まだISO 27001:2022への移行が完了していない組織は、実質的に「ISMS認証なし」の状態に陥っています。取引先からの信頼低下、入札要件の不適合、サプライチェーンからの除外――移行の遅れがもたらすビジネスリスクは日を追うごとに深刻化しています。

本記事では、ISO 27001:2022への移行に必要な知識を体系的に解説します。2013年版からの変更点、附属書Aの再編、新設された11の管理策、移行審査の実務、費用の目安、そして中小企業が陥りがちな失敗パターンまで、移行プロジェクトの全体像を網羅的にお伝えします。

目次

  1. ISO 27001:2022とは？2013年版からの主な変更点
  2. 附属書A管理策の変更（114項目→93項目、新設11項目の詳細）
  3. 移行期限と審査スケジュール
  4. 移行に必要な作業
  5. 新設された11の管理策の解説と実装方法
  6. 移行費用の目安（規模別）
  7. 移行プロジェクトのスケジュール例（6ヶ月計画）
  8. よくある移行の失敗パターンと対策
  9. まとめ

ISO 27001:2022とは？2013年版からの主な変更点

ISO 27001:2022の概要

ISO 27001:2022は、2022年10月25日に発行された情報セキュリティマネジメントシステム（ISMS）の国際規格の最新版です。前版であるISO 27001:2013から約9年ぶりの改訂となり、クラウドコンピューティング、リモートワーク、サプライチェーン攻撃など、近年の情報セキュリティ環境の変化に対応した内容に更新されています。

日本では、JIS Q 27001:2023として2023年9月に日本産業規格（JIS）に反映されました。

本文（箇条4〜10）の変更点

ISO 27001:2022の本文部分の変更は比較的限定的ですが、重要な追加・修正が含まれています。

箇条変更内容影響度
箇条4.2利害関係者の要求事項のうち、ISMSで対処するものを明確化中
箇条4.4ISMSに必要なプロセスとその相互作用を決定することを追加中
箇条6.2情報セキュリティ目的の監視について追加低
箇条6.3「変更の計画」が新設。ISMSの変更を計画的に実施することを要求高
箇条8.1プロセスの基準の確立、基準に基づくプロセスの管理の実施を追加中
箇条9.1監視・測定の方法の比較可能性・再現性の要求中
箇条9.3マネジメントレビューのインプットに利害関係者のニーズ・期待の変化を追加低
箇条10改善（10.1）と不適合・是正処置（10.2）の順序を入れ替え低
特に注目すべきは箇条6.3「変更の計画」の新設です。ISMSの変更（適用範囲の変更、新技術の導入、組織再編など）を計画的に管理することが明示的に要求されるようになりました。

附属書Aの大幅再編

最も大きな変更は附属書A（管理策のリファレンス）です。ISO 27002:2022の改訂に合わせて、管理策が大幅に再編成されました。

  • 2013年版: 14カテゴリ・114管理策
  • 2022年版: 4テーマ・93管理策

管理策の数が114から93に削減されたのは、統合・整理によるものであり、セキュリティ要求のレベルが下がったわけではありません。むしろ、クラウドセキュリティやデータマスキングなど、現代のIT環境に即した11の新規管理策が追加されています。

附属書A管理策の変更（114項目→93項目、新設11項目の詳細）

4テーマへの再編

2022年版では、従来の14カテゴリから以下の4テーマに再編されました。

テーマ管理策数内容
A.5 組織的管理策37項目ポリシー、役割、資産管理、アクセス制御方針など
A.6 人的管理策8項目選考、雇用条件、教育、懲戒、退職時の対応など
A.7 物理的管理策14項目セキュリティ境界、入退室管理、機器保護など
A.8 技術的管理策34項目認証、暗号化、ネットワーク、開発セキュリティなど

管理策の統合・整理

93の管理策のうち、以下のように分類されます。

  • 新規追加: 11項目
  • 統合（複数→1つ）: 24項目（旧版の57管理策を統合）
  • 改訂（名称・内容変更）: 58項目

属性（Attribute）の導入

2022年版では、各管理策に5つの属性が付与されました。これにより、組織の視点に応じた管理策の分類・フィルタリングが可能になっています。

属性値の例
管理策タイプ予防、検知、是正
情報セキュリティ特性機密性、完全性、可用性
サイバーセキュリティ概念特定、防御、検知、対応、復旧
運用能力ガバナンス、資産管理、人的セキュリティなど
セキュリティドメインガバナンス・エコシステム、保護、防御、レジリエンス
この属性タグは、適用宣言書（SoA）の整理や、経営層への報告時のフレームワークとしても有用です。

移行期限と審査スケジュール

移行期限の確認

マイルストーン日付状況
ISO 27001:2022 発行2022年10月25日完了
JIS Q 27001:2023 発行2023年9月20日完了
2013年版での新規認証受付終了2024年4月30日完了
2013年版認証の失効2025年10月31日完了
2025年10月31日をもって、ISO 27001:2013の認証は全て失効しました。 現時点（2026年4月）で2022年版への移行が完了していない組織は、ISMS認証を喪失した状態です。

未移行の場合にすべきこと

移行期限を過ぎた場合、以下の選択肢があります。

  1. 移行審査の早期実施: 認証機関に相談し、最短で移行審査を受ける。認証の空白期間は生じるが、新規取得よりも負担は軽い。
  2. 新規認証取得として申請: 移行ではなく新規取得として扱われる場合がある。ステージ1審査とステージ2審査の両方が必要。
  3. 認証機関の変更: 現在の認証機関のスケジュールが合わない場合、他の認証機関への移転も検討。

いずれの場合も、一日でも早く認証機関に連絡することが最も重要です。

移行に必要な作業

移行プロジェクトは、大きく分けて以下の4つのフェーズで構成されます。

1. ギャップ分析

現行のISMSと2022年版の要求事項を比較し、不足している部分を特定します。

主な確認ポイント:

  • 本文（箇条4〜10）の変更に対する適合状況
  • 箇条6.3「変更の計画」のプロセスが存在するか
  • 附属書Aの93管理策に対する適用状況の見直し
  • 新設11管理策への対応状況
  • 適用宣言書（SoA）の更新要否

ギャップ分析チェックリスト（抜粋）:

  • [ ] 箇条4.2: 利害関係者のISMS関連要求事項を特定しているか
  • [ ] 箇条4.4: ISMSのプロセスとその相互作用を文書化しているか
  • [ ] 箇条6.3: ISMSの変更管理手順を策定しているか
  • [ ] 箇条8.1: プロセスの基準を明確にし、管理を実施しているか
  • [ ] 附属書A: 新管理策93項目との対応を確認したか
  • [ ] SoA: 適用宣言書を2022年版に基づいて更新したか

2. 文書改訂

ギャップ分析の結果に基づき、ISMSの文書体系を更新します。

改訂が必要な文書の例:

文書名主な改訂内容
ISMS基本方針規格番号・版の更新、変更管理の方針追加
適用宣言書（SoA）93管理策への再マッピング、新管理策の採否決定
リスクアセスメント手順新管理策を選択肢に追加
情報セキュリティ目的監視方法の明確化（箇条6.2対応）
変更管理手順新規作成（箇条6.3対応）
脅威インテリジェンス手順新規作成（A.5.7対応）
クラウドサービス利用方針新規作成または改訂（A.5.23対応）
データマスキング手順新規作成（A.8.11対応）
DLP（情報漏えい防止）方針新規作成（A.8.12対応）

3. リスクアセスメントの更新

2022年版の管理策体系に基づいて、リスクアセスメントとリスク対応計画を更新します。

更新のポイント:

  1. リスク特定: クラウドサービス、リモートワーク、サプライチェーンなど新たな脅威シナリオを追加
  2. リスク分析: 新管理策を踏まえた管理策の選定
  3. リスク対応計画: 新管理策の実装スケジュールを含める
  4. 適用宣言書との整合: SoAとリスク対応計画の一貫性を確保

4. 内部監査の実施

移行審査の前に、2022年版の要求事項に基づく内部監査を少なくとも1回は実施する必要があります。

内部監査の重点ポイント:

  • 新規追加された箇条6.3への適合性
  • 適用宣言書（SoA）が2022年版の管理策体系に更新されているか
  • 新設11管理策のうち適用とした管理策が実装されているか
  • リスクアセスメントが更新されているか
  • トップマネジメントのマネジメントレビューが実施されているか

新設された11の管理策の解説と実装方法

ISO 27001:2022で新たに追加された11の管理策は、現代の情報セキュリティ環境における重要なリスクに対応するものです。以下に各管理策の概要と、中小企業における実装のポイントを解説します。

A.5.7 脅威インテリジェンス（Threat Intelligence）

概要: 情報セキュリティの脅威に関する情報を収集・分析し、適切な緩和策を講じること。

中小企業での実装方法:

  • IPA（情報処理推進機構）やJPCERT/CCの注意喚起情報を定期的に確認する体制を構築
  • セキュリティベンダーのメールマガジンやRSSフィードを購読
  • 月次で脅威情報のレビューミーティングを実施
  • 自社に関連する脅威（業界・利用技術・地域）を優先的に監視

実装難易度: ★★☆☆☆（低コストで着手可能）

A.5.23 クラウドサービスの利用における情報セキュリティ（Information Security for Use of Cloud Services）

概要: クラウドサービスの取得、利用、管理、終了のプロセスにおいて情報セキュリティ要求事項を確立すること。

中小企業での実装方法:

  • 利用中のクラウドサービスの棚卸しを実施（SaaS/IaaS/PaaS）
  • クラウドサービス利用方針を策定（選定基準、データ保管場所、責任分界点）
  • 各サービスのセキュリティ設定（多要素認証、アクセス制御、ログ取得）を確認
  • 契約終了時のデータ削除手順を明確化

実装難易度: ★★★☆☆（棚卸しに工数がかかる）

A.5.30 事業継続のためのICTの備え（ICT Readiness for Business Continuity）

概要: 事業継続の目的に基づいて、ICT（情報通信技術）の備えを計画、実装、維持、テストすること。

中小企業での実装方法:

  • 重要な業務システムのRTO（目標復旧時間）とRPO（目標復旧時点）を設定
  • バックアップの取得状況と復旧手順の確認
  • 年1回以上の復旧テスト（DR訓練）を実施
  • クラウドサービスの冗長性・可用性SLAの確認

実装難易度: ★★★☆☆（BCP策定済みならスムーズ）

A.7.4 物理的セキュリティの監視（Physical Security Monitoring）

概要: 施設を継続的に監視し、不正な物理的アクセスを検知すること。

中小企業での実装方法:

  • サーバールーム・重要区画への監視カメラの設置
  • 入退室ログの定期的なレビュー
  • 営業時間外の不審なアクセスに対するアラートの設定
  • 監視記録の保存期間の決定（最低90日を推奨）

実装難易度: ★★☆☆☆（既存の設備を活用可能）

A.8.9 構成管理（Configuration Management）

概要: ハードウェア、ソフトウェア、サービス、ネットワークの構成を確立、文書化、実装、監視、レビューすること。

中小企業での実装方法:

  • IT資産台帳にOS・ソフトウェアのバージョン情報を追加
  • 標準構成（ベースライン）を定義し文書化
  • 構成変更時の承認プロセスを確立
  • 定期的な構成の棚卸しと逸脱の検出

実装難易度: ★★★☆☆（IT資産管理の基盤が必要）

A.8.10 情報の削除（Information Deletion）

概要: 情報システム、デバイス、その他の記憶媒体に保存された情報を、不要になった場合に削除すること。

中小企業での実装方法:

  • 情報の保存期間ルールの策定（法定保存義務との整合）
  • 保存期限切れデータの定期的な削除プロセスの実施
  • クラウドストレージ・SaaSのデータ削除手順の確認
  • 機器廃棄時のデータ消去の証明書取得

実装難易度: ★★☆☆☆（ルール策定がメイン）

A.8.11 データマスキング（Data Masking）

概要: 適用される法令、規制、その他の関連する義務に沿って、データマスキングを使用すること。

中小企業での実装方法:

  • マスキングが必要なデータの特定（個人情報、テストデータ等）
  • テスト環境で本番データを使用する場合のマスキングルールの策定
  • 外部委託先へのデータ提供時のマスキング手順の確立
  • ログ出力における機微情報のマスキング

実装難易度: ★★★★☆（技術的な対応が必要）

A.8.12 データ漏えいの防止（Data Leakage Prevention）

概要: データ漏えい防止策を、機微な情報を処理、保存、送信するシステム、ネットワーク、その他のデバイスに適用すること。

中小企業での実装方法:

  • 機密情報の分類と取扱いルールの整備
  • メール添付ファイルの制限（拡張子、サイズ等）
  • USBデバイスの使用制限ポリシーの導入
  • クラウドストレージの外部共有設定の管理
  • Microsoft 365やGoogle Workspaceの情報保護機能の活用

実装難易度: ★★★☆☆（ツール導入で効率化可能）

A.8.16 監視活動（Monitoring Activities）

概要: ネットワーク、システム、アプリケーションの異常な挙動を検知するための監視を行い、情報セキュリティインシデントの可能性を評価すること。

中小企業での実装方法:

  • ファイアウォール・UTMのログ監視の有効化
  • 不審なログイン（時間外・海外IP）のアラート設定
  • サーバー・ネットワーク機器のリソース監視
  • セキュリティイベントのレビュー体制の構築（週次または月次）

実装難易度: ★★★☆☆（SOCサービスの活用も有効）

A.8.23 ウェブフィルタリング（Web Filtering）

概要: 外部ウェブサイトへのアクセスを管理し、悪意のあるコンテンツへの暴露を低減すること。

中小企業での実装方法:

  • UTMやDNSフィルタリングによるカテゴリベースのアクセス制御
  • フィッシングサイト・マルウェア配布サイトへのアクセスブロック
  • 業務に不必要なカテゴリ（ギャンブル等）のフィルタリング
  • 利用者への通知と例外申請プロセスの整備

実装難易度: ★★☆☆☆（UTM導入済みなら設定のみ）

A.8.28 セキュアコーディング（Secure Coding）

概要: ソフトウェア開発にセキュアコーディングの原則を適用すること。

中小企業での実装方法:

  • 自社で開発を行っている場合: セキュアコーディング規約の策定
  • 外部委託の場合: 委託先のセキュアコーディング基準の確認と契約への反映
  • 脆弱性診断（ペネトレーションテスト）の定期実施
  • OWASP Top 10を参考にした開発ガイドラインの導入

実装難易度: ★★★★☆（開発組織の有無で大きく異なる）

移行費用の目安（規模別）

移行費用は組織の規模、既存ISMSの成熟度、認証範囲によって大きく異なります。以下は一般的な目安です。

小規模企業（従業員50名以下）

項目費用目安
ギャップ分析30万〜50万円
文書改訂支援50万〜100万円
内部監査代行20万〜40万円
移行審査費用（認証機関）40万〜70万円
合計140万〜260万円

中規模企業（従業員51〜300名）

項目費用目安
ギャップ分析50万〜100万円
文書改訂支援100万〜200万円
内部監査代行40万〜80万円
移行審査費用（認証機関）70万〜120万円
教育・研修20万〜50万円
合計280万〜550万円

大規模企業（従業員300名超）

項目費用目安
ギャップ分析100万〜200万円
文書改訂支援200万〜400万円
内部監査代行80万〜150万円
移行審査費用（認証機関）120万〜250万円
教育・研修50万〜100万円
ツール・システム導入100万〜300万円
合計650万〜1,400万円

費用を抑えるポイント

  1. 自社でできる作業を特定: ギャップ分析の一部やSoAの更新は、ISMS担当者が実施可能
  2. コンサルタントの活用範囲を限定: 全工程を委託するのではなく、新管理策の実装支援など重点領域に絞る
  3. 内部監査員の育成: 内部監査を外部委託せず、自社の監査員で対応する
  4. 認証機関の比較検討: 審査費用は認証機関によって差があるため、複数機関から見積もりを取得

移行プロジェクトのスケジュール例（6ヶ月計画）

以下は、中小企業を想定した6ヶ月の移行プロジェクトスケジュールです。

第1月：キックオフ・ギャップ分析

週作業内容
第1週プロジェクトチーム編成、キックオフミーティング
第2週ISO 27001:2022の規格理解研修
第3〜4週ギャップ分析の実施（本文・附属書A）
成果物: ギャップ分析報告書、移行作業一覧

第2月：適用宣言書・リスクアセスメント更新

週作業内容
第1〜2週適用宣言書（SoA）の再作成（93管理策へのマッピング）
第3〜4週リスクアセスメントの更新（新たな脅威シナリオ追加）
成果物: 適用宣言書（2022年版）、更新済みリスクアセスメント

第3月：文書改訂

週作業内容
第1週ISMSマニュアル・基本方針の改訂
第2週変更管理手順の新規策定（箇条6.3対応）
第3週新管理策に対応する手順書の作成
第4週文書体系の整合性確認・レビュー
成果物: 改訂済みISMS文書一式

第4月：新管理策の実装

週作業内容
第1週脅威インテリジェンス収集体制の構築（A.5.7）
第2週クラウドサービス棚卸し・管理策の実装（A.5.23）
第3週DLP・データマスキング対策の実装（A.8.11, A.8.12）
第4週監視活動・ウェブフィルタリングの設定（A.8.16, A.8.23）
成果物: 新管理策の実装完了報告

第5月：内部監査・マネジメントレビュー

週作業内容
第1週内部監査計画の策定
第2〜3週内部監査の実施（2022年版要求事項基準）
第4週マネジメントレビューの実施、是正処置
成果物: 内部監査報告書、マネジメントレビュー議事録

第6月：移行審査対応

週作業内容
第1週審査前の最終確認（文書・記録の整備）
第2〜3週移行審査（認証機関による審査）
第4週指摘事項への対応・是正処置の実施
成果物: 移行審査完了、ISO 27001:2022認証取得

スケジュールの注意点

  • 認証機関の審査スケジュールは2〜3ヶ月前に予約が必要
  • 繁忙期は審査枠が埋まりやすいため、早期の予約を推奨
  • 是正処置が必要な場合、追加で1〜2ヶ月かかることを想定
  • 年度末（3月）は認証機関が混み合うため、避けることを推奨

よくある移行の失敗パターンと対策

失敗パターン1：形だけの文書改訂

問題: SoAや手順書の「版番号」と「規格番号」だけを更新し、実質的な内容変更を行わない。

なぜ失敗するか: 審査員は新管理策の実装状況を具体的に確認します。特に新設11管理策に対して「該当なし（Not Applicable）」を乱用すると、その理由を厳しく問われます。

対策:

  • 新管理策それぞれについて、自社環境での適用可否を真剣に検討する
  • 不適用とする場合は、合理的な根拠を文書化する
  • 適用する管理策は、運用記録（エビデンス）を蓄積しておく

失敗パターン2：新管理策への理解不足

問題: 脅威インテリジェンス（A.5.7）やDLP（A.8.12）など、これまでの管理策にはなかった概念を正しく理解せずに実装する。

なぜ失敗するか: 管理策の趣旨を理解しないまま手順を作ると、審査時に「なぜこの対策をしているのか」の説明ができず、不適合と判定される。

対策:

  • ISO 27002:2022のガイダンスを参照し、管理策の目的と実施の手引きを理解する
  • 外部セミナーや研修で最新の知識を習得する
  • 必要に応じて専門コンサルタントの支援を受ける

失敗パターン3：リスクアセスメントの未更新

問題: 管理策の体系は更新したが、リスクアセスメントは旧版のまま。

なぜ失敗するか: SoAの管理策選定はリスクアセスメントの結果に基づく必要があります。両者が整合していないと、ISMSの根幹であるPDCAサイクルが機能していないと判断されます。

対策:

  • SoAの更新とリスクアセスメントの更新をセットで実施する
  • 新たな脅威（クラウドリスク、サプライチェーン攻撃等）をリスク台帳に追加する
  • リスク対応計画に新管理策の実装を明記する

失敗パターン4：経営層の関与不足

問題: 移行作業をISMS担当者やIT部門に丸投げし、経営層が関与しない。

なぜ失敗するか: ISO 27001は「マネジメントシステム」規格であり、トップマネジメントのリーダーシップとコミットメントが不可欠です。マネジメントレビューの質が低いと、審査で問題視されます。

対策:

  • プロジェクトの初期段階で経営層にブリーフィングを実施
  • マネジメントレビューのインプット情報を充実させる
  • 情報セキュリティ目的を経営戦略と紐づけて説明する

失敗パターン5：移行期限を過ぎてからの着手

問題: 「まだ大丈夫」と考えて移行を先送りにし、期限切れ後に慌てて着手する。

なぜ失敗するか: 認証失効後は取引先からの信頼低下、入札資格の喪失、サプライチェーンからの除外リスクがあります。また、認証機関の審査枠が確保できず、さらに遅延するという悪循環に陥ります。

対策:

  • 今すぐ認証機関に連絡し、最短の審査日程を確保する
  • 移行コンサルタントの支援を受けて短期集中で対応する
  • 取引先に対して移行スケジュールを開示し、信頼回復に努める

失敗パターン6：教育・周知の軽視

問題: 文書の改訂は行ったが、従業員への教育や周知を実施しない。

なぜ失敗するか: 審査では現場のスタッフに対してインタビューが行われます。自社のISMSの変更点を理解していないと、運用が形骸化していると判断される可能性があります。

対策:

  • 全従業員向けの移行説明会を開催
  • 変更点のポイントをまとめた資料を配布
  • 部門責任者を通じた周知と理解度の確認

まとめ

ISO 27001:2022への移行は、単なる規格の版更新ではなく、組織の情報セキュリティ体制を現代のサイバー脅威に対応させる重要な機会です。

移行のポイントを振り返り

  1. 本文の変更は限定的だが重要: 特に箇条6.3「変更の計画」の新設に対応が必要
  2. 附属書Aは大幅再編: 4テーマ・93管理策への移行と、新設11管理策への対応が核心
  3. 2013年版は既に失効: 未移行の場合は一日も早く認証機関に連絡を
  4. 費用は規模次第: 小規模企業でも140万〜260万円程度を見込む
  5. 6ヶ月あれば移行可能: ただし認証機関の審査枠は早期に確保すべき
  6. 形だけの移行は通用しない: 新管理策の実質的な実装とエビデンスが必要

移行を先送りにしてはいけない理由

  • 取引先からの要求: ISMS認証は多くの業界で取引条件に含まれている
  • 入札・プロポーザルへの影響: 官公庁や大手企業の案件ではISMS認証が必須条件
  • サプライチェーンリスク管理の強化: サプライヤーの認証状況を確認する企業が増加
  • サイバー攻撃の激化: 新管理策は実際のセキュリティ強化に直結する内容

ISO 27001:2022への移行は、コストではなく投資です。適切な計画と専門家の支援があれば、中小企業でも確実に移行を完了できます。

移行相談はこちら

よくある質問（FAQ）

Q1. ISO 27001:2013の認証が失効しましたが、今から移行できますか？

はい、可能です。ただし、認証の空白期間が生じているため、認証機関によっては「移行審査」ではなく「初回認証審査」として扱われる場合があります。まずは現在の認証機関に相談し、最短のスケジュールを確認してください。

Q2. 移行にはどのくらいの期間がかかりますか？

組織の規模や既存ISMSの成熟度にもよりますが、3〜6ヶ月が一般的です。認証機関の審査枠の確保に1〜2ヶ月かかることも考慮が必要です。

Q3. 自社だけで移行は可能ですか？

ISMSの運用実績が豊富で、規格に精通した担当者がいる場合は可能です。しかし、新設11管理策の解釈や適用宣言書の再構成には専門知識が求められるため、コンサルタントの部分的な支援を受けることを推奨します。

Q4. 認証機関を変更しても移行できますか？

はい、認証機関の変更（移転）と同時に移行審査を受けることも可能です。移転先の認証機関に事前に相談し、必要な手続きを確認してください。

Q5. 新設11管理策は全て実装する必要がありますか？

いいえ。リスクアセスメントの結果に基づき、自社に適用する管理策を選定します。ただし、不適用とする場合は合理的な理由を適用宣言書（SoA）に記載する必要があります。「自社には関係ない」という漠然とした理由では、審査で不適合と判定される可能性があります。

Q6. 小規模企業でもISO 27001は必要ですか？

取引先からの要求がある場合や、官公庁の入札に参加する場合は事実上必須です。また、ランサムウェアなどのサイバー攻撃は企業規模に関係なく発生しており、ISMSの構築・運用は自社を守るための有効な手段です。