補習所考査対策　【ITのリスク評価の概論】③　既に218名が購入済み

確度のきわめて高い出題予想箇所と過去問で出題された箇所を太文字で明示。さらに、ただの丸暗記は苦痛なので、＜理由＞で深堀りして＜具体例＞でイメージを。これにより、理解しながら暗記することが可能に！！

Ⅳ 評価したリスクに対応する監査手続

１．情報処理統制のリスク対応手続（運用評価手続）

ＩＴの情報処理統制を評価する場合には、主要なパターン以外の取引がどのように処理されるロジックであるかを把握し、サンプルの抽出の際に考慮しなければならない。
＜理由＞
①　リスクの特定と管理：主要なパターン以外の取引は、通常の業務フローから外れるため、エラーや不正のリスクが高まる。これらの取引を無視すると、潜在的なリスクを見逃す可能性がある。
②　全体的な信頼性の確保：すべての取引が適切に処理されていることを確認するためには、主要なパターン以外の取引も含めて評価する必要がある。これにより、システム全体の信頼性を確保できる。
③　コンプライアンスの遵守：特定の規制や基準に従うためには、すべての取引が適切に処理されていることを証明する必要がある。主要なパターン以外の取引も含めて評価することで、コンプライアンスを確保できる。

＜具体例＞
①　例外処理の管理：エラーが発生した場合の修正と再処理の手順を確認することが重要である。
②　マスタデータの維持管理：取引に使用されるマスタデータが正確で最新であることを確認するための統制。
③　アクセス管理：システムの利用に関する承認や操作範囲の限定など、アクセス権限の管理。
これらの具体例を考慮することで、主要なパターン以外の取引も含めた包括的な評価が可能になる。

ＩＴ全般統制の整備又は運用状況に不備が存在する場合は、情報処理統制の運用評価手続の範囲を拡大させることを検討する。ＩＴ全般統制の不備の程度により、情報処理統制の有効性の評価ができないと判断される場合がある。

＜理由＞
基盤の信頼性の欠如: ITGCは、システム全体の信頼性とセキュリティを確保するための基本的な統制である。これに不備があると、システム全体の信頼性が損なわれ、ITACの有効性も疑わしくなる。
リスクの増大: ITGCの不備は、システムの操作やデータの整合性に対するリスクを増大させる。例えば、アクセス管理の不備があると、不正アクセスやデータの改ざんが発生する可能性が高まる。
統制環境の弱体化: ITGCは、ITACが効果的に機能するための環境を提供する。ITGCに不備があると、ITACが期待通りに機能しない可能性が高くなる。

情報処理統制の運用状況の評価にあたっては、当該内部統制がどのように機能するかを質問等により理解する。その上で、以下のような手続により期待どおりに機能するかどうかについての心証を得る。なお、本番環境上での再実施は、本番データへの影響を慎重に検討することに留意する。
・ 証憑等を利用した処理の再実施
具体例: 例えば、売上取引の証憑（請求書や納品書）を基に、システム内での売上計上処理を再実施する。これにより、システムが正確に売上を計上しているかを確認する。

・ アクセス・コントロール、マスタチェック等の入力時の統制の再実施
具体例: ユーザのアクセス権限を確認し、特定のユーザが適切な権限を持っているかをテストする。また、マスタデータ（例えば、顧客情報や製品情報）の入力時に適切なチェックが行われているかを確認する。

・ テストデータ法による、計算方法（ロジック）の正確性の検証
具体例: テストデータを使用して、給与計算システムの計算ロジックを検証する。例えば、特定の従業員の給与計算をテストデータで実施し、期待される結果と一致するかを確認する。

・ 本番データを入手して、処理結果としての電子ファイル間の整合性の検証、網羅性
の検証（ＣＡＡＴｓ）
具体例: 本番データを使用して、売上データと在庫データの整合性を検証する。例えば、売上データと在庫データを突合し、売上が発生した際に在庫が適切に減少しているかを確認する。

・ プログラムのレビュー
具体例: システムのソースコードをレビューし、特定の機能が正しく実装されているかを確認する。例えば、データの暗号化機能が正しく実装されているかをコードレベルで評価する。

・ モニタリングレポートのフォローアップ
具体例: システムのモニタリングレポートをレビューし、異常な活動やエラーが報告されていないかを確認する。例えば、アクセスログのモニタリングレポートを確認し、不正アクセスの兆候がないかをチェックする。

２．期中で入手した監査証拠の利用

監査人は、期中で内部統制の運用状況の有効性に関する監査証拠を入手する場合、以下の手続を実施しなければならないが、情報処理統制に関しては、ＩＴによる処理に一貫性があるため、情報処理統制の業務への適用に関する監査証拠は、ＩＴ全般統制（特に、変更に関する内部統制）の有効性に関する監査証拠と組み合わせることにより、監査対象期間における情報処理統制の運用の有効性に関する監査証拠を提供する。

＜理由＞
①　一貫性の確保: ITによる処理は通常、一貫した方法で実行されます。システムが変更されない限り、同じ入力に対して同じ出力が得られるため、IT全般統制が有効であれば、情報処理統制も一貫して有効であると判断できる。
②　変更管理の重要性: システムの変更が適切に管理されていることを確認することで、システムの信頼性と一貫性が保たれていることを保証できる。変更管理が適切であれば、システムの機能や統制が意図した通りに動作していることが確認できる。
③　統制環境の強化: IT全般統制は、情報処理統制が効果的に機能するための基盤を提供する。特に変更管理に関する統制が有効であれば、システムの安定性と信頼性が確保され、情報処理統制の有効性も高まる。

＜具体例＞
①　ソフトウェアアップデートの管理: 例えば、会計システムのソフトウェアアップデートが適切に管理されている場合、アップデート後もシステムが正しく動作し、情報処理統制が維持されていることを確認できる。
②　アクセス権限の管理: システムへのアクセス権限が適切に管理されている場合、不正アクセスやデータの改ざんが防止され、情報処理統制の有効性が保たれる。
③　変更履歴の追跡: 変更管理システムを使用して、システムの変更履歴を追跡し、すべての変更が適切に承認され、テストされていることを確認する。これにより、変更がシステムの統制に与える影響を評価できる。

① 運用評価手続を実施した後の当該内部統制の重要な変更についての監査証拠を入手する。
② 期末日までの残余期間に対してどのような追加的な監査証拠を入手すべきかを決定する。

３．過年度の監査で入手した監査証拠の利用

監査人は、内部統制の運用状況の有効性を評価するに際し、過年度の監査で入手した監査証拠を利用する場合、当該内部統制の重要な変更が過年度の監査終了後に発生しているかどうかについての監査証拠を入手し、過年度の監査から引き継ぐ監査証拠の適合性を確認しなければならない。
監査人は、当該内部統制についての理解を確かめるため、質問に観察又は記録や文書の閲覧を組み合わせて実施し監査証拠を入手しなければならない。さらに、以下のような事項に留意する。
① 過年度の監査から引き継ぐ監査証拠の適合性に影響する変更があった場合には、当年度の監査で内部統制の運用評価手続を実施しなければならないこと
理由: 過年度の監査証拠が適合しない場合、内部統制の有効性に関する結論が誤っている可能性がある。システムやプロセスに変更があった場合、その影響を評価し、内部統制が引き続き有効であることを確認する必要がある。

具体例: 例えば、会計システムのアップデートが行われた場合、その変更が内部統制に与える影響を評価し、必要に応じて新たなテストを実施する。

② 情報処理統制については、それを支援するＩＴ全般統制の有効性
理由: 情報処理統制は、IT全般統制（ITGC）が有効であることを前提としている。ITGCが有効でない場合、情報処理統制も信頼できない可能性がある。

具体例: 例えば、アクセス管理の統制が適切に機能しているかを確認するために、ユーザのアクセス権限のレビューを行います。ITGCが有効であれば、情報処理統制も信頼できると判断できる。

③ 情報処理統制に関連する障害の発生状況
理由: 情報処理統制に関連する障害が頻繁に発生している場合、その統制が期待通りに機能していない可能性がある。障害の発生状況を確認することで、統制の有効性を評価できる。

具体例: 例えば、システムのログを確認し、エラーや障害の発生頻度を評価する。頻繁にエラーが発生している場合、その原因を特定し、統制の改善が必要かどうかを判断する。

４．情報処理統制に前年度からの変更がないことを確認する監査手続例

前回、運用状況の有効性を確かめたときから情報処理統制に変更がないことを確かめる監査手続として、以下のような方法や前年度と同様の検証手続の実施が考えられる。
(1) プログラムやシステム設定等、システム自体に全く変更がなく、評価対象の情報処理統制等については変更がない場合
① 市販されている簡易なパッケージ・ソフトウェアをカスタマイズなく利用している場合
バージョン情報を把握し当該ソフトウェアに更新があったかどうか確かめる。
なお、システム設定の変更等の有無についても留意する。

バージョン情報を把握し当該ソフトウェアに更新があったかどうか確かめる理由と具体例。

理由: 市販のパッケージ・ソフトウェアは、ベンダーによって管理されており、バージョン情報や更新履歴が明確に記録されている。これにより、ソフトウェアに変更がないことを確認することが容易である。

具体例:

バージョン情報の確認: 使用しているソフトウェアのバージョン情報を確認し、前年度から変更がないことを確認する。例えば、ソフトウェアの「バージョン情報」画面やベンダーの提供する更新履歴をチェックする。
システム設定の確認: システム設定が変更されていないことを確認する。例えば、設定ファイルや管理画面を確認し、設定内容が前年度と一致していることを確認する。

システム設定の変更等の有無についても留意する理由と具体例

理由: 自社開発ソフトウェアやERPシステムは、内部で管理されているため、変更管理台帳やバージョン管理台帳を通じて変更履歴を詳細に追跡できる。これにより、システムに変更がないことを確認することができる。

具体例:

変更管理台帳の確認: IT全般統制の評価手続において、プログラムバージョン管理台帳や変更管理台帳の正確性と網羅性を確認する。これにより、変更がないことを確認する。
変更案件の確認: 変更管理台帳に記載された変更案件がないことを確認する。例えば、変更管理システムを使用して、過去1年間に登録された変更案件がないことを確認する。

② 自社開発ソフトウェアやＥＲＰシステムを利用している場合
ＩＴ全般統制の評価手続においてプログラムバージョン管理台帳や変更管理台帳の正確性、網羅性の心証を得ている場合は、当該台帳等に変更案件がないことを確かめる。

理由
IT全般統制の評価手続において、プログラムバージョン管理台帳や変更管理台帳の正確性と網羅性を確認することで、システムに変更がないことを確実に把握できる。これにより、情報処理統制が前年度と同様に有効であることを確認できる。

具体例
プログラムバージョン管理台帳の確認
理由: プログラムバージョン管理台帳には、システムのバージョン情報や更新履歴が記録されている。これを確認することで、システムに変更がないことを確認できる。
具体例: プログラムバージョン管理台帳をレビューし、前年度からのバージョン変更がないことを確認する。例えば、バージョン番号や更新日付をチェックし、変更がないことを確認する。

変更管理台帳の確認
理由: 変更管理台帳には、システムの変更履歴が記録されている。これを確認することで、システムに変更がないことを確認できる。
具体例: 変更管理台帳をレビューし、過去1年間に登録された変更案件がないことを確認する。例えば、変更管理システムを使用して、変更案件の有無を確認する。

システム設定の確認
理由: システム設定が変更されていないことを確認することで、情報処理統制が前年度と同様に有効であることを確認できる。
具体例: システム設定ファイルや管理画面を確認し、設定内容が前年度と一致していることを確認する。例えば、設定ファイルの内容を比較し、変更がないことを確認する。

(2) プログラムや設定等、システム自体に変更はあるが、評価対象の情報処理統制等については変更がない場合
① 市販されている簡易なパッケージ・ソフトウェアをカスタマイズなく利用している場合
通常、バージョンアップ時には、機能改善又は追加された箇所がリリースノートに記載されている。当該リリースノートの内容を確かめることで、情報処理統制等に変更があったかどうかの心証を得る。

① 市販されている簡易なパッケージ・ソフトウェアをカスタマイズなく利用している場合
理由: 市販のパッケージ・ソフトウェアは、ベンダーによって管理されており、バージョンアップ時にはリリースノートに機能改善や追加箇所が記載されます。これにより、情報処理統制に変更があったかどうかを確認することができる。

具体例:

・リリースノートの確認: ソフトウェアのバージョンアップ時に提供されるリリースノートを確認する。リリースノートには、追加された機能や改善点が記載されているため、情報処理統制に影響を与える変更がないかを確認する。
例えば、リリースノートに「新しいレポート機能の追加」や「既存のデータ入力画面の改善」といった記載がある場合、それが情報処理統制にどのような影響を与えるかを評価する。
・システム設定の確認: システム設定が変更されていないことを確認する。例えば、設定ファイルや管理画面を確認し、設定内容が前年度と一致していることを確認する。
具体的には、アクセス権限設定やデータ入力の検証ルールが変更されていないかを確認する。

５．情報処理統制の運用評価手続の具体例