はじめに
IPO準備やJ-SOX対応の現場に入ると、「セキュリティ対策」と「IT統制」が、似ているようで別の言葉で語られていることに気づきます。
- セキュリティ担当は NIST CSF や CIS Controls で考える
- 監査・内部統制の担当は ITGC（IT全般統制） で考える
この2つは重なる部分が大きいのに、対応関係が整理されていないために、「セキュリティは頑張っているのに、監査で必要な統制が抜けている」あるいは逆に「監査対応はしたが、セキュリティのフレームワークとの接続が説明できない」という食い違いが起きます。
この記事では、NIST CSF 2.0の6機能を、J-SOXで問われるITGCにどうマッピングするかを、実務で使える粒度で整理します。フレームワーク間の"翻訳表"として使えることを目指します。
注：本記事は方法論の整理であり、特定企業の監査可否を判定するものではありません。ITGCの適用範囲は監査実務で解釈が分かれます。最終的な水準・範囲は監査法人の判断によります。
前提：2つのフレームワークの立ち位置
NIST CSF 2.0 の6機能
NIST Cybersecurity Framework 2.0 は、サイバーセキュリティを6つの機能（Function）で捉えます。IPA公式訳に沿うと：
| 略号 | 機能（英） | 機能（日・IPA訳） | ざっくり言うと |
|---|---|---|---|
| GV | Govern | 統治 | リスク管理の方針・体制（2.0で新設） |
| ID | Identify | 識別 | 資産・リスクの把握 |
| PR | Protect | 防御 | アクセス制御・保護の実装 |
| DE | Detect | 検知 | 異常・インシデントの検知 |
| RS | Respond | 対応 | インシデントへの対応 |
| RC | Recover | 復旧 | 復旧・事業継続 |
2.0での最大の変更は、Govern（統治）が独立した機能として新設されたことです。従来ID配下にあったガバナンス要素が格上げされ、リスク管理を組織の意思決定に組み込むことが明示されました。
ITGC（IT全般統制）の定型領域
一方、J-SOX（金融商品取引法に基づく内部統制報告制度）で問われる ITGC は、財務報告の信頼性を支えるIT統制です。実務上、以下の4領域に整理されるのが定型です。
| ITGC領域（定型） | 内容 |
|---|---|
| アクセス管理 | 財務関連システムへのアクセス権限の付与・剥奪・棚卸、認証 |
| 変更管理 | プログラム変更の承認・テスト・職務分掌 |
| 運用管理 | ジョブ運用、バックアップ、証跡（操作ログ）の保全 |
| 外部委託管理 | 委託先・利用クラウド/SaaSの把握と、委託先の統制水準の評価 |
なお、資産管理（全端末・情報資産の特定と掌握）は、ITGCの正式な定型領域ではなく、上記4領域を成立させる"前提" です。資産の所在が掴めていなければ、アクセス管理も運用管理も成り立ちません。この前提の弱さが、IPO準備企業のつまずきの起点になります（後段で詳述）。
ここで重要な注意点があります。セキュリティ成熟度として価値があっても、財務報告統制でなければITGC必須ではない、ということです。この線引きを混同すると、「監査に不要な投資を必須と誤認する」「必須の統制を任意扱いして抜かす」という両方の事故が起きます。
本題：NIST CSF 2.0 × ITGC マッピング表
以下が、6機能とITGCの対応関係です。各機能の代表的なサブカテゴリを、ITGC領域に接続します。
GV（統治）→ 統制環境の前提
| NIST サブカテゴリ | 内容 | ITGC上の位置づけ |
|---|---|---|
| GV.RR-02 | リスク管理の役割・責任の確立・周知 | 統制環境（ITGCの土台。個別の必須統制というより前提） |
| GV.PO-01 | セキュリティ方針の策定 | 統制環境 |
| GV.SC-07 | サプライヤー（委託先）のリスク評価・優先順位付け | 外部委託管理（委託先の統制評価） |
GVは「土台」です。ITGCの個別統制をカウントする際には計上しないことが多いですが、これが無いと個別統制が"仕組み"として成立しない、という位置づけです。
なお、NIST CSF 2.0では外部委託（サプライチェーン）のリスク管理が GV.SC として統治機能に位置づけられた点が重要です。標準ITGCの「外部委託管理」のうち、委託先の統制評価は GV.SC-07・ID.RA-10（重要サプライヤーの評価）に対応します。一方、委託先の"把握"側は資産の棚卸（ID.AM-04）に対応します。つまり外部委託管理は、NIST CSF 2.0では単一機能ではなく、統治（評価）と識別/資産（把握）の2側面に分かれて表れます。
ID（識別）→ 主に資産管理
| NIST サブカテゴリ | 内容 | ITGC領域 | 必須/任意 |
|---|---|---|---|
| ID.AM-01 | ハードウェア資産台帳の維持 | 資産管理（ITGCの前提） | 必須 |
| ID.RA-01 | 資産の脆弱性の識別・記録 | （変更管理に近接） | 任意 |
ID.AM-01（資産台帳）は必須です。理由は明確で、「資産がどこにあるか把握できていること」がITGCの前提だからです。私物PCの混在や、情報がSlack/Notion/Drive間で発散してマスターが不明、といった状態は、監査法人が「重大な欠陥」とみなす典型です。実務上も、アクセス管理の不備（削除漏れ等）と、資産管理の不実（私物PC・未管理端末）は、ITGC不備の二大要因として知られています。
PR（防御）→ 主にアクセス管理
ここがITGC必須と最も密に対応します。
| NIST サブカテゴリ | 内容 | ITGC領域 | 必須/任意 |
|---|---|---|---|
| PR.AA-01 | 認証情報のライフサイクル管理（失効含む） | アクセス管理（退職者失効） | 必須 |
| PR.AA-03 | ユーザー・サービスの認証 | アクセス管理（MFA） | 必須 |
| PR.AA-05 | 最小権限・職務分掌の原則でアクセス権を管理・レビュー | アクセス管理（権限棚卸） | 必須 |
| PR.PS-04 | ログの生成・監視・フォレンジクス活用 | 運用管理（証跡保全） | 必須 |
| PR.PS-02 | ソフトウェアの維持・更新（パッチ管理） | 変更管理に近接 | 任意 |
PR.AA系（Authentication and Access Control）が、ITGCアクセス管理の必須統制とほぼ一対一で対応します。退職者アクセスの剥奪（PR.AA-01）、MFA（PR.AA-03）、最小権限と権限棚卸（PR.AA-05）——この3つは、監査でまず問われる核心です。
DE（検知）→ 主に任意（ただし証跡は必須）
| NIST サブカテゴリ | 内容 | ITGC領域 | 必須/任意 |
|---|---|---|---|
| DE.CM-01 | ネットワーク・サービスの監視 | （運用管理の証跡と重なる部分は必須） | 原則任意 |
| DE.CM-09 | ハードウェア・ソフトウェアの監視（EDR等） | 脅威検知 | 任意 |
ここが最も誤解の多い領域です。SIEMやSOC監視、EDRの高度な脅威検知は、セキュリティ成熟度には効くが、ITGC必須ではありません。「検知が弱いからSIEMを入れないと監査に通らない」というのは過剰接続です。
ただし注意点として、EDR/MDMは機能が混在します。「端末を会社管理下に置き特定する」部分は資産管理（必須）、「脅威を検知する」部分は任意。一つの製品を一行で"必須/任意"と断じず、製品内の機能を分けて評価するのが正確なやり方です。
RS（対応）・RC（復旧）→ 体制は関連、頻度は任意
| NIST サブカテゴリ | 内容 | ITGC領域 | 必須/任意 |
|---|---|---|---|
| RS.MA-01 | インシデント対応計画の実行 | （体制は関連） | 任意 |
| ID.IM-04 ※ | インシデント対応計画の確立・改善（訓練含む） | （体制は関連） | 任意 |
| RC.RP-01 | 復旧計画の実行（バックアップからの復旧） | 運用管理（バックアップ） | L2〜L3が目安 |
※ ID.IM-04はコード上は識別（ID）配下の「改善（Improvement）」カテゴリですが、内容がインシデント対応の改善に関わるため、対応・復旧の文脈でここに併記しています。
インシデント対応は、体制の存在は問われうるが、訓練頻度までは必須ではない、という微妙な位置づけです。バックアップ・復旧（RC）は運用管理として一定の水準が期待されます。
補足：NIST CSF 1.1でインシデント対応の改善を担っていたRS.IM-01/02は、2.0で改善（Improvement）がID.IMカテゴリに再編され、ID.IM-04が対応します。厳密な1:1の置き換えではなく再編なので、バージョン間の対応を追うときの注意点です。
マッピングから見える「設計原則」
この対応表を作る中で、実務的に効く原則が3つ見えてきます。
1. 6機能すべてに最低1つの統制を対応させる
GVからRCまで、どの機能にも空白を作らない。ただし「全項目を網羅する」こととは違います。正確には「6機能すべてに対応しつつ、標準ITGCの4領域（アクセス・変更・運用・外部委託）に対応し、加えてその前提となる資産管理を土台として測る。それ以外は優先度に基づき意図的に選定する」という主張が誠実です。「網羅しています」とは言わない。ここは正確さが信頼に直結します。
2. 必須/任意を、製品でなく統制概念で判定する
EDRの例のように、製品名で「必須」と決めない。その製品が担う統制概念（資産管理なのか、脅威検知なのか）に分解して判定する。
3. 判定はマッピング定義に封じ込め、適用は機械的に
どの設問がどのITGC領域に対応するかをあらかじめ定義表として固定しておけば、レポート生成時の属人的な誤接続（例：SIEMをIPO必須と誤記）を防げます。判断を人が都度やると必ずブレます。定義を凍結し、適用を機械化する——これがマッピングを"再現可能な資産"にするコツです。
補足：現在地把握ツールとして実装するときの領域設計
この翻訳表を、実際に現在地を測るツールに落とすと、標準ITGCの4領域をそのまま並べるのではなく、次の設計になります。
- 資産管理を"土台"として明示的に領域化する。 前述のとおり資産管理は定型ITGCの正式領域ではなく前提ですが、IPO準備企業では私物PC・野良SaaS・台帳不在でこの前提が最も崩れています。だから前提を見える領域として最初に測る。土台が崩れていれば、その上のアクセス・変更・運用の統制も成立しないからです。
- 外部委託は2側面に分けて測る。 「委託先の把握」は資産の棚卸（ID.AM-04）＝識別/資産の側面、「委託先の統制評価」は GV.SC-07 ＝統治の側面。単一領域に丸めず、NIST CSF 2.0の構造どおり2つの機能に対応させます。
これは定型ITGCの写しではなく、"前提（資産）を最初に固め、外部委託は把握と評価に分けて測る"という設計判断です。定型と1対1で並べないぶん、「なぜこの領域構成なのか」を外部に説明できることが前提になります。
まとめ
- NIST CSF 2.0のPR.AA系がITGCアクセス管理の必須統制とほぼ一対一で対応する
- ID.AM-01（資産台帳）は必須——資産管理はITGCの正式領域でなく"前提"だが、実装では最も崩れやすいので土台として最初に測る
- 外部委託管理は単一機能でなく、把握（識別/資産・ID.AM-04）と評価（統治・GV.SC-07）の2側面に分けて捉える
- DE（検知）系の多くは任意——SIEM/EDR高度機能を"監査必須"と誤認しない
- EDR/MDMのように機能が混在する製品は、統制概念に分解して評価する
- 6機能対応 ＋ 標準ITGC4領域への対応（＋前提としての資産管理） ＋ 意図的選定、と正確に主張する（「全網羅」と言わない）
セキュリティのフレームワークと内部統制は、翻訳表さえあれば、同じ現在地を別の言葉で語っているだけだと分かります。この対応を組織の共通言語にできると、「セキュリティ投資」と「監査対応」が、別々の作業ではなく一つの営みになります。
この記事の対応表は、私が開発しているセキュリティ可視化サービス「SecuROI」の設問設計の背景にあるマッピングロジックを、公開できる範囲で整理したものです。20問の診断で現在地をNIST CSF 2.0／ITGC観点でスコア化する仕組みに関心があれば、セキュリティ可視化サービス『SecuROI』で検索してご覧ください。