SGのシステム監査対策｜独立性・監査証拠・フォローアップをケースで理解

SGシラバスVer.4.1のシステム監査分野には、目的と手順、倫理、独立性・客観性、証拠、報告、フォローアップが挙がっています。技能項目10-2では、文書をそろえ、インタビューに応じ、指摘への改善策を活動計画にして実施することも示されています。用語を覚えるだけでなく、業務担当者が監査にどう協力するかを考えるとつながります。

例えば、監査人から設定変更の承認記録を求められたとき、業務担当者は対象期間と変更案件に対応する記録を説明します。監査人の結論を先回りして作るのでも、指摘されないよう不都合な案件を隠すのでもありません。自分の担当範囲と、評価する側の役割を分けて読むことが大切です。

監査で評価する対象の仕組みはSGの内部統制・職務分掌とIT統制で、業務に組み込む対応と監査の役割を分けて確認できます。

自己点検は、担当する業務の実施状況を自ら確かめる取組として使われます。一方、監査では対象を評価する立場の独立性と客観性が重要になります。社内で行う内部監査だから独立性が不要ということでも、外部の会社へ依頼すれば利害関係を一切考えなくてよいということでもありません。

架空の例で、購買システムの権限を設計・設定した担当者が、自分の設定だけを見て「監査済み」と結論を付けようとしたら、評価する立場を確認する必要があります。別の部署に所属していても、その人が対象の運用を実質的に決めているなどの事情がないかを見ます。所属名や役職名だけで判定しません。

NCOの関係法令Q&AハンドブックVer.3.0は、システム監査や情報セキュリティ監査が、社内の内部監査部門によって行われる場合と、外部機関によって行われる場合を説明しています。ここでは制度上の監査義務や監査人資格の取得要件を判定せず、学習上の役割の違いを整理します。

監査を行う側の行為や実施・報告の枠組みと、対象の管理がどうあるべきかという判断の尺度を混ぜないようにします。例えば、評価する人の独立性と、システム利用者の権限が適切かという論点は、どちらも重要でも見ている対象が違います。

JASAは、情報セキュリティ監査基準を監査主体の行為規範として、情報セキュリティ管理基準を監査上の判断の尺度として説明しています。システム監査と情報セキュリティ監査は関連しますが、名称を入れ替えて全く同じ制度と扱わないでください。SGの学習でも、どの基準の何を問う説明かを確認します。

本記事はシラバスの基礎概念と架空例を扱うもので、監査基準の全文解説や認証審査の代行ではありません。規格・基準の具体的な番号や版を学ぶ場合は、その発行元の現行資料を参照してください。古い資料の項目数や告示年を、そのまま現在のものとして覚えないようにします。

架空の会社Mでは、購買システムの設定変更に、実施前の責任者承認と変更後の確認記録を必要とするルールがあります。対象期間の変更申請は12件で、監査人はそのうち3件の記録を確認したとします。2件は申請番号に対応する承認と確認記録があり、残る1件について担当者は「口頭で了承を得た」と説明しました。

この場合、3件のうち2件で記録を確認できたことと、12件全てがルールどおりだったことは別です。また、1件の記録が見つからないことだけで、不正や未承認と確定するのでもありません。求めるルール、対象案件、得られた情報、まだ確かめられない点を分け、必要な追加確認を検討します。

12件・3件・2件という数は当サイトの架空の説明用であり、監査の標準抽出数や必要サンプル数ではありません。対象のリスク、母集団、抽出方法、確認内容によって結論の範囲は変わります。少数の確認を全体の完全な保証に読み替えないことを、この例の中心に置いてください。

資料の名称だけでなく、その材料が何の主張を裏付けるかを結び付けます。対象外の時期の画像や別案件の承認書を流用して、確認できた範囲を広げないようにします。

文書の確認、関係者へのインタビュー、許可された範囲での状態の確認は、それぞれ得られる情報が異なります。口頭説明は手順や背景を知る材料になりますが、それだけで承認記録を必要とするルールの運用まで確認したとはいえません。逆に、記録があるだけで対象や時点を照合せず結論を付けることも避けます。

会社Mの1件なら、対象の申請番号、承認の経緯、記録の保管先、変更した時点を担当者へ確認することが考えられます。証拠が得られない場合には、その制約を残します。後から承認日を変更したり、当時なかった記録を当時から存在したように作ったりして、過去の状態を埋めてはいけません。

監査証跡としてのログと、監査人が判断の根拠として扱う証拠は関連しますが、ログが大量にあれば自動的に結論が決まるわけではありません。保持・検索・時刻の詳しい設計は証跡の保存期間と取得、記録の種類はクラウド監査ログに分けています。

仮に確認の結果、会社Mで必要な記録を残す運用に問題が認められたなら、業務側は原因と改善策を整理します。「今後気を付ける」だけでなく、申請と承認をひも付ける手順、責任者、期限、完了を確認する方法を決めます。監査人が自ら承認設定を変更し、そのまま自分の変更を評価する役回りに置き換えないことも大切です。

改善後には、新しい手順ができた事実と、実際に使われている状態を分けます。フォローアップでは、指摘への対応状況を確かめ、未了や効果が未確認の点があれば引き続き扱います。監査報告書が発行されたことだけで、指摘が全て解消したとは扱いません。

会社Mが電子承認の手順を導入しても、それだけで過去の1件に当時の承認記録があったことにはなりません。「今後の運用改善」と「過去に確認できなかった範囲」を同じ欄で消さないようにします。必要に応じて責任者が追加調査やリスク対応を判断します。

学習ノートでは、指摘事項に対して誰が何をし、何を見れば改善したと言えるかを書きます。実行担当と確認担当、予定と実績を分けると、選択肢が役割や時間軸を取り違えていないかを説明しやすくなります。

この表は監査調書の正式なひな形ではありません。個人名・取引情報・秘密を学習サービスへ持ち込まず、架空の名称と条件で練習してください。

知識確認では、監査の独立性、判断の尺度、証拠、報告とフォローアップの目的を一文で説明します。ケースでは「監査人が評価すること」「業務側が改善すること」「責任者が判断すること」を分けて考えます。ただし設問本文にない社内体制を勝手に付け足さず、指示された立場と条件を優先してください。

読み方全体は科目Bの条件整理、残るリスクの判断はSGのリスク対応ケースで確認できます。SGの学習目次で範囲を整理し、無料6問では教材の操作と解説を試せます。無料体験が監査分野の網羅的な診断になるわけではありません。収録内容と条件は教材・料金へ。

SLOとエラーバジェットの計算では、測定の分母と集計期間をそろえ、数値を復旧や変更の判断へつなげる方法を独自例で確認できます。