解説

業務パッケージである支払管理システムを題材に、システム監査の基本的な理解が問われていますが、手作業を含めた業務プロセスは比較的平易であり、システム監査の理解が十分でなくとも、問題文を丁寧に読み解けば、解答する語句をピックアップできる問題です。システムの概要説明、予備調査で判明した事実の説明、監査手続についての問題点を解明するという流れは例年通りです。

〔abについて〕
項番2の監査手続は、支払管理システムのパスワードポリシーが、V社のパスワード規程に準拠しているかどうかを確認するというものです。この点については、〔支払管理システムの運用の概要〕(1)に「業務パッケージのパスワードポリシーの一部には，規程類に適合するようにパスワードポリシーを適用できない箇所があった」と記載されていて、予備調査において既に不備の存在が予測されています。

これに対応して追加する監査手続であることを踏まえて本文を読むと、〔支払管理システム及び関連システムの概要〕(1)で「規程類に適合しない機能を採用する場合には，対応策を含めて，リスク委員会の承認を受ける必要がある」という管理策が存在することがわかります。パスワード管理機能は業務パッケージの標準機能であり、カスタマイズ等が実施されずに適合しない状態そのままで運用されているわけですから、導入時におけるこのコントロールが適切に行われたかどうかを確認すべきです。これが本調査において追加すべき監査手続となります。つまり「何が」に相当する空欄bには「リスク委員会の承認」が当てはまります。

空欄aについては、本文中に支払管理システムの導入に至る一連のプロセス（企画，要件定義，業務パッケージ選定，設計，開発，テスト及びリリース）が記載されていて、『この中から選べ』という出題者からのメッセージが読み取れます。この一連のプロセスのうち、適合しない機能を採用するという判断が行われるのは業務パッケージ選定の段階ですので、リスク委員会の承認もこの段階で行われることになります。したがって、空欄aには「業務パッケージ選定」が当てはまります。

∴a＝業務パッケージ選定
　b＝リスク委員会の承認

〔cについて〕
項番3の監査要点は、支払予定データが調達実績データから適切に作成されていることの確認です。支払予定データが調達実績から作成されるプロセスについては、〔支払管理システムの運用の概要〕(2)の④と⑤で説明されています。④⑤の記載事項の要点は次のとおりです。

1. 支払予定データを生成するには、支払先マスターに調達用支払先を登録しておく必要がある
2. 支払予定データは、半月ごとに調達管理システムから調達実績データを取り込むことで生成される
3. 取込み処理でエラーが発生した場合は、情報システム部がエラー対応する
4. エラー以外の理由で支払予定データが生成できない場合は保留ファイルに格納され、経理部が対応後に保留ファイルの更新処理を行う

上記のうち、項番3の監査手続に入っていない事項を探すと、a～cについては表1の監査手続で確認対象となっていますが、dについては確認対象に含まれていません。これより、支払予定データの作成に関して追加すべき監査手続は、経理部が行う保留ファイルの更新処理を実行する一連の作業についての確認であることがわかります。したがって、空欄cには「保留ファイル」が当てはまります。

∴c＝保留ファイル

〔dについて〕
項番4の監査要点は、経費精算などの支払予定データが適切に承認されていることの確認です。支払申請入力と承認のプロセスについては、〔支払管理システムの運用の概要〕(2)の①～③で説明されています。①～③のうち承認に関する記載事項の要点は次のとおりです。

1. 支払申請入力について、承認者が承認入力を行うことで支払予定データが生成される
2. 支払金額が一定額を超過する場合、事業本部長および担当役員の承認が必要となる。この承認は、承認者が経理部宛のCCを含む電子メールを上位者に送信することによって行われる
3. 経理部は、証ひょう類に不備がある場合、支払予定データを未承認の状態に変更する

上記のうち、支払金額に関連して項番4の監査手続に入っていない事項を探すと、支払金額が一定額を超過する場合における追加の承認手続に対する確認が不足していることがわかります。したがって、これが追加されるべき監査手続となり、空欄dには「一定額を超過する場合」が当てはまります。「支払額を減額したい場合」は減額の支払申請を入力するだけですから、承認には関係ありません。

申請・稟議・承認などが電子メールで行われることは多いですが、電子メールを利用した承認は、システムに組み込まれた機能で行われる場合と比較して、送受信時に不適切な介入や改ざん、共謀による不正行為が発生するリスクが大きいと言えます。このため、通信記録の保全など適切なコントロールが行われているかどうかの確認が重要となります。

∴d＝一定額を超過する場合

解説

〔eについて〕
〔支払管理システムの運用の概要〕(2)の⑦に、振込データは、作業完了した支払予定データから経理部が作成すると記載されているので、支払予定データに対して経理部が振込データ作成前に完了させておくべきことを⑦以前から探します。経理部が主語になっている文を探すと、「保留ファイルの更新処理」と「一定額超過の承認メールを含む証ひょう類に不備がないかチェック」の2つが見つかります。「保留ファイルの更新処理」が完了していることの確認は、漏れのチェックにつながるもので、表1項番5に記載の監査手続における確認対象となります。したがって、空欄eには「証ひょう類に不備がないかのチェック」が当てはまります。

支払管理システムでは、支払申請が承認された場合、その時点で支払予定データが生成されます。その後、経理部がチェックし、証ひょう類に不備があれば未承認に変更する流れです。V社では「証ひょう類を承認者に回付せず，申請者が入力後に経理部に送付する」運用なので、承認段階では不備を発見できず、不備の発見は経理部のチェックによることになります。このため、承認済みでも不備のある支払予定データが存在する可能性があり、これを適切に管理しないと、不適切な振込データが作成されるおそれがあります。したがって、振込データの作成前に、経理部による証ひょう類のチェックが完了していることの確認が必要となります。

∴e＝証ひょう類に不備がないかのチェック

解説

〔fについて〕
昨年度のシステム監査での発見事項は、「取引先別の調達実績データの合計額が支払管理システムの支払予定データの合計額と一致していない」というものです。表1の監査要点のうち、これを確かめているのは、調達実績データから支払予定データが生成されるプロセスを確認する項番「3」です。

∴f＝3

解説

〔gについて〕
支払申請入力に関連して、調達実績データと支払予定データの差異が発生する可能性を考えます。

〔支払管理システムの運用の概要〕(2)を読むと、支払管理システムの支払先マスターには、調達用支払先とそれ以外の支払先の両方が登録されていると考えられます。「調達用支払先は，調達管理システムに関する支払業務以外では利用しない」とされていますが、経費精算などそれ以外の支払申請において、調達用支払先を誤って利用してしまった場合、その調達先に対する支払予定額が増えます。これにより、合計額の差異が発生することになります。したがって、空欄gには「調達用支払先」が当てはまります。

∴g＝調達用支払先

〔hについて〕
支払遅延防止のために追加の支払申請入力に関連して、調達実績データと支払予定データの差異が発生する可能性を考えます。

支払期日に間に合わせるために追加の支払申請入力を行った場合、次回の取込処理までに重複防止のための減額の支払申請入力が必要とされていて、これを行えば取引先ごとの合計額について帳尻が合います。しかし、これを怠った場合、取込処理により重複して支払予定データが作成されることとなり、調達実績データよりも支払予定額が多くなってしまいます。これにより、合計額の差異が発生することになります。したがって、空欄hには「減額の支払申請入力」が当てはまります。

∴h＝減額の支払申請入力