IT全般統制とは？監査対応で情シスが準備すること

IT全般統制とは、会計や販売などのシステムが正しく作られ、正しく動き続けることを支える、システム横断の管理の仕組みです。英語ではITGC（IT General Controls）と呼ばれ、上場企業が金融商品取引法に基づいて行う内部統制報告制度（J-SOX）の中で、経営者が評価し、監査法人が監査する対象になります。

中身は、変更管理、運用管理、アクセス管理、外部委託の管理という、情シスが日々やっている仕事そのものです。監査で問われるのは「やっているか」より「やったことを第三者が確かめられる形で残しているか」です。IT統制の3つの階層、4つの領域と求められる証跡、対象システムの決め方、RCMの記入例、年間の動き方、よく指摘される不備を、情シスの準備の順に並べます。

IT統制とは：3つの階層の違い

内部統制報告制度では、内部統制の基本的要素の1つとして「ITへの対応」が挙げられており、その中のIT統制は、次の3つの階層に分けて評価されます。金融庁の実施基準では「ITに係る全般統制」のように呼ばれますが、実務では短く「IT全般統制」と言うことがほとんどです。

IT全般統制が効いていないと、IT業務処理統制も信頼できなくなります。例として、販売管理システムの請求金額の自動計算（業務処理統制）が今日正しくても、誰でもプログラムや設定を変えられる状態（全般統制の不備）なら、その計算が期末まで正しい保証はありません。監査人はこの理屈で、全般統制に不備があるシステムについては自動化された統制に頼れないと判断し、手作業による追加の検証を求めます。全般統制の不備が、経理部門の作業を増やす形で跳ね返ってくるわけです。

IT全般統制の4つの領域と、監査で求められる証跡

右端の列が示すとおり、求められることの大半は、情シスがすでにやっている仕事です。違いは記録の残し方にあります。退職者のIDを止めていても、人事の退職者一覧と突き合わせた記録がなければ、監査人は「全員分を止めた」ことを確かめられません。変更管理の考え方そのものはITILの変更の3分類がそのまま使えます。

対象システムの決め方（スコーピング）

社内の全システムが評価の対象になるわけではありません。対象は、財務報告に影響する業務処理統制が載っているシステムと、その土台（データベース、OS、ネットワーク、ID基盤）です。一般的な事業会社では、売上・売掛金・棚卸資産に至る業務プロセスが評価の中心になるとされ、そこで使う販売管理、在庫管理、会計のシステムが候補になります。

1. 経理・内部監査の担当と一緒に、評価対象の業務プロセスと、その中の自動化された統制（自動計算、入力チェック、システム間の連携）を洗い出す
2. それらの統制が動いているシステムを一覧にする。SaaSも含める
3. システムごとに、アプリケーション・データベース・OS・ネットワーク・ID基盤のどの層までを対象にするかを決める
4. SaaSや外部委託先について、保証報告書が入手できるかを確かめ、入手できない場合の代わりの手続きを監査人と相談する
5. 対象の一覧を監査人と合意し、年度の途中でシステムが変わったら、その都度連絡する

SaaSの会計システムでも、利用者のIDと権限、マスタの変更は自社の統制の範囲に残ります。事業者のSOC1報告書（受託業務に係る内部統制の保証報告書）には、利用者側で実施することが前提になっている統制が書かれているので、その項目を自社のRCMに取り込みます。IDの付与と停止をSSOとSCIMで自動化しておくと、この部分の統制と証跡づくりが大きく楽になります。確認項目はSaaSのSSO/SCIM対応チェックリストにまとめています。

RCMのIT全般統制部分の記入例

RCM（リスクコントロールマトリクス）は、リスクとそれに対応するコントロールを1行ずつ並べた表で、実務では業務記述書・フローチャートと合わせて「3点セット」と呼ばれることの多い文書です。全般統制の各行には、「誰が・いつ・何を・どの証跡で」を1行に収めます。

コントロールの文に「適切に」「必要に応じて」と書かないでください。監査人は「適切かどうか」を判定できないので、テストの手続きを組めません。頻度、実施者、期限、証跡が具体的に書かれていれば、監査人はサンプルを選んで証跡を確かめるだけで済み、情シスの対応時間も短くなります。具体的に書けないコントロールは、運用の中身が決まっていない疑いがあります。

証跡は、実施したその時点で作ってください。監査の直前に過去の日付で確認表を作ると、記録全体の信頼性が疑われ、手続きが1件漏れていたことより重い問題になります。棚卸しや突き合わせは、実施した日に確認者の名前と日付が入った状態で保存し、以後は編集できない場所（読み取り専用のフォルダや、変更履歴が残るシステム）に置きます。

監査対応の年間の動き方

評価は、コントロールの設計が妥当かを見る整備状況の評価と、1年を通じて実際に運用されたかを見る運用状況の評価の2段階で進みます。時期は監査人との計画で決まるので、次は3月決算の会社を想定した一例です。

不備が見つかった場合、影響の大きさによっては「開示すべき重要な不備」として内部統制報告書に記載されることがあります。情シスにとって現実的な目標は、不備をゼロにすることではなく、見つかった不備を期末までに是正し、是正後の運用を一定期間示せる状態にしておくことです。そのためにも、上期の整備状況の評価で指摘を早く受ける方が有利です。

よく指摘される不備と防ぎ方

3行目の「職務を分けられない」は、情シスが数人の会社では避けられません。この場合は、変更を事前に止める予防的な統制の代わりに、変更の後で別の人が確かめる発見的な統制を置くことを監査人と相談します。本番の変更ログを週次でレビューし、レビューした人と日付を残せば、少人数でも説明のつく形になります。

SaaSの操作ログ（監査ログ）の保存期間は、製品と契約プランで違います。保存期間が評価の対象期間より短いと、期末に遡ってログを確かめられません。対象のSaaSごとに保存期間を確かめ、足りなければログを定期的に書き出して、改ざんできない場所に保管してください。

情シスが今から準備すること

• 財務報告に関わるシステムの一覧（SaaSを含む）と、各システムの管理者の一覧
• 入社・異動・退職のID処理の手順と、人事データとの突き合わせの記録
• 特権IDの一覧と、利用の申請・ログ確認の手順
• 本番変更の申請・承認・テスト・反映を1件ずつたどれる記録の残し方
• ジョブ監視とバックアップの記録、委託先とSaaSの保証報告書の入手状況

ISMSを取得している、または取得を進めている会社なら、アクセス管理や変更管理の規程と記録の多くをそのまま流用できます。ISMSの管理策とIT全般統制の4領域を対応させた表を作っておくと、監査と審査の両方に同じ証跡を出せます。ISMSの進め方はISMS認証取得の進め方で扱っています。

よくある質問

IT統制とIT全般統制の違いは何ですか？

IT統制は、ITに関わる内部統制の総称で、IT全社統制、IT全般統制、IT業務処理統制の3つで構成されます。そのうちの1つがIT全般統制で、個々の業務処理を支えるシステム群を、変更管理・運用管理・アクセス管理・外部委託の管理によって正しい状態に保つ仕組みを指します。

IT全般統制は必要ですか？

上場企業には内部統制報告制度の評価対象として必要で、上場を準備している会社も、上場後の評価に備えて準備の段階から整備が求められます。それ以外の会社に法的な義務はありませんが、ID管理・変更管理・バックアップの記録を残す仕組みは、ISMSの審査や取引先のセキュリティ監査、障害の原因調査でも同じように求められるので、規模に合わせて整えておく価値があります。

IT全社統制とは何ですか？

会社全体としてITをどう管理するかを定める統制で、IT戦略や規程、IT組織と責任者、ITに関するリスクの評価、委託先を管理する方針などが含まれます。個々のシステムではなく方針と体制が対象で、IT全般統制とIT業務処理統制がきちんと働くための土台になります。

SOX法とJ-SOX法の違いは何ですか？

SOX法は米国の企業改革法、J-SOXは日本の金融商品取引法に基づく内部統制報告制度の通称です。J-SOXは米国の制度を参考にしつつ、内部統制の基本的要素に「ITへの対応」を加え、監査人が経営者の評価結果を監査する間接的な方式を採っている点が主な違いです。細部は金融庁の基準で確認してください。

まとめ

IT全般統制は、情シスがすでにやっている変更管理・運用管理・アクセス管理・委託先管理を、第三者が確かめられる記録として残す仕組みです。対象は財務報告に関わるシステムとその土台に絞り、RCMには「誰が・いつ・何を・どの証跡で」を具体的に書きます。証跡はその場で作り、職務を分けられない部分は事後のレビューで補ってください。

次に読む

• ISMS（ISO 27001）認証取得の進め方：情シスが主導するスケジュールと文書化の実務
• SaaSのSSO/SCIM対応チェックリスト：情シスが導入前に確認する項目と設定の流れ
• ITILとは？情シスに必要なプラクティスだけを取り入れる方法