ISMS認証に脆弱性診断は必須？ISO27001の審査ポイントと実施タイミング【２022年最新改訂対応】
- 4月8日
- 読了時間: 7分
更新日：4月9日
はじめに
「ISMS（ISO/IEC 27001）の認証を取得・更新するために、脆弱性診断は必須なのか？」
この疑問を持つ方は少なくありません。結論から言えば、ISMSの規格上、脆弱性診断の実施そのものが明示的に義務付けられているわけではありません。しかし実務上は、審査をスムーズに通過し、かつ実効性のあるセキュリティ体制を維持するために、脆弱性診断は極めて重要な役割を果たしています。
本記事では、ISMSの規格要件と脆弱性診断の関係を整理したうえで、「いつ」「何を」「どの程度」ISMS脆弱性診断をすべきタイミングなどを解説します。
ISMSの規格は脆弱性診断をどう位置付けているか
ISO/IEC 27001:2022の管理策と脆弱性
ISO/IEC 27001:2022（および附属書Aの管理策であるISO/IEC 27002:2022）では、脆弱性に関連する管理策がいくつか定められています。特に重要なの配下の2つです。
A.8.8 技術的脆弱性の管理
利用している情報システムの技術的脆弱性に関する情報を、タイムリーに取得し、その脆弱性に対する組織の露出度を評価し、適切な措置を講じることが求められています。
ここで言う「技術的脆弱性に関する情報の取得」の方法として、脆弱性診断（脆弱性スキャンやペネトレーションテスト）は最も直接的かつ有効な手段です。
A8.34 監査中の情報システムの保護（旧A.12.7.1 に相当）
情報システムの検証に関する活動、つまり脆弱性評価や侵入テストを含む監査活動において、業務システムへの影響を最小限にすることが求めれれています。これは、脆弱性診断の実施を前提とした管理策と言えます。
「義務ではない」が「事実上必須」である理由
ISMS審査において、審査員が確認するのは「リスクアセスメントの結果、適切な対策が講じられているか」です。
Webアプリケーションやシステムを運用している組織が、リスクアセスメントの結果として「技術的脆弱性のリスクがある」と認識しているにもかかわらず、脆弱性診断を一度も実施していなければ、「リスクに対する対策が不十分」と判断される可能性が高いです。
特に以下のようなケースでは、脆弱性診断の実施記録が審査で重視されます。
個人情報や機密情報を扱うWebアプリケーションを運用している
ECサイトやオンラインサービスなど、外部に公開されたシステムがある
クラウド環境（AWS、Azure等）で業務システムを構築している
過去にセキュリティインシデントが発生したことがある
2022年の改訂で変わったこと
ISO/IEC 27001は2022年に大幅改訂されました（以降期限は2025年10月31日）。この改訂で、脆弱性管理に関連するいくつかの重要な変更がありました。
「脅威インテリジェンス」の新設（A.5.7）
最新のセキュリティ脅威動向や脆弱性情報を収集し、自社への影響を判断することが新たに求められました。これは、単に年1回の診断を実施するだけでなく、継続的に脆弱性情報を追跡する体制が必要であることを意味しています。
「構成管理」の追加（A.8.9）
OS、ミドルウェア、アプリケーションのバージョン情報を管理し、新たな脆弱性が公開された場合に速やかに対応することが求められるようになりました。
「セキュアコーディング」の新設（A.8.28）
開発プロセスにおけるセキュリティの組み込みが管理策として明示されました。開発段階での脆弱性の作り込みを防ぐとともに、リリース前の脆弱性診断の重要性がより高まっています。
実務上、どのタイミングで脆弱性診断を行うべきか
ISMS認証のライフサイクルに合わせた計画
ISMSの認証サイクル（3年ごとの更新審査、毎年のサーベイランス審査）に合わせると、以下のタイミングでの脆弱性診断が推奨されます。
年1回の定期診断（推奨：サーベイランス審査の2～3か月前）
審査に間に合うよう、診断→報告書受領→是正対応→記録作成のサイクルを回すために、審査の2～3か月前に実施するのが理想的です。
システム変更時・リリース時
新しいWebアプリケーションのリリース、大規模な機能追加、インフラ構成の変更があった場合は、追加の脆弱性診断を実施すべきです。
インシデント発生後
セキュリティインシデントが発生した場合、原因特定と再発防止のための脆弱性診断が必要です。
何を診断すべきか
診断対象 | 内容 | 頻度の目安 |
Webアプリケーション | SQLインジェクション、XSS、認証・認可の不備、セッション管理等 | 年1回以上（リリース時にも実施） |
プラットフォーム | OS、ミドルウェアの既知脆弱性、不要なポートの開放、パッチ適用状況 | 年1回以上 |
ネットワーク | ファイアウォール設定、外部公開サービスの確認 | 年1回以上 |
クラウド環境 | IAM設定、ストレージの公開設定、セキュリティグループ | 年1回以上（設定変更時にも確認） |
審査で「よく聞かれること」と準備のポイント
ISMSの審査員は、脆弱性管理について以下のような観点で質問・確認を行います。
「脆弱性情報をどのように収集していますか？」
脅威インテリジェンス（A.5.7）に関連する質問です。JPCERT/CCやIPAの情報、利用しているソフトウェアのセキュリティアドバイザリを定期的にチェックしている体制を示せると良いでしょう。
「直近の脆弱性診断の実施記録を見せてください」
診断報告書、検出された脆弱性の一覧、リスク評価、是正対応の記録が必要です。「外部の専門事業者による診断」が実施されている場合、より客観性が担保されていると評価されます。
「検出された脆弱性にどう対応しましたか？」
重要なのは、「脆弱性を発見したこと」だけでなく、「発見した脆弱性に対してリスク評価を行い、優先度をつけて対応したこと」が記録として残っていることです。すべての脆弱性を即座に修正する必要はありませんが、リスク受容の判断を含めた対応方針の記録は必須です。
「脆弱性管理のプロセスは文書化されていますか？」
脆弱性情報の収集→評価→対応→記録という一連のプロセスが、手順書やマニュアルとして文書化されていることが求められます。
脆弱性診断を外部に依頼するメリット
ISMSの脆弱性管理において、外部の専門事業者による脆弱性診断には以下のメリットがあります。
客観性の担保：自社内の診断では見落としがちな観点を、第三者の視点で検査できます。審査員にとっても、外部診断の報告書は「独立した評価」として信頼性が高く評価されます。
専門性の活用：セキュリティ診断には高度な専門知識が必要です。OWASP Testing Guideや脆弱性診断しスキルマップに準拠した診断を自社で実施できる体制を持つ企業は限られています。
効率性：年1～2回の診断のために、社内にフルタイムのセキュリティ診断チームを維持するのは、多くの企業にとってコスト効率が悪い選択です。
対応支援：検出された脆弱性に対する是正方法のアドバイスや、再診断による修正確認まで対応できる事業者を選ぶことで、ISMS対応の負担を大幅に軽減できます。
まとめ：ISMS対応の脆弱性診断チェックリスト
最後に、ISMS認証の取得・更新に向けた脆弱性診断の対応チェックリストをまとめます。
□ 自社の情報資産（Webアプリ、サーバ、クラウド環境）を洗い出しているか
□ リスクアセスメントで「技術的脆弱性のリスク」を特定しているか
□ 脆弱性情報の収集体制（JPCERT/CC、IPA等の定期チェック）を構築しているか
□ 年1回以上の脆弱性診断を計画・実施しているか
□ 診断報告書を保管し、検出された脆弱性への対応記録を残しているか
□ 脆弱性管理のプロセスを文書化しているか
□ システム変更時やインシデント発生時の追加診断ルールを定めているか
□ 2022年版への移行に伴う管理策の追加（脅威インテリジェンス、構成管理等）に対応しているか
ISMSは「取得して終わり」ではなく、継続的な改善が求められるマネジメントシステムです。脆弱性診断を「審査のための作業」ではなく「自社のセキュリティを高めるための投資」として位置付けることで、より実効性のあるISMS運用が実現します。
クラスメソッドセキュリティでは、IMSIやPCI DSS等の認証対応に必要な脆弱性診断を、経験豊富なセキュリティエンジニアが提供しています。診断の範囲や頻度についてのご相談も承っておりますので、お気軽にお問い合わせください。
[脆弱性診断サービス「Matrix Inspect」の詳細はこちら→]
