IT全般統制の監査で見られるツールとは？クラウド・GitHub・テスト・バッチを公認会計士が解説

公開日： ／更新日：

IT全般統制の監査で、監査法人のIT専門家から、「本番環境の変更は、誰が承認していますか」「バッチのエラーは、どこに通知されますか」と聞かれて、答えに詰まってしまった。上場やIPOを目指す会社で、内部統制の整備・運用を進めていると、こうした場面に出会います。

IT統制の検証は、監査法人の公認会計士ではなく、IT専門家と呼ばれる方が個別に行うことが多い、専門性の高い領域です。そのため、監査対応をしている方も、財務諸表監査をしている公認会計士も、「いったいどこを見ているのか」「そもそも現場で動いているツールのことが分からないから、話についていけない」となりがちです。

先に答えを書きます。IT全般統制の監査で、監査人が見ているのは、ツールそのものではありません。そのツールが、変更管理・運用管理・アクセス管理・外部委託管理の4つの領域のどこを担っているかです。ツールの名前ではなく、役割を4つの領域に結びつけて説明できれば、監査人との会話は成り立ちます。

この記事では、システム監査技術者であり公認会計士でもある筆者が、IT全般統制の監査で使われるツールを、領域ごとに、監査人が何を確認するのかとあわせて解説します。監査対応を任された経理・管理部門の方や、財務諸表監査の中でIT統制に触れる公認会計士の方を主な読者として書いています。

この記事を読んでわかること

  • IT全般統制の監査で見られる4つの領域（変更管理・運用管理・アクセス管理・外部委託管理）
  • クラウド・バージョン管理（GitHub）・テストツール・バッチ処理ごとの、監査人の確認ポイント
  • 自社のツールを4つの領域に結びつけて、監査に備える進め方
  • SOCレポートがない委託先、ノーコードツール、AIの利用など、実務で迷いやすい3つのケース

IT全般統制の監査とは：監査人が見る4つの領域

ツールの話に入る前に、IT全般統制とは何かを整理します。ここがずれたままだと、ツールの説明を聞いても、どこに効いてくるのかが分からないからです。

見られるのは「財務報告に係る」部分だけ

上場企業やIPOを目指す会社に適用される基準のうち、特に重要なものは、「財務報告に係る内部統制の評価及び監査の基準」（以下、内部統制基準）と、「一般に公正妥当と認められる監査の基準」です。これらの基準の中で、「財務報告」、つまり企業の財政状態や経営成績に係る内部統制の有効性を評価することが求められます。

重要なのは、「財務報告に係る」という点です。見るべきところは、あくまで財務報告に関わる部分です。それ以外のシステムは、同じレベルでは見られません。つまり、会社にあるツールのすべてが対象ではありません。財務報告に影響するかどうかが、最初の線引きになります。

ITに係る内部統制は3種類ある

ITを対象とする内部統制は、主に次の3種類です。全体像を図にすると、以下のようになります。

  • IT全社的統制
  • IT全般統制
  • 情報処理統制（IT業務処理統制）
内部統制の全体図（IT全般統制とIT情報処理統制の位置づけ）
内部統制の全体図（情報システム監査実践マニュアルを基に筆者作成）

3種類の違いは、内部統制とIT統制の違いで整理しています。この中で、監査人との話がいちばん分からなくなりやすいのが、IT全般統制です。

IT全般統制の定義と、4つの領域

IT全般統制は、監査基準委員会報告書315で、次のように定義されています。

IT環境の継続的かつ適切な運用を支援する企業のITプロセスに係る内部統制

正直なところ、初めて読んだときは、何を言っているのか分かりませんでした。要するに、こういうことです。

システムやITインフラが、きちんと動いているという前提として、会社の体制がちゃんとしているか。

この「体制」は、主に次の4つの領域で見られます。

  • 変更管理（開発・変更・保守）：誰でも本番のプログラムやデータを書き換えられる状態になっていないか
  • 運用管理：システムの運用プロセスや、障害・インシデントへの対応が記録され、管理されているか
  • アクセス管理：誰が、どのシステムに、どんな権限でアクセスできるかが管理されているか
  • 外部委託管理：システムの運用を委託している先の統制を、確認できているか

また、情報処理統制（業務処理統制）は、IT全般統制が対象期間を通じて有効であることを前提にしています。前提が崩れていれば、業務処理の統制に依拠することが難しくなります。そのため、IT全般統制の検証が必要になります。4つの領域の全体像は、IT全般統制（ITGC）とはで詳しく解説しています。

監査人と話が噛み合わない原因は、ツールを知らないこと

では、なぜ話が噛み合わないのでしょうか。原因の多くは、技術の難しさではなく、現場で動いているツールの名前と役割が、分からないことにあります。

エンジニアは、AWSやGitHubといったツールを日常的に使っています。一方、経理担当者や会計士は、ツールに触れたことがないことも多く、監査人が「ブランチ保護は設定していますか」と言っても、何のことか分かりません。

分からないまま進むと、何が起きるでしょうか。監査人の質問の意図を理解できないので、会社側に判断の軸がなく、言われたことをそのまま受け入れるしかなくなります。その結果、現場の運用に合わない統制ができあがり、回らなくなります。実際、監査人の言いなりになって、現場に合わない内部統制ができあがってしまうケースも、ないわけではありません。

一方で、監査人も、ツールについて網羅的な知識を持っているとは限りません。つまり、機能と役割を説明してもらえれば理解できる、という部分も多いのです。ツールの発展は著しいので、監査人側の理解が追いついていないケースがあるという話も耳にします。だからこそ、会社側が、ツールの役割を4つの領域に結びつけて説明できることが、監査対応の質を左右します。

監査人の見方は、次の3ステップに整理できます。

STEP1ツールの機能と役割を知る（何のために使っているのか） → STEP24つの領域のどれに当たるかを結びつける → STEP3誰が・いつ・何を承認したかの証跡が残っているかを確認する

ツール別に見る：監査人が確認するポイント

ここからは、IT全般統制の監査で使われる代表的なツールを、4つ紹介します。細かい機能は、必要になったときに調べれば十分です。大切なのは、そのツールがどの領域を担っているかという基本です。先に、対応を一覧にしておきます。

ツール 変更管理 運用管理 アクセス管理 外部委託管理
クラウド（AWS・GCP・Azure） － ○ ◎ ◎
バージョン管理（GitHub等） ◎ － ○ －
テストツール ◎ － － －
バッチ処理のツール ○ ◎ － －

◎：主に確認される　○：関連して確認される　－：主な確認対象ではない。この表は、本記事と関連記事で解説した範囲を、筆者が整理したものです。実際の評価範囲は、会社のシステム構成や監査人の判断によって変わります。

クラウド（AWS・GCP・Azure）

クラウド会計ソフトなど、「クラウド」という言葉はよく耳にします。では、クラウドとは何でしょうか。代表的なクラウドサービスであるAWSは、次のように定義しています。

クラウドとは、ニーズに応じて IT リソースをインターネット経由により従量制料金で提供することを指します。

出典：Amazon Web Services（AWS）「クラウドとは」

代表例としては、AWSのほかに、Google社のGoogle Cloud Platform（GCP）や、マイクロソフト社のAzureがあります。昨今のWebサービスは、こうしたクラウド上に構成されることが多く、かつて自社で保有して運用していたオンプレミスのサーバーやデータベースが、クラウドに置き換わりつつあります。基本的には、次のようなインフラが、クラウド上に置かれるイメージです。

  • サーバー
  • ネットワーク環境
  • データベース

便利な反面、クラウドには特性ゆえのリスクがあります。まず、サーバーなどを簡単に増設できるので、設置や運用の管理体制を整えないと、システム環境そのものを管理できなくなります。平たく言えば、「エンジニアなら誰でも簡単に触れるようになるので、管理体制が定まっていないと危険度が高い」ということです。

監査人が確認するのは、主に次の点です。

  • アカウントと権限の管理：特に、アカウントの付与権限を持つ特権IDの管理です。誰が特権IDを持ち、どう管理されているかが確認されます（アクセス管理）
  • 増設・設定変更の管理体制：サーバーやネットワークの構成を、誰がどう変えられる状態になっているか（運用管理）
  • 提供会社のSOCレポートの有無：クラウドの提供会社は、相応の物理セキュリティ体制やメンテナンス体制を構築しています。その体制が有効であることを証明するために、多くの提供会社がSOCレポートを提供しています。IT全般統制の要素の一部を、SOCレポートで代替できることも多いです（外部委託管理）

システムを構築する段階で、「SOCレポートはあるのか」を考えておくと、後の監査対応が楽になります。SOC1レポートの見方は、SOC1レポートとはで解説しています。アカウント管理の実務は、アカウント棚卸とはを参考にしてください。

監査法人の言葉が、現場に伝わらないと感じている方へ

月次決算・IPO準備・IT統制の実務知見を、月1回メールでお届けします

無料でメルマガを受け取る

バージョン管理システム（GitHub・Bitbucket・Backlog）

バージョン管理システムは、エンジニアが作成したコードなどのバージョンを管理するソフトウェアです。代表例は、GitHub、Bitbucket、Backlogなどです。具体的には、次のようなことができます。

  • コード変更のログや、ソースコードのレビュー機能を持っている（変更されたことの証拠として残せる）
  • プルリクエストにより、ソースコードの相互レビューや、本番環境へのマージを管理できる
  • 開発のタスクと、コードの変更を紐づけられる

自社開発のシステムが財務報告と密接に関わっている場合、IT全般統制では、コード変更の管理が必ず求められます。そのため、バージョン管理システムの導入は、ほぼ必須だと考えて差し支えありません。

監査人が確認するのは、変更管理の次の4点です。

  • 変更の要件（なぜ変えるのか）が記録されているか
  • 申請者以外の承認者が、レビューして変更内容を承認しているか
  • 本番環境へ反映する前に、テストが行われているか
  • 本番への反映が、承認の後に行われているか

GitHubのプルリクエストは、この4点をログとして記録するために使われます。ただし、使い方を間違えると、証跡として不十分になります。たとえば、メインブランチへ誰でも直接pushできる状態や、プルリクエストの作成者が自分で承認できる状態は、少人数のスタートアップで、よく見るものです。設定の方法は、IT全般統制の変更管理で解説しています。

テストツール（Jenkins・TestRail・Selenium）

テストツールとは、システムなどのプログラムから、欠陥を見つけ出すためのツールです。Jenkins、TestRail、Selenium が代表例です。自動テストのツールを使う場合もあれば、Excelのチェックリストを使った手動テストで行う場合もあります。

テストツールを考えるうえで大切なのは、システムが実際に使える状態になる前（デプロイ前）に、どれだけテストの体制を作れているかです。方法は、現場によってさまざまです。ただ、監査人が確認するのは、変更管理の一部として、次の点です。

  • テスト内容の管理と承認：何をテストし、その結果を誰が承認したかが、記録されているか
  • バグの重要度の評価：テストで見つかったバグを、どう評価しているか
  • チケット（タスク）の優先度の判断：評価に基づいて、対応の優先度を決めているか

テストをしていても、承認の記録が残っていなければ、監査では「テストをした」ことを示せません。自己点検の入口には、IT全般統制チェックリストが使えます。

バッチ処理のツール（AWS Lambda・Cloud Scheduler・digdag）

バッチ処理とは、一定量（または一定期間）のデータを集めて、一括で処理する方法です。たとえば、月次の売上データ、販売データ、人事労務データなどを、一定期間ごとにまとめて処理します。アプリケーションを自動で実行する場合にも使われます。代表例は、Cloud FunctionsとCloud Scheduler、AWS Lambda、digdagなどです。

バッチ処理は自動で実行されるので、定期実行の方法や、エラーが出たときの通知の仕組みを、あらかじめ決めておく必要があります。システム監査人は、次のような点を確認します。

  • そもそも、バッチ処理は何のツールで行っているのか
  • エラーが出たとき、どう対処するのか
  • エラーの後の変更は、どのように管理しているのか（変更管理）
  • 定期実行は、どのようにプログラムされているのか

エラーが出たときの対応の記録は、運用管理の領域で見られます。運用の管理でよくある落とし穴は、インシデント対応で「やってはいけないこと」にまとめています。

ツールと4領域の対応表：監査対応の準備の進め方

ここまでのツールは、あくまで代表例です。実際の会社では、業務ごとに別のツールが使われています。だから、監査対応の準備では、ツールの説明を暗記するのではなく、自社のツールを、自分で4つの領域に当てはめる作業を先に済ませておくのがおすすめです。進め方は、次の3ステップです。

  1. 使っているシステム・ツールを一覧にする。ベンチャー企業では、「現場が勝手に登録していた」「個人アカウントで登録していた」というケースも珍しくありません。だから、まずシステムの一覧を作り、会社で使っているものを洗い出します。
  2. 財務報告に関わるものを絞り、4つの領域に結びつける。先ほどの対応表を参考に、各ツールが変更管理・運用管理・アクセス管理・外部委託管理のどれを担っているかを書き出します。
  3. 領域ごとに、証跡がどこに残るかを確認する。「誰が・いつ・何を承認したか」が、どのツールのどこに残っているかを、実際に開いて確かめます。

特に3ステップ目が重要です。「設定していること」と「機能していること」は、別物だからです。設定は入っていても、運用が定着していなければ、証跡は途中で切れてしまいます。自社側のIT全般統制がどこまでできているかは、ITGCチェックリスト（自己点検用）で把握できます。

実務で迷いやすい3つのケース

ここからは、実務で特に判断が難しいと感じるケースを3つ取り上げます。正解が定まっていない論点も含まれているので、私自身も試行錯誤している部分として読んでいただければと思います。

SOCレポートがない委託先をどう評価するか

クラウドや会計システムの委託先が、SOC1レポートを取得していないことがあります。この場合、監査法人はSOC1レポートに依拠できないので、別の方法で委託先の内部統制を確かめる必要が出てきます。具体的には、追加のヒアリングや、証跡の個別確認、場合によっては委託先への往査です。いずれも、時間と工数がかかります。

実務では、SLA（サービス水準の合意）を確認することで、委託先の評価を代替することも多いです。ただ、SLAは、稼働率や対応時間といったサービスの水準を約束するものです。多くの場合、委託先の内部統制が実際に運用されていることまでは、示してくれません。だから、SLAを見るだけで済ませると、監査で「何を根拠に委託先を評価したのですか」と聞かれたときに、説明できなくなるおそれがあります。

私は、ここをきちんと見たいと考えています。考え方としては、委託先の運用体制、変更や障害の記録の残し方、アクセス権限の管理を、質問や証跡で確認し、その結果を記録に残しておくことです。SOCレポートがない場合の影響は、SOC1レポートとはで詳しく解説しています。

ノーコードツールで「統制は取れている」と言われたとき

ノーコードツールで業務システムを作っている会社では、「統制は取れています」と説明されることがあります。ところが、実際に確認していくと、統制が取れていないケースが多く、対応がかなり大変になります。

なぜ、こうしたことが起きやすいのでしょうか。ノーコードツールは、業務部門の担当者が、画面から直接変更できることが多くあります。そのため、変更の承認やテスト、履歴の記録といった、通常の開発プロセスに組み込まれているはずの手続きが、プロセスの外に置かれやすいのです。誰が編集権限を持っているのかも、把握されていないことがあります。

確認するポイントは、バージョン管理のときと同じです。

  • 変更の履歴が、システムに残っているか
  • 変更を承認する人が、変更する人と別になっているか
  • 本番に反映する前に、テストが行われているか
  • 編集権限を持つ人が、一覧で把握できているか

「取れています」という説明だけで監査を迎えると、証跡を出せず、不備として指摘されることになります。説明と実態が合っているかを、実際の画面で確かめておくことが、最も重要です。

AIを開発や業務に組み込む場合の統制

最近、特に難しいと感じているのが、AIを開発や業務に組み込んでいる場合の統制です。従来のシステムと違って、AIは同じ入力でも出力が変わることがあります。そのため、これまでの変更管理や運用管理の考え方を、そのまま当てはめられません。私自身、この点をどう進めていくべきか、まだ考えている途中です。

考え方の整理は、IT全般統制にAIのリスクをどう組み込むかにまとめています。AIの利用ケースをまず棚卸しして、4つの領域に当てはめていく、という順番です。

IT全般統制の整備・運用をご検討の方へ

IPO準備や上場企業の内部統制の現場で、IT全般統制の構築とシステム監査のご相談を承っています。お気軽にご相談ください。

無料相談・お問い合わせ

まとめ

IT全般統制の監査で、監査人が見ているのは、ツールの名前ではなく、そのツールが変更管理・運用管理・アクセス管理・外部委託管理のどこを担っているかです。クラウドはアクセス管理と外部委託管理、バージョン管理とテストは変更管理、バッチ処理は運用管理、と結びつけて説明できれば、監査人との会話は成り立ちます。

まずは、自社で使っているツールを一覧にして、4つの領域に当てはめてみてください。そのうえで、「誰が・いつ・何を承認したか」の証跡が、どこに残っているかを確かめるところから始めるのが現実的です。

ただ、システム監査人も、ツールの理解が十分とは限りません。ツールの発展は著しく、理解不足のまま監査に臨んで、クライアントに迷惑をかけてしまうケースも耳にします。システム監査を依頼するときは、この記事に書いたような内容を正確に理解している方を担当にできると、失敗は起きにくいと思います。とはいえ、システム監査人は、担当者によって差が出やすい面もあり、選ぶこと自体が難しいのが現状です。

当事務所には、システム監査技術者の資格を持つ公認会計士がいます。会計・税務だけでなく、業務プロセスの改善やシステム導入、IPO支援にも取り組んでいます。データサイエンスの知識もあり、エンジニアとの連携もできます。システム構築やシステム監査で迷われている場合は、お気軽にお問い合わせください。

関連記事

※プログラミングに関する書籍も書いています。気になる方は、こちらもご覧ください。

現役公認会計士が解説！GASで自動化する経営管理（技術の泉シリーズ）

稲垣大輔／インプレスR&D

Amazonで詳細を見る

おすすめ記事

一覧へ