【IT統制】IT全般統制のRCMはどう作る？ひな形と書き方 ‣ はてなベース株式会社

IT全般統制のRCM（リスクコントロールマトリクス）は、「どのリスクを、どの統制で抑え、どう確かめるか」を1行に書いた表です。作るときは、5つの分類（開発・調達、変更・保守、運用、アクセス、委託先）ごとにリスクを挙げ、リスク1つにつき統制、確かめ方の順で1行を埋めます。書く項目（欄）は、経済産業省「システム管理基準追補版」の記入例にそろえます。SaaSで経理を回す会社でも、5つの分類それぞれに自社の行が残ります。
この記事の要約

RCMの1行は、何が起きるか（リスクと統制目標）、何で防ぐか（統制状況と記録）、どう確かめるか（頻度・サンプル数・評価手続）、評価の結果（評価結果・検出事項・調書番号）の4つのまとまりでできている。

架空のA社は社員30人、経理2人で、情シス（情報システム担当）は管理部長が兼務です。会計をfreee会計（アドバンス）で、請求書の受け取りと経費精算をバクラクで回しています。上場準備で、監査法人から「IT全般統制のRCMを作ってください」と言われました。業務プロセスのRCMは書き始めていますが、IT全般統制のRCMは、何から書き始めればよいのかが分からず止まっています。

項目は追補版付録2-2の記入例にそろえ、5つの分類を行の区切りにする

書く項目は、経済産業省の「システム管理基準追補版（財務報告に係るIT統制ガイダンス）」（2024年12月25日改訂、以下追補版）の付録2-2にそろえるのが近道です。付録2-2には、IT全社的統制・IT全般統制・IT業務処理統制の3つの表の例があります。IT全般統制の表は、上に会社名・決算期・事業拠点・対象システム・作成者・作成日・回答者の欄を置き、次の14の項目を並べています。

まとまり	項目	何を書くか
何が起きるか	分類、No.、リスク、統制目標	誤りの起き方と、保ちたい状態
何で防ぐか	統制状況、整備・運用、予防・発見、文書名	誰が何をし、何が記録に残るか
どう確かめるか	頻度、サンプル数、統制評価手続	何件を、どう突き合わせるか
評価の結果	評価結果、検出事項、調書番号	評価の結論、見つかった逸脱、記録の番号（評価を終えてから書く）

4つのまとまりは編集部の整理です。追補版は各項目の意味を説明しています。リスクは「財務報告の虚偽リスクの具体的な内容」、統制目標は「リスクに対応するの統制目標」（括弧は原文のまま）、評価結果は「対象としたリスクが低減されているか」です。追補版はそのうえで、この例は「あくまでもサンプル」であり、自社でカスタマイズして使うものだと書いています。

分類の欄には、開発・調達管理、変更・保守管理、運用管理、アクセス管理、委託先管理の5つが並びます。この5つが、RCMの行を分ける区切りになります。追補版の本文は、「システムの開発、変更・保守」「システムの運用・管理」「内外からのアクセス管理等のシステムの安全性の確保」「委託先の管理」の4つの区分で書かれています。付録の5分類は、最初の区分を開発・調達と変更・保守に分けた形です（対応づけは編集部の読みです）。追補版の本文では、区分の下の統制項目ごとに【統制目標の例】と【統制の例と統制評価手続の例】が載っているので、行を書くときの言葉の引き出しになります。

付録2-2の項目の説明には、自動・手作業の種別と評価要件（アサーション。実在性や網羅性など、財務諸表の数字に求める性質）の欄も挙がっています。これらの欄は、IT業務処理統制の表には入っていますが、IT全般統制の表にはありません。理由は追補版に書かれていません。業務プロセスの表（金融庁の実施基準〈参考文献2〉の参考3「リスクと統制の対応（例）」）との違いは、ここにあります。業務プロセスのRCMの書き方は3点セットの最初の1本の書き方の記事で扱っています。

1行は、リスク、統制目標、統制状況、統制の型の順に埋める

5つの分類ごとに、自社に残る作業から起きうる誤りをリスクとして挙げ、リスク1つを1行にします。1行は、リスク、統制目標、統制状況、統制の型（整備・運用、予防・発見）と文書名、頻度とサンプル数、統制評価手続の順に埋めます。リスクを先に書き、統制はそのあとに書きます。追補版も付録2-2の「２リスクコントロールマトリクスの利用方法」で、「まず、リスクを記入する」とし、次に統制目標と統制の状況を記入する順を示しています。統制から書き始めると、「やっていること」の一覧になり、どのリスクが抑えられていないかが見えなくなります。

1行を埋める順。リスクを文で書き、統制目標、統制状況、統制の型（整備・運用と予防・発見）と文書名、頻度とサンプル数、統制評価手続の順に埋める。

リスクは、「何が起きると・何が誤るか」の文で書きます。「アクセス管理が不十分」は統制が無いことを言っているだけで、リスクの文になっていません。A社なら「退職・異動した人のIDが残り、権限のない人が仕訳や設定を変えられる状態が続く」と書きます。

統制目標は、リスクを裏返した「保ちたい状態」です。「退職・異動のときに、アクセス権を適時に削除・変更する」のように書きます。追補版第IV章の統制目標の例は、自社のシステム名と業務の言葉に直して使います。

統制状況は、誰が、いつ、何を見て、何をし、どこに記録するかまで書きます。ここが曖昧だと、文書名の欄が埋まりません。A社の退職の行では、「総務の退職・異動連絡を受けて、情シス兼務の管理部長が最終出社日までに、退職者はfreee・バクラクのメンバーから削除し、異動者は権限を変えて、ID管理台帳に削除した日（変更した日）を記録する」とし、文書名の欄に「退職・異動連絡、ID管理台帳」と書きます。

整備・運用と予防・発見の2つの欄は、統制の型を示します。整備・運用の欄は、その行で確かめるのが、仕組みや手順が定められていること（整備）か、期中に繰り返し動いた記録（運用）か、その両方かを示す印です。付録2-2のIT全般統制の例は2行だけです。規程があるかを見る行は「整備」とし、頻度とサンプル数を「-」にしています。繰り返し動く統制の行は「運用」とし、サンプル数を入れています。同じ付録のIT全社的統制の例は、1行に「整備運用」の両方を書いています。A社のひな形は後者の形にし、統制評価手続の中で整備の手続と運用の手続を分けて書きました。

予防・発見の欄は、誤りが起きる前に止めるか、起きたあとに見つけるかの区別です。予防の行だけでは、すり抜けた誤りが見つかりません。A社では、設定変更の事前承認（予防）に、四半期ごとの台帳と画面の突き合わせ（発見）を組み合わせました。設定変更の台帳の作り方はSaaSの設定変更を記録に残す方法の記事で扱っています。

サンプル数の目安は頻度で決め、統制評価手続は統制状況の裏返しで書く

頻度を先に決めると、サンプル数の目安を追補版付録1の表から引けます。追補版の付録1は、件数は一概に言えず、統制の重要性や複雑さなどを考慮して決めるとしています。そのうえで、業務プロセスに係る内部統制のうち手作業による統制について、全社的な内部統制が適切である場合の例として、頻度ごとのサンプル件数の表を示しています。許容する逸脱（統制が決めたとおりに動かなかったこと）は、どの頻度でも0件です。IT全般統制の件数を正面から示した一次資料は見当たりませんが、付録2-2のIT全般統制の記入例も25件を使っています。編集部の見立てでは、IT全般統制の行もこの表を目安にします。

頻度ごとのサンプル件数の目安。1日につき多数と日次は25件、週次は5件、月次と四半期は2件、年次は1件で、許容逸脱はいずれも0件。随時は件数に応じて決める。

25件には統計の裏付けがあります。追補版は、十分に大きい母集団（評価の対象になる全件）から25件を無作為に抽出し、逸脱が1件も無ければ、9%以上の逸脱がないことを信頼水準90%で説明できるとしています。一方で、1日につき多数と日次以外の件数は統計的方法によるものではないと断っています。実施基準も、監査人の手続の例として、二項分布を前提に90%の信頼度を得るには少なくとも25件が必要としています（III.4(2)①ロa）。

IT全般統制には「随時」の行が多く出ます。設定の変更、IDの削除、SaaSの導入は、起きた都度に行い、決まった間隔が無いからです。付録1の表には「随時」の目安がありません。付録2-2の記入例では、受入テスト（導入前に利用者が動作を確かめるテスト）の行の頻度を「随時」、サンプル数を25件としていますが、件数の根拠は書かれていません。編集部の見立てでは、期中の発生件数の見込みを頻度の欄に書き添え、件数をどう決めるかを監査法人とそろえておくのが確実です。A社のように退職者が年に数人なら、全件を確かめるのが分かりやすい形です。

付録1の表は、逸脱が0件であることを有効の条件にしています。一方で付録2-2の記入例には、25件のうち1件で承認の記録が無かった行があります。その行の検出事項には、記録が無かったのは押印漏れで、追加テストでは押印漏れが検出されなかったため例外的なエラーと判断した、という経緯が書かれています。そのうえで評価結果を「有効」としています。逸脱が出たときの扱いは監査法人の判断が分かれやすいので、原因と追加で確かめた経緯を検出事項に残し、結論は監査法人と協議して決めます。

統制評価手続は、統制状況の裏返しです。何を入手し、何と何を突き合わせるかを書きます。A社の退職の行なら、「総務から期中の退職・異動者の一覧を入手し、各人の最終出社日と削除した日（変更した日）を、ID管理台帳とSaaSのメンバー一覧で突き合わせる」です。追補版も、アクセス管理の評価手続の例に、退職者のサンプルを抽出して退職後すぐにアクセス権が削除されたかを確かめる手続を挙げています。一覧をどこから出したかも書いておくと、母集団に漏れがないことを説明できます。システムから出した一覧の確かめ方はシステム帳票の正確性と網羅性を確かめる方法の記事で扱っています。

IT全般統制の評価は、原則として整備と運用の両方を見ます。実施基準は、経営者がIT全般統制について、有効に整備及び運用されているかを評価するとしています。例として、システムの開発・保守、運用・管理、アクセス管理などの安全性の確保、外部委託に関する契約の管理を挙げています（II.3(3)⑤ニa）。同じ箇所は、業務処理統制の運用評価の範囲を広げることで、全般統制の運用評価を実施せずに十分な心証（評価者が納得できる根拠）が得られる場合もあるとしています。

SaaS中心のA社でも、5つの分類それぞれに自社の行が残る

A社のRCMは、5つの分類ごとに1〜2行、合計7行で書きました。プログラムの開発とサーバーの運用はベンダー側が行いますが、設定・連携・ID・委託先の管理は自社に残ります。委託先の行で使うSOC1報告書は、SaaSの提供会社の内部統制を監査人が確かめた保証報告書です。SaaSで自社に残るIT全般統制（ITGC）の全体像はSaaSで経理を回す会社に残るITGCの記事で扱っています。

プログラムとサーバーはベンダーへ移り、設定・連携・ID・委託先の7行が自社に残る。開発・調達は導入時の設定確認、変更・保守は設定変更の承認と突き合わせ、運用は連携の監視、アクセスはIDの削除と権限の棚卸、委託先はSOC1報告書の確認。

項目は付録2-2と同じで、行の中身はA社を想定した編集部の例です。評価結果、検出事項、調書番号の3つの欄は、評価を終えるまで空欄にしておきます。

分類	No.	リスク	統制目標	統制状況	整備・運用	予防・発見	文書名	頻度	サンプル数	統制評価手続
開発・調達管理	1	会計SaaSの導入やプラン変更のときに、承認経路や権限の初期設定が業務に合わないまま使い始め、承認を経ない仕訳が帳簿に入る	財務報告に関わる設定が業務に合っていることを確かめてから、本番の利用を始める	導入・プラン変更のたびに、経理責任者が設定確認チェックリスト（承認経路・権限・自動登録ルール・連携）で設定を確かめ、管理部長が承認してから利用を始める	整備・運用	予防	設定確認チェックリスト、稟議書	随時（導入・プラン変更の都度）	期中の件数に応じて監査法人と決める（A社は全件）	整備は、チェックリストの様式と承認の手順を定めた文書を閲覧して確かめる。運用は、期中の導入・プラン変更の一覧を入手し、各件のチェックリストに確認者と承認者の記録があり、利用開始日より前に承認されていることを確かめる
変更・保守管理	2	承認経路や自動登録ルールが承認なく変えられ、誤った勘定科目の仕訳や承認を経ない仕訳が計上される	財務報告に影響する設定の変更は、事前に申請・承認され、変更の内容が記録に残っている	承認経路・自動登録ルール・権限・連携の設定を変えるときは、変える人が設定変更台帳で申請し、管理部長が承認してから変える（申請者が管理部長のときは取締役が承認する）。変更前後の画面を台帳に保存する	整備・運用	予防	設定変更台帳、変更前後の画面	随時（変更の都度）	期中の件数に応じて監査法人と決める（A社は全件）	整備は、対象の設定と承認者を定めた手順と台帳の様式を閲覧して確かめる。運用は、期中の設定変更の一覧を入手し、各変更について、変更日より前の承認が台帳にあり、変更前後の画面が台帳の内容と合っていることを確かめる
変更・保守管理	3	台帳を通さずに設定が変えられても気づかず、未承認の設定のまま決算を迎える	未承認の設定変更を適時に見つけ、事後承認か元に戻すかを決める	四半期ごとに、管理部長が承認経路・自動登録ルール・権限・連携の設定画面を開き、今の設定を前回保存した画面および台帳と突き合わせ、差異と対応を確認記録に残す。管理部長自身が申請した変更は取締役が確かめる	整備・運用	発見	設定の突き合わせ記録、保存した設定画面	四半期	2	整備は、突き合わせの手順と確認者を定めた文書を閲覧して確かめる。運用は、抽出した四半期の確認記録を閲覧し、確認者・確認日・差異と対応が残っていることを確かめ、記録に載った設定が今の画面と合っているかを見る
運用管理	4	銀行・カードの明細連携や、バクラクからfreeeへの連携が止まり、取引の取り込み漏れが月次決算まで見つからない	連携の異常を適時に見つけ、取引を漏れなく取り込む	経理担当が毎営業日、連携の状況とエラーの通知を確認し、エラーは再取得・再連携して連携チェック表に記録する	整備・運用	発見	連携チェック表	日次	25	整備は、確認する連携の一覧とエラー時の手順を定めた文書を閲覧して確かめる。運用は、抽出した日の連携チェック表を閲覧し、確認者と確認日、エラーがあった日は再連携の記録と取り込み後の件数が残っていることを確かめる
アクセス管理	5	退職・異動した人のIDが残り、権限のない人が仕訳や設定を変えられる状態が続く	退職・異動のときに、会計SaaSのアクセス権を適時に削除・変更する	総務の退職・異動連絡を受けて、情シス兼務の管理部長が最終出社日までに、退職者はfreee・バクラクのメンバーから削除し、異動者は権限を変えて、ID管理台帳に削除した日（変更した日）を記録する	整備・運用	予防	退職・異動連絡、ID管理台帳	随時（退職・異動の都度）	期中の件数に応じて監査法人と決める（A社は全件）	整備は、退職・異動連絡からID削除までの手順と期限を定めた文書を閲覧して確かめる。運用は、総務から期中の退職・異動者の一覧を入手し、各人の最終出社日と削除した日（変更した日）を、ID管理台帳とSaaSのメンバー一覧で突き合わせる
アクセス管理	6	管理者権限が必要な範囲を超えて付与され、仕訳を起票する人が承認経路や権限を自分で変えられる	管理者権限を含むアクセス権が職務に合っていることを定期的に確かめる	四半期ごとに、経理責任者がfreee・バクラクのメンバー一覧の画面を日付つきで保存してID管理台帳と突き合わせ、管理部長が結果を承認する（管理部長自身の権限は取締役が確かめる）	整備・運用	発見	権限の棚卸記録、保存したメンバー一覧	四半期	2	整備は、棚卸の手順・実施者・承認者を定めた文書を閲覧して確かめる。運用は、抽出した四半期の棚卸記録について、保存した一覧がその時点の全メンバーを含むこと、差異への対応、承認者と承認日を確かめる
委託先管理	7	会計SaaSの提供会社の統制に不備があっても気づかず、自社が前提にしている処理の正確性が保たれない	委託先の内部統制の状況を把握し、委託先が利用会社（自社）に求める統制を自社で整える	年に1回、経理責任者がfreee・バクラクのSOC1報告書を入手し、対象サービス・対象期間・例外事項・利用会社（自社）に求められる統制を確認記録にまとめ、管理部長に報告する。報告書の種類（Type1かType2か）と対象期間は、報告書の記載で確かめる	整備・運用	発見	SOC1報告書、確認記録	年次	委託先ごとに1（計2）	整備は、入手する報告書と確認する点を定めた文書を閲覧して確かめる。運用は、確認記録を閲覧し、報告書の対象期間と会計期間の重なり、例外事項への対応、利用会社に求められる統制に対応する行がこのRCMにあることを確かめる

Excelのひな形はこの記事の末尾からダウンロードできます。シートは「RCM（IT全般統制）」と「記入の手引き」の2枚です。No.7は報告書を入手できる前提の行です。freeeのように、入手できるかをプランごとに確かめる必要がある委託先では、入手できない場合の補い方を別の行にします。補い方はSOC1レポートの読み方の記事を参考にしてください。

空けておいた3つの欄は、評価を終えたあとに埋めます。評価結果の欄は、追補版の項目の説明ではリスクの低減の程度を書くことになっていますが、記入例の表は「有効」と書いています。この記事とExcelは記入例に合わせ、「有効」「有効でない」で書きます。検出事項には、逸脱の件数と内容、原因、追加で確かめたこと、是正の予定を書き、逸脱が無ければ確かめた範囲を添えます。調書番号は、抽出した一覧や閲覧した画面をまとめた記録の番号です。付録2-2の記入例では「○○」と置かれているだけなので、番号の付け方は自社で決めます。No.5について、評価を終えたあとの3つの欄の記入例を示します。

項目	No.5を評価し終えたあとの記入例
評価結果	有効
検出事項	なし（退職3名・異動2名の全件で、最終出社日までにIDの削除・権限の変更を終えていた）
調書番号	ITGC-05

監査法人には、行の無い統制の理由と一覧の出し方を聞かれやすい

編集部の見立てでは、RCMを監査法人に見せると、行に書いた中身より、行の前提（行が無い理由、一覧の出し方、ほかの表との対応）を聞かれることが多いようです。次の5点を答えられるようにしておくと、やり取りが短くなります。

行の無い統制がある場合、その理由。たとえば自社でプログラムを開発していないなら、開発の行が無い理由と、代わりに導入時の設定確認を置いたことを説明できるか
統制評価手続で使う一覧の出し方。退職者の一覧やメンバーの一覧を、どの画面から、どの時点で出し、漏れがないことをどう確かめるか
委託先の行と、SOC1報告書が利用会社に求める統制の対応。報告書がIDの管理を利用会社に委ねていれば、アクセス管理の行がその統制を担っているか
業務プロセスのRCMとの対応。承認フローや自動仕訳など、IT全般統制が支える業務処理統制がどれか（承認フローや自動仕訳をITACとして評価する記事）
管理部長が情シスを兼ねる会社で、自分の権限を自分で承認しない形になっているか。A社のNo.6では、管理部長の権限を取締役が確かめます（棚卸の進め方は権限の棚卸の進め方の記事）

freeeのSOC1報告書は、公式ヘルプ（2026年10月19日更新）では、担当営業かサポートに問い合わせて入手する案内になっています。プラン別機能表では、内部統制の機能の注記に「SOC対応」が挙がっています。アドバンスプランを使うA社は、入手できるかを担当営業に確かめます。

読み違えやすいポイント

読み違えやすい読み方	原文での扱い
付録2-2「利用方法」の⑥に「右端の評価結果」とあるので、評価結果を右端の欄に置く	付録2-2「利用方法」の⑥は「右端の評価結果」と書いていますが、付録2-2の3つの記入例の表はいずれも調書番号が右端です。この記事とExcelは記入例の並びに合わせています
付録図表1-1の件数は、IT全般統制のために決められた件数だ	付録図表1-1（本文の「付録1の表」）は、業務プロセスに係る内部統制のうち手作業による統制の運用評価の例です。IT全般統制の行に当てはめるのは編集部の見立てです。付録2-2の記入例の行も、自社でシステムを開発する会社を前提にしているので、SaaS中心の会社では行を作り直します