システム監査の目的と実施

要点と定義

システム監査は、情報システムに関するリスクに組織が適切に対応しているかを、独立かつ客観的な立場から検証・評価する活動です。監査人は、評価結果を保証や助言につなげ、業務の効果的・効率的な遂行や組織目標の達成、利害関係者への説明責任に寄与します。リスクに対するコントロールの整備状況と運用状況を評価し、改善につなげることも目的です。

監査人の役割は、アクセス制御などの管理策を自ら制定・設定・運用することではなく、管理状況を確かめて適切性を評価することです。方針の制定や日々の運用は、組織の管理者や被監査部門が担います。

監査の流れは、リスクに基づく計画、計画に沿った調査と評価、結論の形成と報告、改善状況のフォローアップです。調査では、ヒアリングや文書・記録の確認などの監査手続を行い、十分で信頼できる証拠を集めます。ヒアリングで得た説明は、関連する記録などと照合して裏付けます。

監査人は実施した手続、得られた証拠、結論などを監査調書に記録し、監査意見の根拠として保管します。調書は、参照した基準の一覧や公表用の報告書そのものではありません。

監査報告書の原案を被監査部門と確認する際は、指摘事項や改善勧告に事実誤認がないかを確かめます。被監査部門の承認を得ることが目的ではなく、口頭確認だけで不足する調査を置き換えることもできません。

監査結果は依頼者や適切な関係者に報告します。監査人は問題点を指摘し、改善を勧告しますが、被監査部門に改善を命令する立場ではありません。監査依頼者は報告を踏まえて必要な改善を指示できます。

監査人には独立性と客観性が必要です。監査対象の部門に所属する人が自部門を監査すると、自己の業務を評価することになり、独立した判断を保ちにくくなります。専門家が監査に協力する場合も、監査人は支援の範囲や方法を管理し、監査結果を判断する責任を負います。

適用条件と例

例えば、経理システムの利用者権限を監査するとします。監査人は権限の管理記録、承認記録、設定内容などを確認し、職務に必要な範囲に権限が限られているか、変更が承認どおり行われたかを評価します。監査人自身が権限設定を変更したり、アクセス制御方針を書いたりすると、評価対象を自ら作ることになり、独立した評価が難しくなります。

ヒアリングで「退職者の権限はすぐ削除する」と説明された場合、説明だけで結論を出さず、退職者一覧とアカウント削除記録、処理日などを照合します。たとえば対象期間の記録で、退職日後もアカウントが有効だった例が見つかれば、説明と実際の運用の差を証拠に基づいて検討します。記録が不足しているなら、経験や推測で穴を埋めず、追加調査が必要です。

調査した事実は監査調書に残します。例として「対象期間」「確認した記録」「抽出した件数」「照合結果」「判断の理由」を記録すれば、後から結論の根拠を追いやすくなります。調書は監査人が作成・保管し、報告書に書く結論を支えます。