統制・実装基準体系への案内

はじめに

この記事は、統制・実装基準シリーズへの案内記事です。基準本文はシリーズ配下の各文書を正とします。

セキュリティ基準を現場へ展開するとき、最も避けるべき設計は、NIST、政府統一基準、金融庁、OWASP、ISO、CIS Controls、PCI DSS、SSDFなどの出典をそのまま横並びにすることです。出典別の整理は監査人やセキュリティ専門家には有用ですが、システムオーナー、インフラ担当、アプリ担当、運用担当、委託先管理担当にとっては、「自分が何を実装し、何を証跡として残し、どのリスクを誰へ上げるべきか」が見えにくくなります。

本ガイドは、チェックリスト中心の運用を、統制目的、実装基準、証跡基準、例外管理、評価報告へ分解するための第1版です。前提にある考え方は、チェックリストを否定することではありません。チェックリストを説明責任の本体にしてはならない、ということです。説明責任の本体は、「いつ、どの資産で、どの統制が、どの証跡により有効と判断されたか」を説明できる状態です。

このガイドでは、次の4つを厳格に分けます。

• 統制目的：何を達成しなければならないか。
• 実装基準：統制目的を満たすため、何を設定、構築、運用しなければならないか。
• 証跡基準：統制が有効であることを、何で、どの鮮度で、誰が示さなければならないか。
• 例外管理：基準を満たせない場合、誰が、どの残余リスクを、いつまで受け入れるか。

関連する考え方は、既存記事のチェックリスト疲弊を超えるセキュリティ説明責任と大企業向けセキュリティ証跡基盤の作り方を前提にしています。本稿はそれらを、実際に文書体系へ落とすためのガイドとして位置付けます。

全体像

この構造で重要なのは、出典文書を本体にしないことです。外部基準や社内規程は、統制目的へ正規化するための入力です。現場へ提示する本体は、統制目的、担当者別実装基準、証跡基準、例外管理でなければなりません。

適用範囲

本ガイドは、企業または組織が保有、開発、運用、利用、委託する情報システムを対象にします。対象には、オンプレミス、クラウド、SaaS、PaaS、IaaS、業務委託、子会社環境、共同利用基盤、AI・データ分析基盤、CI/CD基盤を含めます。

本ガイドは、次の用途に使います。

• 社内セキュリティ基準を、統制目的と実装基準へ分け直す。
• 現場担当者が、自分の担当範囲で実装すべき事項を把握する。
• 統制有効性を、自己申告ではなく証跡で説明できる状態にする。
• 例外を隠さず、リスク受容、期限、代替統制、再評価日を管理する。
• 経営、CISO、2線、内部監査が見る評価指標を定義する。

本ガイドは、特定の規制への完全準拠を単独で保証するものではありません。規制対象業務では、法務、コンプライアンス、監査、業界基準の要求を別途確認し、統制目的カタログと出典マッピングを更新しなければなりません。

用語定義

用語	定義
統制目的	リスクを許容範囲に収めるために達成すべき状態。技術や製品に依存しない。
統制基準	統制目的を組織内で要求事項として定義したもの。適用要否、責任者、評価方法を持つ。
実装基準	統制基準を満たすための設定、設計、運用、レビュー、テスト、承認の要求。環境差を許容する。
証跡基準	統制基準と実装基準が有効であることを示す証跡の種類、取得元、頻度、鮮度、責任者、保存期間の要求。
証跡契約	対象システムが、どの統制目的について、どの証跡を、どの形式と頻度で提供するかを定める合意。
一次証跡	API、ログ、設定、CI/CD、チケット、スキャン結果など、対象システムまたは統制実行元から直接生成される証跡。
補助証跡	スクリーンショット、会議資料、手作業集計など、一次証跡を補足する証跡。主証跡にしてはならない。
例外	基準を満たせない状態を、期限、理由、代替統制、残余リスク、承認者付きで管理するもの。
リスク受容	残余リスクを、定められた権限者が期限付きで受け入れる意思決定。無期限の受容を認めてはならない。
代替統制	要求された実装を満たせない場合に、同等または限定的にリスクを低減する補完策。
共通統制	IdP、EDR、ログ基盤、クラウド標準環境など、複数システムが継承できる統制。
継承統制	システム個別ではなく、共通基盤やSaaS提供者から提供される統制を利用すること。継承範囲の証跡が必要である。

設計原則

基準体系は、次の原則を満たさなければなりません。

1. 統制目的を先に定義し、実装方法を後から割り当てる。
2. 全システムへ同じ実装を強制してはならない。
3. 統制目的は共通化し、証跡の深さはリスクとTierに応じて変える。
4. 自己申告を主証跡にしてはならない。
5. 一次証跡またはシステム生成レポートを標準証跡にする。
6. 例外を禁止してはならない。ただし、無期限、無承認、代替統制なしの例外は認めてはならない。
7. チェックリストは回答収集ではなく、統制目的と証跡要求への索引として扱う。
8. 出典マッピングは本体ではなく付録に置く。
9. 統制不備は、改善計画、リスク登録簿、投資判断へ接続する。
10. 内部監査は、証跡集めの代行者ではなく、証跡品質と例外妥当性の独立評価者として扱う。

これらは、NIST CSF 2.0のGovern機能、NIST SP 800-137の継続的監視、NIST SP 800-53Aの統制評価、NIST SP 800-55の測定、国内の政府統一基準群や金融庁ガイドラインが重視するガバナンス、役割、評価、報告の考え方と整合します。¹²³⁴⁵⁶

避ける分類

次の分類を本体にしてはなりません。これらは補助資料としては有用ですが、現場展開の主導線にすると説明責任が弱くなります。

避ける分類	例	問題
出典別分類	NIST編、OWASP編、金融庁編、ISO編	担当者は自分の作業ではなく、どの文書を読むかを探すことになる。
統制項目の羅列	アクセス制御、ログ管理、脆弱性管理	担当者、証跡、例外判断、評価指標が分離されず、現場で使いにくい。
チェックリスト単体	MFAを有効化しているか、ログを取得しているか	証跡品質、鮮度、責任者、例外判断が抜け、自己申告運用へ戻る。
技術レイヤー単体	ネットワーク、サーバ、DB、アプリ	SaaS、PaaS、委託先、AI、CI/CDなど境界をまたぐ対象を扱いにくい。
ツール別分類	EDR編、CSPM編、SIEM編、SCA編	ツール未導入環境や外部委託環境が例外化し、統制目的が見えなくなる。

本体は、統制目的を中心に置きます。担当者別の導線を用意し、実装基準と証跡基準へ落とします。出典文書は、最後に「なぜその要求があるか」を説明する付録として扱います。

文書体系

完成形では、文書体系を次のように分けます。最初から全ファイルを作る必要はありませんが、文書境界は初期段階で定義しなければなりません。境界を曖昧にすると、後からチェックリスト、規程、証跡台帳、監査資料が重複します。

番号	文書	役割
00	全体原則ガイド	統制目的中心、証跡中心、例外管理、責任分担の原則を定義する。
01	システム分類・適用判定ガイド	Tier、外部依存、AI・データ利用、法規制、業務影響により適用深度を決める。
02	統制目的カタログ	出典文書を自社共通言語へ正規化した統制目的を管理する。
03A	システムオーナー向け実装基準	重要度、データ分類、リスク受容、例外、改善計画、委託先責任を扱う。
03B	インフラ・基盤担当向け実装基準	資産、構成、ネットワーク、パッチ、バックアップ、暗号化、管理経路を扱う。
03C	アプリ・開発担当向け実装基準	設計、認可、入力検証、CI/CD、依存関係、リリース、SBOMを扱う。
03D	運用・監視担当向け実装基準	ログ監視、アラート、変更管理、作業承認、インシデント初動を扱う。
03E	外部サービス・委託先管理向け実装基準	SaaS、委託先、契約、再委託、監査報告、解約時削除を扱う。
04	証跡基準ガイド	証跡種別、取得元、鮮度、改ざん耐性、保存期間、証跡レジストリを定義する。
05	例外・リスク受容ガイド	例外ID、理由、代替統制、残余リスク、期限、承認者、再評価日を定義する。
06	評価・報告ガイド	KPI、KRI、経営報告、2線モニタリング、内部監査観点を定義する。
90	出典マッピング	NIST、政府統一基準、金融庁、OWASP、ISO、CIS、PCI DSS、SSDF等との対応を持つ。
91	証跡テンプレート集	証跡契約、例外申請、アクセスレビュー、復元試験、委託先評価の様式を持つ。
92	チェックリスト索引	従来チェック項目を統制目的ID、実装基準、証跡基準へ接続する。

文書番号90番台は付録です。現場担当者が最初に読む文書にしてはなりません。

システム分類と適用深度

システム分類は、統制の強度と証跡の鮮度を決めるために使います。全システムへ同じ深さの証跡を求めることは、重要システムの証跡品質を下げ、低リスクシステムに過剰負荷をかけます。

分類	対象例	要求水準
Tier 0	IdP、認証基盤、鍵管理、ネットワーク中核、監視基盤、CI/CD基盤、端末管理基盤	最重要。一次証跡中心、短い鮮度SLA、共通統制としての継承証跡、経営報告対象。
Tier 1	基幹、決済、顧客情報、規制対象、重要業務、社会的影響が大きいシステム	高水準。統制目的を広く適用し、例外はCISOまたはリスク委員会へ上げる。
Tier 2	部門業務、社内利用アプリ、標準的なクラウドアプリ	標準水準。主要統制を適用し、証跡は月次またはイベント時に取得する。
Tier 3	小規模ツール、限定利用、機微情報なし、業務影響が限定的な補助システム	軽量水準。所有者、利用者範囲、データ分類、ID管理、終了手順は必須。
External	SaaS、委託先運用、子会社、共同利用基盤、外部接続	責任分界を明示し、契約、監査報告、設定証跡、アクセス範囲、削除証跡を求める。
AI/Data	生成AI、機械学習、データ分析基盤、モデル利用、プロンプト管理	データ、モデル、利用目的、出力、人間承認、外部送信、ログを統制対象にする。

分類は一度決めて終わりではありません。データ種別、外部公開、利用者範囲、委託先、法規制、業務影響、AI利用が変わった場合は再判定しなければなりません。

統制目的カタログ第1版

統制目的カタログは、実装技術ではなく達成すべき状態を定義します。下表は第1版として、現場展開に必要な主要領域を網羅したものです。組織固有の法規制、業界要求、顧客契約がある場合は、統制目的IDを追加するのではなく、まず既存IDへマッピングできるかを確認します。重複を安易に増やしてはなりません。

ガバナンス

ID	統制目的	主担当	代表証跡
G-01	セキュリティ責任、権限、報告経路を明確にする。	経営、CISO	組織規程、RACI、委員会議事録
G-02	リスク許容度と例外承認権限を定義する。	経営、リスク管理	リスク基準、例外承認規程、委任表
G-03	システムの重要度と適用基準を決定する。	システムオーナー	システム分類記録、影響度評価
G-04	統制不備を改善計画と投資判断へ接続する。	CISO、システムオーナー	改善計画、予算要求、進捗報告
G-05	共通統制と個別統制の責任境界を定義する。	CISO、共通基盤担当	共通統制一覧、継承証跡
G-06	内部監査が証跡品質と例外妥当性を独立評価できる状態にする。	内部監査	監査計画、サンプリング記録、指摘管理

資産管理

ID	統制目的	主担当	代表証跡
A-01	システム、資産、所有者、利用目的を把握する。	システムオーナー	システム台帳、資産台帳
A-02	サーバ、クラウド資源、端末、コンテナ、DBを識別する。	インフラ担当	CMDB、クラウド資産一覧、EDR一覧
A-03	データ種別、保管場所、処理目的を識別する。	データ担当、システムオーナー	データ分類表、DPIA、データフロー
A-04	外部接続、委託先、SaaS、API連携を把握する。	委託先管理担当	外部依存台帳、接続一覧
A-05	所有者不明、管理外、棚卸し未了の資産を検知し是正する。	インフラ担当、運用担当	不明資産レポート、是正チケット

ID・アクセス管理

ID	統制目的	主担当	代表証跡
I-01	利用者IDを本人、雇用状態、委託契約、利用目的と結び付ける。	ID担当、人事連携担当	IdPユーザー一覧、人事連携ログ
I-02	管理者と特権IDを通常IDから分離し、利用を最小化する。	ID担当、インフラ担当	特権ID一覧、PAMログ
I-03	MFAを利用者、管理者、外部委託IDへリスクに応じて適用する。	ID担当	MFA設定、例外一覧
I-04	権限付与、変更、削除を承認制にする。	システムオーナー、ID担当	権限申請、承認履歴
I-05	退職、異動、契約終了時にIDと権限を期限内に削除する。	ID担当、運用担当	無効化ログ、棚卸し結果
I-06	定期的にアクセスレビューを実施し、不要権限を削除する。	システムオーナー	レビュー記録、削除チケット
I-07	機械ID、APIキー、サービスアカウント、シークレットを管理する。	アプリ担当、インフラ担当	シークレット台帳、ローテーション履歴

境界・ネットワーク防御

ID	統制目的	主担当	代表証跡
P-01	外部公開面を把握し、不要な公開を禁止する。	インフラ担当	外部公開資産一覧、ASM結果
P-02	管理経路を分離し、直接インターネット公開を禁止する。	インフラ担当	ネットワーク構成、VPN/ZTNA設定
P-03	必要な通信だけを許可し、通信経路を記録する。	インフラ担当	FWルール、Security Group、変更履歴
P-04	Web/APIの公開面に防御、監視、レート制御を適用する。	アプリ担当、インフラ担当	WAF設定、API Gateway設定
P-05	DNS、証明書、ドメイン、外部公開設定を管理する。	インフラ担当	DNS台帳、証明書一覧、更新履歴

構成管理

ID	統制目的	主担当	代表証跡
C-01	OS、ミドルウェア、クラウド、SaaSの安全な構成基準を定める。	インフラ担当、SaaS管理担当	ベースライン、CSPMポリシー
C-02	構成変更を承認、記録、レビューする。	運用担当	変更申請、IaC履歴、承認ログ
C-03	構成逸脱を検知し、期限内に是正する。	インフラ担当	CSPM結果、ドリフト検知、修正チケット
C-04	時刻同期、証明書、暗号設定、名前解決を標準化する。	インフラ担当	NTP設定、TLS設定、証明書管理
C-05	コンテナ、Kubernetes、サーバレスの実行設定を制御する。	インフラ担当、アプリ担当	クラスタ設定、Admissionログ

脆弱性管理

ID	統制目的	主担当	代表証跡
V-01	重要資産の脆弱性を検出し、リスクに応じて期限内に是正する。	インフラ担当、アプリ担当	スキャン結果、修正チケット
V-02	認証付きスキャン、エージェント、SCA、DASTを対象に応じて使い分ける。	セキュリティ部門、各担当	スキャン設定、実行結果
V-03	重大度、悪用可能性、露出度、業務影響で優先順位を決める。	セキュリティ部門	優先度判定、SLA表
V-04	期限内に修正できない脆弱性を例外管理へ接続する。	システムオーナー	例外申請、代替統制
V-05	再スキャンまたは代替検証により是正完了を確認する。	運用担当、アプリ担当	再スキャン結果、検証記録

ログ・監視

ID	統制目的	主担当	代表証跡
L-01	重要イベントを取得し、調査可能な形式で保全する。	運用担当	ログ源一覧、SIEM転送設定
L-02	認証、特権操作、設定変更、データアクセス、外部通信を監視対象にする。	運用担当、ID担当	監視ルール、検知履歴
L-03	ログの時刻同期、欠損、保持期間、改ざん耐性を管理する。	運用担当	時刻同期設定、欠損レポート
L-04	アラートの一次対応、エスカレーション、調査記録を残す。	運用担当	アラートチケット、調査記録
L-05	監視対象外の重要資産を検知し、是正する。	運用担当	ログ未収集一覧、是正チケット

バックアップ・復旧

ID	統制目的	主担当	代表証跡
R-01	重要データと重要システムを復旧可能な状態に保つ。	インフラ担当、システムオーナー	バックアップ設計、ジョブ結果
R-02	RTO、RPO、保存世代、隔離、暗号化を定義する。	システムオーナー	復旧要件、バックアップ設定
R-03	バックアップの成功、失敗、遅延を監視する。	運用担当	ジョブレポート、アラート
R-04	復元試験を実施し、結果と改善事項を記録する。	インフラ担当、運用担当	復元試験記録、改善チケット
R-05	ランサムウェアや破壊に備え、改ざん困難なバックアップを確保する。	インフラ担当	WORM設定、隔離設定

データ保護

ID	統制目的	主担当	代表証跡
D-01	データ分類に応じて保存、利用、共有、削除を管理する。	データ担当、システムオーナー	データ分類表、共有設定
D-02	個人情報、機密情報、決済情報、規制対象データを識別する。	データ担当	データ台帳、DLP結果
D-03	保存時と通信時の暗号化を適用し、鍵を管理する。	インフラ担当	KMS設定、TLS設定
D-04	データ持ち出し、外部共有、ダウンロードを制御する。	SaaS管理担当、運用担当	DLPログ、共有リンク一覧
D-05	保存期間と削除期限を定義し、削除証跡を残す。	システムオーナー、法務	保持ポリシー、削除記録
D-06	本番データの開発・検証利用を制御する。	アプリ担当、データ担当	マスキング記録、利用承認

セキュア開発

ID	統制目的	主担当	代表証跡
S-01	企画、要件、設計、実装、テスト、リリースにセキュリティを組み込む。	アプリ担当	SDLC定義、レビュー記録
S-02	脅威モデリングまたはリスクレビューを実施する。	アプリ担当、セキュリティ部門	脅威モデル、設計レビュー
S-03	認証、認可、入力検証、セッション、エラー処理を安全に実装する。	アプリ担当	コードレビュー、テスト結果
S-04	SAST、SCA、DAST、IaCスキャンをCI/CDへ組み込む。	アプリ担当、基盤担当	CI/CD結果、スキャン結果
S-05	依存ライブラリ、OSS、コンテナイメージ、SBOMを管理する。	アプリ担当	SBOM、SCA結果
S-06	シークレットをコード、ログ、成果物へ混入させない。	アプリ担当	シークレットスキャン結果
S-07	リリース承認、署名、ビルド証明、ロールバック手順を管理する。	アプリ担当、運用担当	リリース承認、署名ログ

サプライチェーン

ID	統制目的	主担当	代表証跡
T-01	委託先、SaaS、製品、OSS、外部接続のリスクを評価する。	委託先管理担当	委託先評価、リスク評価
T-02	契約にセキュリティ要求、監査権、通知義務、削除義務を含める。	調達、法務	契約書、覚書
T-03	再委託、オフショア、サポートアクセスを把握する。	委託先管理担当	再委託一覧、アクセス記録
T-04	SaaSの顧客側設定、ID連携、権限、ログを管理する。	SaaS管理担当	設定エクスポート、権限一覧
T-05	委託先の監査報告、認証、是正状況を定期確認する。	委託先管理担当	SOC報告書、ISO証明、是正計画
T-06	解約、移管、契約終了時にデータ返却、削除、アクセス停止を確認する。	委託先管理担当	削除証明、停止記録

人的運用

ID	統制目的	主担当	代表証跡
H-01	役割に応じた教育、周知、訓練を実施する。	人材、セキュリティ部門	受講記録、訓練結果
H-02	作業承認、職務分掌、相互牽制を定義する。	運用担当、システムオーナー	作業申請、承認記録
H-03	委託先要員の入退場、教育、アクセス権を管理する。	委託先管理担当	要員台帳、権限棚卸し
H-04	特権作業、緊急作業、例外作業の記録を残す。	運用担当	作業ログ、緊急変更記録

インシデント対応

ID	統制目的	主担当	代表証跡
E-01	インシデントの検知、報告、判断、封じ込め、復旧の手順を定義する。	セキュリティ部門、運用担当	対応手順、連絡網
E-02	重要システム、委託先、SaaS、法務、広報との連携手順を持つ。	システムオーナー、法務	連携手順、契約上の通知条件
E-03	インシデントチケットに時系列、判断、証跡、影響範囲を記録する。	運用担当	インシデントチケット
E-04	机上演習、技術演習、復旧演習を実施する。	セキュリティ部門	演習記録、改善計画
E-05	再発防止策を統制カタログ、証跡基準、実装基準へ反映する。	CISO、各担当	再発防止策、基準改定履歴

AI・自動化統制

ID	統制目的	主担当	代表証跡
AI-01	AI利用目的、利用者、対象データ、モデル、外部送信を把握する。	システムオーナー、データ担当	AI利用台帳、モデル台帳
AI-02	機密情報、個人情報、規制対象データのAI入力を制御する。	データ担当、SaaS管理担当	DLPログ、利用承認
AI-03	AI出力の利用範囲、人間承認、誤用時の責任を定義する。	システムオーナー	承認記録、業務ルール
AI-04	AIエージェント、自動化ID、連携ツールの権限を最小化する。	ID担当、アプリ担当	機械ID一覧、権限設定
AI-05	プロンプト、モデル設定、評価結果、出力監視を必要に応じて記録する。	アプリ担当、データ担当	評価ログ、プロンプト管理記録

担当者別実装基準

担当者別実装基準は、統制目的カタログを現場の作業へ落とすための導線です。担当者別に見せる理由は、責任を分断するためではありません。各担当者が、自分の責任範囲、他者へ依頼すべき事項、例外時に上げるべき相手を理解するためです。

システムオーナーの実装責任

システムオーナーは、技術実装のすべてを直接行う必要はありません。ただし、重要度、利用データ、業務影響、例外、リスク受容、委託先責任を他者へ丸投げしてはなりません。

領域	実装基準	接続する統制目的
システム分類	Tier、外部依存、AI/Data該当性、規制対象性を判定する。	G-03、A-01
データ分類	扱うデータ種別、保存場所、外部共有、削除要件を記録する。	A-03、D-01、D-02
責任定義	Owner ID、運用責任者、委託先責任者、例外承認者を定義する。	G-01、G-05
リスク受容	期限、代替統制、残余リスク、承認者なしに例外を認めない。	G-02、V-04
改善計画	重大不備を期限付き改善計画へ落とし、投資判断へ上げる。	G-04
アクセスレビュー	権限レビューを承認し、不要権限削除を完了させる。	I-04、I-06
復旧要件	RTO、RPO、復元試験頻度を決め、未達を受容する場合は承認する。	R-01、R-02、R-04
委託先責任	SaaS、委託先、再委託の責任分界を確認する。	T-01、T-02、T-03

システムオーナーの主証跡は、システム台帳、データ分類表、リスク評価記録、例外承認記録、改善計画、委託契約、SLA、委託先監査報告、業務影響度評価です。

インフラ・基盤担当の実装責任

インフラ・基盤担当は、資産、構成、ネットワーク、OS、ミドルウェア、クラウド、DB、コンテナ、鍵、バックアップ、管理経路を統制します。個別システムだけでなく、共通統制として他システムへ継承される証跡を提供しなければなりません。

領域	実装基準	接続する統制目的
資産識別	クラウド資源、サーバ、DB、コンテナ、端末をAsset IDで管理する。	A-02
安全な構成	CIS Benchmark等を参考にベースラインを定義し、逸脱を検知する。	C-01、C-03
ネットワーク	外部公開、管理経路、通信許可、DNS、証明書を管理する。	P-01、P-02、P-03、P-05
パッチ	OS、ミドルウェア、DB、コンテナイメージの脆弱性を期限内に是正する。	V-01、V-03
暗号・鍵	KMS、証明書、TLS、鍵ローテーション、権限分離を管理する。	D-03、C-04
バックアップ	保存世代、隔離、暗号化、復元試験を実装する。	R-01、R-03、R-04、R-05
管理者アクセス	特権ID分離、PAM、MFA、管理ログを実装する。	I-02、I-03、L-02
共通証跡	共通基盤を利用するシステムへ継承統制の証跡を提供する。	G-05、L-01

主証跡は、クラウド資産一覧、CSPM結果、IaC履歴、構成エクスポート、脆弱性スキャン結果、パッチ適用履歴、バックアップジョブ結果、復元試験記録、管理者アクセスログです。

アプリ・開発担当の実装責任

アプリ・開発担当は、要件、設計、コード、API、認可、入力検証、依存関係、CI/CD、リリースを統制します。セキュリティレビューを後工程の承認イベントにしてはなりません。企画、設計、実装、テスト、リリース、運用へ組み込む必要があります。NIST SSDFやデジタル庁のセキュリティ・バイ・デザイン、CI/CD関連資料はこの考え方の参照先になります。⁷⁸⁹

領域	実装基準	接続する統制目的
設計	脅威モデリング、認可設計、データフロー、外部連携をレビューする。	S-01、S-02、D-01
認証・認可	認証は標準IdPを使い、認可はサーバ側で強制する。	I-01、S-03
入力・出力	入力検証、出力エンコード、エラー制御、ログ秘匿を実装する。	S-03、D-04
依存関係	SCA、SBOM、ライセンス、脆弱性通知を管理する。	S-05、T-01
CI/CD	SAST、SCA、IaCスキャン、シークレットスキャンを組み込む。	S-04、S-06
リリース	承認、署名、ビルド証明、ロールバック手順を管理する。	S-07
API	認可、レート制御、監査ログ、外部公開面を管理する。	P-04、L-02
AI実装	AI入力、プロンプト、モデル設定、出力利用、人間承認を管理する。	AI-01、AI-02、AI-03、AI-05

主証跡は、設計レビュー記録、脅威モデリング記録、コードレビュー履歴、SAST/SCA/DAST結果、SBOM、CI/CD実行結果、シークレットスキャン結果、リリース承認履歴、脆弱性修正チケットです。

運用・監視担当の実装責任

運用・監視担当は、日々の監視、アラート、変更、作業承認、インシデント初動、定期点検、復旧対応の証跡を残します。運用手順が存在するだけでは不十分です。手順が実行され、失敗が検知され、エスカレーションされ、改善に接続されたことを示さなければなりません。

領域	実装基準	接続する統制目的
ログ収集	重要ログ源を定義し、SIEM等へ転送し、欠損を監視する。	L-01、L-03、L-05
アラート対応	一次対応、重大度判定、エスカレーション、クローズ条件を定義する。	L-04、E-01
変更管理	変更申請、承認、実施、戻し、事後確認を記録する。	C-02、H-02
作業管理	特権作業、緊急作業、委託先作業を承認制にする。	H-02、H-04
定期点検	バックアップ、監視、証明書、ジョブ、ログ転送を点検する。	R-03、C-04
インシデント	時系列、判断、証跡、影響範囲、復旧をチケットに記録する。	E-03
復旧	復元試験、障害復旧、DR手順の結果を記録する。	R-04、E-04
証跡保全	証跡の保管場所、保存期間、改ざん耐性を管理する。	L-03

主証跡は、監視アラート履歴、インシデントチケット、変更申請、作業承認、作業ログ、定期点検結果、復旧対応記録、エスカレーション記録、再発防止策です。

外部サービス・委託先管理担当の実装責任

外部サービス・委託先管理担当は、SaaS、クラウドサービス、業務委託、再委託、契約、監査報告、サービス停止、データ持ち出し、解約時削除を統制します。クラウドやSaaSでは責任共有モデルが前提であり、提供者が基盤を保護していても、顧客側のデータ、ID、設定、アクセス管理、ログ確認は残ります。¹⁰¹¹

領域	実装基準	接続する統制目的
委託先評価	契約前に情報セキュリティ、可用性、再委託、事故対応を評価する。	T-01
契約要求	通知義務、監査権、削除義務、再委託、SLA、ログ提供を契約に含める。	T-02
SaaS設定	MFA、IdP連携、権限、共有、ログ、外部アプリ連携を管理する。	T-04、I-03、D-04
監査報告	SOC報告書、ISO認証、ISMAP、脆弱性対応、是正状況を確認する。	T-05
再委託	再委託先、国、サポートアクセス、オフショア運用を把握する。	T-03
データ終了処理	解約、移管、契約終了時に返却、削除、アクセス停止を証跡化する。	T-06、D-05
インシデント連携	通知期限、連絡先、証跡提供、共同調査範囲を定義する。	E-02
外部依存台帳	SaaS、委託先、外部API、子会社環境をSystem IDへ結び付ける。	A-04

主証跡は、委託先評価票、契約書、覚書、SOC報告書、ISMAPやISO等の認証情報、SaaS設定エクスポート、アクセス権限一覧、退職・異動・解約時の削除記録、インシデント通知記録、定期レビュー記録です。

証跡基準

証跡基準は、この体系の中心です。統制を実装していても、説明できなければ統制有効とは扱えません。証跡基準は、統制目的ごとに、対象、取得元、鮮度、責任者、評価方法、例外時の扱いを定義します。

証跡メタデータ

証跡には、少なくとも次のメタデータを持たせます。

項目	必須内容
統制目的ID	どの統制目的に対する証跡か。
System ID	どのシステムに関する証跡か。
Asset ID	どの資産、アカウント、データ、設定に関する証跡か。
証跡ソース	API、ログ、スキャン、CI/CD、チケット、契約、監査報告など。
証跡形式	JSON、CSV、PDF、ログイベント、チケット、設定エクスポートなど。
取得時刻	証跡が生成または取得された時刻。
鮮度SLA	日次、週次、月次、四半期、イベント時など。
生成元	システム、ツール、委託先、担当者、承認者。
完全性	対象範囲、欠損、未収集、対象外の有無。
改ざん耐性	署名、ハッシュ、WORM、原本リンク、アクセス制御。
責任者	証跡を生成、確認、評価する責任者。
評価方法	自動判定、目視レビュー、サンプリング、監査テストなど。
例外処理	不合格、未収集、対象外の場合の例外ID。
保存期間	監査、法務、契約、インシデント調査に必要な期間。

証跡信頼度

証跡は信頼度で分類しなければなりません。証跡の信頼度を定義しない場合、スクリーンショットや自己申告が主証跡に混入し、統制有効性の説明が崩れます。

Level	分類	例	扱い
Level 1	一次証跡	API取得ログ、クラウド設定、IdPログ、EDRログ、CI/CD実行結果、スキャン結果、チケット履歴	主証跡にする。
Level 2	システム生成レポート	CSPMレポート、脆弱性診断レポート、SBOM、アクセスレビュー出力、バックアップジョブレポート	主証跡または準主証跡にする。生成元と版数を保持する。
Level 3	補助証跡	スクリーンショット、台帳転記、手作業集計、会議資料	補助に限定する。一次証跡へのリンクを併記する。
Level 4	自己申告	チェックリスト回答、メール回答、監査前メモ	統制有効性の主証跡にしてはならない。説明補足に限定する。

原則として、Tier 0とTier 1ではLevel 1またはLevel 2を主証跡にしなければなりません。Level 3またはLevel 4しか存在しない場合は、証跡不備として例外管理へ登録します。

鮮度と保存

証跡の鮮度は、統制目的とシステム分類に応じて定義します。古い証跡は、存在していても統制有効性を示しません。

統制領域	Tier 0/1	Tier 2	Tier 3
資産管理	日次から週次	月次	四半期
特権ID	日次から週次	月次	四半期
脆弱性	継続または週次	月次	四半期または変更時
ログ転送	継続監視	継続または日次	月次確認
バックアップ	日次確認、定期復元試験	日次または週次確認	月次確認
アクセスレビュー	四半期以上	半期以上	年次以上
委託先証跡	四半期以上、重大変更時	年次以上	契約更新時

保存期間は、法令、契約、監査、インシデント調査、個人情報保護の要件に基づき定義します。保存期間が長いほど良いわけではありません。保存目的、閲覧権限、削除条件を定義しなければなりません。

改ざん耐性

重要証跡は、生成後に都合よく修正できる状態にしてはなりません。次のいずれかを適用します。

• 原本システムへのリンクを保持する。
• ハッシュ、署名、タイムスタンプを付与する。
• WORM、オブジェクトロック、監査ログ付きストレージを使う。
• 証跡閲覧権限と削除権限を分離する。
• 証跡レジストリに取得時刻、取得者、評価結果を残す。

監査前に手作業で作ったPDFやスクリーンショットは、改ざん耐性のある証跡とは扱いません。

標準フォーマット例

各統制目的は、次の形式で管理します。これは文書の書式であると同時に、証跡レジストリやGRC基盤へ登録するデータ項目の原型です。

項目	記載例
統制目的ID	V-01
統制目的	重要資産の脆弱性を検出し、リスクに応じて期限内に是正する。
主担当	インフラ担当、アプリ担当
関係者	システムオーナー、運用担当、セキュリティ部門
適用対象	Tier 0、Tier 1、Tier 2。Tier 3は変更時または四半期確認。
実装基準	認証付きスキャンを実施する。SCAをCI/CDへ組み込む。重大度と露出度に基づく修正期限を定める。
証跡基準	スキャン結果、SCA結果、修正チケット、例外承認記録、再スキャン結果。
評価指標	認証付きスキャン率、重大脆弱性SLA内是正率、期限切れ例外数。
例外条件	業務影響により即時修正できない。ベンダー修正版が未提供。代替統制が有効。
参照元	NIST CSF、NIST SP 800-53A、政府統一基準群、OWASP ASVS、CIS Controls。

この形式を採用すると、「何を達成するか」「誰が実装するか」「何を証跡にするか」「どう評価するか」「できない場合に誰が受け入れるか」が同じ項目内でつながります。

例外管理とリスク受容

例外は悪ではありません。例外を隠すことが悪です。基準を満たせないシステムは必ず存在します。重要なのは、例外を「未対応のまま放置する状態」ではなく、「期限付きで管理されたリスク受容」にすることです。

例外には、少なくとも次の項目を持たせます。

項目	必須内容
例外ID	一意に追跡できるID。
対象システム	System ID、システム名、Owner ID。
対象統制	統制目的ID、実装基準、証跡基準。
例外理由	なぜ基準を満たせないか。技術、業務、契約、費用、期限を分ける。
代替統制	リスクを低減する補完策。ない場合は明示する。
残余リスク	代替統制後に残る影響、発生可能性、悪用可能性。
期限	恒久対応または再評価までの期限。無期限は禁止する。
再評価日	状況変化、契約更新、次回リリース、ベンダー修正予定に合わせる。
承認者	承認権限を持つ者。担当者本人の自己承認は禁止する。
リスク受容者	残余リスクを事業上受け入れる者。
経営報告要否	Tier 0/1、重大リスク、期限切れは報告対象にする。
恒久対応方針	解消、代替継続、移行、廃止、投資判断のいずれか。

次の例外は認めてはなりません。

• 期限がない例外。
• 承認者とリスク受容者が不明な例外。
• 代替統制がないのに、残余リスクが評価されていない例外。
• Tier 0またはTier 1で、経営報告要否が未判定の例外。
• 監査前に発見された不備を、事後的に例外として処理するだけの運用。

評価・報告

評価・報告は、「チェックしたか」ではなく、「統制が効いていると説明できるか」を主語にします。準拠率だけを報告してはなりません。準拠率は、証跡品質、鮮度、重要度、例外、再指摘率を隠すためです。

指標	意味	主な利用者
重要システム証跡契約率	Tier 0/1に証跡契約がある割合。	経営、CISO
System ID付与率	全システムが台帳と証跡へ接続できる割合。	CISO、運用
Owner ID付与率	責任者不明システムを減らせているか。	経営、システムオーナー
一次証跡比率	自己申告やスクリーンショット依存を下げているか。	CISO、内部監査
証跡鮮度SLA遵守率	古い証跡で判断していないか。	2線、内部監査
重大脆弱性SLA内是正率	期限内に重大脆弱性を是正できているか。	CISO、システムオーナー
特権IDレビュー完了率	特権権限を定期的に見直しているか。	ID担当、監査
ログ取得カバレッジ	重要ログ源が収集、保全、監視されているか。	運用、SOC
バックアップ復元試験成功率	復旧可能性を実際に検証しているか。	システムオーナー、運用
例外滞留日数	例外が長期放置されていないか。	経営、CISO
期限切れ例外数	リスク受容期限を過ぎた例外がないか。	経営、リスク管理
監査再指摘率	同じ不備が繰り返されていないか。	内部監査、CISO
委託先証跡更新率	外部依存の証跡が期限内に更新されているか。	委託先管理担当
共通統制継承率	共通基盤の統制を各システムが利用できているか。	CISO、共通基盤担当

評価結果は、重大不備、期限切れ例外、重要システムの証跡欠損、外部依存の未確認をリスク登録簿へ接続します。リスク登録簿へ接続しないKPIは、経営判断に使われにくくなります。

チェックリストの扱い

チェックリストは廃止しません。ただし、役割を変えます。

従来の役割	今後の役割
はい、いいえを回答する。	統制目的IDを探す索引にする。
スクリーンショットを添付する。	必要な証跡基準へ誘導する。
監査前に集計する。	平時の証跡レジストリへ接続する。
自己申告で完了扱いにする。	一次証跡または例外承認へ接続する。

チェックリスト項目は、次のように変換します。

従来質問	変換後
MFAを有効化しているか。	I-03に対応。対象利用者、管理者、外部委託ID、例外ID、IdP設定証跡を確認する。
ログを取得しているか。	L-01からL-05に対応。ログ源、転送先、欠損、保持、監視ルール、調査記録を確認する。
脆弱性診断を実施しているか。	V-01からV-05に対応。対象範囲、認証付きスキャン、SCA、修正SLA、例外、再スキャンを確認する。
バックアップを取得しているか。	R-01からR-05に対応。RTO/RPO、ジョブ結果、隔離、復元試験、失敗時対応を確認する。
委託先は安全か。	T-01からT-06に対応。責任分界、契約要求、監査報告、再委託、解約時削除を確認する。

チェックリストは入口です。回答を集める道具として主運用にしてはなりません。

導入ロードマップ

第1版を導入する場合、次の順序で進めます。最初から巨大なGRC基盤を構築してはなりません。まず、統制目的、ID、証跡契約、例外管理を揃えます。

段階	期間目安	実施内容	成果物
Phase 0	0から1か月	既存チェックリスト、規程、監査指摘、主要出典を棚卸しする。	要求一覧、重複整理
Phase 1	1から2か月	統制目的カタログ、システム分類、担当者別実装基準を確定する。	統制目的カタログ、Tier基準
Phase 2	2から4か月	Tier 0/1と代表的なTier 2で証跡契約を作る。	証跡契約、証跡メタデータ定義
Phase 3	4から6か月	資産、ID、脆弱性、ログ、バックアップ、セキュア開発から証跡収集を始める。	証跡レジストリ、初期KPI
Phase 4	6から12か月	例外管理、リスク登録簿、経営報告、内部監査観点を接続する。	例外台帳、リスク報告、監査手続
Phase 5	12か月以降	SaaS、委託先、AI/Data、サプライチェーン、共通統制継承へ広げる。	外部依存証跡、AI台帳、共通統制証跡

最初に重点化する領域は、資産管理、ID・アクセス管理、脆弱性管理、ログ・監視、バックアップ・復旧、セキュア開発です。この6領域は、多くの主要基準に共通して現れ、事故時の説明責任にも直結します。

出典マッピング付録

出典マッピングは本体ではありません。ただし、監査、規制、顧客説明、社内規程との整合を示すために必要です。第1版では、次のように役割を分けて参照します。

出典	主な使い方
NIST CSF 2.01	Governを含む全体構造、リスク管理、統制目的の上位整理に使う。
NIST SP 800-3712	RMF、共通統制、継続監視、組織レベルとシステムレベルの接続に使う。
NIST SP 800-53A3	統制評価、評価手続、証跡品質、評価方法の設計に使う。
NIST SP 800-554	KPI、測定値、報告指標の設計に使う。
NIST SP 800-1372	継続的監視、証跡鮮度、統制有効性の可視化に使う。
NIST SSDF7	セキュア開発、CI/CD、依存関係、リリース統制に使う。
政府統一基準群5	国内組織の規程、PDCA、教育、監査、報告、対策基準の参照に使う。
デジタル庁DS-2008	セキュリティ・バイ・デザイン、企画から運用までの実装に使う。
デジタル庁DS-2029	CI/CD、開発基盤、シークレット、パイプライン保護に使う。
デジタル庁DS-20313	サプライチェーン、責任分界、委託先との協力、継続監視に使う。
金融庁ガイドライン6	経営関与、CISO、業務部門責任者、KPI/KRI、サードパーティリスクに使う。
OWASP ASVS14	Webアプリの認証、認可、入力検証、セッション、API、ログ等の実装基準に使う。
CIS Controls15	資産管理、脆弱性管理、構成管理、ログ、アクセス制御などの実装項目に使う。
ISO/IEC 27001・270021617	ISMS要求事項と情報セキュリティ管理策の参照に使う。
PCI DSS18	カード会員データ環境、決済情報、ログ、アクセス制御、脆弱性管理の規制要求に使う。

マッピングは、統制目的IDを起点に作ります。出典文書の章番号を主キーにしてはなりません。

まとめ

セキュリティ基準の本体は、出典文書の横並びでも、チェックリストの回答欄でもありません。本体にすべきものは、統制目的、担当者別の実装基準、証跡基準、例外管理、評価報告です。

このガイドの要点は次の通りです。

• 統制目的を共通化し、実装方法と証跡取得方法はシステム特性に応じて許容する。
• 担当者には、出典文書ではなく、自分の責任範囲、実装基準、証跡基準を見せる。
• 証跡は説明責任の本体であり、自己申告を主証跡にしてはならない。
• 例外は隠さず、期限、代替統制、残余リスク、承認者、リスク受容者を持たせる。
• 評価報告は、準拠率ではなく、証跡品質、鮮度、是正速度、例外滞留、再指摘で行う。

この形に再構成すると、担当者は「何を守るべきか」「何を実装すべきか」「何を証跡として残すべきか」「誰が説明できる状態にすべきか」を分けて理解できます。結果として、チェックリスト疲弊を抑えながら、経営、2線、内部監査、現場が同じ言葉で統制有効性を確認できる状態に近づきます。

参考資料（出典）

Footnotes

1. NIST, The NIST Cybersecurity Framework (CSF) 2.0（Web/PDF, 2024年2月26日）。Govern機能を含むサイバーセキュリティリスク管理の枠組み。https://www.nist.gov/publications/nist-cybersecurity-framework-csf-20 ↩ ↩²

2. NIST, SP 800-137: Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations（Special Publication, 2011年9月）。資産、脅威・脆弱性、統制有効性の継続的可視化を扱う。https://csrc.nist.gov/pubs/sp/800/137/final ↩ ↩²

3. NIST, SP 800-53A Rev.5: Assessing Security and Privacy Controls in Information Systems and Organizations（Special Publication, 2022年1月）。統制評価の方法論を示す。https://csrc.nist.gov/pubs/sp/800/53/a/r5/final ↩ ↩²

4. NIST, SP 800-55 Vol.1: Measurement Guide for Information Security（Special Publication, 2008年7月）。情報セキュリティ測定値の識別、選定、活用を扱う。https://csrc.nist.gov/pubs/sp/800/55/v1/final ↩ ↩²

5. 国家サイバー統括室, 政府機関等のサイバーセキュリティ対策のための統一基準群（Web）。政府機関等向けの統一規範、統一基準、対策基準策定ガイドライン等を掲載。https://www.cyber.go.jp/policy/group/general/kijun.html ↩ ↩²

6. 金融庁, 金融分野におけるサイバーセキュリティに関するガイドライン（PDF, 2024年10月4日）。経営陣の関与、CISO、業務部門責任者、KPI/KRI、サードパーティリスク管理を整理。https://www.fsa.go.jp/common/law/cybersecurity_guideline.pdf ↩ ↩²

7. NIST, SP 800-218: Secure Software Development Framework (SSDF) Version 1.1（Special Publication, 2022年2月）。安全なソフトウェア開発慣行を整理。https://csrc.nist.gov/pubs/sp/800/218/final ↩ ↩²

8. デジタル庁, 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン（PDF, 2024年1月31日）。企画から運用までの一貫対策、関係者の役割、セキュア調達を整理。https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/7e3e30b9/20240131_resources_standard_guidelines_guidelines_01.pdf ↩ ↩²

9. デジタル庁, CI/CDパイプラインにおけるセキュリティの留意点に関する技術レポート（PDF, 2024年3月29日）。CI/CD、シークレット、アクセス制御など開発基盤の保護を整理。https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/33f31336/20240329_resources_standard_guidelines_guideline_01.pdf ↩ ↩²

10. Amazon Web Services, Shared Responsibility Model（Web）。AWSと顧客の責任分担、Security of the CloudとSecurity in the Cloudの考え方を説明。https://aws.amazon.com/compliance/shared-responsibility-model/ ↩

11. Microsoft, Shared responsibility in the cloud（Microsoft Learn）。SaaS、PaaS、IaaS、オンプレミスでの責任分担を整理。https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility ↩

12. NIST, SP 800-37 Rev.2: Risk Management Framework for Information Systems and Organizations（Special Publication, 2018年12月）。RMF、共通統制、継続監視、組織レベルとシステムレベルの接続を整理。https://csrc.nist.gov/pubs/sp/800/37/r2/final ↩

13. デジタル庁, 政府情報システムにおけるサイバーセキュリティに係るサプライチェーン・リスクの課題整理及びその対策のグッドプラクティス集（PDF, 2025年6月30日）。サプライチェーンリスク、責任分界、委託先との協力、継続監視を整理。https://www.digital.go.jp/assets/contents/node/basic_page/field_ref_resources/e2a06143-ed29-4f1d-9c31-0f06fca67afc/a547f9a6/20250630_resources_standard_guidelines_technical_report_01.pdf ↩

14. OWASP, Application Security Verification Standard（Web）。WebアプリケーションとAPIのセキュリティ検証基準。https://owasp.org/www-project-application-security-verification-standard/ ↩

15. Center for Internet Security, CIS Critical Security Controls Version 8（Web）。資産管理、アクセス制御、脆弱性管理、ログ管理等の実装管理策。https://www.cisecurity.org/controls/v8 ↩

16. ISO, ISO/IEC 27001:2022 Information security management systems（標準ページ）。ISMSの要求事項を示す国際規格。https://www.iso.org/standard/27001 ↩

17. ISO, ISO/IEC 27002:2022 Information security, cybersecurity and privacy protection - Information security controls（標準ページ）。情報セキュリティ管理策の参照先。https://www.iso.org/standard/75652.html ↩

18. PCI Security Standards Council, PCI DSS（Web）。カード会員データ環境のセキュリティ要求事項。https://www.pcisecuritystandards.org/standards/pci-dss/ ↩