SaaS 委託先監査の実務 — 業務システムから AOC / SOC2 を引き当てる運用設計

1. 委託先マスタの 1 元化

業務システム上に委託先マスタを持ち、サービス名・契約者・連絡先・利用範囲・取扱い情報・契約期間・契約書 URL を一覧で管理します。

これだけでも、監査時に 「契約書はどこにありますか」 と聞かれて Slack や個別 Google Drive を探すムダがなくなります。

2. 取扱い情報の分類

委託先ごとに、取り扱う情報の種類 (個人情報・カード情報・財務情報・社外秘・非機密) を業務システム上で分類して持ちます。

これにより、 PCI DSS なら 「カード情報を扱う委託先のみ」 、個人情報保護法対応なら 「個人情報を扱う委託先のみ」 を瞬時に絞り込めます。

3. AOC / SOC2 報告書の保管

PCI DSS の AOC、SOC2 の Type II 報告書、ISMS 認証書、Pマーク認証書を業務システム上に保管 URL を持っておきます。

監査時に 「今年の AOC は」 と聞かれて、即座に URL を提示できる状態にしておくと、説明が一段階速くなります。報告書の有効期限が切れる前にアラートを出す仕組みも入れます。

4. 年次評価フローの組み込み

委託先評価は年 1 回が最低限ですが、評価フローを業務システム上で回さないと、評価が形骸化しがちです。

業務システム上に評価チェックリスト (情報の取扱い範囲・サブ委託の有無・データセンター所在地・暗号化・アクセス制御・教育記録) を持ち、評価実施記録を年次で残します。前年と差分があった項目は赤くハイライトして表示します。

5. 委託先変更時のフロー

委託先が変わる時 (移行・追加・廃止) は、業務システム上の申請・承認フローを通します。

新規 SaaS の利用申請を業務システム上で出し、情報セキュリティ担当者・法務担当者が承認するフローにすることで、シャドー IT の混入が大幅に減ります。退会時にも、業務システム上で 「退会申請・データ削除確認・契約終了」 を順番に確認するフローを持ちます。

6. 委託先側の事故対応

委託先側で情報漏洩・サービス停止・データ消失が起きた時、業務システム上で 「影響範囲・対応状況・社内通知・本人通知・法令対応」 を記録します。

これがないと、事故対応が個別 Slack スレッドに残るだけで、後日の総括・委員会等への報告で抜けが出ます。