【応用情報技術者試験】システム監査を学ぼう！　　　　　~第2章~システム監査の実施

システム監査は、独立した第三者（システム監査人）が情報システムを総合的に点検・評価し、安全性や信頼性を保証・助言する手続きです。監査計画、予備調査、本調査、報告、フォローアップの5ステップで実施し、リスク低減やガバナンス向上を目的に、経済産業省の『システム監査基準』に基づき実施されます。

画像参照：https://www.itmedia.co.jp/im/articles/0402/28/news002.html 

実施手順

1. 監査計画の策定: 目的、範囲、体制、スケジュールを定義し、計画を立案する。
2. 予備調査: アンケートや関連資料のレビューを通じて、対象システムの概要とリスクを把握する。
3. 本調査（実地調査）: ヒアリング、現地調査、記録の確認などを行い、客観的な証拠を入手する。
4. 評価・報告: 入手した証拠に基づき、基準に沿って評価を行い、指摘事項や改善勧告をまとめた報告書を作成して提示する。
5. フォローアップ: 被監査部門による改善活動の実施状況を確認し、必要に応じて支援する。 

実施のポイント

• 基準の遵守: 『システム監査基準』や『システム管理基準』を基盤とし、客観的な視点で検証を行う。
• リスクベースのアプローチ: 重要度やリスクの高いシステムに重点を置いて調査を行う。
• 目的の明確化: 不正の摘発よりも、信頼性・安全性・効率性の向上や、組織の目標達成への貢献に主眼を置く。
• 第三者性: 監査対象部門から独立した立場で実施する。

監査計画の策定

システム監査の「監査計画の策定」は、効果的かつ効率的に監査を実施するための最重要プロセスであり、目的、範囲、手法、スケジュール、体制（監査チーム、被監査部門）を明確にする。リスクベースアプローチを採用し、重要リスク領域に監査資源を集中させ、基準に準拠した計画を策定する。 

主なプロセス

1. 監査の目的と範囲の明確化: 経営課題やリスクに基づき、「何を・どこまで・何のために」監査するかを定義する。
2. リスク評価（リスク・アプローチ）: ITシステムのリスクの大きさを把握し、影響度が大きい箇所を重点対象とする。
3. 監査手法・手順の選定: ヒアリング、アンケート、実地調査、チェックリストなど、適切な調査手法を計画する。
4. スケジュールと体制の確定: 監査期間、要員（監査人）、および被監査部門（対象者）の役割分担を決定する。
5. 計画書（個別計画）の作成と承認: 上記をまとめた「個別計画書」を作成し、経営層や監査依頼人の承認を得て決定する。

構造と内容

• 中長期計画（3年程度）: 経営戦略・中期情報化計画と連動し、重点監査対象を策定。
• 基本計画（年度計画）: 中長期計画を基に、単年度の目的や体制、予算などを定義。
• 個別計画書（プロジェクト単位）: 個別のシステムや業務に対する詳細な計画。

計画策定のポイント

• リスクに基づくアプローチ: 重大なリスクがある領域に注力する。
• 柔軟性の確保: 状況変化に応じて適時に計画を変更・修正できるようにする（アジャイルな対応）。
• 客観性と専門性: システム監査基準に基づき、独立した第三者の立場を堅持する。

予備調査

システム監査の「予備調査」は、本調査を効率的かつ効果的に実施するために、対象システムや業務の概要、リスクの所在を事前に把握するプロセスです。関連文書（規程・手順書など）のレビューやアンケート調査により、本調査の重点項目を絞り込み、調査計画を精緻化します。 

主な目的

• 現状の把握: 業務内容、システム構成、組織体制、管理手順を理解する。
• リスクの特定: 不正や不備が発生しやすい「リスクの高い箇所」を特定する。
• 本調査の効率化: 調査対象の絞り込みや、ヒアリング対象者の選定を行い、本調査をスムーズに進める。 

実施する主な手法

1. 資料のレビュー（文書監査）: 事務手続書、システム運用マニュアル、組織図、業務分掌、過去の監査結果などを確認する。
2. アンケート調査: 被監査部門の管理者や担当者に対し、リスク認識やコントロール状況（規程の遵守など）についてアンケートを実施する。
3. 簡易的なヒアリング: 関係者からシステムの概要を聞き取り、課題を把握する。 

本調査との違い

• 予備調査: 概要把握、リスクの洗い出し、本調査計画の見直し。
• 本調査: 証拠の入手、詳細調査、監査結果の確定。 

予備調査の結果、リスクが低いと判断された箇所は本調査の対象外に、リスクが高いと判断された箇所は重点的に調査するよう、計画を修正します。 

本調査（実地調査）

システム監査の実施における「本調査（実地調査）」は、予備調査で特定したリスクに基づき、客観的な証拠を入手し、情報システムが安全性、信頼性、効率性を確保しているかを検証する中心的なプロセスです。 

主に「質問（ヒアリング）」「観察」「検査（ドキュメントレビュー）」「実証テスト（再実行）」の4つの手法を組み合わせて実施されます。

本調査の主な技法

• 質問: 被監査部門の担当者や責任者に、管理体制や手順についてインタビューを行う。
• 観察: データセンターの入退室管理や物理的セキュリティ、実際の運用作業（バックアップ処理など）が規定通りに行われているかを現地で直接確認する。
• 検査: セキュリティポリシー、手順書、ログ記録、システム設定のスクリーンショット、契約書などの書類をチェックし、コントロールが機能している証拠を収集する。
• 実証テスト（再実行）: 監査人が実際にシステム操作を行うか、または被監査者に再実行してもらい、計算やプロセスが正しいかを確認する。
• CAAT（コンピュータ支援監査技法）: システムデータそのものを専用ツールで分析し、特権IDの不正利用やデータ矛盾の兆候を抽出する。

重点的な調査項目

• アクセス管理（セキュリティ）: 特権IDの管理、退職者のアカウント削除、ファイアウォールの設定、パスワードポリシーの遵守状況。
• 物理的セキュリティ: データセンターやサーバールームの入退室ログ、監視カメラ、物理的アクセス制限。
• 運用管理: バックアップ・復旧手順、パッチ適用状況、ログの定期チェック。
• 開発・変更管理: アプリケーションの開発・修正プロセスにおける承認手続き、テスト実施記録。
• 事業継続計画（BCP）: 災害復旧計画の策定とドリル（訓練）の実施状況。

プロセス

1. オープニング会議: 調査の目的、範囲、スケジュールを再確認し、協力を要請する。
2. 実地調査（オンサイト・監査）: 現場の視察、関係者へのヒアリング、証拠の入手を実施する。
3. 不備の確認と原因分析: 証拠に基づき、規定（基準）と実態の乖離（不適合）を特定し、その根本原因を探る。
4. 監査結果の整理: 5C（Criteria/基準, Condition/実態, Cause/原因, Consequence/影響, Corrective Action/是正措置）のフレームワークを用いて報告書を作成する。 

実地調査におけるポイント

• 客観的証拠の収集: 担当者の「説明」だけでなく、ログやドキュメントなどの「実証可能な資料」を重視する。
• サンプリング調査: すべてのデータを調べるのではなく、リスクが高い取引や期間をサンプルとして抽出し、代表的に確認する。
• 独立性の維持: 被監査部門から独立した立場で、客観的に評価する。

このプロセスを経て、監査人は「適切な管理がなされているか」を判断し、改善勧告を行うための基礎資料を作成します。

監査技法

基本的な監査技法を下記に整理します。

技法	内容
チェックリスト法	システム監査人が事前に作成した質問書（チェックリスト）に関係者が回答する監査技法。
ドキュメントレビュー法	システム監査人が規定類、手順書、システムログ、設計書などの関連資料を点検し、客観的な監査証拠を入手する監査技法。
突合法・照合法	システム監査や会計監査において、関連する複数の資料・記録（例えば伝票と帳簿、ログと業務記録）を突き合わせ、情報の整合性、正確性、実在性を客観的な証拠に基づいて検証する監査技法。
現地調査法	システム監査人が監査対象部門（データセンターや事務所）に直接赴き、実際の業務の流れ、物理的なセキュリティ状況、設備環境などを観察・調査する監査技法。
インタビュー法	関係者への口頭質問を通じて業務実態や内部統制の運用状況を短時間で把握する監査技法。

コンピュータ監査技法を下記に整理します。

評価・報告

システム監査の「評価・報告」は、収集した証拠に基づきリスクや改善点を特定し、経営層へ報告する最終段階です。客観的な評価、具体的な改善勧告、経営トップへの報告が必須であり、これらを通じて組織のガバナンス向上やシステム信頼性の確保を目指します 。 

評価・分析（監査調書の作成と評価）

• 客観的根拠に基づく判断: 収集した監査証拠（ヒアリング記録、資料、画面キャプチャなど）を基に、システム監査基準等と照らし合わせる。
• 問題点・リスクの抽出: 安全性、信頼性、効率性の観点から問題点とそのリスク（影響範囲）を明確にする。
• 改善勧告の策定: 発見された問題に対する建設的かつ具体的な改善策を策定する。

報告書の作成と報告

• 監査報告書の構成: 監査の目的、対象範囲、実施期間、手法、概要、結論、指摘事項、改善勧告を網羅する。
• 事前相談（ドラフト確認）: 誤解や不当な指摘を防ぐため、最終報告前に被監査部門と内容のすり合わせを行う。
• 経営層への報告: システム監査報告書は原則として組織の長（経営トップ）に直接提出・報告する。 

評価・報告時のポイント

• 建設的な意見: 批判ではなく、システムの更なる発展に寄与する前向きな内容とする。
• 明確な根拠: 「客観的証拠」に基づいていること。
• 結論の種類: 通常、無限定適正意見、限定付適正意見、不適正意見、意見不表明などの形式で表明される。

無限定適正意見（むげんていてきせいいけん）
公認会計士や監査法人が企業の財務諸表を監査した結果、すべての重要な点において会計基準通りに適正に作成されていると判断した際に表明する最も標準的な意見です。

このプロセスを通じて、単なる不備の指摘に留まらず、組織全体の情報システム管理体制の強化に貢献します。

フォローアップ

システム監査の「フォローアップ」とは、監査報告書で指摘された不備や改善勧告に対し、被監査部門が適切な改善策（是正処置）を計画・実施しているかを、システム監査人が事後的に確認・モニタリングするプロセスです。目的は、リスクの低減と監査結果に基づく実質的な業務改善の確実な履行です。 

システム監査におけるフォローアップの特徴

• 役割分担: 改善を行うのは「被監査部門（主体）」であり、監査人はそれを「確認・支援（事後評価）」する立場です。
• 独立性の保持: 監査人が改善計画を策定したり、直接改善活動を行ったりすることは、独立性を損なうため不適切とされています。
• プロセス: 改善計画の策定状況、実施の進捗、再発防止策の導入状況を確認し、必要に応じて助言や指導を行います。 

主なフォローアップ手順

1. 改善計画書の提出要求: 被監査部門に対し、指摘事項に対する改善計画（実施内容、時期、担当者）の提出を求める。
2. モニタリング・確認: 定期的な報告会、ヒアリング、または再調査（現地確認）を実施する。
3. 評価と報告: 改善が計画通り行われているか評価し、経営陣にフォローアップ結果を報告する。
4. 再勧告・フォローアップ終了: 改善が不十分な場合、再度の指導を行う。改善が完了したと判断されれば、該当テーマのフォローアップを終了する。 

留意点

• 継続性: 指摘事項が確実に解消されるまで、追跡調査を継続する。
• 経営報告: 改善が適切に行われない場合、リスクが放置されていることを経営層へ報告する。 

このフォローアップこそが、監査の報告だけで終わらせず、企業のガバナンスとIT運用の実質的な品質向上を担保する「PDCAサイクル」の要（Check/Act）となります。