全般統制は業務処理統制の土台
ITに係る業務処理統制の具体例
ITに係る業務処理統制の例を挙げ、説明していきます。
最近では、新規の受注が取れた後、契約書の情報を請求管理システムに入力すると、そこから請求書の発行、請求データの会計システムへの連携、売上高に係る仕訳の生成まで自動でなされるものが多くなっております。
つまり、契約書の情報を正しく請求システムに入力さえできれば、売上高の正確性、網羅性、実在性などのアサーションが担保されることになります。これは、ITによってエラーが防止されており、業務プロセスに組み込まれているため、「ITに係る業務処理統制」と呼称されます。
ITに係る統制を他の統制と区別する意義
ITに係る統制は、プログラムに従って実行されているため、ある1時点で適正に運用されていることが確認されていれば、期中を通じて適正に運用されていると判断することができます。監査法人の内部統制監査の運用テストでも、ITに係る業務処理統制は原則一時点でしかテストしません。
これは、内部統制を構築する側、監査する側の両方にとって非常に重要なポイントです。
人の手によって実施される他の業務処理統制の場合、期中を通じて適正に運用されている心証を得るには、期中を通じて広くサンプリングテストを実施しなくてはなりません。
全般統制が有効でないと業務処理統制に依拠できない
入力された契約情報から売上高に係る仕訳を自動で生成するプログラムが適切に稼働していたとしても、プログラムが容易に書き換えられてしまう状況であったり、出力されたデータを格納するデータベースに容易にアクセスして修正できてしまうようだと、ITに係る業務処理統制の有効性に対して心証を得たとしても、それに依拠することはできません。
このように、業務処理統制の有効性の前提となる統制を全般統制と言います。会計、請求、給与、勤怠、経費システムなど、財務報告には多数のシステムが関連するため、ITに係る全般統制について慎重に検討することが必要になります。
「ITに係る全般統制」の評価例と前提環境
監査基準では4つの評価例が挙げられている
「財務報告に係る内部統制の評価及び監査の基準」においては、下記の4つの評価例が挙げられています。
- システムの開発、保守に係る管理
- システムの運用・管理
- 内外からのアクセス管理などシステムの安全性の確保
- 外部委託に関する契約の管理
監査基準が想定している環境は現代に適合していない
基準が述べていることを理解するためには、数十年前のシステム環境を思い起こす必要があります。
かつての主流なシステム環境は、経理スタッフなどが操作するクライアントコンピュータにソフトウエアをインストールし、社内サーバーが設置され、社内サーバーにデータベースが構築されるオンプレミス型でした。社内サーバーのメンテナンスは一定の専門知識が必要となるため、外部の業者に委託することが一般的でした。
そうすると、インストールされているプログラムのアップデートや障害対応、社内サーバーのバックアップ体制などは、ユーザー企業とサーバーのメンテナンスを依頼する外注業者が主体的に対応することになります。データベースも社内にある訳です。
基準が、システムの開発、保守、運用、管理、及びアクセス管理などを評価項目の筆頭に挙げてくるのは非常によく理解できます。しかし、現代において財務報告を取り巻く環境は大幅に変化しております。
クラウド環境下の財務報告に係るシステム状況
現在においては、財務報告に関連するシステムはクラウド環境で提供されることが多くなっております。クラウド型のシステムは、情報連携のしやすさから内部統制の構築がしやすく、IPO準備においてはクラウドERPシステムの導入を当然のように求められるからです。
SaaS型のプロダクトを提供しているソフトウエアベンダーも、基本的にサーバーを社内で保有しておりません。AWSのようなIaaS型クラウドサービスを利用してサーバーを構築しており、AWSにソフトウエアのプログラム、データベースがアップロードされております。
つまり、クライアントコンピュータはブラウザを介してAWSに格納されているデータを表示しているに過ぎず、従来社内で管理されていたソフトウエアプログラムやデータベースは、AWSに保存されていることになります。
クラウド環境下のITに係る全般統制
バックアップ機能などはクラウド事業者が提供
データベースのバックアップやセキリティ機能については、クラウド環境ではクラウド事業者のサービスとして提供されており、ベンダーが適切な設定を行っていれば問題はないものと考えられます。ユーザーがサーバールームに立ち入ることはできませんので、物理的な干渉を考慮する必要性もあまりありません。
かつて、ユーザーの社内で実施されていたITに係る全般統制は、AWSの機能などを使用して実施されるようになったと言えます。
AWSのサービス自体に対して手続きを求められる可能性はあまりない
理論上はAWSなどの一連のサービスが適切に提供されていることを確かめなければ業務処理統制に依拠できないことになりますが、これらに対しリスクを高めに評価し、何らかの手続きの必要性が主張された例は聞いたことがありません。
かなりの大手が提供しているサービスであり、世界的に広く受け入れられているためだと思われます。ただ、これらの機能も適切に設定をしなければ意義を持たないのは当然であり、クラウド環境ではベンダー側が設定を行います。そのため、ベンダー側の対応状況について言及されることはあります。
システムの開発、変更、及び運用に係る統制
クラウド環境下では、プログラムを複写して提供するのではなく、ユーザーはAWSにアップロードされた同一のプログラムにアクセスしている状態です。
そのため、ベンダー側でプログラムのバージョン管理、移行管理、テストを厳重にしていることが想定され、Git Hubなどのバージョン管理システムを使用して更新がなされるため、問題があればベンダー側で復旧がなされます。基準上の全般統制は自社開発システムも視野に入れた記載となっているため、現在のシステム環境を説明できれば、最低限の説明や確認作業で済むことがほとんどです。
データのバックアップ体制も、ベンダーのホームページで設定状況が公表されていることが多く、一読して監査人に伝えれば済みます。
アクセス管理に係る統制
財務数値は、会計システムで作成され、サーバーのデータベースに格納されますが、サーバーを管理している企業のエンジニアであれば、会計システムを介さなくてもSSH接続などでサーバーに直接接続し、データベースの中身を閲覧したり、書き換えたりすることが可能です。
クラウド環境下では、サーバーに直接アクセスできるのはベンダー側のエンジニアになります。ベンダー側のエンジニアが不正の意図をもって特定企業のデータベースを書き換えたりする動機は想定できないため、あまり監査の俎上にあがったことはありません。ユーザーが有効な統制を構築することは難しいでしょう。
純粋に理論を突き詰めれば、委託先の統制として心証を得る必要があるということになるのかもしれませんが、データベースへのアクセスログはAWSにインストールされたWEBサーバーが吐き出すため、それをユーザーが入手することは通常不可能です。当然ですが、データベースへ直接接続した場合には、会計システムなどのアプリケーションを経由しないため、会計システムにログを記録する機能が実装されていたとしてもログに残りません。
ID棚卸統制
現代におけるITに係る全般統制の主役は専らID棚卸統制です。ID棚卸統制は、会計システムなどの重要なシステムのID、及び権限が適切に付与されていることを担保する統制です。定期的にIDと権限の一覧を閲覧することにより統制が運用されます。
仮に、営業成績に対して強いプレッシャーを有している役員、従業員が会計システムのIDや強い権限を有していたり、退職した従業員がアクセスできたりすれば、ITに係る業務処理統制に依拠できないと判断される可能性は十分に考えられます。
IPO準備企業を想定した会計システムなどでは、IDと権限の変更ログを出力できるようになっておりますので、こちらを活用して統制活動を実施することになります。
SOCレポートの入手
ベンダーに依頼するとSOCレポートを入手できることがあります。
ベンダー側で適切に内部統制を整備・運用しており、SOCレポートにより裏付けることができるのであれば、有力な心証となりますので、基幹システムを選定する際はSOCレポートを入手できるプロダクトを選択した方が無難です。