ISMS認証は「形骸化」の罠を超えられるか

ISO/IEC 27001 は、組織が保護すべき情報資産を洗い出し、それに対するリスクを評価し、適切な対策を講じるための一連のフレームワーク(ISMS: Information Security Management System)の要件を定めた国際規格です。 日本国内でも取得企業が非常に多く、「大手企業とB2B取引をする際の参加チケット(足切り要件)」として取得されるケースが多々あります。

ISMS 形骸化の罠

「認証取得」そのものを目的としてしまい、審査の直前だけ慌ててチェックシートを埋め、実業務とは乖離した分厚いポリシー文書を作り上げる組織が後を絶ちません。ISO 27001が真に求めているのは「完璧な状態」ではなく、組織のビジネス環境に合わせた**「PDCAサイクルの自律的な継続(継続的改善)」**です。


メジャーアップデート:2022年版(ISO 27001:2022)の核心

2013年版から実に約9年ぶりに行われた「2022年版」への改訂では、DXの進展、クラウドシフト、高度なサイバー兵器の台頭という現実を踏まえ、セキュリティアーキテクチャの考え方が一新されました。

付帯書A(Annex A)で定義されている具体的な管理策(コントロール)は、114項目から93項目に整理・統合され、新たに以下の**「11の新規管理策」**が追加されました。これらが現代の最重要テーマを表しています。

新規管理策のテーマ実務上の意味合いとアクション
脅威インテリジェンス(A.5.7)『自社が誰に・どう狙われているか』をパッシブ・アクティブに収集し、リスク評価に組み込むこと。
クラウドサービスの情報セキュリティ(A.5.23)AWSやAzure、SaaSなどのクラウド特有の共有責任モデルと、セキュアな設定管理(CSPM要素)。
ICTの事業継続準備(A.5.30)単なるデータバックアップではなく、ランサムウェア等でシステム全体が停止した際の「システム自体の復旧力(レジリエンス)」を持つこと。
データマスキング / データ漏洩防止(A.8.11, 8.12)テスト環境への本番データコピー時のマスキング義務と、エンドポイントにおけるDLP(Data Loss Prevention)ツールの導入。
セキュアコーディング(A.8.28)開発組織において「リリース前に静的解析(SAST)を通す」など、OWASP Top 10レベルの脆弱性をコード段階で潰すこと。

リスクマネジメントの中核プロセス

ISMSの中心エンジンは**リスクアセスメント(リスク評価)**です。 すべての情報資産を守ることは不可能です。「何が重要で、何が危険か」を定量化・定性化し、防衛予算を割り振る論理的根拠を作ります。

  1. リスクの特定: 資産(例:顧客DB)× 脅威(例:外部からのハッキング)× 脆弱性(例:パッチ未適用)
  2. リスク対応の決定: 評価したリスクに対し、以下の4つのアクションのうちどれを取るかを経営として決定します。
情報セキュリティにおける『リスクの4つの対応方針』
対応方針意味具体例
リスク低減(コントロール)セキュリティ対策を施し、リスクを許容可能なレベルまで引き下げる(最も標準的)。[WAF](/glossary/waf/)を導入し、[SQLインジェクション](/glossary/sql-injection/)の発生確率を下げる。
リスク移転(シェア)リスクに伴う金銭的負担を第三者に移す。サイバーセキュリティ保険に加入し、万が一の損害賠償をカバーする。
リスク回避リスクの原因となる活動そのものを中止する。「危険すぎる」として、自社でのクレジットカード番号の保存をやめ、外部決済代行に一任する。
リスク受容対策コストが損害額を上回るため、何も対策せずにそのリスクを受け入れる。「この公開情報サイトが1時間ダウンしても被害はないので、高額なDDoS対策サービスは入れない」と合意する。

ISO 27001 と NIST CSF は競合しない

「我々はISOを取得すべきか、NIST CSFに準拠すべきか?」という質問があります。正解は「両方組み合わせて使う」です。
ISO 27001 は、「監査可能なマネジメントの仕組み(PDCAが回っているか)」を証明するための適合証明書(パスポート)として機能します。一方、NIST CSF は、技術的な防御や検知・対応の「実務的なサイバーセキュリティ戦略」を具体的に設計するためのハンドブックです。最新の現場では、NIST CSFの戦略に基づいた実運用を、ISO 27001の枠組みで監査・維持するというハイブリッドアプローチが主流です。


理解度チェック

【確認問題】ISMSのリスクアセスメントにおいて、「自社サーバーで独自の決済システムを構築するとセキュリティ侵害のリスクが甚大であるため、自社システムでの決済機能の実装を中止し、すべての決済処理を外部の大手ペイメントサービスに委託する」という判断を下しました。これはリスク対応手法のどれに該当しますか?