IT内部統制の実務～業務処理統制の整備状況の有効性評価

総論：

「整備状況の有効性評価」での作業を「規定の有無を確かめて終わり」「現状をフローチャートやRCMに書いたら終わり」と考えていたのでは、運用テストができないだけでなく、「有効に出来ない」ことが懸念される。

「整備状況」と「運用状況」に分けて有効性評価を行う理由は、理論的にはともかく、実務的に見ると2点考えられる。
１．「運用状況の有効性評価」はいってみれば本番であり、多数のサンプルテストを行う。これをスムーズに行うためには「下見」と「練習」が必要である。
２．「不備」を改善する場合の影響範囲やコストは、「整備状況」に関連するｍののほうが大きいと思われる。システムや体制などの修正が必要になる可能性があるからである。

整備状況の有効性評価とは：

「整備状況の有効性評価」の目的は、実務的にはキーコントロールを選定する（運用テスト「すべき」で、且つ運用テスト「できる」であろう統制活動を絞り込む）ことだと言える。

【整備状況の有効性評価の構成要素と進行】

（１）現状の文書化「こうなっているはず」
（２）評価その１「RCM上での分析」
（３）ウォークスルーによる実地確認「要改善？」
（４）評価その２「運用テストの1件前倒し」
（５）整備状況「有効」の判定（４）で要改善じゃなければ

取引フローの現状の文書化：

デザイン＝「こうなっているはず」という「仕組み」

文書化の着眼点＝リスク発生源である「情報の変換点」
※ここでいう「情報」は仕訳の構成要素となる情報である。（つまり、勘定科目、経常日付、金額）

RCMによる分析：

デザイン評価、およびその結果としての「キーコントロールの選定」においては、統制活動ごとの（１）強弱（２）広狭（３）補完関係に注目する必要がある。
この点でRCMのマトリクス（行列）形式は有意義である。

【キーコントロールの具備要件】
１．強弱、広狭、保管関係、等を考慮して、「リスクを軽減する費用対効果」が高い強制活動であること。
２．テスト手続が意味のある形で、かつ実行可能である統制活動であること。
３．以上の両要件を満たせば、その統制活動は「テスト対象とする費用対効果が高い統制活動である」と言える。

【統制活動の「強弱」の着眼点】
１．業務には例外処理などの想定外処理がつきものだが、防止的統制ではこれに関連する『漏れ』が防げない場合が多い。また内部統制の限界の一つである人間の注意力の限界というべきヒューマンエラーも防ぎきれない。
２．発見的統制は以上のような点を補完できるが、事後に発見できても意味がないという場合もあるし、発見できても原因特定できない場合も多い。

【統制活動の「広狭」の着眼点】
守備範囲が「広い」統制活動は、効率的な統制活動であるから、これをRCMによる分析で洗い出す小t個によって、運用テストなどの有効性評価作業の効率性を大きく向上させることが可能である。

【統制活動の「強弱」と「広狭」：「マクロな統制」の認識】

既存のビジネスリスクに対処するための統制活動は、取引ごとの「防止的」な統制が多く、取引複数に包括的に網をかける「発見的」統制が少ない。
「財務諸表に重要な虚偽記載がない」という目的に照らすと、上記の既存の統制活動は効率が悪い可能性が高い。
マクロな統制は、管理者レベルの統制であるため、効率良く、テスト「すべき」だが「できる」といいきれないところが問題である。

【キーコントロール選定に関する補足】

１．キーコントロールの選定において、「自動化された統制活動」と手作業の統制活動とは、同じプールに入れて検討すべきである。
２．統制活動の「広狭」の検討は他の取引フローとも共通かどうかの検討も忘れずに。
３．防止的統制と発見的統制とは、完全に代替がきくものか？吟味が必要。
（どちらか一方のみへの依存は不健全）

実在実務確認（ウォークスルー）：

【ウォークスルーの目的】

ウォークスルーの目的は、文書の記載内容の確認であると言えるが、記載内容には統制活動も含まれる。この記載が正しいかどうかを確認するのだから、と時点統制テストの性質を持つ。

【ウォークスルーと「運用テスト」の違い】

ウォークスルー＝ある時点におけるその統制活動の実在を評価対象として、順進方向に照合し、1件をサンプルとして、対象の統制活動を多めに実施する。
運用テスト＝ある期間にわたる、その統制活動の継続を評価対象として、順進、逆進のどちらの照合もあり得る。サンプルは複数件であり、対象となる統制活動は、ウォークスルーに比較すると少ない。（キーコントロールのみ）

【ウォークスルーは必須か？】
１．ウォークスルーの実施は必須か？
　法的には経営者の裁量に任されている。
２．実施するとして、毎年実施する必要があるのか？
　変更がなかったということを確かめるのもウォークスルーである。変わっていないということを評価者が確かめ、その記録・証跡を残すことが必要である。

【ウォークスルーと運用テスト1件前倒しの違い】
目的が違う。
ウォークスルーは統制活動が「実在するか」を確認することが目的であり、1件テストは運用テストが「実行可能であるか」を確認することが目的である。

IT内部統制の実務～業務処理統制のスコーピング

総論：

１．キーコントロールとは、「運用テスト」（期間にわたる有効性の検証）対象となる統制活動のこととする。

２．財務会計数値の生成過程全体を「取引フロー」、その実際の処理や統制活動を受ける各局面を「プロセス」と呼ぶ。

３．キーコントロールとなり得るか（財務報告目的で重要な役割を負っているのか）は、会計仕訳までつながる「取引フロー」として、「プロセス」を「つなげて」認識しなければ判別できない。

４．どの業務処理統制（の中の「自動化された統制活動」）をテスト対象にするかは、その取引フローにおいてどの「自動化された統制活動」がキーコントロールであるかと、同義である。

５．ある業務システムの提供する「自動化された統制活動」が、一つもキーコントロールではないとしたら、その業務システムの全般統制は、有効性評価の対象とする必要がなくなる。

取引フローとしての「つながり」：

内部統制記述の文書の（担当組織ごとの）「プロセス」ごとの細分化は、作業実務上やむをえない。ポイントは、それらの文書を「つなげる」ことができるかである。
なぜなら、仕訳に結び付けて考えなければ、どれが重要であるか判断できないはずだから。
「財務報告に係る内部統制」の有効性評価という観点からは、プロセスにおける活動を常に仕訳に結び付けて考えなければ、リスクにせよ統制活動にせよ、どれが重要なのか、特にキーコントロールが何か、を的確に判断しにくくなる可能性が高い。

取引フローの終点＝分析の起点：

「T字分析」（勘定科目ごとの「仕訳パターン」の洗い出し）等による仕訳数値の構成要素分析によって、仕訳パターン別の金額を把握して、量的・質的に重要なものを判別した根拠とする。その仕訳数値の生成過程が「取引フロー」となる。

取引フローの「束ね」：

認識された「取引フロー」の数々は、あくまで「仕訳」としては別のものだったというだけで、その数値生成過程である「取引フロー」上の内部統制は同じかもしれない。
「束ね」られるものなら「束ね」て評価作業のボリュームをへらすにこしたことはない。

「束ね」についてある程度の基準の枠内で迷う場合は、とりあえず「分けて」であれ「一つにして」であれ進めてみて結果で判断するしかない場合もある。この見直しをかけるタイミングを前もって決めておくことも重要である。

取引フローの「始点」：

取引フロー（財務会計情報の生成過程）の、「どこが始点になるか」は、「どこまで遡るか」、つまり「どこまで『しばり』があるか」で決まる。

始点と終点の間に含めるプロセス：

仕訳から逆進して把握した取引フロー上に出てこないプロセスは、仕訳数値に対する直接の関連性は低いと解釈できる。

IT内部統制の実務～IT内部統制の実務とは

リスクベースであること：

必要とされる統制は「リスク」次第で異なり、その「リスク」は企業活動の「環境」と「目的」次第で異なる。

必要とされる統制について、上記の連環による合理的な絞込みや優先度を重視し、必要以上の現場負担が生じることを防ぐアプローチをリスクベースと呼ぶ。

【内部統制の目的の優先度付けの必要性と優先度付けのための判別の必要性】

プロジェクトの対象を「財務報告目的」以外にの目的の内部統制にまで広げる場合には、目的間の優先度付けを可能にしておくことが、プロジェクト管理上も、実際の監査対応の上からも、重要である。

１．従業員としても経営者としても、内部統制プロジェクトを「どうせやるなら」業務改善・品質向上に結び付けたいと思うのは自然なことでもある。

２．「財務報告目的」内部統制への優先度付けを推奨する考え方は、それを否定するものではない。要は、目的ごとのリスクや統制の違いを判別できることが重要である。

【「目的」と「リスク」が重要である理由】

１．「最低限これさえ守っておけばいい」という共通の基準・ガイドラインないしは「静態的な」達成目標（値）はない。「動態的な」プロセスの継続運用が発生目標と言うことになる。

２．やっていることの意義や合理性を見失いそうになったら、「目的」と「リスク」が何であったか、に立ち戻ることが有効である。

【統制ベースではなくリスクベースに】

「統制ベース」だと、「リスクがないから、明らかに必要がない」といような統制までも、必要かのごとく思い込む懸念がある。


全般統制と業務処理統制の関係：

【全般統制と「自動化された統制活動」と業務処理統制の関係】

業務処理統制の中の「自動化された統制活動」の、「時点における有効性」を、「期間にわたる有効性」へと引き伸ばす方法の一つが、全般統制である。

【IT固有の「反復性」の活用】

内部統制が「有効である」と言えるためには、「期間にわたる有効性」の検証が必要であって、ある時点のみの有効性の検証だけでは不足する。
したがって、普通は「複数件の直接テスト」が必要になるはず。
しかし、業務処理統制に含まれる「自動化された統制活動」に限っては、サンプル1件の有効性を「期間全域へ引き伸ばす」ための別の統制＝全般統制が有効に働いている場合は、サンプル1件のテストで事足りる。
「変えない限りは繰り返す」はずだというIT固有の反復性に着目するのが全般統制である。

【全般統制は目的ではなく手段＝＝＞コスパ考慮要】

「手作業の統制活動」であれば「期間にわたる有効性」を検証するには、期間全域にわたる母集団から抽出した複数のサンプルを検証するしか方法はない。しかし「自動化された統制活動」であれば、他にITならではの反復性を提供する統制（すなわち全般統制）の有効性を検証するという方法もある。

【全般統制に依存する費用対効果】

全般統制（の有効性に依存すること）の費用対効果は、その全般統制プロセスが、どのような「キーコントロールとなる自動化された統制」（を提供しているアプリケーション）をサポートしているか、で決まる。

「内部統制監査」と他の監査・認証等との関係：

【会計監査と内部統制監査とにおけるIT内部統制】

類似の実務
（１）会計監査の中の財務報告目的の内部統制の有効性評価＝＝＞対象期間全域にわたる有効性が求められる。
（２）米SOX404条適用会社において、同監査に備えた、財務報告目的の内部統制の有効性評価
（３）「日本版SOX法」における「内部統制監査」に備えた、財務報告目的の内部統制の有効性評価＝＝＞期末日基準での有効性が求められる。

【内部統制の評価実務の差分：「会計監査」と「内部統制監査」

●評価基準（厳しさ）は同じ＝＝＞目的が同じだから
●対象範囲も同じ＝＝＞目的が同じだから
●対象範囲の違い＝＝＞小規模会社などで、監査戦略次第で有り得る
会計監査人がその都度「実証手続き」を実施して内部統制の有効性に「依拠しない」選択が会計監査上は有り得る。（件数が少なくて、そのほうが安上がりな場合）
●手続種類の違い＝＝＞内部統制監査での追加：会社側の手続も評価対象
増分は
（１）企業自身によるテストの手続と結果
（２）上記テストの前提となった分析資料（RCM等）

「会計監査」と「内部統制監査」とを比較した場合に、
１．評価基準と対象範囲は同じ。目的が同じだから。
２．対象範囲は小規模会社などで、監査戦略故の違いは有り得る。

【ダイレクトレポーティング不採用」についての誤解

ダイレクトレポーティングは不採用だがテスティングではない。
レポーティングとは監査報告のことを言っている。米SOX404条対応では、内部統制について外部監査人は二つの報告をしている。（１）「経営者による内部統制評価」に関する監査意見（２）「自らの独自に行う内部統制評価」に基づく監査意見　であるが、ダイレクトレポーティング不採用とは、（２）をなくそうという話。

外部監査人による直接の理解と評価のための直接テストはなくせない。
しかしながら、外部監査人の「直接のテスティング」の範囲が、（１）の範囲（つまり経営者による内部統制評価の実施範囲）に限定されることが狙いである。
ということは、その対象範囲については、事前に企業と外部監査人で合意しておく必要がある。

【IT関連の認証（ISMS/ISO27000、BS7799等）との関係】

１．直接的には、監査（審査）結果やテスト結果を流用できる等のアドバンテージはない。（目的も手続きも異なるから）

２．間接的には、認証のおかげで整備された内部統制の「実体」が、「結果として」監査対応や監査結果に貢献することはあり得る。


【「システム監査」との異同および「内部監査」との異同】

「システム監査」における相違点
１．目的が自由
２．対象選択や手続き内容が自由

「システム監査」における共通点
１．手続種類＝＝＞決まり方が異なるが結果として同じ手続きが選ばれる場合（定番の手続き）

「内部監査」における相違点
１．実施者が限定されるが、目的や対象選択、手続内容はシステム監査以上に自由

「内部監査」と「IT内部統制の有効性評価」との関係

・手続内容（手続種類、時期、範囲）
・その手続を実施する内部監査人のスキル・経験
について外部監査人側の要件を満たせば、内部監査結果に「依存」できる。


１．「システム監査」と「IT内部統制の有効性評価」には、手続に同種のものも多いが、後者の目的ではテスト上の制約がある。

２．内部監査の手続や結果を外部監査に流用するには、内部監査計画段階における内部監査人と外部監査人との意思疎通が重要である。



社外への委託業務：

【社外への委託業務に関する論点】

もともとの原語「外部委託」の「外部」は「サードパーティ」であり、グループ内のシェアード・サービスは含まない。
日本企業を意識した場合、グループ内も含む「社外」委託管理としている。

【社外への委託業務に係る内部統制監査報告書とは】

日本基準では「18号（監査基準委員会報告書第18号　委託業務に係る内部統制の有効性の評価）」、米国基準では「SAS70（米国監査基準書　Statement Of Audit Standards　第70号）」と略称される監査報告書があり、内容は実質上同じもの。
受託側、委託側、監査人の効率化のために、受託業者の内部統制に関する監査手続の定型化を行い、その報告書を委託元企業に配布することで、委託元企業ごとの監査人による監査の繰り返しに代替しようとする仕組み。

【社外への委託業務だというだけで特別な対応が必要か？】

１．まずそもそも「文書化・テストの対象」であるかどうかをチェックする。
２．次に「普通に」文書化・テストができないものかを考える。


エンドユーザコンピューティング：

【EUCであることと、評価対象にする／しないは無関係】

※EUCとは、システム部の管理下にないデータ処理形態の総称とする。

１．EUCであろうとなかろうと、有効性評価の対象になるかどうかは、まず重要勘定からトップダウンで導いた取引フロー（仕訳数値の生成過程）に載ってくる統制活動であると言うことが最低条件であることに変わりはない。
２．マクロやクエリー利用により「自動化された統制活動」であると言えるとしても、時点統制テスト対象（キーコントロール）に該当しなければ、全般統制の有効性評価対象とはなり得ない。

【それは本当にキーコントロールなのか？】

キーコントロールの選定は「そこで間違ったらもう誰も気づかないのか？」という点をよく吟味する必要がある。

IT内部統制の実務～IT内部統制とは何か？

総論：

【IT統制の定義とイメージ】

１．ITの統制とは、ITを取り入れた情報システムに関する統制であり、自動化された統制を中心とするが、しびしば手作業による統制が含まれる。

２．財務報告の信頼性に係るITの統制は、会計上の取引記録の正当性、完全性及び正確性を確保するために実施される。

３．金融商品取引法による内部統制報告制度においては、財務報告の信頼性以外の他の目的を達成するためのITの統制の整備および運用を直接的に求めるものではない。

【ITの統制　全般統制と業務処理統制】

「IT内部統制」のに大分野は全般統制と業務処理統制である。

原文ではGeneral　Controls　と　Application　Controlsでそもそも対応関係がない。
本来は、IT全般（共通）統制に対比してのIT個別処理統制であったと思われる。

全般統制とは何か：

【実施基準「ITに係る全般統制」の定義】

「ITに係る全般統制」の定義上のポイントは、一つは業務処理統制との関係において捉えられていること、もう一つは複数の業務処理統制ないしシステムに関係しているとされていることである。

【「ITに係る全般統制」に関するいくつかの注意事項】

全般統制もプロセスである。「統制」と呼ばれるからには何らかの「リスク」に対応するものであり、それは何らかのプロセスにおいて「何かを誤る可能性」から生じている。

業務処理統制とは何か：

【実施基準「ITに係る業務処理統制」の定義

業務処理統制とは、業務プロセスに組み込まれたITに係る内部統制であると言える。
業務処理統制には、「手作業」（ITに依存し、人手とコンピュータ処理が一体となって機能している場合も含む）による場合と、「プログラムに組み込まれて自動化」されている場合がある。
統制活動が自動化されていても、テストは「手作業」でできる場合がある。

トップダウンであること：

評価対象システムの識別はゴール（財務諸表）からの逆算により、演繹的に行う。

財務諸表項目の「重要勘定」からスタートし、この数値を増減させる「仕訳」の生成過程である「業務プロセス」をつなげた「取引フロー」を確保し、その「取引フロー」上に出現する「自動化された統制活動」を提供する「アプリケーション」がITに係る業務処理統制の有効性評価対象となる。そして、このアプリケーションを束ねるシステム基盤がITに係る全般統制の有効性評価対象となる。

Ｊ－ＳＯＸ覚書

【根本的な誤解 】

内部統制といわゆるJ-SOXを混同している方が多い。

「内部統制」と言った場合には、「会社法」に定められているものと「金融商品取引法」に定められているものがあって、いわゆるJ-SOXは後者のこと。

今度の4月から施行！と騒いでいるJ-SOXは、「金融商品取引法」に定めているほうで、その目的は、株主が誤った財務諸表を見て、誤った投資判断をしないために、「財務諸表がちゃんと作られていますよ」ということを担保すること。だから、実務手続は「財務報告に係る内部統制」を経営者に評価させてその、報告書を開示させ、それを監査人が監査して監査報告を作成するということ。

つまり、財務報告に係らない部分はいわゆるJ-SOXには含まれません。

「個人情報の保護」とか、「法令遵守」とかは内部統制としてあるんだけど、J-SOXの範囲ではありません。

【心証の形成】

Ｊ－ＳＯＸに関する書物ではしばしば「心証」という用語が出てきます。
ここでいう心証とは、会計監査用語としての「心証」であって、一般的な「心証」とは、若干、意味合いが異なります。

会計監査用語的には、
「心証」は形成するものであって、良かったり、悪かったりするものではありません。

ですから、会計的には「心証」が悪いということはなく、
心証は「得られる」か「得られないか」
というものです。

会計監査用語でいう「心証」とは、
「だいたいＯＫ」
という意味なのです。
つまり、詳細に見ていけば少しくらいは問題があるかもしれないけど、大局的に見地から言えば、正しいと言えるでしょう！
という状態が「心証を形成できた」と言います。


で、Ｊ－ＳＯＸの文書化とは存在するはずの内部統制について（存続している上場企業の規模の会社において、内部統制がまったく機能していないとか、そもそも「ない」とかはあり得ないでしょう）、監査人の『心証』を形成するための手続なのです。

【検証可能性】

心証の項でも書きましたが、『内部統制』そのものは従来から存在しているはずです。

J-SOXではその「内部統制」が有効に機能していることを経営者が評価して報告することが『義務付け』られました。

「有効性評価」が義務付けられた時点で、「内部統制」は「それを検証できるか」という検証可能性が問われるようになったのです。
検証とは、「全部しっかりやってます」ということを第三者に示せるかが重要なのです。

検証できないとすれば「全部しっかりやっていた、と言い切れない」ということになり「有効ではない」と結論付けられる可能性があります。

最近、Ｊ－ＳＯＸ対応と謳っているソフトウエアが実は、すべての操作記録をログに残しておくだけだったりするのですが、これは「検証」の可能性を提供しているという点で、Ｊ－ＳＯＸに対応できる可能性があるということを言っているのです。
ログが残らないソフトウエアを使っていたとしても、他の方法で検証できればＪ－ＳＯＸに対応することは可能です。

【アサーション】

実在性
　架空じゃなくて、本当のこと
　（今期末に予算達成のために受注計上しておいて、来期早々に受注取り消しとかダメですから。）

網羅性
　もれなく

権利と義務の帰属
　他人のじゃなくて、自分の
　（例えば、別部署の売上を上げちゃうとか、子会社の売上を自分の会社の売上みたいに計上しちゃうとかはNG）

評価の妥当性
　サバをよまずに
　（10人月の工数を投入したからって、必ずしも仕掛が10人月じゃないよねぇ。）

期間配分の適切性
　遅れず、早すぎず
　（赤字確定するのが嫌だから、すでに納品済なのに売上を計上しないで、来期の仕掛にしておくなんてNGでしょ！）

表示の妥当性
　飾らず、ありのままの姿で
　（容姿端麗、成績優秀・・・・）