キーコンとIT統制

IT統制の評価が必要となる場合

キーコントロールを識別する過程の中で、ITに係る統制（IT業務処理統制）がキーコントロールとして識別されれば、そのIT基盤の全般統制を評価対象とするかどうかを検討する。ここで重要なことは、IT基盤が会社にあるからそれを評価・監査するということではなく、あくまでも一連の財務報告プロセスにおけるITの位置づけを見極めた上で、重要なものを選別して評価・監査するという点である。

IT基盤の識別

評価・監査対象とすべきIT基盤の識別は一般に次のように行なわれる。すなわちそれぞれの段階での判断が加わるので、すべからくITを評価・監査しなければならないわけではない。

評価対象とされた業務プロセスを識別

基本的には企業の主たる業務に関わるプロセスすなわちバリューチェーンと呼ばれる部分を識別すべきですが、日本の制度では、いわゆる｢三勘定」（売上・売掛金・棚卸資産）とされているので、これに係る部分を識別する。なお、たとえばデリバティブなどを大規模に行なっている場合には、特定された固有のリスクがあるはずなので、三勘定以外にも例えば資金運用なども対象となる。

支える自動化された統制活動

業務プロセスのフローチャートなどによって、財務報告に係るキーコントロールを識別する。ここが最も重要なところで、単にシステムを使っているからということではなく、財務報告に重要な影響を与える数値が生成加工される手続のうちITにより自動化されている部分があるか否かをきちんと識別するべきである。自動化の中にも、単なる転記、集計といった自動化から、複雑な演算（ブラックショールズモデルによるオプション価値の計算など）まで色々とあるので、その依存度、誤りのリスクなどを考慮する。一般には、ITにより自動化された部分のうち、最も大事なのは、人と一体となって機能する統制（いわゆるキーレポートの生成）のところである。キーレポートとは、ITから出力される各種帳票（画面を含む）のうち、人がそれを見て何らかの判断をして何らかのアクションを起こすことが期待されているものである。そのアクションには、システム上の会計データに対して必要なフィードバックをするためのものもあれば、会計には直接関わらないが影響すると想定されるものなどが含まれる。たとえば、

• 一日の処理件数を出力して、手元にある入力原票の枚数と照合して、齟齬があればその原因を追究して対策をとる。
• 滞留売掛金のリストを出力して、必要な回収措置をとる。
• 異常なアクセスが検出された場合に、警告を発してアクセスの正当性の確認や、不正アクセスへの防止策をとる。

それを実現するアプリケーションシステム

自動化された処理のうち、キーコントロールに相当するものがあった場合には、それを実現しているアプリケーションシステムを識別する。

そのアプリケーションシステムを機能させる各種基盤

俗にプラットフォームと言われるアプリケーションが稼動する「システムの単位」を識別する。Operating System、データベース管理システム、ハードウェア構成、ネットワーク構成などから共通性を判断する。

それらの機能を保証するIT全般統制を評価する

識別されたIT基盤に係る、開発管理、変更管理、運用管理、アクセス制御について評価する。

IT全般統制とは

 IT環境を適切に保つための統制

IT全般統制とは何かについては、公認会計士監査の基準となっているＩＴ委員会報告第３号「財務諸表監査における情報技術(ＩＴ)を利用した情報システムに関する重要な虚偽表示リスクの評価及び評価したリスクに対応する監査人の手続について」（通称IT3号）にも明確に記載がありません。あえて定義らしい定義を選ぶと、第13項に次のような記載があります。

全般統制は、取引、勘定残高及び開示における情報の信頼性を確保すること、及び業務処理統制の継続的な運用を確実にすることを間接的に支援するものである。

これだけ世の中を騒がせながらその概念定義がないというのは、よほど世間に共通認識があるものと考えられているのでしょうか。確かに会計監査の世界では、EDP監査という用語が使われていた80年代頃には既に全般統制という用語は使われていました。

しかしそれではあまりに不親切と考えたのか、IT3号を解説したＩＴ委員会研究報告第31 号（31号とかIT3号Q&Aと呼ばれる）Q2の１には次のような解説が補足されています。

ネットワークの運用管理、システム・ソフトウェアの取得及び保守、アクセス・コントロールやアプリケーション・システムの取得、開発及び保守に関する統制活動が含まれており、ＩＴを利用した情報システムの運用・管理に関する統制活動のこと

すなわちIT全般統制とは次のような定義ができるでしょう。

ITを用いた業務処理の継続的な運用を確実にし、
（財務）情報の信頼性を確保するために行われる、
情報技術を利用した情報システムの運用・管理に関する統制活動

財務報告にかかる内部統制という観点からは、（1）財務情報を作成する基礎となるデータを適切な形に生成・維持・加工・廃棄する仕組みが必要であり、また（2）そのようにして作られたデータを悪意ある変更や消去（すなわち改竄）から守ることも必要^[1]です。

（1）の目的は通常の場合、ITが設計で意図した通りに作動しまた人間が設計で意図した通りにITを利用している限りにおいては、設計で意図した結果をもたらすものと考えられます。したがって財務報告の信頼性の前提となる情報の信頼性を確保するためには、設計意図通り（仕様上の問題をカバーすることも含めて）にITが機能するように環境を整備する必要があります。これがIT全般統制の一つの側面です。

さらに（2）の目的は、それ自体がIT全般統制のもう一つの側面であるとともに、（1）の目的を阻害しないようにデータやプログラムのおかれている環境を整備する必要が生じます。

 IT全般統制のレベル感

IT全般統制の目的を理解すれば自ずと解ることですが、IT全般統制はIT業務処理統制と比べると、どの程度の統制を整備していればそれが有効（すなわち財務報告上のリスクを合理的に低減できる）と言えるのか曖昧模糊としています。

例えば経理部員が３人しかいないような小さな会社で、仕訳入力をしたら試算表や元帳などが印刷されるようなPC用のソフトウェアを使っているようなケースで、例えばパソコンルームへの入室制限や個人別IDのアクセス権限の変更管理などが必要でしょうか。ソフトウェアをPCに設定する人とそのPCを利用する人との分離が必要でしょうか。

換言すれば、IT全般統制はそれ自体が財務報告上のリスクに対して直接的に作用するものではないため、先ずはどの程度のリスクを想定してどの程度の全般統制を整備する（裏返せば、どの程度の業務処理統制が機能しないで誤ったデータが生成されるリスクや、悪意によってデータ等が改竄されるリスクを許容する）か経営者による判断が必要ということになります。

一言で経営者による判断というのは簡単ですが、経営者が直接判断するというよりも、ITへの投資予算方針や業務依存方針などを通じて間接的に判断されていると考えればよいでしょう。

私見ではありますが、結局は、不正をどの程度まで想定（類型、頻度、金額）するかということと、不正や誤謬による財務報告上の許容できない虚偽記載がきちんと発見できるかどうかということと相俟って議論しなければ、IT全般統制の深度を議論しても建前論に終始してしまうことになるでしょう。不正や誤謬は防止･発見できるに越したことはありませんし、その可能性はゼロということは論理的に不可能ですので、「リスクが心配だ、だから統制が必要だ」という一側面だけで議論していると、「必要な」統制は一方的に膨らんでいく一方です。制度はリスクの「合理的な軽減」を期待しているに過ぎませんが、システムを業として担う人は、何とか完璧に防止発見しようと努めるでしょう。しかし必ずしも予算がつく（つまり経営者が資源を配分してくれる）とは限りません。また、財務報告上の重要な虚偽記載を防止発見するための統制のレベルと、会社の他の業務を適切に行うための諸活動を維持する統制のレベルとは、自ずと資源配分の重点が異なるはずです。そういった諸々の条件をバランスよく理解して落とし処を探ることが、リスクの評価という行為に他なりません。経営判断とは、リスクとリターンとの比較考量ですから、必ずしもリスクの高い領域が機械的に優先措置されるものとも限りません。それらを会社の中できちんと議論して論点を明らかにして経営者に判断を仰ぎ、さらに経営者の判断を取締役会等において様々な知見を通じて批判検討するという状態が、制度が想定している健全な内部統制の姿であり、ITに関して言えば「IT全社統制」と言われている分野の論点です。

※ちょっと一言

• ITACで25件サンプルテスト頑張る覚悟があるなら、ITGC評価不要。別に大層なものじゃないと思う - 名無しさん (2010年12月21日 10時23分50秒)
• そうですね。統制評価に「こうであればよい」とか「こうでなければならない」というのはありませんね。あくまでリスク判断によって変わるものですから。 - 著者より (2014年01月12日 17時48分09秒)

ITGCでキーコントロールといえばGAIT

IT全般統制の評価範囲を決定するに当たっては、The GAIT Principles http://www.theiia.org/guidance/technology/gait/ が発行されているものの中で最も簡潔明瞭な指針となるだろう。^[2]

GAITでは４つの原則が示されている。以下意訳すると、

原則１

IT全般統制プロセスにおけるリスクの認識とそれに関係する統制を識別するには、重要な勘定やそれに関係するリスクやキーコントロールを識別したトップダウン＆リスクベースアプローチの延長として行なわなければならない。

チェックリスト方式などは非効果的で非効率である。

原則２

識別すべきIT全般統制リスクとは、財務会計上重要なアプリケーションとデータにおける重要なIT機能に対して影響を与えるものであるべき。

トップダウン＆リスクベースアプローチとは、業務プロセスにおいて虚偽記載をもたらすリスクのあるポイントとそれに関係するキーコントロールを識別する。その上で、それがIT機能（すなわち、自動化されたキーコントロールや、キーレポート、重要な財務データ）に拠っている場合に、そのアプリケーションは財務会計上重要となるから、IT全般統制プロセスの欠陥からもたらされるIT機能のリスクを識別しなければならない。

原則３

識別すべきIT全般統制プロセスのリスクは、業務プロセス中にあり、かつ、各ITレイヤ（アプリケーション、データベース、オペレーションシステム、ネットワーク）上に存在している。

原則４

IT全般統制プロセスにおけるリスクは、IT統制目標の達成によって軽減されるものであり、個々別々のコントロール手続ではない。

各IT全般統制プロセスには、IT統制目標を支援する手続が埋め込まれている。IT統制目標とは、

• システムが実装される前に、適切にテストされ評価される
• データは未承認の変更から保護されている
• 運用における支障や事故は、適切に対応され、記録され、調査され、解決される

先ず第一に、財務報告に関連するIT統制目標を識別することが肝要であり、その後にその統制目標を満たすIT全般統制のキーコントロールを識別すべきである。識別されたIT統制目標に関係ないIT全般統制手続は、たとえ重要であっても、ICFRの評価対象に含める必要はない。

IT統制における留意

 ITを用いた統制は「予防的」側面が強い

すなわちITで生成される情報を活用・分析する手続がないところで、ITの統制を議論しても、それは「財務報告の適正性」という目的からは外れたIT統制の確立を自己目的化した議論になる可能性がある

 全体感が必要

IT部門とユーザ部門との「統制の擦り合わせ」「統制のバランス」を見ている人がいないとそれぞれに閉じた議論が全体の不効率に繋がる。特にITを専門にする人と会計を専門にする人との協議は効率的効果的にキーコントロールを選び評価する上で重要である。IT専門家の統制に対する目標は、コントロールによってあくまでも統制による完全なデータ処理をもたらすことを目指しつつも予算や優先順位などの経営者による制約があることを前提にその中でベストなソリューションを提供することを使命としている。他方、監査に求められる保証はあくまでも合理的保証であることから、常に重要性の判断が加わる。したがってIT部門だけにキーコントロールの選定を任せるのではなく、経営目標と照らし合わせるというフィルターをかけて、最終的には経営者の意思としてのキーコントロールの選定としなければならない。

蛸壺に陥る原因と考えられるもの

• 知識言語の違い「IT知識の壁」vs.「会計知識の壁」
• 業務思想の違い「形式知による自動処理」vs.「暗黙知や経験を活用した手処理」
• 経営者が意思と目的を明確にしないと蛸壺にこもりがちになる可能性が高い。

教訓

• 内部監査部門は全体としてリスクが軽減されているかどうかを言う観点（＝経営者の視点）をもち、経営者に提言することが期待されているのではないか。

• 財務報告の適正性を検証するに当たっては、IT統制に依拠する形で検証するのか、IT統制よりも人間統制を重視した形で検証するのかは、評価者、監査人双方にとっては重要な戦略といえる。

 IT統制の評価結果の判断

IT統制の評価結果をどう受け止めるかも難しい問題だろう。特に、監査理論の世界では、「IT全般統制が有効でない→IT統制に依拠できない」という一方通行な判断がされることが多いようだ。しかし、全体観という意味では、ビジネスおよび財務報告におけるITの影響度とITに要求されるリスク軽減レベルはパラレルな関係にある。したがってある特定の統制に不備があるからといって、財務報告リスクが合理的水準にまで軽減されていないと一方的に言い切ってしまってよいものかどうか慎重に判断しなければならない。それは、IT統制に不備がないから不正や誤謬は発生していないとストレートには判断できないことと意味は同じである。統制が有効であるということは、財務報告に関するリスクが合理的に軽減されているということが期待できるということであって、実際にどうなのかは実証テストを経て見ないと分からないし、だからこそ監査では内部統制がたとえ有効であったとしても重要な勘定に対する実証テストが省略できないのである。監査における内部統制評価の目的の原点に立ち返れば、もともとは実証テストの範囲を決定するためのリスク評価手続であることを確認しておきたい。

参考

IT部門と経理部門との業務に対する思考視点視野の違いを整理してみたい。

※ちょっと一言

• 経営者によっては、ＩＴから非ＩＴ化へという流れもあるでしょう。10年ぐらいまでＩＴ不要論がありましたが、それを思い起こします。 - shibayan (2008年03月13日 20時49分52秒)
• IT投資は一旦はじめたら中々やめられませんからね。投資効果は見極めるべきですね。 - なわ (2008年03月16日 07時35分28秒)
• ＩＴ投資をすることは、悪いことではないですが、それが、財務諸表の作成にどう係ってくるの検討を、投資段階から慎重に判断することがポイントとなりそうですね。 - shibayan (2008年03月16日 12時21分18秒)
• ごもっとも。おそらく今後は開発段階から財務報告への影響を評価するというプロセスが必要になるだろうという話を他所でしました。 - なわ (2008年03月16日 15時09分41秒)
• ITCLCって判りにくいけど、この制度での一番のポイントは、きっとそこですね。 - shibayan (2008年03月16日 18時00分23秒)