最近のITAC
の続き。
SOX対応の場合、評価コストを懸念して「この内部統制は財務報告リスクに対応しているか？」ということを常に意識することになるが、内部監査の場合は何を目的（業務の有効性および効率性／財務報告の信頼性／法令遵守／資産の保全）とした内部統制なのかを結構曖昧なまま進めてる感がある。
で資料の建付けも変わったっぽいので。
文書化・評価にあたって基準やガイダンス的なものはあるのか？
・監査・保証基準委員会（JICPA）の発行物：これらは監査法人が財務諸表監査時に従うべきルールであり、企業が内部統制経営者評価で同じレベルまで要求されるわけではない
・監基報315
・実務ガイダンス第5号（旧：IT研57号）
・監査法人の内部統制監査実施マニュアル：実際にはエンゲージメントや品質管理者（パートナー）ごとに考え方が異なっている
・企業の内部統制経営者評価実施マニュアル：もし整備運用されてるなら
文書化として何をやるか？
情報処理統制（PLC）の文書化としては、従来から3点セットが標準的な成果物だった
問題は、そのPLCがITACとして特定された場合、どんな文書を作成する必要があるのかということ
システムレベルの3点セットまで作るのはやりすぎな感があるけど、いずれにしても評価するためには突合確認が必要になるので、そのためにはデータ抽出元テーブル（何と何を突合するのか）まで特定する必要がある
評価（整備状況評価／運用状況評価）として何をやるか？
おそらく以下の2パターンがある
パターン①
・整備状況評価：設計書の記載（仕様の妥当性）を検証する
・運用状況評価：本番環境の実装を検証する
パターン②
・整備状況評価：本番環境の実装を検証する（設計書の記載は文書化時点で行っておく）
・運用状況評価：「ITGCが有効であるため、整備状況評価時点での評価結果を利用する」旨を説明する
設計書の記載が妥当かどうか？というのを判断するのは難しい気がするが、そこが評価者の専門家としての判断が求められる部分
プログラムのステップ通りに検証しなければならないのか？
実務ガイダンス第5号（IT研57号）の記載によると、プログラムのステップに沿ってデータ処理を検証する必要はない
評価者は、テーブルからデータを抽出して、数式にあてはめて再計算して、算出できた金額とシステム処理結果を比較すればOK
ただ一方で、「内部統制の機能を理解した上で」という記載もあり、どのテーブルからデータを抜いて、どんな数式を使うのかは、手続として検討する必要があると思われる
Ｑ15： 自動化された情報処理統制の評価手続について説明してください。
Ａ15：
プログラムにより自動化された情報処理統制の評価手続では、内部統制が期待される機能を果たしているかどうかについて、合理的な心証を得ることになります。なお、必ずしも、ITアプリケーションのプログラムの機能を完全に再現することや、プログラムの手順どおりに評価を実施する必要はありません。
当該内部統制の機能を理解した上で、入力された情報や状況に対してあらかじめ設定された出力結果や処理が実施されることを確かめることで検証できる場合がありま す。
内部統制監査（監査法人）と経営者評価（内部監査部）のスコープにはどの程度ギャップがあっていいのか？
実務上は、以下のスタンスでOK
・まず経営者評価は、内部統制監査で監査法人に許容されるレベルまで簡略化する
・あとは財務諸表監査で資料やデータの提供依頼を受けた時に、監査法人対応として応対する
※（監査法人に従って）丁寧にやろうとすればどこまでもコストがかかってしまうため、「いかに簡単に評価するか？」という発想に切り替えることが重要
経営者評価をやることになると、文書化評価にかかるコストが膨れ上がってしまう
一方で、監査法人対応なら、言われた通りに応対するだけなのでコストは抑えられる
監査法人によっては、内部統制監査や財務諸表監査の作業量を減らすために、経営者評価の量と質を増やす（監査法人が利用できるレベルまで）ことを要求してくることがある
その場合、企業側は、監査報酬の引き下げ交渉を行うこともできる
内部統制監査において、監査法人は、企業側の経営者評価の結果を利用する場合、その評価調書（＝評価者の判断過程）を確認する義務がある
（経営者評価の結果を利用しない場合は、監査法人は独自の内部統制監査手続を実施することになる）
もし、企業側の経営者評価の評価調書（3点セットも含む）のレベルが十分に高ければ、監査法人はそれを利用できる（独自に監査手続する必要がなくなる）ため、楽ができる→監査報酬の引き下げ交渉に使える
一方でレベルが不十分であれば、監査法人は独自の監査手続を実施せざるを得なくなるため、楽ができない→監査報酬を引き上げられることになる
財務報告リスクとは？
例えば、PL上に表示されている「売上」勘定の金額は、大量の期中仕訳の積み重ね（残高）になっている
この金額の適切性を直接的に立証することはできないため、個々の仕訳に分解し、それぞれの仕訳の適切性を立証することを以て間接的に立証する、という理屈になっている
例えば、それぞれの仕訳について以下の要素
・勘定科目
・金額：単価×数量
・計上日
が正しいことを立証できれば、間接的にPL上の「売上」勘定の適切性を立証できると考える
そのため、各要素を確定するにあたって最も重要な（リスクを下げている）コントロールをキーコントロールとして見做す
ITACとPLCの関係は？
内部統制（ICFR）は、
・全社的な内部統制（ELC）
・業務プロセスに係る内部統制（PLC：情報処理統制）
・決算財務報告プロセス（FCRP）
・その他の業務プロセス
に区分される
PLCのうち、システム処理で実施されているコントロールが、ITAC
ITACの実態は、コントロールを実装しているアプリケーションプログラム
業界の事情でITだけ切り出されてしまっているが、理論的にはITACはPLCの一部に過ぎない
※監査法人の監査担当者も、企業の内部統制評価担当者も、業務チーム／ITチームに分断されてしまっており、双方のコミュニケーション不足により評価範囲に無駄が発生していることが多い
まず、PLCレベルで財務報告リスクとコントロールを特定（会計士のスキルが必要）してから、システム処理の明細を把握（エンジニアのスキルが必要）する必要がある
実務上は、以下の者を一同に集めて、業務／システムをまとめてウォークスルーするのが効率的（別々に行うとコントロールが重複してしまう可能性があるため）
・業務プロセスの担当者（ユーザ部門など）
・情シスの担当者（ベンダなど）
①重要科目の選定
・量的に重要な勘定（重要拠点の事業上主要な勘定科目）：売上、売掛金、棚卸資産、など
・質的に重要な勘定（高リスク、見積り、非定型）
・日常的：不動産や金融資産の流動化証券化、など
・決算財務報告（固有）：引当金、減損、税効果会計、など
②業務プロセスの明確化
・重要科目×業務プロセスのマトリクスを作成する
・業務プロセスはフェイズごとに区分できる
例：販売プロセス（売上債権管理プロセス）：与信→受注→出荷→請求→売上計上→回収
・業務プロセスはデータ種類によって区分できる
例：販売対象：商品／コンテンツ／役務提供
・会計データの生成過程（原始証憑から仕訳まで）を文書化する
・特に、勘定科目／金額／計上日が確定するタイミング、確定後に更新されるタイミングを明確にする：データが登録更新されるということは、誤登録誤更新リスクもあるということ
・定刻が到来した時点（バッチ処理による確定）
・承認された時点（オンライン処理による確定）
など
※自動処理でこれらが決まっている場合、ユーザが認識できていないこともあるので注意
ITACとシステム処理の関係は？
原則的な考え方はPLCと同じ
①財務報告リスクを低減している処理か？
→低減していればコントロールとして見做す
（対応する財務報告リスクがない場合、それはコントロールではなく、単なる自動処理）
②キーコントロールとして扱えるか？
→キーコントロールとして扱うなら、評価対象にする
（キーコントロールにするほど主要なコントロールでなければ、評価対象にはしない）
EUCはどう扱うか？
EUCはITACの一種として扱われている
ただ、従来はITGCが有効であることを示せれば、EUCの期末時点の評価結果を延長することができたが、最近（監基報315）ではその方法を認めていない
（EUCのITGCが有効になることは実質的に稀であるため）
ITELCとITACの関係は？
まずITELCの段階で、以下の「ITの概括的理解」を作成する必要がある（ITACの評価計画に関わるため）
・拠点名
・会計期間
・情シス部門の体制
・財務報告に利用しているシステム
・システム名
・関連する業務プロセス
・関連する勘定科目
・処理件数
・システム構成
・アプリ
・ミドルウェア：DB、ジョブスケジューラなど
・OS
・ハードウェア
・設置場所
など
・ユーザー部門
・保守部門
・前回評価時から発生した重要な変更・障害
・前期評価時の内部統制上の不備
・今後（当期・翌期以降）の開発変更計画
・当期に開発変更がある場合、ITAC評価時期を検討する必要がある
・翌期に開発変更がある場合、要件定義段階からITACレビューを実施した方がよい（本番稼働後に内部統制上の不備が検出されると、期末日＝内部統制を有効化しなければならない日までの修正が困難になってしまうため）
評価に使うデータはどうやってサンプリングすればいいのか？
○正確性の立証
・原則：PLCレベル（業務レベル）で特定した処理パターンごとに1件ずつ（処理パターンを網羅するという発想）
※単体テストのようにプログラム条件分岐のカバレッジ100%を目指す必要はなく、あくまでも業務レベルで識別できたリスク・コントロールの単位で確認すればOK（逆を言えば、プログラム条件分岐上では例外処理のひとつに過ぎなくても、それが業務上コントロールとして重要だと特定されているならば、確認する必要がある）
・許容：無作為抽出した最大25件（サンプルから母集団を推測するという発想）
○網羅性の立証
・バッチ処理の場合：コントロール処理1回あたりで処理対象となる全データ
・オンライン処理の場合：確認不要（データは1件ずつ逐次処理されるため）
２．自動化された情報処理統制とＩＴから自動生成される情報を照合する手続の例
自動化された情報処理統制とＩＴから自動生成される情報を照合するに当たっては、当該内 部統制がどのように機能するかを仕様書の閲覧や質問等により理解します。その上で、以下のよ うな手続により期待どおりに機能するかどうかについての心証を得ます。
(1) サンプルテストによる照合
当該情報処理統制に依拠しようとする期間にわたって情報処理統制の運用の結果からサン プルを抽出してテストすることにより評価します。自動化された情報処理統制の場合、プログラムの整備状況が適切であれば、処理パターンが同じであれば、サンプルで抽出されたもの以外でも同様の信頼性になることが期待されます。
例えば、外貨換算の正確性を確かめる場合、一つの外貨について為替レートと外貨建ての売上金額により円建ての売上を再計算し、計上された円建ての売上金額とを照合して一致を確認できれば、他の外貨についても同様に正しく計算されると期待されます。
市販パッケージに関する経営者評価の必要性は？
・実務的には、特殊なカスタマイズが実施されていなければ、経営者評価は不要
・ただし、監査法人としては監査することになっている
ITACが不備になったらどうなる？
・ITACはITGCとは異なり、勘定科目に直接的に影響を及ぼすため、マニュアル統制に不備が検出された場合と同様に、虚偽表示金額の集計を行う
・ITACの性質（誤処理も反復してしまう）上、不備のあるITACで処理された金額は全て虚偽表示金額と見做す（不一致な差額が10円でも、その処理で1億円が処理されていれば、虚偽表示金額が1億円だと見做す）のが原則的
・ただし、この原則に基づくと、すぐに内部統制が非有効になってしまうため、実務上はある程度の少額な差異ならITACでも不備と見做さないと判断することが多い
ITACの前期評価を利用するためには？
以下を立証する必要がある
①特検リスクに対するコントロールではないこと
②ITGCが有効であること
③前期評価時点から内部統制が変更されていないこと
④不具合が発生していないこと
①
②はITGCの話になるので省略
③は、以下を立証する必要がある（何を以て「変更がない」と見做すかは、対象となるITACの重要度により変わるので、監査法人と相談する）
・ITACを実装しているプログラムに変更がないこと
例：
・本番環境における該当プログラムファイルが更新されていないこと（更新日付、サイズ、ハッシュ値などを比較）：最も直接的だが、プログラムファイルが更新されていても、該当ITAC部分のコードには影響していない可能性もある
・該当プログラムに関する開発ドキュメントファイルが更新されていないこと：間接的
・受理された変更依頼書がないこと：間接的
・パラメータ（プログラム実行時の引数）に変更がないこと
例：
・該当パラメータについて変更ログが更新されていないこと：最も直接的だが、クラウドサービスのパラメータは設定画面上で変更でき、ログが残らない可能性もある
・パラメータ管理台帳が更新されていないこと
④は、障害管理台帳を確認する
ITACの種類は？
マニュアル統制においても、
・ただの処理（業務上は必要なステップでも、実質的に財務報告リスクを低減しているとはいえない）：受注見積書の承認など
・コントロール（このステップを実施しないと財務報告が誤るリスクが高まる）：売上入力の確認など
の区別がある
同様に、自動化された情報処理統制（ITAC）においても、
・コントロールをプログラムが機能として実装しているもの（インターフェイス、アクセス制御など）
・プログラム機能自体はコントロールになっていないもの（自動計算、レポート出力など）
がある
自動計算
・利息：元本、金利、返済期間、など
・減価償却費：取得原価、耐用年数、残存価格、償却方法、など
・円換算額：現地通貨額、為替レート、など
など
レポート出力
・マニュアル統制の根拠となる資料を出力する処理（適切に出力されることが前提となっている処理）は、ITACとして見做す
・プルーフリスト：決算修正仕訳リスト
・例外リスト：受注後未出荷リスト、入荷後未検収リスト、未回収債権リスト
など
・ITACとして評価対象にする場合、出力処理（テーブルからの抽出クエリ）が正しいかなどを検証する
・ただし、外部から入手できる証憑と照合が可能な場合、そのマニュアル統制をキーコントロールとして扱い、評価することも可能（システム処理を評価するより簡単になる）
エディットチェック
・入力項目単体をチェックするもの／複数をチェックするもの
・マスタとの整合性をチェックするもの
・キーコントロールになることはない：入力データが制限範囲内であることは担保できるが、入力データの正確性／網羅性／正当性は担保できないため
・入力データの正確性／網羅性／正当性を担保するためのコントロールは、プルーフリストのレビュー（マニュアル統制）
インターフェイス
・インポート処理
・データ処理前とデータ処理後でレコード件数などを比較して、一致していない場合は処理をロールバックする
マッチング
・入金と売掛債権の金額を比較して、一致したら消し込む
アクセス制御
・認証と認可
・権限の付与（申請に基づく）はシステム処理（ITAC）ではなく情シス業務（ITGC）であることに注意
評価方法の種類は？
閲覧
設計書の閲覧
※これだけでは評価手続として足りない
質問
情シスへの質問
※これだけでは評価手続として足りない
照合
本番環境の出力（画面や帳票）を比較する
※経営者評価で行われる典型的な評価方法（システム内部を見ないので、PLCの評価方法として一般的）
再計算
本番データを抽出し、スプレッドシート上で再計算し、システム処理結果と比較する
※経営者評価で行われる典型的な評価方法（システム内部を見るので、ITACの評価方法として一般的）
再実施
本番環境を使って統制が実施されるかを確認する
※経営者評価でここまでやるのは一般的ではない（監査では実施されることがある）
レビュー
ソースコードやDBMSクエリの確認
※経営者評価でここまでやるのは一般的ではない（監査では実施されることがある）
分析的手続
経営者評価としては使わない（監査では使う）
この記事が気に入ったらサポートをしてみませんか？