SYSTEM AUDIT / PRACTICAL GUIDE

システム監査のフォローアップとは？｜改善提案を実行・検証・定着させる実務

監査報告後の改善計画、是正措置、監査証拠、残存リスク、クローズ判定を、自社SaaS企業の具体例と操作ラボで解説。監査対象部門と監査人の責任分担も理解できる。

監査後の改善証拠による確認スタートアップの実例インタラクティブラボ

01｜監査報告書が届いたら、何が起こる？

社員15人のBtoB SaaS会社を想像してください。法人顧客が増え、契約前のセキュリティ審査も厳しくなりました。外部専門家によるシステム監査では「退職者のアカウント削除が遅い」という問題が見つかります。

監査報告書を受け取って終わりなら、次の退職者にも同じ問題が起こります。そこで必要なのが、改善の担当者を決め、期限までに対策を実行し、それが実際に機能しているか追いかけることです。この監査側の追跡がフォローアップです。

フォローアップは「監査人が改善作業を代行すること」ではありません。改善の責任は、経営者や対象部門の管理者など、改善を実施する側にあります。

02｜監査のライフサイクルのどこにある？

STEP 1

予備調査

業務・リスクを理解

STEP 2

本調査

証拠で検証

STEP 3

監査報告

問題と改善提案

STEP 4

改善実行

対象部門が対応

STEP 5

フォローアップ

実施状況を確認

実務上は改善中にも報告・確認が繰り返され、再評価のために追加の検証が必要になる場合があります。

監査の計画・調査・報告で得た「発見事項」を、実際の改善につなげる段階です。報告書自体の品質管理や未了の本調査とは、目的が異なります。

03｜フォローアップの定義と目的

システム監査人が、監査報告書で示した改善提案について、改善計画とその実施状況に関する情報を収集し、改善状況をモニタリングする活動を指します。進んでいない項目を把握し、必要に応じて経営者等に報告して対応を促すことができます。

実施状況

担当者・期限・対応内容がどうなったか

実効性

対策が機能して同じリスクを減らしたか

残存リスク

未対応・部分対応の危険を誰が受容するか

04｜誰が何をする？責任の分離

立場	主な仕事	やってはいけない混同
経営者・責任者	リスク対応方針と優先順位を決定	報告を読むだけで責任を終える
対象部門	原因分析・改善計画・対策実施・証拠保存	対策を監査人に丸投げする
監査人	証拠確認・進捗評価・未了項目の報告	自ら設定変更して自分で監査する
管理者・顧客窓口	関係部署の調整と必要な説明	監査済みを無条件に安全と保証する

少人数企業では同じ人が複数の役割を担う場合があります。そのときも、承認者や確認者を可能な範囲で分け、独立性の限界を明示することが大切です。自己点検と独立した監査は同じではありません。

05｜実例：退職者アカウントが残っていた

1. 発見

退職から14日後も権限が有効

2. 原因

人事連絡がチャットのみ

3. 改善

退職チケットと停止確認を必須化

4. 確認

停止ログと対象者一覧を突合

「アカウントを1件削除した」だけでは応急処置です。「退職が確定したら自動的に作業依頼が届く」「作業完了を別の担当が確認する」「停止までの所要時間を継続的に監視する」といった仕組みが、再発防止になります。

06｜是正・是正処置・予防を区別する

是正（修正）

見つかった退職者アカウントを即時停止する

是正処置

通知漏れの原因を調べ、退職処理の手順を改善する

予防的な工夫

権限棚卸しの自動通知で将来の見落としを検知する

改善計画は「何を直すか」だけでなく、根本原因、対象範囲、担当者、期限、完了条件、確認証拠を明確にします。

07｜改善計画に必要な7項目

01指摘事項の識別番号と内容
02影響・リスクの重大度
03原因と再発防止策
04実施責任者・承認者
05目標期限とマイルストーン
06完了条件と必要な証拠
07進捗報告・再確認の方法

例えば「10月末までに改善」とだけ書くより「退職者一覧の全員が、定めた期限内に無効化されていることを確認し、停止ログと承認記録を保存する」とした方が、完了判定ができます。

08｜『完了しました』だけでは確認できない

実施側の口頭報告やチケットの「完了」表示は進捗情報にはなりますが、統制が実際に機能していることを十分に説明できるとは限りません。監査人は必要に応じて、権限設定、承認記録、実行ログ、実際のサンプルなどを確認します。

証拠の強さは目的によって変わる

主張

『全件停止済み』

資料

退職者一覧と停止日時

検証

サンプルの権限状態を再確認

09｜ウォークスルーと再テストはどう使い分ける？

前回の記事で扱ったウォークスルーは、業務の流れや組み込まれた統制を1件の取引などで追う方法です。一方、フォローアップで運用の定着を確認するには、複数の退職事例のサンプル抽出や権限一覧との突合、実際の再テストなどを組み合わせることがあります。

1件の正常な処理を追跡できたことと、全期間にわたって統制が有効だったことは同義ではありません。検証方法はリスクや目的に応じて決めます。

10｜優先順位：全部を同時に直せないとき

深刻度は「起こる可能性 × 起きた場合の影響」のような考え方で整理できます。ただし数値は説明のための簡略化で、実際の順位付けには顧客への影響、法令・契約、検知可能性、代替策も考慮します。

RISK 01

退職者のアカウント

退職後も管理画面にログインできる

RISK 02

バックアップの復元

バックアップはあるが復旧できるか不明

RISK 03

本番環境の権限

開発者全員が恒常的に本番DBを書き換えられる

11｜ステータスは『着手』『実装』『確認済み』を分ける

「対策を実装した」と「監査人が十分な情報に基づき確認した」を別の状態として管理します。改善策の完了とフォローアップのクローズは、社内で定めた基準に従って区別できます。

未着手

対応中

実装済み・確認待ち

確認済み

12｜期限に間に合わないときの対応

未対応のリスクが残る場合、監査人は現状や遅延理由を把握し、必要な相手に報告します。改善責任者は暫定措置を検討し、新しい期限と理由を残します。監査人が独断で残存リスクを受容したり、対象部門に代わって改善を実施したりはしません。

遅延時の報告例

「退職者アカウント自動停止の実装は予定より2週間遅延。暫定措置として毎日手動照合を実施。責任者は開発部長、再設定した期限は11月15日。リスク受容の判断は経営責任者に求める」

13｜クローズとは、何が確認できた状態？

対策が行われたという報告、記録の提出、対策が有効に働くことの確認、残るリスクの扱いを、事前に定めた基準で評価します。十分な確認ができなければ未了として追跡し、重大な事情があれば適切な責任者へ報告します。

閉じた後も環境変更や新しいリスクが生じれば、別の監査や定期レビューで再評価が必要になる場合があります。

14｜小さなSaaS企業ならどう始める？

第1週監査指摘をチケット化し、担当・期限・暫定措置を登録
第2週重要リスクから対応。変更のレビューと証拠保管を徹底
第3週対象者一覧・設定値・ログで実施状況を確認
第4週未了項目と残存リスクを経営者へ報告し次の確認日を設定

専任監査部門を置けなくても、事業責任者が改善を指示し、別の担当者や外部専門家が点検する体制は作れます。ただし独立性が十分でない場合、その活動を独立した監査と称さないことが重要です。

15｜よくある指摘と具体的な確認方法

01｜退職者のアカウント

対応：退職通知とアカウント停止の連携を標準化

証拠：退職者一覧・停止ログ・承認記録

確認：抽出した退職者について停止までの時間を照合

02｜バックアップの復元

対応：復元試験を定期実施し結果を記録

証拠：試験手順・実行ログ・復元結果

確認：試験記録を確認し必要に応じ再実施を観察

03｜本番環境の権限

対応：役割を限定し特権操作を記録

証拠：権限一覧・変更承認・操作ログ

確認：現時点の設定と承認記録を突合

16｜関連する概念を一度に整理

用語	役割
監査報告	発見事項・結論・改善提案を伝える
改善計画	実施側が原因・対策・担当・期限を決める
フォローアップ	監査側が改善状況を情報収集・モニタリングする
是正処置	原因に対処して再発を防ぐ
残存リスク	対策後も残る危険性
監査証拠	判断の根拠となる資料・ログ・観察結果
内部統制	リスクを管理するための仕組み
継続的改善	目標に照らして運用全体を改善し続ける

17｜操作ラボ：監査指摘の改善を追跡する

架空のSaaS企業の指摘事項を使い、改善状況と監査証拠を更新してください。対策を実装しても証拠が不足すれば「確認済み」にならないことを試せます。クイズでは実施責任とモニタリング責任の区別も確認できます。

監査フォローアップ・シミュレーター

実装・証拠・確認は別々の状態です（架空の練習データ）。

2 / 3

実装済み

1 / 3

証拠未提出（実装済み）

0 / 3