副題：NIST CSF・FISC・ISMSを横断する「使える」評価設計
想定読者：CISO、情報セキュリティ企画、内部監査、2線リスク管理部門
第1回では、金融庁ガイドラインを「経営課題」として読む視点を示しました。次に必要なのは、自社がいまどこにいるのかを測ることです。
ところが成熟度評価は、やり方を誤ると「基準ごとに別々のチェックリストが3つできた」「担当者の自己申告で全部レベル3になった」という結果に終わります。本稿では、複数基準を横断しながら、経営判断に使える評価を設計する手順を解説します。
1. 評価の目的を先に決める
成熟度評価には少なくとも3つの用途があり、目的によって設計が変わります。
用途 | 主な読者 | 求められる精度 | 適した粒度 |
|---|---|---|---|
経営報告・投資判断 | 取締役会、経営会議 | 傾向が分かればよい | 領域別（6〜10項目） |
ガイドライン対応状況の確認 | 2線、内部監査、当局対応 | 項目単位の根拠が必要 | 個別要求事項（100項目超） |
改善計画の立案 | CISO、セキュリティ部門 | 施策に変換できる具体性 | 統制単位（30〜50項目） |
3つを1回の評価で兼ねようとすると破綻します。お勧めは「統制単位で評価し、上に集約して経営報告、下に展開してガイドライン対応表を作る」という中間粒度で設計する方法です。
2. 基準をどう組み合わせるか
金融機関が参照する主な基準は、それぞれ役割が異なります。
- 金融庁ガイドライン：当局が求める「最低限＋望ましい水準」。対応状況の説明責任に直結
- NIST CSF 2.0：統治（Govern）・特定・防御・検知・対応・復旧の6機能。成熟度の骨格として国際的に通用
- FISC安全対策基準：国内金融機関の実務レベルの統制。設備・運用・技術の具体策
- ISMS（ISO/IEC 27001・27002）：管理策の網羅性。認証取得との整合
実務上の要点は、NIST CSFを骨格に据え、他の基準を「証拠の参照先」として紐づけることです。こうすると、1つの統制を1回評価すれば、ガイドライン対応表もFISC対応表も同じ根拠から生成できます。
3. 評価尺度の設計
尺度は5段階が一般的ですが、重要なのは各段階の定義を「証跡で判定できる言葉」にすることです。
レベル | 定義（例：脆弱性管理） | 必要な証跡 |
|---|---|---|
1 初期 | 場当たり的に対応。手順なし | ― |
2 反復 | 手順は存在するが属人的 | 手順書 |
3 定義 | 手順が文書化され、責任者と頻度が明確 | 規程、実施記録 |
4 管理 | KPIで測定し、逸脱を是正している | 測定結果、是正記録 |
5 最適化 | 測定結果をもとに継続的に改善している | 改善履歴、経営報告 |
「規程がある＝レベル3」で止めず、「実施記録がある」「測定している」まで確認することで、自己申告のインフレを防げます。
4. 証跡とインタビューの進め方
評価の信頼性は証跡の質で決まります。
証跡の3分類
- 設計証跡：規程、手順書、体制図、設定基準
- 運用証跡：実施記録、チケット、ログ、会議体議事録
- 有効性証跡：テスト結果、監査指摘と是正、演習結果
レベル3以上を判定するには、設計証跡だけでなく運用証跡が必要です。レベル4以上には有効性証跡が求められます。
インタビューのコツ
- 「やっていますか」ではなく「直近でいつ、誰が、何をしましたか」と聞く
- 1線（現場）・2線（リスク管理）・3線（内部監査）の三者に同じ質問をし、認識のずれを見る
- 回答が規程の読み上げになったら、実際の記録を見せてもらう
5. Gap分析の考え方
評価結果は「現状レベル」だけでは意味がありません。目標レベルとの差（Gap）を出して初めて施策に変換できます。
目標レベルの置き方には2つの軸があります。
- 外部要求からの目標：ガイドラインの「求められる事項」は最低ラインとして必達、「望ましい事項」は業態・規模に応じて設定
- 自社リスクからの目標：業務影響が大きい領域（勘定系、決済、顧客データ）は高め、影響が限定的な領域は現実的な水準に
Gapが大きい領域が「対策の優先候補」ですが、Gapの大きさだけで順序を決めてはいけません。次回扱う「重要度・依存関係・コスト」の観点が必要です。
6. よくある落とし穴
- 基準の項目数に引きずられる：項目が多い基準ほど重要に見えるが、統制単位に正規化すれば粒度の違いに過ぎない
- 評価者の独立性がない：担当部門の自己評価だけで終えると甘くなる。2線または外部のレビューを入れる
- 一度きりで終わる：翌年に同じ尺度で再評価して初めて「改善したか」が分かる
評価設計チェックリスト（10項目）
- 評価の目的（経営報告／当局対応／計画立案）を明文化したか
- 骨格となる基準（NIST CSF等）を決めたか
- 他基準とのマッピング表を作成したか
- 尺度の各レベルを証跡で判定できる言葉で定義したか
- 証跡を設計・運用・有効性の3分類で収集したか
- 1線・2線・3線にインタビューしたか
- 評価者の独立性を確保したか
- 目標レベルを外部要求と自社リスクの2軸で設定したか
- Gapをヒートマップ等で1枚に可視化したか
- 次回評価の時期と担当を決めたか
まとめ
成熟度評価は「基準を選ぶ」作業ではなく、「経営判断に使える形で現状を測る」設計作業です。次回は、この評価結果を3年間のロードマップとKPI/KRI、経営報告に変換する方法を解説します。
主要出典
- 金融庁「金融分野におけるサイバーセキュリティに関するガイドライン」（2024年10月、2025年7月一部改正）
- NIST「The NIST Cybersecurity Framework (CSF) 2.0」（NIST CSWP 29、2024年2月）
- 公益財団法人金融情報システムセンター（FISC）「金融機関等コンピュータシステムの安全対策基準・解説書」（最新版）
- ISO/IEC 27001:2022、ISO/IEC 27002:2022
本記事は公開情報に基づく一般的な解説です。基準の改訂に応じて定期的に見直します。