月曜日の朝、経営会議が終わった直後に内部監査室長の内線が鳴ります。週末に同業他社がランサムウェアの被害を受けたという報道を見た社長が、「うちは大丈夫なのか。次の取締役会で説明してほしい」と言っているというのです。情報システム部に聞けば「対策はしています」と返ってきますが、何を根拠に「大丈夫」と言えるのかは誰も説明できません。
内部監査室には IT 全般統制（ITGC）の評価経験があります。けれども J-SOX の ITGC は財務報告に関係するシステムが対象で、工場の制御系や委託先の保守回線までは見ていません。バックアップが実際に戻せるかを試した記録を見た人もいません。これは多くの内部監査部門が直面している状況を組み立てた架空のモデルケースです。
こうしたときに、監査の物差しとして広く使われているのが米国国立標準技術研究所（NIST）の「サイバーセキュリティフレームワーク（CSF）」です。2024 年 2 月に公表された 2.0 版では、経営の関与を問う「GOVERN（統治）」が新たに加わり、内部監査が取締役会に報告する枠組みとして使いやすくなりました。本記事では、CSF 2.0 を使ったサイバーセキュリティ監査の進め方を、計画から報告まで順に解説します。
この記事の要点
- NIST CSF 2.0 は 6 機能・22 カテゴリ・106 サブカテゴリで「達成すべき成果」を示す枠組みで、手順書やチェックリストではない
- 新設の GOVERN は、方針・役割・リスク許容度・サプライチェーンなど「経営の関与」を問う。内部監査が最初に見るべき領域でもある
- 監査は「スコープ設定 → 現状プロファイル → 目標との差分 → リスク評価 → 報告」で進め、Tier は成熟度の点数ではなく管理の厳格さの目安として扱う
- J-SOX の ITGC とは目的と範囲が違う。対応表を作れば既存の評価結果を再利用でき、重複を減らせる
サイバーセキュリティ監査とは——ITGC 監査と何が違うのか
サイバーセキュリティ監査とは、組織がサイバー攻撃や情報漏えいなどのリスクを、経営の方針に沿って識別・防御・検知・対応・復旧できる状態にあるかを、独立した立場から評価する活動です。対象は情報システムに限らず、方針、体制、人材、委託先管理、事業継続計画まで含みます。
混同されやすいのが J-SOX の IT 全般統制です。金融庁の「財務報告に係る内部統制の評価及び監査に関する実施基準」が求める ITGC は、財務報告の信頼性を支えるための統制で、プログラム変更やアクセス管理などが中心になります。目的が財務報告なので、対象システムも会計や販売管理など財務数値に影響するものに限られます。一方、サイバー攻撃で止まるのは工場の生産ラインや顧客向けサービスであることが多く、ITGC の範囲だけでは経営が知りたい「事業が止まるリスク」に答えられません。ITGC の基本は ITGC（IT 全般統制）とは？クラウド/SaaS 時代の評価ポイント で整理しています。
内部監査の基準も「サイバー」を名指しした
国際的な動きとして、内部監査人協会（IIA）は 2025 年 2 月 5 日に「サイバーセキュリティ・トピック別要求事項（Cybersecurity Topical Requirement）」を公表し、2026 年 2 月 5 日に発効しました。これは「グローバル内部監査基準」を補完するもので、サイバーセキュリティのガバナンス、リスク管理、コントロール・プロセスの 3 領域について、監査で評価すべき最低限の事項を示しています。IIA の基準に準拠する内部監査部門では、サイバーセキュリティを対象とする監査業務を行う際にこの要求事項を踏まえることになります。適用の範囲や文書化の方法は IIA の公表資料とユーザーガイドで確認してください。基準全体の動向は グローバル内部監査基準の改訂ポイント も参考になります。
なぜ「枠組み」が必要なのか
技術の変化が速い領域で、監査人が製品や設定の良し悪しを判断しようとすると、専門部署との知識差で議論が進みません。「何を達成すべきか」を共通言語で示した枠組みに沿って質問すれば、監査人は「成果が出ているか」「それを示す証拠があるか」に集中できます。
NIST CSF 2.0 の構造——6 機能・22 カテゴリ・106 サブカテゴリ
NIST CSF はもともと、米国の重要インフラのサイバーセキュリティ向上を目的とした 2013 年の大統領令 13636 を受けて、2014 年 2 月に 1.0 版が公表されました。2018 年 4 月の 1.1 版を経て、2024 年 2 月 26 日に 2.0 版（NIST CSWP 29）が公表されています。2.0 版では、対象を重要インフラに限らず、規模や業種を問わないあらゆる組織に広げたことが明記されました。日本語訳は情報処理推進機構（IPA）が NIST の了解のもとで公開しています。
CSF の中核（CSF Core）は、「機能 → カテゴリ → サブカテゴリ」の 3 階層で成果を並べたものです。2.0 版の機能は次の 6 つです。
| 機能 | 略号 | NIST による定義の要旨 | カテゴリ（抜粋） |
|---|---|---|---|
| GOVERN（統治） | GV | リスク管理の戦略・期待・方針が確立、伝達、監視されている | 組織の状況（GV.OC）、リスク管理戦略（GV.RM）、役割・責任・権限（GV.RR）、方針（GV.PO）、監督（GV.OV）、サプライチェーンリスク管理（GV.SC） |
| IDENTIFY（識別） | ID | 現在のサイバーセキュリティリスクが理解されている | 資産管理（ID.AM）、リスクアセスメント（ID.RA）、改善（ID.IM） |
| PROTECT（防御） | PR | リスクを管理するための保護策が使われている | ID 管理・認証・アクセス制御（PR.AA）、意識向上と訓練（PR.AT）、データセキュリティ（PR.DS）、プラットフォームセキュリティ（PR.PS）、技術インフラのレジリエンス（PR.IR） |
| DETECT（検知） | DE | 攻撃や侵害の可能性が発見・分析されている | 継続的モニタリング（DE.CM）、有害事象の分析（DE.AE） |
| RESPOND（対応） | RS | 検知したインシデントへの措置が取られている | インシデント管理（RS.MA）、分析（RS.AN）、報告とコミュニケーション（RS.CO）、軽減（RS.MI） |
| RECOVER（復旧） | RC | 影響を受けた資産と業務が復旧されている | 復旧計画の実行（RC.RP）、復旧時のコミュニケーション（RC.CO） |
カテゴリは合計 22、サブカテゴリは合計 106 です。1.1 版にあった一部のカテゴリは統合・移動されているため、旧版の対応表を使っている場合は NIST が公開している移行資料で確認してください。
GOVERN が中心に置かれた理由
CSF 2.0 の文書では、6 機能を円（ホイール）で示し、GOVERN をその中心に置いています。GOVERN は「ほかの 5 機能をどう実施するかを方向づける」ものであり、サイバーセキュリティを全社的リスクマネジメント（ERM）に組み込むうえで欠かせないと説明されています。1.1 版までは、識別・防御などの「現場の対策」が中心で、経営の関与はカテゴリの一部に散らばっていました。攻撃の被害が事業停止や取引先への波及として経営問題になった結果、「誰が責任を持ち、どこまでのリスクを許容するのか」を独立した機能として問う形になったといえます。
内部監査の立場から見ると、これは大きな変化です。個々の技術的な不備を指摘するだけでは、同じ問題が形を変えて再発します。GOVERN の成果、たとえば「リスク許容度が定められ、伝達されている（GV.RM-02）」や「経営層がサイバーセキュリティリスクに責任を負っている（GV.RR-01）」を評価すると、不備の根本原因を経営レベルの課題として報告できます。
「チェックリストではない」ことの意味
CSF 2.0 自身が、中核の成果は「実施すべき行動のチェックリストではない」と明記しています。成果を達成する具体的な方法は組織ごとに異なり、機能やカテゴリの並び順も優先順位を意味しません。監査人が 106 項目に「○×」を付けて終わりにすると、この趣旨から外れます。後で述べるように、自社のリスクに応じて対象を絞り、各成果が「どの程度」達成されているかを証拠で確かめるのが本来の使い方です。
監査計画——スコープ設定とプロファイルの考え方
CSF 2.0 には、組織の状態を記述する道具として「組織プロファイル」があります。現在達成している成果を示す「現状プロファイル（Current Profile）」と、目指す成果を示す「目標プロファイル（Target Profile）」の 2 つで、その差分がギャップになります。業界団体などが共通の目標として作る「コミュニティプロファイル」を、目標プロファイルの土台に使うこともできます。
NIST はプロファイルの作成と活用を、次の 5 段階で示しています。
- プロファイルの範囲を決める
- 必要な情報を集める（方針、リスク管理の優先度、事業影響度分析など）
- プロファイルを作成する
- 現状と目標の差分を分析し、行動計画を作る
- 行動計画を実行し、プロファイルを更新する
監査は「プロファイルを作る側」ではない
ここで注意したいのは、プロファイルを作って改善を進めるのは第 1・第 2 ラインの仕事だという点です。内部監査が自らプロファイルを作り、行動計画まで書いてしまうと、監査対象を自分で設計することになり、独立性が損なわれます。役割分担の考え方は 3 ラインモデルとは？ を参照してください。
内部監査の基本的な立ち位置は、次のいずれかです。
- 情報システム部や CISO がプロファイルを作っている場合: その作り方が妥当か（範囲、目標の根拠、証拠の裏付け）と、ギャップへの対応が進んでいるかを監査する
- プロファイルがまだない場合: CSF を監査の評価基準として使い、監査結果として現状を示す。そのうえで、プロファイル作成を経営に提言する
スコープ設定の記入例
CSF の範囲は組織全体でも、特定のシステムや脅威に絞っても構いません。NIST 自身も「財務システムを対象としたランサムウェア対策」のように絞った例を挙げています。初回の監査は範囲を広げすぎないことが大切です。以下は、冒頭のモデルケースを想定したスコープ設定の記入例です。
| 項目 | 記入例（架空のモデルケース） |
|---|---|
| 監査テーマ | ランサムウェアによる事業停止リスクへの備え |
| 対象範囲 | 基幹業務システム、ファイルサーバー、生産管理システム、外部接続（VPN・保守回線）、主要クラウドサービス 3 件 |
| 対象外と理由 | 海外子会社（翌年度に別監査として計画）、個人情報保護の法令遵守（コンプライアンス監査で実施） |
| 評価基準 | NIST CSF 2.0 のうち GV.RM、GV.RR、GV.SC、ID.AM、ID.RA、PR.AA、PR.DS、PR.PS、DE.CM、RS.MA、RC.RP の 11 カテゴリ |
| 目標水準の出所 | 情報セキュリティ委員会が承認した目標（なければ経営と合意した暫定目標） |
| 主な証拠 | 方針・規程、委員会議事録、資産台帳、脆弱性スキャン結果、アクセス権棚卸記録、ログ監視記録、復旧テスト記録 |
| 外部専門家 | 侵入テストの結果は外部ベンダー報告書を利用し、監査人は範囲と指摘への対応を評価 |
「対象外と理由」を書く欄が重要です。取締役会は「全部見た」と誤解しがちなので、見ていない範囲を明示しておくことが、報告の信頼性を守ります。範囲の絞り方は リスクベース内部監査の始め方 の考え方がそのまま使えます。
着手前のチェックリスト
- 監査テーマ・範囲・対象外の理由を監査計画書に書いた
- 選んだカテゴリのサブカテゴリを CSF 2.0 本文（または IPA の日本語訳）で読み込んだ
- 目標水準の出所（経営承認か暫定か）を被監査部門と確認した
- 資産台帳、委託先一覧、ネットワーク構成図を事前に入手した
- 外部専門家の報告書（侵入テスト・脆弱性診断）の有無と範囲を確認した
- 入手する機密情報（構成図・脆弱性情報）の調書での保管方法とアクセス権を決めた
最後の項目は見落とされがちです。脆弱性の一覧は攻撃者にとっても価値のある情報なので、監査調書の書き方と保管ルール に沿って扱いを決めておきます。
機能別の監査手続——何を見て、何を証拠にするか
CSF のサブカテゴリは成果を述べた短い文です。監査では、それを「監査上の質問」に言い換え、どの証拠で確かめるかを決めます。以下は、中堅企業で最初の監査を行う場合を想定した手続の例です。サブカテゴリの番号と要旨は CSF 2.0 本文に基づいています。
| 機能 | 対象（サブカテゴリ例） | 監査上の質問 | 主な証拠 |
|---|---|---|---|
| GV | GV.RM-02 リスク許容度の明示 | 許容できる停止時間や損失が経営の言葉で決まっているか | 取締役会・委員会資料、リスク選好の記載 |
| GV | GV.RR-01 経営層の責任 | 責任者が任命され、定期的に報告を受けているか | 任命記録、報告の頻度と内容 |
| GV | GV.SC-04 委託先の重要度分類 | 重要な委託先が特定され、優先度が付いているか | 委託先一覧、評価記録、契約条項 |
| ID | ID.AM-01/02 資産台帳 | ハードウェア・ソフトウェア・サービスの台帳が最新か | 台帳と実機・ネットワーク検出結果の突合 |
| ID | ID.RA-01 脆弱性の識別 | 脆弱性が見つかり、記録され、対応期限が管理されているか | スキャン結果、対応チケットの期限遵守率 |
| PR | PR.AA-05 最小権限と職務分離 | 権限が方針どおり付与・見直しされているか | 権限棚卸記録、特権 ID 一覧、退職者照合 |
| PR | PR.DS-11 バックアップ | バックアップが作成・保護・テストされているか | 取得ログ、隔離・不変保存の設定、テスト記録 |
| PR | PR.PS-04 ログの生成 | 監視に必要なログが出力・保管されているか | ログ設定、保管期間、欠落の有無 |
| DE | DE.CM-01 ネットワーク監視 | 異常を検知する仕組みがあり、誰かが見ているか | アラート件数と対応記録、夜間休日の体制 |
| RS | RS.MA-01 対応計画の実行 | 対応計画が第三者と連携して実行できるか | 対応計画、訓練記録、外部連絡先の更新日 |
| RC | RC.RP-03 復旧前の完全性確認 | 戻す前にバックアップの健全性を確かめる手順があるか | 復旧手順書、リストア試験の結果 |
証拠は「ある」ではなく「動いている」を見る
サイバーセキュリティ監査で最も多い落とし穴は、規程や設計書が「ある」ことを確認して終わってしまうことです。たとえばバックアップ（PR.DS-11）について、取得設定の画面を見ただけでは不十分です。CSF 2.0 は「作成され、保護され、維持され、テストされている」ことを成果としており、さらに復旧の場面では「使う前に完全性を確認する（RC.RP-03）」ことまで求めています。ランサムウェアはバックアップ自体を暗号化・削除しようとするため、隔離されているか、実際に戻せたかという「運用の証拠」がなければ、評価は保留にすべきです。
アクセス管理（PR.AA-05）も同様で、方針よりも棚卸の記録と、退職者・異動者の照合結果を見ます。具体的な手順は アクセス管理の監査手順 で解説しています。
GOVERN は「議事録」から読む
GOVERN の評価では、規程よりも会議体の記録が有力な証拠になります。取締役会や委員会でサイバーセキュリティがどの論点で議論され、リスク許容度や予算について経営が何を判断したか。こうした記録がなければ、GV.RR-01 の「経営層が責任を負う」という成果は形式上の任命にとどまっている可能性があります。
評価の付け方——Tier・ギャップ・リスクの 3 段で整理する
証拠を集めたら、評価を取締役会が理解できる形にまとめます。ここで迷うのが CSF の「Tier（ティア）」の扱いです。
Tier は成熟度の点数ではない
CSF 2.0 の Tier は、組織のリスクガバナンスと管理の「厳格さ」を 4 段階で示すものです。名称は Tier 1「部分的（Partial）」、Tier 2「リスク情報を活用（Risk Informed）」、Tier 3「反復可能（Repeatable）」、Tier 4「適応（Adaptive）」です。NIST は、Tier は組織のリスク管理手法を置き換えるものではなく補完するものであり、上位 Tier への移行はリスクや要求が大きい場合や費用対効果が見込める場合に推奨されるとしています。つまり「全社で Tier 4 を目指すべき」という物差しではありません。
監査で Tier を使うなら、「目標 Tier を経営が決めているか」「現状がそれに届いているか」を見るのが適切です。監査人が独自に目標 Tier を決めて「未達」と指摘すると、経営判断を監査が代行することになります。
ギャップ評価シートの記入例
以下は、カテゴリ単位で現状と目標の差を整理し、リスクの大きさで優先順位を付けるシートの記入例です（架空のモデルケース）。
| カテゴリ | 目標（経営承認） | 現状の観察 | ギャップ | 想定される影響 | 優先度 |
|---|---|---|---|---|---|
| GV.RM | 許容停止時間を主要業務ごとに定める | 定めがなく、部門ごとに認識が異なる | 大 | 復旧の優先順位が決まらず、初動が遅れる | 高 |
| ID.AM | 全資産を台帳で管理 | 工場系の機器 2 割が台帳外 | 中 | 脆弱性の対応漏れ | 高 |
| PR.DS | 隔離バックアップを四半期ごとに試験 | 取得はあるが復元試験の記録なし | 大 | 復旧不能のおそれ | 高 |
| PR.AA | 特権 ID を半年ごとに棚卸 | 棚卸は年 1 回、共有 ID が残存 | 中 | 侵害時の横展開 | 中 |
| RS.MA | 年 1 回の対応訓練 | 訓練は情シス内のみで経営層不参加 | 小〜中 | 公表・取引先対応の判断遅延 | 中 |
報告は「対策」ではなく「経営判断」の言葉で
取締役会向けの報告では、技術用語を並べるより、「許容停止時間が決まっていないため、攻撃を受けたときにどの業務から戻すかを誰も決められない」のように、事業への影響と経営が決めるべきことを示します。発見事項の書き方は 内部監査報告書の書き方 の 5 要素（事実・基準・原因・影響・提言）が有効です。CSF の番号は、根拠として脚注や別表に回すと読みやすくなります。
最終的な評価や改善の優先順位は、自社のリスク選好と経営判断によって決まるものです。監査はその判断材料を示す立場にある点を、報告書にも明記しておくとよいでしょう。
ITGC・J-SOX・国内ガイドラインとの対応づけ
多くの企業では、J-SOX の ITGC 評価、ISMS の内部監査、委託先評価など、似た評価が別々に行われています。CSF を監査の軸にするときは、既存の評価結果を再利用できるよう対応表を作ると、被監査部門の負担が大きく減ります。
経済産業省と IPA の「サイバーセキュリティ経営ガイドライン Ver 3.0」（2023 年 3 月公表）は、経営者が認識すべき 3 原則と、経営者が CISO 等に指示すべき「重要 10 項目」で構成されています。国内の経営層にはこちらの方がなじみがあるため、CSF と並べて示すと説明が通りやすくなります。
| CSF 2.0 の機能 | J-SOX の ITGC で近い領域 | サイバーセキュリティ経営ガイドライン Ver 3.0 で近い項目 |
|---|---|---|
| GOVERN | IT に係る全社的な統制（方針・体制） | 指示 1〜3（方針策定、管理体制、資源の確保）、指示 9（サプライチェーン） |
| IDENTIFY | 対応する領域は限定的（資産の把握は前提） | 指示 4（リスクの把握と対応計画） |
| PROTECT | アクセス管理、システムの運用管理、変更管理 | 指示 5（リスクに対応する仕組みの構築） |
| DETECT | システムの運用管理（ログ・監視）の一部 | 指示 5、指示 6（継続的改善） |
| RESPOND | 障害対応の一部 | 指示 7（緊急対応体制）、指示 10（情報共有） |
| RECOVER | バックアップ・リカバリー | 指示 8（事業継続・復旧体制） |
この表は各枠組みの目的の違いを踏まえた大まかな対応です。細かな対応づけは、NIST が公開している参照情報（Informative References）や各ガイドラインの付録を確認してください。
再利用するときの注意
ITGC で「アクセス管理は有効」と結論づけていても、それは財務報告に関係するシステムでの話です。「どのシステムで」「いつ時点の」結果かを脚注に残し、過大評価を避けます。自社の ITGC の弱い領域は ITGC 簡易診断 で見当を付けてから、CSF の重点カテゴリを決める方法もあります。
よくある失敗と対策
失敗 1: 106 項目すべてを一度に評価しようとする。 項目数の多さに作業が追いつかず、どれも浅い確認で終わります。対策は、リスクの大きいテーマを決めて 10 前後のカテゴリに絞ることです。残りは翌年度以降の計画に回し、複数年で全体を一巡させます。
失敗 2: 監査人が技術論争に巻き込まれる。 製品や設定値の議論に入ると、専門部署との知識差で進みません。監査人は成果・証拠・経営判断の有無に集中し、技術的な妥当性は外部専門家の報告書などで補います。
失敗 3: Tier を点数化して部署間で競わせる。 Tier は管理の厳格さの目安であり、すべての領域で高 Tier を目指すものではありません。目標を経営が決め、その目標との差で評価します。
失敗 4: 規程の存在だけで「有効」と結論づける。 特にバックアップと対応訓練は、試験や訓練の記録がなければ評価を保留にし、次回までに実施を求めます。
失敗 5: 委託先を範囲から外す。 CSF 2.0 はサプライチェーンリスク管理（GV.SC）を GOVERN の中に置いています。重要な委託先の一覧と評価記録がない場合、それ自体を発見事項として扱います。
よくある質問
Q. 情報システム部門の経験がない監査人でも実施できますか？
実施できますが、役割の切り分けが前提です。GOVERN や、方針・体制・委託先管理・訓練記録の確認は、一般的な内部監査の技能で十分に評価できます。脆弱性の技術的な深刻度やネットワーク設計の妥当性などは、外部専門家の報告書の利用や、社内の専門人材の協力で補います。CISA などの資格取得は、中長期の育成計画として検討するとよいでしょう。
Q. ISMS 認証を取得していれば、サイバーセキュリティ監査は不要ですか？
ISMS 認証は管理の仕組みが規格に沿っていることを示すもので、有用な証拠になります。ただし、認証範囲が一部の部署やサービスに限られている場合や、経営が決めた事業継続上の目標に照らした評価までは含まれていない場合があります。認証範囲と CSF の対象範囲を突き合わせ、重なる部分は認証審査の結果を利用し、重ならない部分を監査で見るのが効率的です。
Q. 監査の頻度はどの程度が適切ですか？
一律の決まりはなく、リスク評価に基づいて決めます。脅威の変化が速いため、全体を複数年で一巡させつつ、ランサムウェアや委託先経由の侵入など重点テーマは毎年いずれかの角度で取り上げる組み立てが考えられます。年間計画への組み込み方は 年間内部監査計画書の書き方 を参照してください。
まとめ
NIST CSF 2.0 は、サイバーセキュリティを「経営が方向づけ、組織全体で成果を出すもの」として整理した枠組みです。内部監査では、6 機能・22 カテゴリの中からリスクに応じて範囲を絞り、GOVERN を起点に「経営が決めるべきことが決まっているか」を確かめ、防御・検知・対応・復旧では「動いている証拠」を集めます。Tier は点数ではなく、経営が決めた目標との差を示す道具として使います。
まず次の一歩として、自社の ITGC の弱い領域を ITGC 簡易診断 で把握し、CSF のどのカテゴリを重点にするかを決めてみてください。関連する論点は アクセス管理の監査手順、ITGC とクラウド・SOC 報告書、AI ガバナンスの監査 でも扱っています。監査計画の設計や体制づくりのご相談は お問い合わせ からどうぞ。
参考資料
- NIST「The NIST Cybersecurity Framework (CSF) 2.0」NIST CSWP 29（2024 年 2 月 26 日） https://nvlpubs.nist.gov/nistpubs/CSWP/NIST.CSWP.29.pdf
- NIST Cybersecurity Framework 公式サイト（参照情報、実装例、クイックスタートガイド、移行資料） https://www.nist.gov/cyberframework
- 独立行政法人情報処理推進機構（IPA）「セキュリティ関連 NIST 文書について」（CSF 2.0 日本語訳ほか） https://www.ipa.go.jp/security/reports/oversea/nist/about.html
- 経済産業省・IPA「サイバーセキュリティ経営ガイドライン Ver 3.0」（2023 年 3 月） https://www.meti.go.jp/policy/netsecurity/mng_guide.html
- The Institute of Internal Auditors「Cybersecurity Topical Requirement」（2025 年 2 月 5 日公表、2026 年 2 月 5 日発効） https://www.theiia.org/en/standards/2024-standards/topical-requirements/cybersecurity/
- The Institute of Internal Auditors「Global Internal Audit Standards」 https://www.theiia.org/en/standards/2024-standards/global-internal-audit-standards/
- 金融庁「財務報告に係る内部統制の評価及び監査の基準並びに財務報告に係る内部統制の評価及び監査に関する実施基準」
