はじめに

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』で検索してご覧ください。