ISMSにおける脆弱性とは？脅威・リスクとの違いと管理策8.8の運用・審査の証跡

ISMSにおける脆弱性（規格上の表記は「ぜい弱性」）は、JIS Q 27000:2019で「一つ以上の脅威によって付け込まれる可能性のある，資産又は管理策の弱点」と定義されています。脅威は弱点に付け込む側、リスクはその結果として目的に及ぶ影響で、3つは別の概念です。この記事では、定義と違いを整理したうえで、技術・人・物理・組織の具体例、リスクアセスメントでの扱い、ISO/IEC 27001:2022の管理策8.8「技術的ぜい弱性の管理」の運用、対応の優先順位の決め方、審査で確認される記録までを順に解説します。

まとめ：ISMSの脆弱性管理で押さえる5点

• 脆弱性は「資産又は管理策の弱点」。サーバの未修正ソフトウェアだけでなく、形だけのアクセス権見直しのような管理策そのものの弱点も含まれます。
• 脅威（損害の潜在的な原因）が脆弱性に付け込み、損害をもたらす可能性に伴ってリスクが生じます。脆弱性があっても、付け込む脅威がなければリスクは小さく評価されます。
• ISO/IEC 27001の6.1.2は、2013年版以降「資産・脅威・脆弱性の列挙」を手順として要求していません。資産ベースで洗い出すかどうかは組織が選びます。
• 技術的な脆弱性への対応は、リスクアセスメント手法とは別に必要性を判断します。管理策8.8の適用を決定した場合は、継続的な運用に組み込みます。情報の入手、さらされている状況の評価、適切な処置の3つが要求の骨格です。
• 対応の優先順位はCVSS基本値だけで決めません。悪用の事実（KEV）、今後の悪用見込み（EPSS）、自社資産の露出度を重ねて決め、その判断と例外承認を記録に残すことが審査対応にも直結します。

以下、定義から順に根拠と実務の手順を説明します。

ISMSにおける脆弱性の定義と脅威・リスクとの違い

JIS Q 27000が定める脆弱性・脅威・リスクの定義

ISMSの用語はJIS Q 27000:2019（ISO/IEC 27000:2018に対応する日本産業規格）で定義されています。3つの用語の定義は次のとおりです（出典：JIS Q 27000:2019 3.61・3.74・3.77）。

リスクの定義は抽象的ですが、同じ3.61の注記6が「情報セキュリティリスクは，脅威が情報資産のぜい弱性又は情報資産グループのぜい弱性に付け込み，その結果，組織に損害を与える可能性に伴って生じる」と3者の関係を明示しています。脆弱性は資産又は管理策の弱点、脅威は損害をもたらし得る原因、リスクはその組み合わせで起こり得る結果と起こりやすさ、と整理すると混同しません。

資産と管理策の両方に存在する脆弱性

定義の後半「資産又は管理策の弱点」は、読み飛ばされやすい部分です。パッチが当たっていないサーバは資産の弱点ですが、ISMSではすでに導入した管理策が機能していない状態も脆弱性にあたります。たとえば次のような状態です。

• バックアップは毎日取っているが、復元試験を一度もしていない
• アクセス権の定期見直しが、一覧を眺めて承認印を押すだけになっている
• 脆弱性情報の収集担当は決まっているが、担当者の異動後に引き継がれていない

こうした管理策の弱点は、脆弱性スキャナでは検出できません。内部監査（9.2）やマネジメントレビュー（9.3）で拾い、是正処置につなげるのが本来の経路です。技術的な検査だけでは、担当者の引き継ぎ漏れや形式的な承認といった管理策の運用上の弱点を見落とします。

脆弱性の放置によるインシデントとCIAへの影響

脆弱性そのものは損害ではありません。脅威が存在するだけでインシデントになるわけではなく、事業運営や情報セキュリティを脅かす情報セキュリティ事象が発生した場合に、インシデントとして扱います。IPAが2026年1月29日に公表した「情報セキュリティ10大脅威 2026」組織編では、「システムの脆弱性を悪用した攻撃」が4位に入っています（6年連続の選出）。順位の読み方は情報セキュリティ10大脅威2026の解説で整理しています。機密性・完全性・可用性（CIA）のどれが損なわれるかは脆弱性の種類で変わるため、リスクアセスメントでは影響をCIAの観点で分けて見積もります。情報セキュリティの3要素そのものは情報セキュリティの基本を整理した記事で解説しています。

ISMSで想定する脆弱性の種類と具体例

脆弱性は技術・人・物理・組織の4つの側面で整理するのが一般的です。ISO/IEC 27001:2022の附属書Aも管理策を組織的（37）・人的（8）・物理的（14）・技術的（34）の4テーマ・計93項目に分けており、脆弱性の側面と対応する管理策を結びつけやすくなっています。

表の対応は代表例で、1つの脆弱性が複数の側面にまたがることは珍しくありません。たとえば「退職者のアカウントが残っている」は、技術的には不要なアカウントの存在、組織的には人事とシステム管理の連携不足です。側面ごとに担当者を分けると、こうした境界の脆弱性が誰の管理にも入らなくなるので、脆弱性の台帳は側面ではなく資産やプロセス単位で一本化しておく方が運用しやすくなります。

公表済みの技術的脆弱性の中にはCVE番号が割り当てられ、NVDやJVN iPediaで照会できるものがあります。ただし、公表済みでもCVE番号や各データベースへの掲載がない場合があります。CVE番号の仕組みはCVE（共通脆弱性識別子）の解説を参照してください。修正プログラムが提供される前に悪用される「ゼロデイ脆弱性」や、利用しているOSSや委託先の製品に由来する脆弱性については、修正版への更新や自社での修正が可能かを確認します。修正が難しい場合は、後述する緩和策や供給者管理で扱います。

リスクアセスメントにおける脆弱性の扱いと手法の選択

6.1.2の要求事項と資産・脅威・脆弱性の列挙の位置付け

ISMSの解説では「資産を洗い出し、資産ごとに脅威と脆弱性を特定する」手順がリスクアセスメントの標準として紹介されることが多くあります。しかしISO/IEC 27001の要求事項は、2013年版以降この手順を必須にしていません。JIS Q 27001:2014の6.1.2 c) 1)は、リスク特定を「ISMSの適用範囲内における情報の機密性，完全性及び可用性の喪失に伴うリスクを特定する」ことと定めており、資産・脅威・脆弱性という語は出てきません。2022年版の6.1.2もこの構造を引き継いでいます。

資産・脅威・脆弱性の3点セットは、2005年版の要求事項に由来します。2005年版の4.2.1 d)は、資産の特定、資産に対する脅威の特定、その脅威に付け込まれる可能性のあるぜい弱性の特定を順に求めていました。2013年版で要求事項から外れたため、現在の規格では、この方法は選択肢の1つです。解説書や社内手順書がこの手順を「必須」としている場合は、旧規格への対応なのか、組織が現在も採用している手順なのかを確認します。規格上の必須手順でなくても、組織が定めた手順には従う必要があります。

イベントベースと資産ベースの2つのアプローチ

リスクマネジメントの指針であるISO/IEC 27005:2022は、リスク特定の方法として、起こり得る事象のシナリオから考えるイベントベースのアプローチと、資産目録から考える資産ベースのアプローチを対比して示しています。脆弱性が明示的に登場するのは資産ベースの方です。

どちらを選ぶかは、評価表を維持できる体制があるかで決めるのが現実的です（以下は規格ではなく本記事の目安です）。資産ごとの脅威・脆弱性の表を毎年数百行更新する余力がない組織は、イベントベースで主要なシナリオに絞る方が、実際に見直される評価になります。技術的な脆弱性の拾い漏れは、次章の管理策8.8を継続運用することで補えます。逆に、クラウドとオンプレミスで数百台規模の資産を持ち、資産目録（5.9）とスキャン結果を自動で突き合わせられる組織なら、資産ベースの方が根拠のある評価になります。

リスク対応と残留リスクの承認

評価したリスクには、6.1.3に従って適切な対応を選定します。対応の代表的な整理には「低減・回避・移転・保有」があり、複数を組み合わせることもあります。脆弱性管理でいえば、パッチ適用・設定変更・監視の強化が低減、該当機能の廃止が回避、保守契約やサイバー保険での補填が移転、対策後にも残るリスクを認識して引き受ける判断が保有にあたります。保有を選んだ場合に限らず、リスク所有者によるリスク対応計画の承認と残留リスクの受容を得て、その記録を残します（6.1.3 f)）。どの管理策を採用したかは適用宣言書（SoA）に反映します。附属書Aの管理策の選び方は附属書Aの93項目と選定手順の記事で詳しく扱っています。

管理策8.8「技術的ぜい弱性の管理」の要求と運用

管理策の本文と2013年版からの変化

2022年版の管理策8.8は、英語原文で「Information about technical vulnerabilities of information systems in use shall be obtained, the organization’s exposure to such vulnerabilities shall be evaluated and appropriate measures shall be taken.」と定めています。2013年版では、同趣旨の管理策A.12.6.1が「利用中の情報システムの技術的ぜい弱性に関する情報は，時機を失せずに獲得しなければならない。また，そのようなぜい弱性に組織がさらされている状況を評価しなければならない。さらに，それらと関連するリスクに対処するために，適切な手段をとらなければならない」と定めていました（JIS Q 27001:2014）。2022年版では「時機を失せずに」に相当する語が本文から外れましたが、入手・評価・処置という骨格は変わっていません。

要求の骨格は「情報を入手する」「自社がさらされている状況を評価する」「適切な処置をとる」の3つで、脆弱性診断の実施やツールの導入は管理策の本文に書かれていません。

ISO/IEC 27002の手引が示す実施事項

具体的な進め方は、管理策の実践の手引であるISO/IEC 27002に書かれています。現行はISO/IEC 27002:2022（JIS Q 27002:2024）の8.8ですが、本文は有料のため、ここでは旧版のJIS Q 27002:2014の12.6.1から、運用設計の参考になる項目を紹介します。この一覧は現行版8.8の手引全体を示すものではなく、現行版への適合性の確認には使えません。

• 技術的ぜい弱性の管理に関する役割及び責任を定める（ぜい弱性監視、リスクアセスメント、パッチ適用、資産移動の追跡を含む）
• ぜい弱性を把握するための情報資源を、資産目録のソフトウェアに対応させて特定する
• ぜい弱性の通知に対処するための予定表（対応期限）を定める
• パッチは適用前に試験・評価し、利用可能なパッチがない場合はサービスの停止、アクセス制御の追加、監視の強化などを考慮する
• 実施した全ての手順の監査ログを保持し、リスクの高いシステムから対処する

この手引の冒頭には「最新で完全な資産目録は，技術的ぜい弱性に対する有効な管理のために不可欠である」と書かれています。どの製品のどの版を使っているかが分からなければ、公表された脆弱性が自社に関係するかを判断できません。ここで8.8は、資産目録（5.9）や、設定の承認済み状態を管理する構成管理（管理策8.9）と直結します。

発見から再確認までの運用サイクル

8.8を日常業務に落とすと、次の5段階のサイクルになります。

1. 情報の入手：ベンダーの勧告、JVN、NVD、CISAのKEVカタログなどを定期的に確認する。脅威動向の収集は管理策5.7の範囲で、詳しくは脅威インテリジェンス（ISMS管理策5.7）の記事で扱っています。
2. 影響の確認：資産目録と照合し、該当する製品・版・設定を使っている資産を特定する。
3. 優先順位の決定：露出度・悪用状況・深刻度から対応期限を決める（次章）。
4. 処置：パッチ適用、設定変更、機能の無効化、アクセス制限などを行う。パッチは検証環境で試験してから本番へ適用する。
5. 確認と記録：再スキャンや版の確認で解消を確かめ、対応記録を閉じる。

このサイクルで詰まりやすいのは4段階目です。業務システムの停止調整が付かずパッチを当てられない場合は、通信制限や監視の強化で当面のリスクを下げ、残留リスクとして承認を取ったうえで次回の保守時期に適用する、という二段構えにします。「対応できないから記録しない」が最も悪い状態で、審査でも指摘されやすくなります。

脆弱性診断と8.8の関係

8.8は脆弱性診断を義務づけていませんが、「自社がさらされている状況を評価する」手段として、外部公開システムの脆弱性診断は有力な証跡になります。診断は公表済み脆弱性の照合だけでは見つからない、自社開発アプリケーションの不備（入力値検証やアクセス制御の漏れ）を洗い出せる点が強みです。開発工程では管理策8.28（セキュアコーディング）と、設計段階の脅威モデリングが前工程にあたります。診断の種類・費用の目安・外注の判断は脆弱性診断の種類と費用相場の記事を参照してください。スキャンの見積もりを取るときは、対象のIPアドレス数・URL数・認証の有無で費用が変わるため、資産目録から対象を先に確定させておくと比較しやすくなります。

脆弱性対応の優先順位をCVSSだけで決めない理由

脆弱性の深刻度はCVSSで数値化されます。現行版はFIRSTが2023年11月1日に公開したCVSS v4.0で、NVDとJVN iPediaもv4.0の基本値を掲載しています。深刻度は0.0〜10.0のスコアで、None（0.0）・Low（0.1〜3.9）・Medium（4.0〜6.9）・High（7.0〜8.9）・Critical（9.0〜10.0）の5段階に区分されます。スコアの読み方はCVSSの見方と計算方法の記事で解説しています。

ただし、CVSSの基本値は脆弱性そのものの深刻度であって、自社にとってのリスクではありません。FIRSTのCVSS v4.0 User Guideは「CVSS Base (CVSS-B) scores are designed to measure the severity of a vulnerability and should not be used alone to assess risk.」と、基本値だけでリスクを評価しないよう明記しています。米国CISAも2026年6月10日発出の拘束的運用指令BOD 26-04で、KEVカタログの運用を定めていたBOD 22-01と、CVSSによる対応期限を定めていたBOD 19-02を廃止しました。BOD 26-04は、資産の露出度・KEV収載の有無・悪用の自動化可否・技術的影響の4変数で緊急度を決める方式を採っています。対象は米国の連邦民間行政機関ですが、「基本値9.0以上から順に潰す」運用の限界を示す一次情報として参考になります。

実務では、この4つを組み合わせた対応期限の基準を手順書に定めておきます。たとえば「インターネット公開資産でKEV収載なら即時対応、内部限定でEPSSが低くCVSS基本値がMedium以下なら次回の定期保守」のように、判断を担当者の勘に委ねない形にします。EPSSはFIRSTが毎日更新しているスコアで、モデルは改版されます（2026年6月15日から公開されているのはEPSS v5）。基準に数値のしきい値を書くときは、モデルの版が変わったら見直す旨も手順書に入れておきます。

審査で確認される脆弱性管理の記録

ISMSの審査では、手順書があるかより、手順どおりに回っている証拠があるかが見られます。脆弱性管理で用意しておく記録は次のとおりです。

審査で問題になりやすいのは、スキャン結果は毎月あるのに対応記録の完了日が空欄のまま、というパターンです。検出だけして処置の判断が記録されていない状態は、8.8の「適切な処置をとる」を満たしていないと判断されかねません。対応しないと決めた脆弱性も、理由・承認者・見直し期限を記録します。判断の記録を完了しても、受容したリスクは監視とレビューの対象として管理を続けます。未対応が続く状態の扱いはISMSの不適合の判定基準と是正処置の記事、年間の記録運用はISMS運用の年間スケジュールと必須記録の記事で整理しています。

なお、ISO/IEC 27001:2013からの移行期限は2025年10月31日で終了しており、ISMS-ACの認定制度における認証の維持には、2022年版（JIS Q 27001:2023）への移行が必要です。社内の手順書や適用宣言書にA.12.6.1のような旧番号が残っている場合は、8.8へ読み替えて更新しておきます。また、2024年2月23日発行のISO/IEC 27001:2022/Amd 1:2024で、4.1に気候変動が関連する課題かどうかを決定する要求が加わりました（日本語版はJIS Q 27001:2023/追補1:2025、2025年5月20日発行）。脆弱性管理の要求は変わっていませんが、審査では組織の状況の見直しの一部として確認されます。

ISMSの脆弱性に関するよくある質問

ISMSにおける脆弱性と脅威の違いは何ですか？

脆弱性は、脅威によって付け込まれる可能性のある資産又は管理策の弱点です。脅威は、損害を与える可能性がある望ましくないインシデントの潜在的な原因です（JIS Q 27000:2019の3.77と3.74）。脆弱性は資産又は管理策の弱点であり、組織内部に限りません。脅威がその弱点に付け込んで損害をもたらす可能性に伴って、リスクが生じます。

ISMSの情報セキュリティの三要素は何ですか？

機密性・完全性・可用性の3つで、英語の頭文字からCIAと呼ばれます。ISO/IEC 27001の6.1.2は、リスクをこの3つの喪失の観点で特定するよう求めています。脆弱性がどの要素を損なうかによって、影響の大きさの見積もりが変わります。

ISMS認証の取得に脆弱性診断は必須ですか？

必須ではありません。管理策8.8が求めるのは、技術的脆弱性の情報の入手、自社がさらされている状況の評価、適切な処置の3点です。ただし外部に公開しているWebシステムがある場合、状況の評価を示す証跡として脆弱性診断の報告書は有力で、審査の前に直近の結果をそろえておくと説明しやすくなります。

ISO27001:2022で脆弱性に関係する管理策はどれですか？

中心は8.8 技術的ぜい弱性の管理です。周辺では、脆弱性情報や攻撃動向を集める5.7 脅威インテリジェンス、設定の承認済み状態を保つ8.9 構成管理、開発段階で脆弱性を作り込まない8.28 セキュアコーディング、兆候を捉える8.16 監視活動が関係します。5.7・8.9・8.16・8.28は2022年版で新設された管理策です。

CVSSのスコアが高い脆弱性から対応すればよいですか？

CVSSの基本値だけで順番を決めるのは避けます。基本値は脆弱性そのものの深刻度で、自社の資産がインターネットに露出しているか、実際に悪用されているかは反映されていません。KEVカタログへの収載やEPSSの悪用確率、資産の露出度を組み合わせて対応期限を決めます。

関連記事

• ISMSの管理策とは？ISO 27001:2022附属書Aの93項目と選定手順を実務目線で解説
• 脅威インテリジェンス（ISMS管理策5.7）とは｜要求事項・情報源・審査証跡を実務解説
• ISMSの構成管理（管理策8.9）とは？構成記録とベースラインの作り方・変更管理との違い
• 脆弱性診断とは？種類・費用相場・進め方と外注時の判断基準を解説
• CVSSとは？脆弱性の深刻度スコアの見方・計算方法とv4.0の変更点を解説