はじめに
情報セキュリティマネジメントシステム（ISMS）の国際標準であるISO 27001およびISO 27002は、組織が情報資産を体系的に守るための枠組みを提供しています。本記事では、ISO 27001/ISO 27002 - A guide to information security management systems の内容をもとに、規格の全体像と実務上の勘所を整理します。
ISO 27001/27002の背景と位置づけ
規格の成り立ち
ISO 27001の起源は1995年に英国規格として制定されたBS 7799です。その後、2005年にISOが採用してISO/IEC 27001:2005として国際規格化され、2013年・2022年と2度の大改訂を経て現在に至ります。現行の2022年版では、管理策の数が114項目から93項目に整理されており、4つの主要テーマによるシンプルな構造に再編されています。
ISO 27000ファミリー
関連規格は50以上存在しますが、ISMSを構築・運用するうえで核となるのは以下の3規格です。
- ISO 27000：ISMSの概要と主要用語の定義
- ISO 27001：ISMSの要件仕様と認証基準
- ISO 27002：各管理策の詳細な実装ガイダンス
さらに、クラウドのPII保護を対象とするISO 27018や、ISMS内でプライバシー情報管理の仕組みを加えるISO 27701といったアドオン規格も普及しています。GDPRをはじめとするプライバシー法規制への対応として、これらを組み合わせる組織が増加しています。
PDCAと附属書SL
ISMSは「計画・実行・確認・改善（PDCA）」の継続的改善サイクルに基づいています。また、ISO 27001はすべてのISOマネジメントシステム規格が共通の骨格として採用する「附属書SL」に準拠しており、品質（ISO 9001）や環境（ISO 14001）などの他の規格と統合しやすい設計になっています。
第1章：認定認証のしくみ
認証を取得する意義
ISO 27001準拠のISMSを導入するメリットは大きいですが、最大の商業的効果は第三者認証の取得にあります。クライアントや規制当局が単なる自己申告ではなく、独立した検証を求める場面が増えているためです。
認定機関のエコシステム
認証は二層構造になっています。
- 認定機関（日本ではJAB、英国ではUKAS）：認証機関の能力を認定
- 認証機関（CB）：組織のISMSを審査し認証を発行
認定を受けた認証機関（認定CB）が発行する証明書のみが、サプライヤーや他国の機関に広く有効と認められます。費用を安く抑えるために非認定CBを選ぶと、認証を受け入れてもらえないケースが多く、かえって不経済になります。
認証プロセスの流れ
- ステージ1（初回監査）：ISMSの設計・文書が規格に沿っているかを確認します。不適合があっても即失格ではなく、修正する機会が与えられます。
- ステージ2（認証監査）：ISMSが実際に機能していることをエビデンスで確認します。
- サーベイランス監査（年2回）：3年の認証サイクル中に継続的な適合性を確認します。
- 再認証監査（3年ごと）：ISMSの有効性と継続的改善を重点的に審査します。
第2章：抑えておくべき用語と定義
ISO 27000:2018で定義されている主要な用語を整理します。設計・実装の議論においても頻出するため、早期に定義を把握しておくことが重要です。
| 用語 | 定義の要点 |
|---|---|
| 機密性 | 情報が権限のない者に開示されない特性 |
| 完全性 | 正確性と完全性の特性 |
| 可用性 | 承認された主体が要求時にアクセスできる特性 |
| リスク | 不確実性が目標に及ぼす影響 |
| 脅威 | 望ましくないインシデントの潜在的な原因 |
| 脆弱性 | 脅威によって悪用される可能性がある弱点 |
| 管理策（コントロール） | リスクを修正する対策 |
| 不適合 | 要件が満たされていないこと |
機密性・完全性・可用性の3要素はCIAトライアドとも呼ばれ、リスク評価の軸となります。
第3章：ISO 27001の要件（条項4〜10）
ISO 27001の本体要件は条項4〜10で構成されており、附属書SLの共通骨格に情報セキュリティ固有の内容を加えたものです。
条項4：組織の状況
ISMSの設計に入る前に、組織が置かれた状況を把握することが求められます。よく使われる分析フレームワークがPESTLE分析です。政治・経済・社会・技術・法律・環境という6つの視点から、ISMSに影響を与える外部・内部の問題を洗い出します。
また、利害関係者（規制当局・顧客・サプライヤー・従業員等）を特定し、彼らのISMSに関連する要件を整理したうえで、ISMSの**適用範囲（スコープ）**を文書として確定させる必要があります。スコープはISMSの境界を物理的・論理的に定義するものであり、外部にも提示できる形で管理することが求められます。
条項5：リーダーシップ
ISMSの成否はトップマネジメントのコミットメントに直結します。経営陣に求められる主な責務は以下のとおりです。
- 情報セキュリティ方針の策定と維持
- ISMSに必要なリソースの確保
- ISMS責任者への適切な権限付与
- ISMSの有効性に対する最終責任の保持
情報セキュリティ方針はトップレベルのポリシーとして、技術的な専門知識を持たない人にも理解できる平易な言語で記述し、全従業員に周知する必要があります。
条項6：計画
この条項はISMSの中核であり、リスクアセスメントとリスク対応のプロセスを定義します。
リスク評価の基本
リスクは「資産 × 脅威 × 脆弱性」という観点で識別します。評価基準として、発生可能性と影響度をスコアリングする定量的・定性的手法を組み合わせて使うことが一般的です。評価結果を一貫・比較可能な形で記録することが規格上の要件となっています。
リスク対応の4つの選択肢
| 選択肢 | 内容 |
|---|---|
| 許容（Tolerate） | リスクを受け入れ、追加対策を講じない |
| 対処（Treat） | 発生確率または影響度を低減する管理策を実施する |
| 移転（Transfer） | 保険やアウトソーシングでリスクを他者に移す |
| 終了（Terminate） | リスクを生じさせる活動そのものをやめる |
適用性宣言（SoA）
附属書Aのすべての管理策について、採用・非採用の根拠と実装状況をまとめた文書が「適用性宣言（Statement of Applicability）」です。SoAはISMSにおいて最も重要な文書の一つであり、認証機関の審査においても重点確認対象となります。
条項7：サポート
リソース・能力・意識
- ISMS の確立・実装・維持・継続改善に必要なリソースを提供することが求められます。
- 情報セキュリティのパフォーマンスに影響する役割ごとに必要な能力レベルを定義し、研修等でギャップを埋める記録を維持します。
- 情報セキュリティ方針、ISMSへの貢献内容、不遵守の結果について、全従業員への周知が必要です。
文書化された情報の管理
規格が「文書化された情報」として扱うことを要求するドキュメントには、識別子・バージョン・レビュー周期・承認者の定義が必要です。必ずしも高価な専用ソフトウェアは必要なく、SharePointやスプレッドシートの組み合わせで要件を満たすことも可能です。
条項8：運用
リスクアセスメントは少なくとも年1回、または重大な変更が生じた際に実施します。外部委託プロセスについては、管理の範囲を自社の権限内に留め、委託先のセキュリティ対策を評価したうえで自社側の補完策を設けることが求められます。
条項9：パフォーマンス評価
この条項は認証機関が毎回のサーベイランス監査で重点確認するセクションです。
監視と測定
何を・どの方法で・どの頻度で測定するかを定義し、その結果を記録します。「分析（客観的なデータ解析）」と「評価（その結果を人が判断すること）」は区別して設計します。
内部監査
サンプリング方式で実施し、ISMSの各条項への適合性・効果的な実施を検証します。監査員は自身が担当する業務を監査しない独立性の確保が必須です。規模の小さい組織でも、認定研修を修了した内部監査員を育成することが推奨されます。
マネジメントレビュー
経営幹部が少なくとも年1回、規定されたインプット（リスク評価結果・内部監査結果・過去のレビューでのアクション状況等）を網羅する形で実施します。議題と議事録が文書化された情報として保管される必要があります。
条項10：継続的改善
不適合と是正処置
不適合は以下の3カテゴリで管理するのが業界慣行です。
- 重大な不適合：要件が完全に欠如している、または長期・故意の不遵守
- 軽微な不適合：部分的な不備で、ISMSの運用に重大な影響はない
- 改善の機会（OFI）：現時点では問題にならないが将来リスクになりうる軽微な欠陥
是正処置においては根本原因分析が不可欠です。「5つのなぜ」のような手法で因果関係の連鎖を遡り、表面的な対処に終わらせないことが重要です。根本原因を特定して解決することで、再発防止と複合的な問題の解消につながります。
第4章：ISO 27002の役割と管理策の構造
ISO 27002はガイダンス規格
ISO 27002はISO 27001の附属書Aに列挙された93の管理策それぞれに対して、以下の情報を提供します。
- 管理策の説明と目的
- 実装ガイダンス
- 5つの属性（後述）
ISO 27002自体は認証の対象ではありませんが、ISMSを実装する組織にとって事実上必須の参照文書となります。
4つのテーマと5つの属性
管理策は以下の4テーマに分類されています。
| テーマ | 内容例 |
|---|---|
| 組織的 | ポリシー、アクセス制御、インシデント管理、脅威インテリジェンス |
| 人 | 雇用前スクリーニング、意識向上研修、秘密保持契約 |
| 物理的 | セキュアエリア、クリアデスク・スクリーン、機器メンテナンス |
| 技術的 | マルウェア対策、バックアップ、ログ・監視、ネットワーク分離 |
各管理策には以下の5つの属性が付与されており、フィルタリングによる多角的な分析が可能です。
- コントロールタイプ（予防的・発見的・是正的）
- 情報セキュリティ特性（機密性・完全性・可用性）
- サイバーセキュリティの概念（識別・保護・検出・対応・回復）
- 運用機能（資産管理・安全な構成 等）
- セキュリティドメイン（ガバナンス・保護・防御・回復力）
属性はあくまで分析のための補助ツールであり、ISO 27001認証の審査対象ではありません。
管理策の読み方の例：コントロール6.3（情報セキュリティ意識向上）
コントロール6.3は情報セキュリティ意識向上・研修に関する管理策です。ISO 27002では以下の観点で実装ガイダンスを提供しています。
- 意識向上プログラムは組織固有のポリシー・保有情報・実施中の管理策の内容を反映させること
- 入社時および役割が大きく変わった際に研修を実施すること
- 技術者向けと非技術者向けでプログラムを分けること
- 「何をすべきか」だけでなく「なぜ必要か」の理解が浸透しなければ形骸化するリスクがあること
実装にあたっての実践的な示唆
本書から読み取れる実装の勘所をまとめます。
スコープは慎重に設計する
適用範囲を限定しすぎると、実際の業務とISMSの乖離が生じます。一方で広すぎると維持コストが膨らみます。利害関係者の要件を踏まえて、自社の管理権限の範囲内で現実的なスコープを設定することが重要です。
SoAはISMSの設計図として扱う
SoAは一度作成して終わりではなく、リスクアセスメントや管理策の変更に合わせて継続的に更新する必要があります。バージョン管理と承認フローを組み込んだ運用ルールの整備が先決です。
リスク評価チームの多様性を確保する
人はリスク評価において自分の業務領域に引っ張られがちです。財務・法務・エンジニアリング・オペレーションなど横断的なメンバーでチームを構成し、独立したモデレーターを置くことで評価の一貫性と網羅性が高まります。
文書は「Less is more」で設計する
規格が求める文書化の要件を過剰に解釈し、膨大な文書を生成してしまう組織があります。維持コストを考慮し、規格が明示的に要求する文書と、ISMSの有効性維持に本当に必要な文書を切り分けて設計することが長期運用の鍵です。
認定CBの選択は妥協しない
費用や監査負担を理由に非認定CBを選ぶと、得られる認証が多くの場面で認められないリスクがあります。認証取得の目的（サプライヤー要件・法規制対応・競争優位等）を明確にした上でCBを選定することが重要です。
他の情報セキュリティフレームワークとの関係
ISO 27001/27002は唯一の情報セキュリティ標準ではなく、他のフレームワークと併用されることも多いです。
NIST SP 800-53
米国国立標準技術研究所（NIST）が策定する連邦政府向けのセキュリティコントロールカタログです。ISO 27001の附属書Aとは異なる分類体系を持ちますが、管理策の内容に重複部分が多く、グローバルに事業展開する組織や米国政府調達に関わる組織では両者を照合・マッピングして使用するケースがあります。
PCI DSS
クレジットカード情報を取り扱う組織向けの業界標準です。カード会員データ環境（CDE）に特化した詳細な技術要件を定めており、ISO 27001のリスクベースアプローチとは異なるコンプライアンスベースの性格を持ちます。ISMSのSoAにPCI DSSのコントロールを取り込む形で統合運用することが可能です。
SOC 2
米国公認会計士協会（AICPA）が定めるサービス組織向けのセキュリティ報告基準です。SaaS企業を中心に米国市場での信頼性証明として普及しており、ISO 27001認証と組み合わせて取得する事例が増えています。
フレームワーク間の共通点と使い分け
どのフレームワークも「機密性・完全性・可用性」を基盤とし、リスク識別→対応→監視の循環を求める点は共通です。業界・地域・取引先の要件に応じて、ISO 27001を基盤としつつ他のフレームワークの要件を追加的に満たす構成が、維持コストの面でも合理的な選択となります。
まとめ
ISO 27001/27002は、技術的なセキュリティ対策だけでなく、組織・プロセス・人という3つの軸を統合したリスクベースのマネジメントシステムを構築するための規格です。本記事で見てきたように、その要件は「何をすべきか」を定義しつつも、「どうやって実現するか」については組織の判断に委ねる設計になっています。
規格の全体像を把握した上でSoAを軸にした設計を行い、PDCAサイクルを回し続けることが、認証取得にとどまらない実効性の高いISMSを実現する道筋です。情報セキュリティ支援士（SC）の学習とも非常に親和性が高い内容ですので、規格原文と合わせてぜひ参照してみてください。