システム監査

要点と定義

システム監査では、独立かつ客観的な立場の監査人が情報システムに関わるリスクへの対応を検証・評価し、保証や助言を通じて組織の目標達成を支援する。監査は、計画、実施、報告、フォローアップの流れで進む。

システム監査基準は監査人の行為規範であり、監査項目を列挙したチェックリストや評価尺度そのものではない。監査対象を評価する尺度には、対象に応じた管理基準などを参照できる。これは過去の出題で扱った補足である。

監査の種類は、監査する側と対象との関係で区別できる。自組織による内部監査は第一者監査、顧客などが供給者を監査するものは第二者監査、独立した認証機関による審査などは第三者監査に当たる。これは過去の出題で扱った補足である。

監査証拠は監査の結論を裏付ける情報である。監査人は、監査目的に照らして証拠が十分かつ適切かを評価する。証拠の価値は文書の体裁だけでは決まらず、作業記録や開発成果物も評価の対象になり得る。予備調査で実態を把握してから本調査を進め、目的に応じて複数の監査手続を組み合わせることがある。第三者の保証報告書に依拠する場合は、対象範囲などが監査目的に合うかを確かめる。これらは過去の出題で扱った補足である。

監査調書には、調査・検証した情報と、結論に至った過程が分かるように記録する。調書は監査報告書や結論の基礎となる。指摘事項は重要性を踏まえて選び、事実や証拠について対象部門と確認する。保証目的でも助言目的でも、結論を支える合理的な根拠を得るまで監査手続を行う。これは過去の出題で扱った補足である。

ITF法は、実稼働中のシステムに監査用の仮想データを設け、テスト入力の処理結果を期待値と照合する監査技法である。これは過去の出題で扱った補足である。

報告書に記載した改善提案や対象側が作成した改善計画は、所要の措置が適切かつ適時に実施されたかをフォローアップする。対象側の実施状況報告を確認し、必要なら改善内容を追加検証する。改善の実施責任は対象側にあり、監査人は代わりに実施したり、経営陣に実施を指示したりしない。これは過去の出題で扱った補足である。

適用条件と例

監査計画では、目的や範囲、方法、時期などを定める。限られた時間で複数の対象を監査するなら、想定されるリスクを踏まえて優先順位を付ける。例えば、業務停止につながり得るアクセス管理上の懸念と、影響の小さい画面表示の不備が並んでいる場合、業務への影響やリスクを確認し、先に調べる対象を計画する。これはリスクに基づく計画の考え方である。

提案依頼によるベンダ選定を監査するときは、提案条件に関わる追加情報が候補間で公平に共有されているかを確認する。一部の候補だけに情報を渡すと、提案や比較の公平性を損なう可能性がある。これは過去の出題で扱った補足である。