「IT研57号」を読んでみる
お勉強のために通読して感想文を書いてみる
はじめてのすごい長編記事、超力作？
Ⅰ はじめに
監基報315で述べている適用指針のみだと、実務には充分ではないので、IT研57号を作った
「IT研57号」とは、改正「監基報315」が適用される監査において、ITに関する実務上の留意事項をまとめたもの
「IT研57号」の発行に伴って、「IT実6号」と「IT研53号」は廃止になる
ちなみに改正された「監基報315」はこっち
Ⅱ 総論
Q1 ITの利用から生じるリスク
・アクセス権限の不正取得
・データ（マスタデータなど）の未承認な変更・アクセス
・IT環境（アプリ、ミドルウェア、OSなど）に対する未承認な変更
・IT環境に必要な変更が行われないこと
・データへの可用性が損なわれること
情報処理統制を自動化するなら、設計と実装と運用がちゃんとしてないとだめって話
Q2 自動化された情報処理統制の無効化リスク
・プログラムを作っても処理が不十分だと無効化されてしまう
・パッケージ製品を使ってもパラメータ設定が不十分だと無効化されてしまう
・アクセス権の管理が不十分だと無効化されてしまう
「監査人はプログラムの要件定義が会計処理上適切な内容であることを確かめるための手続を必要に応じて実施することになります」って書いてあるけど、実務的にはどんな風に開発プロジェクトに関与していくものなのか
Q3 用語の整理
・「システム」という用語は、自動処理部分のみではなく、それを利用（運用）する手作業部分も含めた用語
・ソフトウェアは、アプリ／ミドルウェア／OSに区分される
・ソフトウェアはプログラムの集合体
システムって用語をハードウェアとソフトウェアにしか使わない人もいるけど、実はユーザやマニュアルを含めた概念なんだよね
Q4 情報処理統制とIT全般統制
・情報処理統制は、情報のインテグリティ阻害リスクを直接低減するコントロール
・情報処理統制は、「ITアプリケーションによる情報処理統制（自動化されている情報処理統制）」と「手作業による情報処理統制」に区分される
・一般的な情報処理統制には、自動化されている部分と手作業な部分が混在している
・IT全般統制（ITGC）とは、企業のITプロセスに係る内部統制で、自動化されている情報処理統制の”継続性”を支援する
・財務報告において依拠する内部統制が自動化されていればされているほど、ITACとITGCの整備運用が重要
「業務処理統制（Application Controls in IT）」という用語は「情報処理統制（Information Proccesing Controls）」に置換されたわけだけど、これにはどうゆう意図があったんだろう
・情報のインテグリティとは、取引データ等の
・網羅性
・正確性
・正当性
であって、これらを阻害するリスクを直接低減するコントロールの例としては
・網羅性：インターフェイス処理における件数チェック
・正確性：マスタ参照チェック
・正当性：認証と権限制御
がある
自動計算（手作業でやってた計算をプログラムで自動化したもの）については言及されていない
Q5 監査人が理解すべき企業のIT環境
・事業上のリスク（財務諸表に影響を与える）の理解
・重要な虚偽表示リスクの理解
・財務諸表（注記を含む）の作成プロセス
などなど
「ITの利用から生じるリスクとアサーションレベルの重要な虚偽表示リスクの関連性を考慮しつつ、…」っていうとこがいまいち解らない
どういう関連性があるのか謎の謎
Q6 企業のIT環境を理解する際の留意点
なんか色々と理解する必要があるらしい
Q7 監査業務にIT専門家を関与させる際の留意点
IT専門家に作らせた監査調書は、監査人がちゃんと査閲しよう
Q8 アプリやインフラを理解する際の留意点
業務プロセス上の入出力とかの情報は重要だと思うけど、ユーザ数とかトランザクション量とか、ソフトウェア構成、ハードウェア構成、ネットワーク構成って要るのか？何に使うのか
Ｑ9 パッケージソフトの計算処理の妥当性等を検証する際の留意点
・社会一般で普及している市販パッケージをそのまま（カスタマイズやアドオンせずに）使っている場合は、簡易的な手続で心証を得てもOK
・パッケージソフトの処理機能と会計方針の整合性のチェック
・パラメータ設定と基礎データ（マスタ？）の妥当性チェック
・設定が適切な申請承認プロセスを経ているか
・数値（為替レート、税率、基準値など）が適切か
・計算処理機能の有効性のチェック
・パッケージ導入／変更時に実施した処理の検証結果を参考にする
・監査人がスプレッドシートで見積値や推定値を算出して比較分析する
・専門家を利用する（退職給付債務など）
これってパッケージじゃなくてスクラッチでも同じことが言えるのでは？
Q10 計算処理の妥当性等を簡易な手続で検証できる場合とは
パッケージを使っていて、かつ
・データの登録・変更・削除
・締切
・自動計算
などの機能に変更を伴うカスタマイズやアドオンが行われていない場合
つまり、パッケージ標準機能しか使ってない場合
Q11 グループ監査においてどの程度にIT環境を理解すべきか
・グループ監査チームは以下を理解する必要がある
・グループ全体統制
・連結プロセス
連結プロセスは、連結パッケージ（という名のExcelファイル）を親会社に連携するにあたって、どんな手作業と自動処理をしてるかっていうこと？
グループ全体統制って何
Ⅲ 情報処理統制
Ｑ12 ITを利用した情報システム及び関連する内部統制を理解するための手続と留意点
・ITアプリケーションの構成（財務報告プロセスの一部を担っているため）
・情報のインテグリティ（網羅性・正確性・正当性）を阻害するリスクを直接低減する自動化された情報処理統制
を理解しよう
Ｑ13 データを含めた処理の流れやシステム帳票の生成過程を理解する方法
・業務プロセスを理解するには、システムのユーザ部門に聞けばいい
・システム上のデータの流れについては、情シス部門に聞かないと分からないこともある
情シス部門に聞いても、「システムを開発運用するためのドキュメントしかない、監査のためにドキュメントなんて作らない」とか言われちゃうけどね
でもこれを整然と、流れに穴を作らずに把握しとかないと、文書化も評価もできない
「承認プロセスがワークフロー化されていた場合には、以下のような事項も実施します」で「ログインに係る認証機能の観察」とか書いてあるけど、権限設定だけじゃなくて認証機能まで見ることを求めてる？
Ｑ14 開発中のシステムについてIT全般統制の識別評価は必要か
他の監査対象項目と同様に、財務諸表全体レベル及びアサーション・レベルの二つのレベル でのリスクを識別し評価することが重要となります。
具体的には、主として以下の２点が挙げら れます。
・新たな情報システムが、企業の採用する会計方針に合致したものであるか（会計方針に沿った 会計処理の機能が当該システムに適切に盛り込まれているか等）。
・新たな情報システムによって、重要な虚偽表示リスクへどのような影響があるか（適切な職務 分掌の設定や情報処理統制及びＩＴ全般統制の整備・運用状況等）。
何故これが「財務諸表全体レベル及びアサーション・レベル」の「リスクになるのか、よく分からない
１．経営者が財務報告の信頼性を軽視してシステム導入してないか
２．システムに内部統制を組み込むためのプロセス（要件定義・テスト・運用）があるか
３．データ移行時の統制が整備されているか
稼働中のシステムの評価とは違って、プロジェクト監査的なこともしなきゃいけないってことなのかな
Ｑ15 自動化された情報処理統制の評価手続
必ずしも、ＩＴアプリ ケーションのプログラムの機能を完全に再現することや、プログラムの手順どおりに評価を実施 する必要はありません。当該内部統制の機能を理解した上で、入力された情報や状況に対してあらかじめ設定された出力結果や処理が実施されることを確かめることで検証できる場合がありま す。
要するに、「合理的な心証を得る」ための理屈付けが大切ってこと
「自動化された情報処理統制」の例
１．自動計算など：月次処理や特定期日到来時に自動で計算を行う、計算結果が会計システムに連携されて自動で仕訳登録まで行うものもある
２．レポート出力：明細レポート、集計レポート、プルーフリスト（システムへの入力データを処理・加工せずそのまま印刷したもの）、エラーリスト、など
３．エディットバリデーション（入力チェック）
４．マッチング：入力値をマスタデータと照合
５．コントロールトータル（網羅性チェック）
６．アクセス制御
自動計算もITAC扱いになっている
「自動化された情報処理統制」が期待通りに機能するという心証を得るための手続の例
・再計算：処理パターンが同じ処理結果から1件をサンプリングして、監査人自身が再計算した値とシステム処理結果値を照合する
・再実施：本番システムを使ってITACを再実施してみる
・ソースコードのレビュー
・クエリのレビュー
飽くまでも「心証を得る」ための手続なんだよね、でもなぜ得られるのかを理屈で説明しなければならないという難しさ
ソースコードのレビューとか、読んでも解らんだろと思う
再計算も、処理パターンなんて膨大にあるのにどれくらい確認する気なんだよとも思う
なお、統制活動における内部統制の識別と 評価において、監査人は、重要な取引種類、勘定残高及び注記事項に関する取引の流れや企業の情報処理活動のその他の側面を規定する企業の方針に関連する全ての情報処理統制を識別し、評価することは求められていません（監基報 315 の A136 項）。
この日本語（「～全ての情報処理統制を識別し、評価することは求められていません」）の意味が解らない。「全ての情報処理統制」は見なくていいなら、どれだけの情報処理統制を見ればいいってことなのか？
なので、監基報315を辿ってみた
A136．統制活動における内部統制の識別と評価において、監査人は情報処理統制に重点を置く。情報処理統制は、情報のインテグリティ（すなわち、取引及びその他の情報（データ）の網羅性、 正確性、正当性）のリスクに直接対応する、企業の情報システムにおける情報処理に適用される内部統制である。しかしながら、監査人は、重要な取引種類、勘定残高又は注記事項に関する取引の流れやその他の情報処理活動を定めた企業の方針に関連する全ての情報処理統制を識別し、 評価することは求められていない。
たしかに同じようなことが書いてある（「～全ての情報処理統制を識別し、評価することは求められていない」）
「重要な取引種類、勘定残高又は注記事項に関する取引の流れやその他の情報処理活動を定めた企業の方針」っていうのが謎なのでさらに調べてみると…
(3) 「ＩＴの利用から生じるリスク」：企業のＩＴプロセスにおける内部統制のデザイン若しくは運用が有効でないことにより、情報処理統制が有効にデザイン若しくは運用されない可能性又は企業の情報システム内の情報のインテグリティ（すなわち、取引及びその他の情報（データ）の網羅性、正確性、正当性）に対し引き起こされるリスクをいう。
(5) 「関連するアサーション」：取引種類、勘定残高又は注記事項に係るアサーションのうち、重要な虚偽表示リスクが識別されたアサーションをいう。アサーションが「関連するアサーション」であるかどうかの判断は、関連する内部統制を考慮する前に行われる（すなわち、固有リスク）。
(8) 「重要な取引種類、勘定残高又は注記事項」：関連するアサーションが一 つ以上存在する取引種類、勘定残高又は注記事項をいう。
(9) 「情報処理統制」：情報のインテグリティ（すなわち、取引及びその他の情報（データ）の網羅性、正確性、正当性）のリスクに直接対応する、企業の情報システムにおけるＩＴアプリケーションの情報処理又は手作業による情報処理に関連した内部統制をいう。
A120．企業の内部統制システムには、企業の報告目的（財務報告の信頼性を確保する目的を含む。） に関する側面が含まれるが、財務報告に関連する場合には、企業の事業経営の有効性と効率性 を高める目的や事業経営に係る法令の遵守を促す目的に関する側面も含まれる場合がある。監 査人による情報システムの理解の一環として、企業がどのように取引を開始し情報を把握して いるかの理解に加え、財務諸表の作成に関連している場合には、事業経営の有効性と効率性を 高める目的や事業経営に係る法令の遵守を促す目的に対処するためにデザインされた企業の内 部統制（企業の方針）に関しても理解することが必要になる場合がある。また、高度に統合され た情報システムを有している企業においては、財務報告の信頼性を確保する目的、事業経営の 有効性と効率性を高める目的及び事業経営に係る法令の遵守を促す目的並びにその組合せを同 時に達成できるように内部統制がデザインされている場合がある。
要するに、「重要な取引種類、勘定残高又は注記事項に関する取引の流れやその他の情報処理活動を定めた企業の方針」＝「固有リスクが高い取引／勘定科目／注記事項に関する内部統制」ってことらしい
この内部統制に関する「全ての情報処理統制」は見なくていい…と言っているが、やっぱり「じゃあどれだけの情報処理統制を見ればいいのか？」ってなるよね
どういう意図で書いたのかご教示願いたい
Ｑ16 紙面への押印ではなく電子承認である場合の留意点
１．承認者が適切な権限を持っているか：認可（権限設計）の問題
２．承認者は本人か（なりすまし・代行ではないか）：認証の問題
３．承認漏れはないか（未承認でも後続処理に進んでないか）：ワークフローの問題
Ｑ17 電子署名やタイムスタンプ機能を用いた電子契約における留意点
電子署名法を参照
Ｑ18 売上を自動計上するシステムにおけるITACの評価
・売上計上に関係するシステムは、売上高や売掛金などの勘定科目に関するアサーションと関係している
・自動計上の仕組みの例
①手作業入力を元に自動計上（マスタ参照チェックあり）
②他システムのデータを元に自動計上
③売上計上予定日に自動計上
④RPAを使って自動計上
⑤AIを使って自動計上
なんか色々書いてあるけど、なんで売上の勘定科目についてだけ特筆してあるんだろって感じ
Ｑ19 インターフェースの有効性を検証する方法
インターフェイスの種類
・システムAからの出力帳票を見て、担当者がシステムBに手入力する
・システムAからダウンロードしたファイルを、担当者がシステムBにアップロードする
・システムAからシステムBに自動的にデータが連携される
テストデータを用いて本番環境でエラーを発生させるテストは実務上は実施困難なので、以下の代替的方法がある
・ソースコードのレビュー
・開発時や本番移行直前のテスト計画やテスト結果のレビュー
・稼働中に実際に発生したエラー処理やリカバリ処理の結果（エラーリストなど）のレビュー
・送信側と受信側の帳票（テーブル）間の照合
1番目は実質的に不可能な気がするから置いといて4番目やるのが普通なのかな
インターフェイス処理っていったらエラー処理は当然組み込まれてると思うけど、3番目で済ませちゃいけないのは何で？
Ｑ20 アプリが作成した情報を利用する場合の留意点
・アプリが作成した情報には以下がある
・企業が内部統制のために利用する情報
・監査人が実証手続の監査証拠として利用する情報
・元データ、アプリ処理のロジック、手入力パラメータに基づいて、アプリは情報を作成する
当たり前のこと言ってるだけな気がする
Ｑ21 アプリが作成した延滞債権リストや滞留在庫リストを利用する場合の留意点
ITアプリケーションから出力された延滞債権リストや滞留在庫リストを利用して実施される内部統制は、ITから自動生成される情報を利用して実施される手作業による内部統制の代表例です。
このQAの意義が解らない、Q20の具体例を挙げてるのか？
Ｑ22 EUCの留意点
・単純なスプレッドシート：手作業による検算や、スプレッドシートの整合性チェックツールの利用による補完統制により、信頼性を損なうリスクを低減できる場合もあると考えられます。
・複雑なスプレッドシート（処理がブラックボックス化している場合）：自動化された情報処理統制と同様の、処理の一貫性を維持するような内部統制の整備が求められる場合もあります。例えば、データベース機能を活用し、在庫管理などの基幹システムとして高度に利用するような場合には、EUC ツールにも、通常のシステムの管理と同等の管理が必要となることがある点に留意します。
・特にスプレッドシートをはじめとしたツールについては、仕様書の作成や変更記録の作成等の全般的な管理体制、アクセス制限に関する内部統制を整備することが困難であることが多く、IT全般統制と同等の有効性を確保することが難しい場合もあります。
・EUCリスクの評価観点
・処理の複雑さ
・処理する金額の重要性
・処理する内容・目的
・変更頻度
・他システムとの連携の程度等
EUCでやってる処理のリスクによって評価手続は変わるってこと
ITGCの有効性を確保できないっていうけど、サンプルたくさん見ればそれで済む問題なのかな
（そもそもITGCに依拠してサンプル件数減らせないなら、ITACじゃなくてPLCとして評価すればいいんじゃないって感じもある）
そもそも設計書も残ってないのに第三者がコード読んでけるかって話、IT専門家ってそんなすごいのか
Ｑ23 「自動化された情報処理統制」について前年度からの変更がないことを確かめる監査手続
まず質問して、「変更がない」と回答を得られた場合は以下を実施する
・パッケージをカスタマイズせずに利用している場合：バージョン情報、リリースノート、環境設定などを確認する
・スクラッチやカスタマイズで開発されたシステムを利用している場合：ITACに影響を及ぼす個々のプログラムを全て特定し、当該プログラムの最終更新日付をシステム上で確認する
このQAに基づくと、「変更がない」を立証するのは実務的に不可能だろうなって思う
まず「ITACに影響を及ぼす個々のプログラムを全て特定」っていうのが難しすぎると思う、複数のソースコードを再利用して1つの処理を構成してるっていうのが現代のアプリだから
Ｑ24 「ITの利用から生じるリスク」とアサーションの関連性
ITの利用から生じるリスクは通常、アサーションと直接的に関連するものではありませんが、 アサーションから導き出される重要な虚偽表示リスクにITの利用から生じるリスクがどの程度影響を及ぼすかについて監査人が判断を下すという点で関連性を有するといえます。
リスクがリスクに影響を及ぼす…
従来のすべて手作業だったときはアサーション阻害リスクのみだけだったけど、自動化したことによって、「IT利用リスク」が生じて、それが「アサーション阻害リスク」の原因になってるとも考えられる、ってこと？
例えば、未承認でデータが変更されてしまう（正当性インテグリティが阻害されてる）なら、架空のデータが作れちゃうので、それは実在性アサーションを阻害する要因のひとつになってるよね、って感じ？
感覚的に、会計士がいってる「網羅性」（アサーションとしての「網羅性」）と、ITAC評価担当者がいってる「網羅性」（情報のインテグリティとしての「網羅性」）って意味が違ってる気がするんだよな
アサーションを直接立証してる感覚がないので理屈も組めないというか…
結局、ITACの評価手続って、アサーションからではなく、情報のインテグリティ（網羅性、正確性、正当性）から導かれてる気がする
担保したい情報のインテグリティに応じて、各ITAC（インターフェイスとか自動計算とか）が設計実装運用されてるんだから、立証すべきはアサーションではなくて、情報のインテグリティなんじゃないのか
Ⅳ IT全般統制
Ｑ25 財務諸表監査上、ＩＴ全般統制を評価する意味はどのようなものでしょうか。
・情報処理統制が自動化されていればいるほど、ITGCの適用が必要になる
・ITAC評価は一時点の有効性しか立証できず、一時点の有効性を期末まで延長する（継続性を立証する）ためにはITGCの有効性を確認する必要がある
・運用評価手続については、手作業による内部統制と同様に、発生頻度に応じたサンプリング、残余期間における有効性の評価に留意する
・ITGCが有効だと評価されたとしても、ITACが有効だと結論付けることはできない
ITGCとはITプロセス（＝情シス部門の業務プロセス）に関する内部統制
Ⅴ パッケージ・ソフトウェア
Ｑ26 ERPが利用されている場合の留意点
ITACとしての観点
・どんな統制機能（自動化された情報処理統制としての機能）が実装されているか
・実装されている機能を適切に利用しているか
・ある一定時点のデータを保管する仕組みがあるか（棚卸実施時点の残高データなど）
・DBが分散している場合、ERPとERP周辺システムとのデータの整合性（処理後は相互にデータ連携しあって不整合を解消する仕組みがあるか）
ITGCとしての観点
・計算方法を決めるパラメータ設定（棚卸資産の評価方法など）
・決裁可能金額の閾値設定
・パラメータ設定の変更管理
アドオン開発部分については、自社開発（スクラッチ）と同様のITAC／ITGC評価が要求される
有名なパッケージ製品なら、内部統制絡みの機能もよく設計実装されてるだろうし、標準機能に業務プロセス（その企業として特段強みになっている業務設計でない部分なら）を合わせたほうが統制評価コストは下がるのだろうか
カスタマイズ地獄に陥ってシステム導入自体が混乱してる話しか聞いたことない
Ｑ27 会計帳簿の作成などに市販の簡易なパッケージ・ソフトウェアを利用している場合の留意点
・中小企業がパッケージを利用する場合、導入コストを抑えるために統制機能を限定したり、「使い勝手を良くする（融通を効かせる）」ために統制機能を無効化している場合があるので、機能として実装されているかだけではなく、実際に運用されていることの確認が必要
・市販の簡易な会計パッケージの機能例
①仕訳の承認：承認された入力仕訳のみを処理する
②仕訳データの変更履歴：一度登録された仕訳は上書きできない（逆仕訳で修正するしかない）
③仕訳データへのアクセス管理
④締め処理：再オープンできない（確定した前期分の仕訳を再編集できない）仕組みになっているか
⑤統制機能に必要なパラメータ設定
・自動採番
・税率
・配賦率
など
⑥財務報告に関連するデータのバックアップ
サイバー攻撃によってデータが破壊されて決算報告を延期した事件もあったし、⑥みたいなITGCも重要だよね
Ⅵ 外部委託
Q28 ITに関する委託業務
・ITGCに関する業務：システム開発保守、サーバの死活監視、バックアップ、ユーザID管理
・ITACに関する業務：データ入力更新
Q29 一般的な委託業務の形態
・ハウジング
・ホスティング
・共同センタ
・ASP
・クラウドサービス（IaaS、PaaS、SaaS）
Q30 委託業務に関する内部統制を評価する場合の留意点
監基報402に従う
CSP（クラウドサービスプロバイダ）も委託先に含む
Ⅶ 「自動化されたツール及び技法」とCAATs
Ｑ31 「自動化されたツールと技法」及び「コンピュータ利用監査技法」
いまどきどんなPCにもExcelはインストールされてるし、CAATs（コンピューター利用監査技法）してない現場なんてないけど、やり方がめちゃくちゃで有効性効率性が出てなかったりするだけ
監基報315では敢えて「自動化されたツールと技法」という用語を使っているけど、これはRPA、ドローン、AIのような未来の技術を意図したものらしい
Ｑ32 リスク評価手続における「自動化されたツールと技法」の利用法
サンプリング試査ではなく母集団データ全体に対する精査、可視化、分析、再計算ができる
Ｑ33 仕訳テスト及び連携して実施すべき取引テストを実施する際にCAATsを利用した方がよい場合
そもそも仕訳テストが何なのかイメージできてなかった
・仕訳テストは、監基報240第31項（2011年）で公表された監査手続
・経営者による内部統制の無効化に関係したリスク対応手続
仕訳テストを実施する際の留意点
・入手した仕訳データの完全性（母集団としてデータが欠落してないか）を確認する
・月次合計値で仕訳計上するような業務プロセスの場合は、仕訳テストだけでは不十分（合計値しか確認できない）なので、合計値の明細となる取引データを全て入手して、取引テストを行う必要がある
・相対的にMMRが高いのは、発生頻度が低い自動計上仕訳、手入力仕訳
Ｑ34 リスク対応手続（運用評価手続・実証手続）におけるCAATsの利用法
・サンプルの抽出：乱数の生成、母集団の階層化、特定項目抽出（偏向データのみに着目）
※実務上、サンプルテストを行う場合、運用状況評価のためか実証手続のためかを区別しにくい場合もあり、双方を兼ねるケースもある
・分析的手続
・再計算
・突合
昔から、運用状況評価と実証テストって何が違うの？って疑問だった
財務諸表監査ではなく内部統制評価をやってると特に
①運用評価手続での活用例
再実施におけるCAATの利用法として、例えば、「売上は、販売管理システムから自動でインターフェースされ、会計システムに仕訳が計上される」という内部統制がある場合：
「販売管理システムから取得した特定の期間の販売データをCAATで集計した結果」と「会計システム上の計上額」を突合することにより、運用状況の有効性を確かめられる
これって「再実施」なの？
②実証手続での活用例
・期末売掛金残高についてマイナス残高の有無を確かめ、マイナス残高発生についての被監査会社による発生理由調査結果と照らし合わせる（売掛金データベースから期末残高がマイナスのものを抽出する）。
・ 売掛金残高に対して滞留月数６か月（180 日）以上の売掛金残高を抽出し、抽出された売掛金残高について貸倒引当金が適切に計上されているか評価する（売掛金データベースにおいて、例えば、回収予定日がデータ項目としてあれば、そこから期末日時点で回収予定日を180日経過しているものを抽出する）。
・ 固定資産における減価償却費の再計算を実施して計算結果を照合する（固定資産データベ ースから取得価額、取得日、耐用年数などの必要なデータ項目を抽出し、このデータ項目からあるべき減価償却費を計算し、実際の固定資産データベース上の減価償却費との一致を確かめる）
2番目と3番目については、これらが自動化された情報処理統制としてシステムに組み込まれてたとしたら（貸倒引当金の自動計上、減価償却費の自動計上）、計算の正確性を確認するためにITACとして評価しなきゃいけない、って理屈なのかな
Ｑ35 CAATsを利用した監査手続を実施する場合、どのような監査調書を作成すればよいか
・CAAT実施計画書：プロセス単位または勘定科目単位で作成する
・CAAT手続書：CAATツール上の実行コマンドなど
・CAAT実施結果：CAATツールの出力ファイル、結論を記述した文書
・入手したファイル
・CAAT手続上で作成した作業用ファイル
こんなのちゃんと調書に残してる現場ってある？
そもそも評価実務は担当者の試行錯誤による属人的なプロセスだし、手続を再利用可能な形式で文書化するなんて、今の技術じゃ無理（というかコストかかりすぎる）でしょ
Ⅷ 不備対応
Ｑ36 IT全般統制に不備があった場合の取扱い
ITGCが不備になった場合、以下の対応を取る
・代替統制、補完統制を識別して評価する
・不備によって「ITの利用から生じるリスク」が顕在化していないことを確認する
・ITAC評価手続の範囲（件数、期間）を拡大する
・実証手続（分析的実証手続、詳細テスト）を拡大する
MMRを直接的に低減しているのはITACなので、ITGCの不備が即刻SD（「重大な不備」）やMW（「開示すべき重要な不備」＝旧「重要な欠陥」）に該当するわけではないんだよね
Ｑ37 情報処理統制等の整備状況が仕様書等により評価できない場合に想定されるリスクの評価及び対応例
・監査人は、仕様書等を査閲することにより、自動化された情報処理統制の整備状況を評価する
・仕様書等が存在しない、または最新の状況に更新されていない場合は、以下の対応を取る
①他の文書を閲覧する
・ユーザマニュアルを読む
・ソースコードを読む（ただし理解可能なことが前提）
②運用状況評価を実施することにより整備状況評価を代替する（ただし飽くまでもサンプリング評価になってしまうので、処理パターンを網羅的に確認したことにはならない）
・画面操作を観察する
・設定パラメータを閲覧する
・テストデータ入力に対するシステム出力結果と再計算結果を照合する
・ただし、仕様書が存在しない、更新されていない状況は、ITGC（開発保守プロセス）の不備を示唆している
仕様書がなくても、運用状況評価して実装されてそうなら整備状況評価も有効ってことにしよう、って話
仕様書がないのに（要件定義フェイズで「アサーション阻害リスクやIT利用リスクを低減するために、○○機能をコントロールとしてシステムに組み込みます」という明示がないのに）、なんかITACっぽい機能が実装されてました…ってことはあるんだろうか？
意識されずに結果としてITACが実装されてたとしても、明示的に要件定義で組み込まなかったというのは、やっぱり開発保守プロセスの不備ってことなんだろな
余談だけど、仕様書とか設計書の記載のうちどこがITACに該当する部分なのかっていうのを文書化して明文化するのってめちゃくちゃ大変だと思う（というかできてる例を見たことがない）
だいたいは調書に「○○.xlsxのシート△△の××を参照」とか書き残すけど、他の人（あるいは調書作成者本人も）が後から見たらどこだっけ？なんでこれで整備状況が有効とか結論付けられるんだっけ？？ってなるのが王道パターン
もっと上流工程から品質管理の一環として、ICFRとのトレーサビリティを担保しとけば、整備状況評価も運用状況評価も省力化できるんだろうけど（ICFR経営者評価を前提とした要件定義レビュー、設計レビュー、テストなどの文書化）、そういう活動って聞いたこともない
Ｑ38 UATが実施されていない場合に想定されるリスクの評価及び対応例
・UATが実施されていないということは、ユーザ部門の要求を満たしているか担保できてないということ
・UATが実施されていない場合、以下の対応を取る
・システム部門のテストに、ユーザ視点のテストが含まれているかどうか（UAT相当と見做せるかどうか）を確認する
・本番移行後の変更要求を確認する（リリース後にユーザ部門が要求している場合がある）
UATなしでリリースされるとかあり得るのか？
Ｑ39 データベースの会計データを直接修正する手続に不備が存在した場合に想定されるリスクの評価及び対応例
・アプリ上の会計データは、通常は、各業務プロセスにおいて承認手続を経て登録や修正されたもの
・しかし、アプリの修正機能が不十分だったり、バグなどの影響によって会計データがユーザの意図しない状態に変わってしまった場合などには、例外的にDBへ直接アクセス（または直接操作ツールを用いて）、データを変更する可能性がある
・DBの直接修正が頻繁に発生しているような場合は、それ自体がMMRとなる可能性がある
DB直接修正に関するコントロールの例
・修正内容に対する事前申請と承認
・職務分離（ユーザ部門の依頼に基づき、情シス部門が修正を実施する）
・更新ログのモニタリング
アクセス管理はITGCのトピックひとつ
まずはアプリ以外からのDBMSへのアクセスを遮断しないとね
Ｑ40 開発担当者・保守担当者と運用担当者の職務分離がない場合に想定されるリスクの評価及び対応例
情シス部門のリソース不足や内部統制を軽視した効率性追求によって、職務分離が実現されていないと、開発担当者や保守担当者自身が、自身が故意または意図的に変更したプログラムを、UATや移行承認など他者チェックを経ることなく、本番環境で稼動させることができる
職務分離に関するコントロールの例
・ワークフローシステムの導入（ユーザ部門の依頼と承認に基づくデプロイ）
・ライブラリ管理システムの導入（ソースコードとプログラムの管理）
職務分離はITGCのトピックのひとつ
ワークフローシステムとかライブラリ管理システム自体の統制機能がITACとして評価されることってあるのかな
Ｑ41 特権ID管理が不十分な場合に想定されるリスクの評価及び対応例
特権IDに関するコントロールの例
・特権IDはシステム部門が管理し、申請承認・貸出返却プロセスを運用する（説明責任を果たせるように共有できないようにする）
・特権ID操作ログをモニタリングする
特権ID管理はITGCのトピックのひとつ
普通は特権IDは封印しといて、機能を制限した管理用IDを別途作成してそれを運用するよね
Ｑ42 監基報315付録5「ITを理解するための考慮事項」の「適用の柔軟性」における「ITの利用から生じるリスクの影響を受ける可能性が十分に低い場合」の柔軟な適用について
例えば以下のような判定基準に基づいて、「ITの利用から生じるリスクの影響を受ける可能性が十分に低い場合」に該当するなら、ITに関する詳細な理解を省略できる
・プログラム変更ができない（ソースコードにアクセスできない）
・パラメータの変更ができない
・財務報告に関係するデータに直接アクセスできない
・取引の量が少なく、複雑性が低い
・自動化された情報処理統制に依存していない（手作業の情報処理統制として各取引を原始証憑と照合・検証している）
よく分からないけど、あまりITを利用してないなら、リスクが低いので、ITAC/ITGCとかじゃなくて、手作業の情報処理統制として文書化評価してねって感じかな
おわり
長かった。。けど勉強になった
知識インプットばっかではなく、実務で使えるようにならないとね
この記事が気に入ったらサポートをしてみませんか？