一つの事故が何社にも広がる――SaaS・委託先から波及する情報漏えい

1．最初に、どこからどの会社へ影響するのかを描く

「同じサービスを使っている」だけでは、影響が同じとはいえません。利用期間、機能、保存項目、連携設定、保存領域の分離などを、各社の担当が確認します。サービス内で会社ごとに分かれた利用領域は、テナントと呼ばれることがあります。

メール配信、予約、会員管理、採用管理のサービスに加え、印刷・発送、物流、コールセンター等の共通委託先も対象です。自社、契約相手、再委託先、基盤、外部連携先について、関係する業務・情報と、確認できる担当を線で結びます。未判明の接続先は空欄のまま放置せず、確認担当と問いを残します。

同じ脆弱性を利用した侵害が複数社で起きても、一つのデータ流出が波及したとは限りません。共通の原因が確認された部分と、各社で別に調べる部分を分けます。他社の公表や報道を、調査の手掛かりにすることと、自社の漏えいの証拠にすることは別です。

2．サービス名ではなく、データの取扱いと契約を確認する

SaaS・クラウドの利用が、常に個人データの取扱いの委託になるわけではありません。PPCは、サービス提供者が個人データを取り扱うこととなっているかを判断の基準にしています。契約とアクセス制御等の実態を情報管理・法務が確認します。［2］

提供者がデータを取り扱わないため委託先の監督義務が生じない場合でも、利用企業自身の安全管理が不要になるわけではありません。利用設定、認証、外部連携、ログ等について、自社が管理する部分を確認します。［3］

委託に当たる事故では、報告・本人通知の主体、所定の委託元通知による免除の条件、各社の協力事項を確認します。「サービス会社が報告したので各利用企業の対応は不要」とは決めません。公表と本人通知、契約上の事故連絡、行政報告も、目的と要件が異なります。［1］

事務局は契約別に、通知条項、回答期限、調査協力、ログ等の提供、再委託、データ返却・削除、利用停止・解約時の条件を整理します。契約にある期限を確認することと、法令上の期限や本人への案内を待ってよいかを判断することは別です。技術・法務・運用の問いを分けて各担当へ依頼します。

3．ベンダーからの連絡を、受領しただけで終わらせない

受領した資料には、発行元・発行時点・版・対象範囲・変更点を付けます。提供者が「速報」「確報」と名付けても、自社の行政報告が済んだことや、自社の全確認が終了したことにはなりません。

共通情報

提供者が確認した原因・期間・機能・復旧状況。出典の資料と発行時点を記録し、未公表・共有制限も確認する。

自社の照合結果

自社の契約・利用設定・保存情報との対応。照合担当、対象の抽出条件と版、確認できない範囲を残す。

追加で尋ねること

自社に必要だが回答がない項目、照会先、引受け、期限、代替確認の方法を残す。

対象期間が変わった、添付も対象になった、外部連携の影響が分かった等の変更は、対象名簿・通知文・FAQ・過去回答へ影響しないかを確認します。資料の更新日時だけで判断せず、何の結論が変わったかを差分で記録します。

複数ベンダーが互いに調査を依頼している場合は、同じ質問を漫然と転送し続けないようにします。答えを確認できる技術担当、契約窓口、判断責任者を分け、回答不能なら理由と次の照会先を求めます。技術的な関係先調整では、必要に応じてCSIRT等と連携します。JPCERT/CCの調整活動も参照先になりますが、法定報告や本人対応を置き換えるものではありません。［5］

4．全体進捗は、会社別の未完了を見える状態にする

全体をまとめる人がいても、会社別の判断と確認待ちを消さないことが要点です。サービス提供会社の事務局であれば顧客会社別に、利用企業であれば自社の法人・業務・契約別に、必要な管理単位を決めます。

進捗台帳には、会社・契約・事案の識別、対象情報と期間、対象者数の定義、抽出担当・条件・版、報告・通知・公表の判断状態、FAQ版、未回答、期限、次回更新を関連付けます。これは法定の統一様式ではなく、承認済みの管理システムで仕事を追うための運用案です。

対象者数が増減したときは、人数とレコード件数を分けます。同じ人が複数社へ登録していても、各社の人数を足した数を「重複のない被害者数」と表示しません。統合の必要性・権限がなければ、重複確認のために各社の全名簿を集めることも避けます。数字の定義と重複の限界を報告に付けます。

全体会議では個人別の詳細ではなく、判断待ち、期限超過、担当未定、追加通知の要否を中心にします。緊急の問題は定例報告を待たずに責任者へ連絡し、本人への案内の担当も残します。

5．共通の発表文を、各社の通知やFAQへそのまま使わない

説明の共通化は、確認した事実と適用範囲がそろう部分に限ります。自社の利用設定や対象情報が異なるのに、提供者の発表文へ社名だけを入れ替えると、不要な不安や対象漏れにつながります。

他社について確認していない事情を説明する文例ではありません。自社が照合できていない場合は、その点を明示し、比較だけで安全・無関係とは答えません。提供者の修正情報が入った場合は、自社の承認者が文面と対象を見直し、過去に異なる回答をした相手も確認します。

問い合わせが提供会社と利用企業の双方へ届く場合は、一般的なサービス状況、個別の対象照会、補償要望、二次被害の申告などを分けます。個別の契約企業が特定できないときも、必要最小限の確認で受け付け、取引関係や他社の対象情報を不用意に明かさないようにします。

共同窓口では、名乗る社名、相談対象の会社、適用FAQ版、承認者、記録先を会社ごとに照合します。他社の回答画面や返信先を使わないよう権限と画面表示を分け、転送時は引受けと本人への再連絡を確認します。全社分の履歴を未承認AIへまとめて入力する運用にはしません。

6．サービス停止・解約は、証跡と本人対応の継続も含めて決める

安全のための制限と、業務・通知・問い合わせを続ける方法を並行して検討します。停止の要否は情報システム・業務責任者等が判断し、調査担当とログや対象情報の保全を確認します。事故窓口が独断でデータ削除・初期化を指示しません。

予約、配信、給与、発送等を別の手段へ移す場合も、引き継ぐ情報、送信元、アクセス権、誤送信の確認、作業結果の回収方法を定めます。急ぎの代替だからといって、私用メールや未承認の共有先へ名簿を移すことは避けます。代替手段で本人対応の履歴が分断されないよう、事案番号と未回答を引き継ぎます。

解約や契約終了の前は、保存・出力できるログと対象情報、データ返却・削除の条件、問い合わせ先の継続、再調査の協力を確認します。ログ取得の権限がない場合は、提供者へ必要な証跡と保全の依頼を出し、実施の回答を追います。契約上の費用・権限と法的判断は専門担当へ上げます。

復旧・再開の承認、行政報告の状況、本人通知の実施、問い合わせ対応の終了は、それぞれ別に記録します。「サービスが動いたから全件完了」としないことで、未達・未回答や追加通知が担当不明になることを防ぎます。

7．定期報告を、次の判断と再発防止確認に使う

報告では、件数だけでなく前回から変わったこと、止まっている確認、次に必要な判断を示します。共通資料の版と会社別の適用状況、担当の引受け、期限超過、本人への次回連絡を確認し、会社ごとに次の作業へ戻します。

問い合わせから対象外とされた範囲の見直しが必要になった場合や、異なる説明が届いた場合は、共通情報の管理担当へ戻します。確認前の申告は確定事実と分け、技術調査、対象者抽出、FAQ更新のどこへ影響するかを記録します。調査を担うチームが変わっても、根拠と判断の経過を失わないようにします。

IPAのサプライチェーン対策は、ビジネスパートナーや委託先等を含めた状況把握と対策を扱っています。事故後も「再発防止策を受領」で止めず、自社に関係する設定・再委託・連絡条件の改善、実施予定、実施の根拠、確認担当を整理する運用につなげます。［4］

終了時は、会社別に必要な通知・回答がどう扱われたかを確認し、未完了には担当・期限・引受けを残します。暫定窓口を閉じる場合も、本人が次にどこへ連絡できるかを各社が案内します。共通の調整事務局を解散することと、各社の事故対応が終わることは同じではありません。

最後に、対象会社別の資料の返却・削除、閲覧権限、保存する判断記録、残った契約交渉を引き継ぎます。共通の事故から得た改善点を利用企業間で共有するときも、契約・守秘義務と個人情報の範囲を確認し、他社の事情を具体例として流用しないようにします。

8．実務チェックと、よくある質問

一つの事故をまとめて進めるときほど、各社の事実・判断・回答を分けることが重要です。共通の調整と会社別の残件管理を組み合わせ、本人への説明が戻るところまで追います。

あわせて読みたい記事