2026.06.16 ガイドライン

ISMSにおける脆弱性とは｜種類・脅威との違いと2022年改訂後の管理プロセス

ISMSにおける脆弱性とは、情報資産を守る仕組みに潜む「弱点」を指し、脅威やリスクと混同されやすい概念です。本記事では、脆弱性の定義と種類・具体例、脅威やリスクとの違いを整理したうえで、ISO/IEC 27001:2022改訂で強化された管理策8.8や脅威インテリジェンス（5.7）との関係を解説します。さらに、リスクアセスメントでの脆弱性評価やCVSSを用いた優先順位付け、脆弱性管理ライフサイクルの実務手順、技術的な脆弱性診断とISMS運用をつなぐ設計までを取り上げます。2025年10月の移行期限経過後に求められる対応や、JIS Q 27001:2025（追補1）の最新動向もあわせて確認できます。

目次

ISMSにおける脆弱性管理の要点と改訂後に優先すべき三つの対応のまとめ

ISMSにおける脆弱性は、組織的・人的・物理的・技術的の4つの側面に存在する「情報資産の弱点」です。脅威がこの弱点を突くことでリスクが顕在化するため、脆弱性を単独で見るのではなく、脅威・影響度と組み合わせてリスクアセスメントで評価することが管理の出発点になります。

ISO/IEC 27001:2022（日本語版 JIS Q 27001:2023）では管理策が93項目に再編され、技術的ぜい弱性の管理（8.8）に加えて脅威インテリジェンス（5.7）やセキュアコーディング（8.28）が脆弱性低減に直結します。2025年10月31日の移行期限はすでに経過し、新規格での運用が前提です。優先すべきは、資産目録と連動した脆弱性の継続的な発見、CVSSとリスク受容基準による優先順位付け、パッチや緩和策の対応記録を審査エビデンスとして残す運用、の三つです。

情報セキュリティにおける脆弱性の定義と脅威・リスクとの違いの整理

ISMSの議論では脆弱性・脅威・リスクが頻繁に登場しますが、定義を取り違えると対策の方向性がぶれます。まずは用語の関係を正確に押さえます。

情報資産の弱点としての脆弱性の定義とCIA三要素との関係

脆弱性とは、情報資産が持つ弱点や、脅威に対する耐性・対策の不足を指します。ISMSが守る対象は情報の機密性（Confidentiality）、完全性（Integrity）、可用性（Availability）の3要素（CIA）であり、脆弱性はこのいずれかを損なわせる入口になります。たとえば、修正パッチを当てていないWebサーバは、攻撃者に侵入されて顧客情報の機密性を損なう弱点です。同じシステムでもバックアップ設計の不備は可用性に関わる脆弱性となり、弱点の所在によって守るべきCIA要素が変わります。脆弱性を洗い出す際は「どの情報資産の、どのCIA要素に影響するか」をセットで記録することが、後段のリスク評価を正確にする判断基準になります。

脅威と脆弱性の違い｜事象としての脅威と耐性不足という弱点の区別

脅威と脆弱性は混同されがちですが、役割が異なります。脅威は情報資産のCIAを侵害しうる「事象」であり、フィッシングメールやランサムウェアといった人為的脅威、地震や停電などの環境的脅威に分けられます。一方、脆弱性は脅威に対する「耐性の不足」という状態を指します。たとえば「標的型メール攻撃」は脅威であり、「従業員がメールの真偽を見分けられない教育不足」が脆弱性です。脅威は組織の外から訪れるため制御が難しいのに対し、脆弱性は組織が手を入れて減らせる対象である点が、対策を設計するうえでの決定的な違いになります。

リスク＝脅威×脆弱性×影響度で捉えるISMSの基本的な考え方

ISMSにおけるリスクは、脅威が脆弱性を突いて情報資産に影響を及ぼす可能性として捉えます。実務では「脅威の発生可能性」「脆弱性の度合い」「影響の大きさ」を掛け合わせてリスク値を見積もる考え方が一般的です。たとえば、既知の脆弱性を抱える公開サーバに重要な個人情報があれば、脅威の到達可能性も影響も大きく、リスクは最大級と判定されます。逆に、同じ脆弱性でも社内限定の検証環境であれば脅威の到達可能性が下がり、リスク値も小さくなります。脆弱性の有無だけで対応を決めず、三つの要素の組み合わせで優先度を見極めることが要点です。

JIS Q 27000の用語定義に沿った脆弱性・脅威・リスクの統一

これらの定義は、ISMSの用語規格であるJIS Q 27000（ISO/IEC 27000）に基づいて統一しておくと、社内の認識ずれを防げます。同規格では脆弱性を、一つ以上の脅威につけ込まれる可能性のある資産または管理策の弱点として位置づけています。審査の場では、組織が独自の言葉で対策を語るよりも、規格定義に沿って脆弱性を説明できるほうが整合性を示しやすくなります。リスクアセスメント手順書やセキュリティ教育資料の冒頭に、この三つの用語の定義を明記しておくと運用が安定します。

脆弱性を放置した場合の情報漏洩・インシデントの具体的影響

脆弱性を放置すると、情報漏洩やサービス停止といった具体的な被害につながります。たとえば、サポートが終了したソフトウェアを使い続けると、新たに公表された脆弱性に対して修正パッチが提供されず、攻撃の格好の標的になります。既知の脆弱性を突かれたランサムウェア感染の事例では、業務システムが暗号化されて復旧に数週間を要し、取引先への信頼低下や損害賠償に発展するケースもあります。脆弱性管理を「コスト」ではなく「インシデント発生時の損失を抑える投資」と位置づける判断が、経営層の関与を引き出すうえで欠かせません。

ISMSで想定する脆弱性の種類と具体例｜技術・人的・物理・組織別

ISO/IEC 27001:2022では管理策が組織的・人的・物理的・技術的の4分類に整理されました。脆弱性もこの4つの側面で捉えると、抜け漏れなく洗い出せます。

技術的脆弱性｜未修正のソフトウェアやCVE登録済みの既知の欠陥

技術的脆弱性は、OSやソフトウェア、ネットワーク機器に存在する欠陥を指します。代表例が、共通の識別子で管理される既知の脆弱性CVE（Common Vulnerabilities and Exposures）で、修正パッチ未適用の状態が典型的な弱点です。圧縮ソフトやWebフレームワーク、ログ出力ライブラリなどに脆弱性が公表されると、攻撃者は公開情報をもとに侵入を試みます。たとえば広く使われる7-Zipで公表された脆弱性のように、利用者の多いソフトウェアほど標的になりやすい傾向があります。技術的脆弱性は脆弱性スキャナや脆弱性診断で機械的に検出しやすい一方、検出件数が膨大になりがちです。そのため、後述するCVSSによる深刻度評価とセットで扱うことが、現実的な管理の前提になります。

人的脆弱性｜誤操作・パスワード使い回し・標的型メールへの耐性不足

人的脆弱性は、人の行動や知識に起因する弱点です。具体的には、パスワードの使い回し、業務端末の紛失、標的型メールのリンクを開いてしまう判断ミスなどが該当します。技術的対策を固めても、従業員一人の誤操作で認証情報が流出すれば、ほかの防御がまとめて無力化されます。人的脆弱性は人的分類の管理策で扱い、セキュリティ教育の定期実施、メール訓練、退職時のアクセス権剥奪といった運用で耐性を高めます。よくある失敗が「年1回の集合研修だけで完結させる」進め方で、訓練の頻度と実践度が伴わないと教育記録が形だけになりがちです。

物理的脆弱性｜入退室管理の不備や記録媒体の持ち出しリスク

物理的脆弱性は、施設や設備、記録媒体に関わる弱点です。サーバ室の入退室が施錠だけで記録が残らない、USBメモリの持ち出しが自由にできる、書類が施錠保管されていないといった状態が典型例です。サイバー攻撃に注目が集まりがちですが、内部関係者による媒体の持ち出しや盗難は、技術的防御をすり抜けて情報を流出させます。物理的分類の管理策では、入退室記録の取得、クリアデスク・クリアスクリーンの徹底、媒体の廃棄手順の明文化などで対応します。データセンターを外部委託している場合は、委託先の物理セキュリティを確認できる契約・報告の仕組みが判断基準になります。

組織的脆弱性｜規程未整備・責任分界点の曖昧さによる対応の停滞

組織的脆弱性は、ルールや体制の不備に起因する弱点です。情報セキュリティ方針が形骸化している、責任分界点が曖昧でインシデント時に誰も動けない、委託先管理の規程がないといった状態が当てはまります。組織的管理策は2022年版で最も項目数が多い分類で、脆弱性管理の土台になります。脆弱性が公表されても「誰がいつまでに対応を判断するか」が決まっていなければ、技術的に検出できても放置されます。役割・責任・期限を規程に落とし込み、運用が回っている記録を残すことが、組織的脆弱性を埋める実務上の要点です。

ゼロデイ脆弱性とサプライチェーン由来の脆弱性の具体例

近年とくに注意が必要なのが、修正パッチが提供される前に悪用されるゼロデイ脆弱性と、外部から調達したソフトウェア部品に潜むサプライチェーン由来の脆弱性です。サプライチェーン由来の脆弱性として広く知られるのが、ログ出力ライブラリで起きたLog4j2の脆弱性です。自社で作り込んでいなくても、利用するオープンソースライブラリや委託先のシステムに脆弱性があれば、自組織の情報資産が危険にさらされます。対策として、利用ソフトウェアの構成を一覧化するSBOM（ソフトウェア部品表）の整備や、脅威インテリジェンスによる早期の情報収集が有効です。ゼロデイは「完全には防げない前提」で、監視や分離による検知と被害局所化に重点を置く判断が現実的です。

ISO27001:2022改訂で強化された脆弱性関連の管理策と主な変更点

ISO/IEC 27001は2022年10月に約9年ぶりに改訂され、日本語版のJIS Q 27001:2023が2023年9月20日に発行されました。脆弱性対応に関わる管理策がどう変わったかを押さえます。

管理策114→93項目・4分類への再編と脆弱性対応の位置づけ

2022年版の最大の変更点は、附属書Aの管理策が旧版の114項目から93項目へ統合・削減され、14分類から組織的・人的・物理的・技術的の4分類に再編されたことです。あわせて11の新しい管理策が追加され、58項目が更新、24項目が統合されました。脆弱性対応の観点では、関連する管理策が複数の分類にまたがって配置されており、技術的対策だけでは完結しない構成になっています。既存のISMSを2013年版で運用していた組織は、適用宣言書（SoA）を新しい管理策番号に合わせて見直す必要があり、ここで脆弱性関連の対応漏れが表面化しやすくなります。

管理策8.8 技術的ぜい弱性の管理で求められる具体的な対応

脆弱性対応の中核が、管理策8.8「技術的ぜい弱性の管理」です。これは旧版の同名の管理策を引き継いだもので、利用中の情報システムの技術的脆弱性に関する情報を適時に入手し、組織のさらされている状況を評価し、適切な対策を講じることを求めます。実務では、資産目録に基づいて利用ソフトウェアを把握し、脆弱性情報を継続的に収集し、CVSSなどで深刻度を評価したうえでパッチ適用や緩和策を実施する一連の流れが該当します。審査では「脆弱性情報の入手元」「評価の基準」「対応の記録」を具体的に示せるかが問われるため、属人的な対応ではなく手順として明文化しておくことが判断基準になります。

新管理策5.7 脅威インテリジェンスと脆弱性情報収集の関係

2022年版で新設された管理策5.7「脅威インテリジェンス」は、最新の脅威動向や脆弱性情報を収集・分析し、自組織に該当するかを判断して対応につなげることを求めます。脅威と脆弱性は表裏の関係にあり、新たな攻撃手法という脅威の情報を得ることで、自社のどの脆弱性が狙われやすいかを先回りで把握できます。情報源としては、IPAやJPCERT/CCの注意喚起、製品ベンダーのセキュリティアドバイザリなどが代表的です。専門性が高い領域のため、管理策5.6「専門組織との連絡」と組み合わせ、外部の情報源を運用に組み込む設計が現実的です。

新管理策8.28 セキュアコーディングによるソフトウェア脆弱性の低減

ソフトウェアを自社開発する組織にとって重要なのが、新管理策8.28「セキュアコーディング」です。これは、開発段階でセキュリティに配慮したコーディング原則を適用し、ソフトウェアに作り込まれる脆弱性の数を減らすことを目的とします。具体的には、採用するコーディング規約の決定、既知の脆弱な実装手法の排除、外部から調達するソフトウェア部品への適用、開発ツールやレビュー体制の整備などが含まれます。脆弱性は「見つけて直す」だけでなく「作り込まない」段階から減らすという発想が、2022年版で明確に示された点が実務上の変化です。

8.16監視活動・8.9構成管理が脆弱性低減に果たす役割

脆弱性低減に間接的に効くのが、新管理策8.16「監視活動」と8.9「構成管理」です。8.16はネットワークやシステムの挙動を監視し、インシデントの兆候を早期に検知することを求めます。脆弱性を突かれた痕跡を見逃さない仕組みは、ゼロデイのように事前対策が難しい脅威への保険になります。8.9の構成管理は、ハードウェアやソフトウェアの設定を定められた状態に維持する管理策で、初期設定のまま放置された不要なサービスや既定パスワードといった設定起因の脆弱性を防ぎます。新規導入時の設定基準と、運用中の継続的な維持を記録に残すことが対応のポイントです。

リスクアセスメントでの脆弱性評価とCVSSを用いた優先順位付け

洗い出した脆弱性は、リスクアセスメントを通じて優先順位を付けて初めて意味を持ちます。評価の流れと判断基準を整理します。

情報資産の特定から脆弱性を入力とするリスク分析への流れ

リスクアセスメントは、情報資産の特定、脅威と脆弱性の洗い出し、リスクの分析、リスクの評価という順で進みます。脆弱性はこのうち分析の入力になり、どの資産にどんな脆弱性があり、どの脅威が結びつくかを組み合わせてリスクの大きさを見積もります。ここで脆弱性の洗い出しが甘いと、リスクそのものを認識できず対策の対象から漏れます。実務では、脆弱性スキャンの結果や過去のインシデント、外部の脆弱性情報を入力源として、資産ごとにリスクを一覧化する方法が一般的です。

CVSS基本値で脆弱性の深刻度を0.0〜10.0で数値化する評価手法

技術的脆弱性の深刻度を客観的に評価する指標がCVSS（Common Vulnerability Scoring System）です。CVSSは脆弱性の特性を0.0〜10.0のスコアで表し、9.0以上を「緊急（Critical）」、7.0〜8.9を「重要（High）」などと段階づけます。たとえば、CVSS9.8の脆弱性が公開サーバに存在すれば、最優先で対応すべき対象と判断できます。ただしCVSSはあくまで技術的な深刻度であり、その資産の重要度や攻撃の到達可能性を加味しないと過不足が生じます。スコアを起点にしつつ、自組織の文脈で補正する運用が現実的です。

リスク受容基準に基づく対応要否の判断とリスク対応の4選択肢

評価したリスクは、あらかじめ定めたリスク受容基準と照らして対応要否を判断します。リスク対応には、対策を講じてリスクを下げる「低減」、保険などへ移す「移転（共有）」、リスク源そのものをやめる「回避」、基準内として受け入れる「受容」の4つの選択肢があります。たとえば、低リスクの脆弱性に多額のコストをかけるのは合理的でないため受容を選ぶ、といった判断が成り立ちます。重要なのは、受容する場合も誰が承認したかを記録に残すことで、無自覚な放置と意図的な受容を明確に区別する点です。

リスクベース脆弱性管理で対応の優先順位を決める実務的な考え方

検出される脆弱性は膨大で、すべてを同時に対応するのは非現実的です。そこで近年主流になっているのが、リスクの高いものから対応するリスクベース脆弱性管理（RBVM）の考え方です。従来のCVSSだけの優先順位付けに対し、RBVMでは実際に攻撃へ悪用されているか（悪用可能性）や資産の重要度を加味して優先度を決めます。たとえば、CVSSは中程度でも実際の攻撃が観測されている脆弱性を、CVSSは高くても攻撃実績のない脆弱性より優先する、といった判断ができます。限られた人員と時間を、被害に直結する脆弱性へ集中させるための実務的な手法です。

残留リスクの承認と適用宣言書（SoA）への反映の実務

対応後にも残るリスク（残留リスク）は、責任者の承認を得て受け入れることがISMSで求められます。あわせて、どの管理策を適用し、どれを適用しないかを示す適用宣言書（SoA）に、脆弱性関連の管理策の採否と理由を反映します。たとえば、自社開発を行わない組織がセキュアコーディング（8.28）を適用除外とする場合、その理由をSoAに明記しておけば審査で説明できます。残留リスクの承認記録とSoAの整合が取れていないと審査で指摘を受けやすいため、リスクアセスメントの結論をこの二つの文書へ確実に落とし込むことが要点です。

ISMS運用に組み込む脆弱性管理ライフサイクルの実務手順と判断基準

脆弱性管理は一度きりの作業ではなく、継続して回す仕組みが必要です。ライフサイクルの各段階とISMSのPDCAへの組み込み方を見ていきます。

発見・評価・優先順位付け・対応・再評価の5段階プロセス

脆弱性管理ライフサイクルは、次の5段階を継続的に繰り返す形で設計します。

  1. 発見：資産目録と脆弱性スキャンで弱点を洗い出す
  2. 評価：CVSSや資産重要度で深刻度を判定する
  3. 優先順位付け：リスクベースで対応の順番を決める
  4. 対応：パッチ適用または緩和策を実施する
  5. 再評価：対応結果を確認し、目録と記録を更新する

各段階を分断せず、再評価の結果を次の発見につなげることで、対応漏れや再発を防げます。一度で終わらせず四半期ごとなど周期を決めて回すことが、ライフサイクルとして機能させる前提になります。

資産目録と脆弱性スキャンを連動させた継続的な発見の仕組み

発見段階の精度は、資産目録の整備状況で決まります。管理対象のサーバや端末、ソフトウェアが目録に載っていなければ、そもそもスキャン対象から漏れ、脆弱性が放置されます。実務では、構成管理（8.9）で維持する資産目録と、脆弱性スキャナの対象範囲を一致させることが基本です。クラウドや開発環境が増えると、把握していない資産（シャドーIT）が脆弱性の温床になりやすいため、定期的な棚卸しと自動検出の併用が現実的な対策になります。

パッチ管理と緩和策の使い分けによる現実的な対応判断

対応段階では、修正パッチの適用が基本ですが、すぐに適用できない場合の緩和策も用意しておく必要があります。稼働中の基幹システムで即時のパッチ適用が難しい場合は、該当機能の一時停止、アクセス制限、ネットワーク分離といった緩和策で攻撃面を下げ、計画的にパッチを当てる判断が現実的です。パッチ適用には動作検証や停止調整が伴うため、深刻度と業務影響を天秤にかけて対応期限を決めます。緊急の脆弱性は何日以内、重要な脆弱性は何週間以内、といった対応SLAをあらかじめ定めておくと、判断が属人化しません。

是正・改善をPDCAサイクルに組み込む継続的な運用設計

脆弱性管理ライフサイクルは、ISMS全体のPDCAサイクルに組み込んで運用します。計画（Plan）で脆弱性管理の方針と対応基準を定め、実行（Do）で発見から対応までを回し、点検（Check）で内部監査やマネジメントレビューにより有効性を確認し、改善（Act）で手順や基準を見直します。たとえば、対応が遅れた脆弱性が監査で見つかれば、原因を分析して対応SLAや体制の改善につなげます。単発の脆弱性対応を改善のインプットとして扱うことで、ISMSの継続的改善の要求と脆弱性管理が一体になります。

対応SLA・KPI設定で形骸化を防ぐ管理プロセスの定着策

脆弱性管理が形だけにならないよう、対応SLAやKPIで運用を可視化します。具体的には、重大な脆弱性の平均対応日数、未対応の脆弱性件数、期限超過の割合といった指標を定点観測します。未対応件数が増え続けている場合は、人員不足か優先順位付けの基準が機能していない兆候です。指標を経営層に定期報告する仕組みがあれば、脆弱性管理が現場任せにならず、必要なリソース配分の判断材料になります。記録だけ残して振り返らない運用が、最も陥りやすい失敗パターンです。

技術的脆弱性診断とISMS管理策をつなぐ運用設計の独自ポイント

一創ではシステム開発の現場で個別製品の脆弱性に向き合ってきました。ここでは、技術的な脆弱性診断とISMSのマネジメントをつなぐ、実装寄りの視点を整理します。

脆弱性診断とペネトレーションテストの違いと管理策8.8の関係

脆弱性診断とペネトレーションテストは、どちらも技術的脆弱性を実地で洗い出す手段ですが、目的が異なります。脆弱性診断はツールや手動で既知の弱点を網羅的に検出することを重視し、ペネトレーションテストは実際の攻撃者視点で侵入可能かを検証します。脆弱性診断では、たとえばOWASP ZAPの診断項目のように、検出対象を体系立てて洗い出すツールが用いられます。これらはISMSの管理策8.8（技術的ぜい弱性の管理）が求める「さらされている状況の評価」を裏付ける具体的手段として位置づけられます。診断結果を管理策の運用記録に結びつけることで、脆弱性を評価しているという要求を、抽象論ではなく実データで示せます。

検出したCVEを管理策8.8の運用記録・台帳へ接続する方法

診断で検出した個々の脆弱性は、CVE番号やCVSSスコアとともに台帳化し、管理策8.8の運用記録として残すと審査での説明力が高まります。たとえば、CVE番号・対象資産・CVSS・対応内容・対応日・承認者を一覧で管理すれば、発見から対応までのトレーサビリティが確保できます。技術部門が持つ生の診断結果と、ISMS事務局が管理する文書が分断されていると、審査時に両者の整合を取るのに苦労します。診断ツールの出力をそのまま証跡にできる台帳の形式を、あらかじめ設計しておくことが実務上の工夫です。

開発工程（SDLC）とISMS運用を橋渡しするシフトレフトの発想

自社開発を行う組織では、開発ライフサイクル（SDLC）の各工程にセキュリティ観点を組み込むことで、脆弱性を作り込む前に減らせます。要件定義でのセキュリティ要件の明確化、設計でのセキュアアーキテクチャ、実装でのセキュアコーディング（8.28）、テストでの脆弱性診断という流れは、ISMSの管理策と自然に対応します。リリース直前の診断だけに頼ると、見つかった脆弱性の修正に手戻りが発生し、納期を圧迫します。開発の上流からセキュリティを組み込むシフトレフトの発想が、脆弱性対応のコストを下げる判断基準になります。

個別製品の脆弱性情報を組織的に集約する体制づくり

実務では、利用している個別製品ごとに脆弱性が日々公表されます。圧縮ソフト、Reactのようなフレームワーク、ログ出力ライブラリなど、製品単位の脆弱性情報を技術者が個別に追うだけでは、組織としての対応漏れが生じます。脅威インテリジェンス（5.7）の枠組みで、利用製品のセキュリティアドバイザリを集約し、自社の資産目録と突き合わせて影響を判定する体制が有効です。一創でも個別製品の脆弱性情報を技術記事として継続的に整理しており、こうした技術知見を組織のISMS運用に還元することが、現場とマネジメントを結ぶ強みになります。

診断の内製・外部委託の判断と頻度を決める実務上の基準

脆弱性診断を内製するか外部委託するかは、対象システムの重要度と社内の専門人材の有無で判断します。日常的な脆弱性スキャンは内製で自動化し、年1回や大規模リリース時の精密な診断・ペネトレーションテストは専門事業者に委託する、といった役割分担が現実的です。診断頻度は、外部公開システムは高頻度、社内限定システムは年次といった具合に、リスクの高さに応じて差をつけます。すべてを同じ頻度で診断しようとすると、コストばかりかさんで重要資産への集中が薄れるため、めりはりをつける判断が要点です。

移行期限経過後のISMS審査対応と脆弱性管理で問われる実務ポイント

規格改訂の節目を越えた今、ISMS認証の取得・更新で脆弱性管理がどう問われるかを、最新の規格動向とあわせて確認します。

2025年10月31日の移行期限経過後に求められる新規格での運用

旧規格ISO/IEC 27001:2013からの移行期限は2025年10月31日と定められ、すでに経過しています。これからISMS認証を取得する組織は、当然に現行のISO/IEC 27001:2022（JIS Q 27001:2023）が審査基準となります。既存の認証組織も、移行審査を終えていれば新管理策に沿った運用が前提です。脆弱性対応の観点では、新設された5.7・8.28・8.16などの管理策が運用に組み込まれているかが、移行後の通常審査でも継続的に確認されます。移行は済んだが新管理策の運用記録が薄い、という状態が移行後に指摘を受けやすい典型例です。

JIS Q 27001:2025（追補1）の気候変動考慮と認証文書への影響

最新の動きとして、2025年5月20日にJIS Q 27001:2025（追補1）が公示されました。これはISO/IEC 27001:2022/Amd 1:2024に対応するもので、内容は箇条4.1・4.2に「気候変動が関連する課題かどうかの考慮」を求める追加のみです。脆弱性管理の要求そのものを変えるものではありませんが、組織の状況把握において気候変動の観点を検討し、該当する場合はマネジメントシステムに反映する必要があります。なお追補1は改正部分のみを示すため、要求事項の全体はJIS Q 27001:2023との併読が前提です。認証文書の規格表記の扱いは認証機関により異なるため、確認しておくと安全です。

移行審査・更新審査で脆弱性管理について問われる具体的な観点

移行審査や更新審査では、脆弱性管理について、仕組みが定められ、実際に運用され、記録が残っているかが一貫して問われます。具体的には、脆弱性情報の入手手段（5.7・8.8）、深刻度の評価基準（CVSS等）、対応の優先順位付け、対応期限と実績、残留リスクの承認といった一連の流れを説明できるかが確認されます。審査員は完璧な対応よりも、自組織のリスクに見合った合理的な運用と、その証跡を重視します。背伸びした理想的な手順書を作るよりも、実際に回せる手順を定めて記録を残すほうが、審査での評価につながります。

審査でエビデンスとして提示すべき脆弱性管理の記録

脆弱性管理に関して審査で求められやすい記録には、次のようなものがあります。

  • 脆弱性管理の手順書と対応SLA・リスク受容基準
  • 脆弱性の検出・評価・対応を記録した台帳（CVE・CVSS・対応日・承認者）
  • 脆弱性スキャンや脆弱性診断の実施報告書
  • 残留リスクの承認記録と適用宣言書（SoA）
  • セキュリティ教育やメール訓練の実施記録

これらは普段の運用の中で自然に生成される記録です。審査直前にまとめて作るのではなく、日常の運用がそのまま記録として残る仕組みにしておくことが、負担を抑える要点になります。

認証取得・更新で脆弱性管理体制を整える際のよくある失敗

脆弱性管理体制を整える際に陥りやすい失敗として、第一に「手順書はあるが運用されていない」状態が挙げられます。立派な規程を作っても、実際の対応記録がなければ審査で運用実態を示せません。第二に、技術部門とISMS事務局の連携不足で、診断結果が文書に反映されないケースです。第三に、移行や更新の直前に慌てて記録を整える進め方で、これは負担が一時に集中し品質も下がります。脆弱性管理は日常業務として継続的に回し、その記録を蓄積していく姿勢が、結果として最も確実に審査を通過する近道になります。

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

ISMSにおける脆弱性について、実務でよく寄せられる質問をまとめました。

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

脅威は情報資産の機密性・完全性・可用性を侵害しうる「事象」で、フィッシングメールやランサムウェア、地震などが該当します。一方、脆弱性は脅威に対する「耐性の不足」という弱点で、修正パッチの未適用やパスワードの使い回しなどが例です。脅威は外部から訪れて制御が難しいのに対し、脆弱性は組織の取り組みで減らせる点が大きな違いになります。リスクは、この脅威が脆弱性を突いて情報資産に影響を及ぼす可能性として捉えます。

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

ISO/IEC 27001は、脆弱性診断という特定の手段を直接義務づけてはいません。ただし、管理策8.8で技術的脆弱性のさらされている状況の評価が求められるため、その評価手段として脆弱性診断が実務上ほぼ不可欠になります。技術的脆弱性を抱えるシステムを持つ組織が、診断や脆弱性スキャンをまったく行わずに「評価している」と説明するのは困難です。診断の頻度や範囲は、資産の重要度に応じてリスクベースで決めるのが現実的です。

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

中核は管理策8.8「技術的ぜい弱性の管理」です。これに加え、2022年版で新設された5.7「脅威インテリジェンス」が脆弱性情報の収集に、8.28「セキュアコーディング」がソフトウェア脆弱性の作り込み防止に、8.16「監視活動」や8.9「構成管理」が脆弱性の検知や設定起因の弱点防止に関わります。脆弱性対応は技術的分類だけで完結せず、組織的管理策を含めて横断的に設計する必要があります。

脆弱性管理ツールはISMS運用に必要ですか？

ツールの導入は必須ではありませんが、管理対象が増えるほど有効になります。脆弱性スキャナや脆弱性管理ツールを使うと、資産ごとの脆弱性の検出・一覧化・対応状況の追跡を効率化できます。小規模で対象が限られるなら、台帳と手動の脆弱性情報収集でも運用は可能です。判断の目安は、手作業で対応漏れや期限超過が発生し始めたらツールによる自動化を検討する、という考え方です。ツールの導入自体が目的化しないよう注意してください。

2025年10月の移行期限を過ぎた今、何をすべきですか？

移行期限（2025年10月31日）を過ぎた現在は、ISO/IEC 27001:2022（JIS Q 27001:2023）での運用が前提です。移行審査を終えていない場合は、速やかに認証機関へ相談する必要があります。移行済みの組織は、新管理策（5.7・8.8・8.28など）の運用記録が継続的に蓄積されているかを点検しましょう。あわせて、2025年5月公示のJIS Q 27001:2025（追補1）が求める気候変動の考慮について、自組織に該当するかを確認しておくと安心です。

関連記事

資料請求

RELATED POSTS 関連記事

一覧へ戻る