SaaS委託先の事故通知条項｜初報期限・影響範囲・更新連絡を揃える方法
SaaSや外部委託先でセキュリティ事故が起きたとき、利用企業が最も困るのは、原因が分からないことより「いつ、何を、次にいつ知らせてもらえるか」が決まっていないことです。委託先が調査完了まで連絡を控えると、自社のアクセス停止、顧客連絡、本人通知、監督機関への報告、経営判断に使える時間が失われます。
結論として、SaaS委託先の事故通知条項では、通知対象、起算時刻、初報期限、最低通知項目、未確定情報の扱い、更新間隔、連絡経路、証拠保全、終報を一つの時系列として定めます。初報は原因確定を待たず、確認済み・推定・未確認を分けて届けてもらい、次回更新時刻を必ず示す設計にします。法令上の期限をそのまま委託先の初報期限にせず、自社が判断と連絡を行う時間を差し引いて契約上の期限を決めます。
本記事のポイント
- 事故通知の時計は、委託先が事故の可能性を認識した時点から動かし、原因や対象件数の確定を初報条件にしない。
- 初報では、発覚時刻、対象サービス、影響の可能性、暫定措置、連絡責任者、次回更新時刻を最低限そろえ、未確定項目は未確定と明示する。
- 委託先の通知IDを自社のインシデントIDへ結び、アクセス制御、顧客連絡、法令判断、復旧、終報までを同じ時系列で追跡する。
事故通知条項に含める10項目
条項は「速やかに通知する」の一文だけでは運用できません。速やかさの基準、誰が受け取るか、何が未確定でも送るか、調査中にどの間隔で更新するかまで決めます。NIST SP 800-61 Rev.3は、外部サービス事業者との責任分担を契約で明確にし、情報の流れ、調整、行動権限をインシデント対応チームが把握する考え方を示しています。通知条項も、法務文書であると同時に対応手順として読める粒度が必要です。
| 条項項目 | 決める内容 | 曖昧なままだと起きること |
|---|---|---|
| 通知対象 | 漏えい、侵害、不正アクセス、マルウェア、サービス停止、認証情報流出、そのおそれ | 漏えい確定まで通知されない |
| 起算時刻 | 委託先が事故または合理的な疑いを認識した時刻 | 社内承認や原因確定で時計が後ろ倒しになる |
| 初報期限 | 重大度別の時間、休日・夜間の扱い、期限の計測方法 | 担当者の感覚で通知時刻が変わる |
| 最低通知項目 | 発覚時刻、対象サービス、影響候補、暫定措置、連絡責任者、次回更新 | 「調査中」の一文しか届かない |
| 未確定情報 | 確認済み・推定・未確認を分け、後続更新で訂正できること | 完全な情報を待って初報が遅れる |
| 連絡経路 | 24時間窓口、代替連絡先、暗号化手段、受領確認、エスカレーション | 退職者のメールや停止中の管理画面へ送られる |
| 更新間隔 | 重大度別の定期更新、重要変化時の随時通知、次回予定時刻 | 初報後に情報が途切れる |
| 協力・証拠 | ログ保全、タイムライン、影響特定、監査・当局・顧客説明への協力 | 自社が判断に必要な根拠を得られない |
| 外部発表 | 法令上必要な通知、顧客・報道発表、法執行機関との調整、機密情報の扱い | 委託先と自社の説明が食い違う |
| 復旧・終報 | 封じ込め、復旧、監視、根本原因、対象範囲、再発防止、残存リスク、提出期限 | サービス復旧だけで案件が閉じられる |
「事故」は個人データ漏えいだけに限定しない方が実務的です。管理者権限の窃取、APIキー流出、他社テナントとの分離不備、バックアップ破損、ランサムウェア、長時間停止は、漏えい件数が未確定でも自社の業務と顧客に影響します。対象サービス、データ、権限、地域、下位委託先を契約別に棚卸しする方法は、SaaSのサブプロセッサ変更通知管理と合わせると整理しやすくなります。
初報期限は自社の判断時間から逆算する
初報期限に万人共通の正解はありません。扱うデータ、サービス停止の影響、利用地域、顧客との契約、報告義務、自社の夜間体制で変わります。重要なのは、法令上の最終期限を委託先の期限にコピーしないことです。自社には、事実確認、影響顧客の特定、経営・法務・セキュリティの判断、監督機関や本人への連絡を行う時間が必要だからです。
個人情報保護委員会は、報告対象となる漏えい等を発覚した場合にまず速やかに報告するよう案内しています。GDPR第33条は、管理者に対して原則72時間以内の監督機関通知を定める一方、処理者には個人データ侵害を認識した後、不当な遅延なく管理者へ通知するよう求めています。複数法域にまたがる場合もあるため、委託先からの初報は、自社側の法令判断より前に届くよう設計します。
| 運用上の重大度例 | 初報目標の決め方 | 更新間隔の例 | 注意点 |
|---|---|---|---|
| 重大 | 進行中の侵害、管理者権限、重要データ、広範停止は時間単位で設定 | 封じ込めまで短い間隔、重要変化は随時 | 例示時間を固定値にせず自社の当番体制と合わせる |
| 高 | 影響の可能性があり顧客・法令判断が必要なら当日中を基本に設計 | 次回予定を初報に明記し、少なくとも日次で見直す | 件数未確定を通知延期の理由にしない |
| 中・低 | 封じ込め済みで影響が限定的でも、契約上の対象なら期限を明示 | 調査節目または合意した営業日 | 後から重大度が上がった場合の再分類を定める |
「1時間以内」「24時間以内」といった値を採用する場合は、それが法令の共通要件ではなく、委託先と自社が合意する運用目標であることを明確にします。起算時刻は、顧客への影響を確定した時ではなく、委託先の監視、担当者、下位委託先が事故の可能性を認識した時点とします。下位委託先からSaaS事業者、SaaS事業者から自社へ連絡が直列になる場合は、各段階で時間を使い切らないよう契約を連鎖させます。
受信先も期限と同じくらい重要です。通常窓口、24時間窓口、電話、暗号化された共有経路、代替担当を登録し、半年ごとや担当変更時に疎通を確認します。ステータスページ購読者の登録・削除は、SaaSステータスページの購読者情報管理で整えられます。ただし一般公開の稼働情報だけを契約上の事故初報の代わりにしません。
影響範囲が未確定でも送れる初報テンプレート
事故直後にすべてを確定できる委託先はほとんどありません。そこで、正確さを下げずに速く伝えるため、各項目へ「確認済み」「推定」「未確認」の状態を付けます。未確認を空欄にせず、確認方法、担当、次回更新時刻を添えます。後続調査で訂正したときは、前の内容を消さず、変更理由と時刻を残します。
- 事故IDと通知版：委託先側の一意なID、初報・第2報・終報の版、送信時刻を示します。
- 認識時刻と発生期間：検知時刻、委託先が事故と認識した時刻、現時点で推定する開始・終了時刻を分けます。
- 対象範囲：サービス、環境、テナント、地域、機能、下位委託先、データ種類、権限を示します。件数は概数でも根拠を添えます。
- 現時点の影響：機密性、完全性、可用性のどこに影響する可能性があるか、顧客操作が必要かを示します。
- 暫定措置：アカウント停止、鍵の失効、通信遮断、機能停止、復元、監視強化など、実施済みと予定を分けます。
- 依頼事項：自社側で直ちに必要なパスワード変更、APIキー失効、接続停止、ログ保全があれば優先順位と期限を示します。
- 連絡責任者と次回更新：技術・法務・顧客連絡の窓口、24時間連絡方法、次回更新の日時を示します。
事故通知条項が機能したと言えるのは、原因が確定した時ではなく、未確定を含む初報が期限内に届き、次の更新時刻まで合意できた時です。
詳細なログや脆弱性情報を通常メールへ添付すると、二次漏えいにつながります。初報本文は判断に必要な範囲へ絞り、証拠は閲覧者、期限、再共有、失効を制御できる経路で渡します。監査報告書や診断結果の共有方法は、セキュリティ資料のアクセス制御も参考になります。
検知から終報までを8段階でつなぐ
- 契約前に対象サービスと責任を特定する。
自社データ、認証、権限、連携、下位委託先、地域を整理し、どの事象を何時間で通知するかをリスク別に定めます。セキュリティ回答の根拠と有効期限は取引先セキュリティチェックシートの回答管理で追跡します。 - 連絡先と疎通を試験する。
通常窓口と緊急窓口、代替担当、暗号化経路、受領確認を登録し、机上演習で夜間・休日の到達とエスカレーションを確認します。 - 初報を受領して自社事故IDへ結ぶ。
委託先の事故ID、認識時刻、通知版を自社のインシデント台帳へ登録し、対象サービス・契約・顧客・データと結びます。メールを受け取っただけで案件を作らない状態を避けます。 - 直ちに保護措置を決める。
進行中の侵害なら、セッション、APIキー、接続、管理者権限、連携処理を止めるか判断します。鍵の失効と段階切替はAPIキーの棚卸し・ローテーション手順を使って影響先まで確認します。 - 影響顧客と法令判断を並行する。
委託先の調査完了を待たず、現時点の対象候補から顧客契約、本人通知、監督機関報告、サイバー事故報告、保険・法執行機関への連絡要否を検討します。判断時点と根拠を残します。 - 定期更新を差分で受け取る。
第2報以降は、前回から変わった事実、訂正、封じ込め、対象範囲、残る不明点、次回更新を明示してもらいます。同じ「調査中」を繰り返す場合は、何を調べ、いつ分かるかを確認します。 - 復旧条件と監視期間を合意する。
サービスが動いたことだけで再開せず、侵入口の封鎖、資格情報の失効、データ整合、影響範囲、追加監視、顧客側の作業が確認できるまで段階的に戻します。 - 終報と再発防止を契約管理へ戻す。
根本原因、確定した影響、全タイムライン、封じ込め・復旧、顧客・当局対応、残存リスク、再発防止、期限と責任者を受け取り、次回の審査・更新・解約判断へ反映します。
調査中に委託先が公表する場合は、自社への先行連絡、法執行機関による開示制限、他顧客の機密保持も調整します。ただし、委託先の広報承認が自社の法令上必要な報告や緊急保護措置を不当に止めないよう、例外と意思決定者を条項へ入れます。
契約が機能するか机上演習で確かめる
署名済み契約に必要項目があっても、窓口が不通、共有リンクが開けない、重大度の定義が双方で違う、顧客一覧を出せないなら機能しません。年1回だけでなく、重要サービスの導入、担当変更、下位委託先変更、大きな機能追加の後にも短い机上演習を行います。
| 試験 | 確認すること | 合格条件 |
|---|---|---|
| 緊急連絡 | 夜間窓口、代替連絡、受領確認、暗号化共有 | 定めた時間内に責任者まで届く |
| 未確定初報 | 件数・原因が不明な想定で最低項目を送れるか | 未確認と次回更新が明示される |
| 影響展開 | サービスから顧客、契約、データ、連携先を抽出できるか | 対象候補と除外根拠を説明できる |
| 保護措置 | 接続停止、鍵失効、管理者停止、ログ保全 | 責任者、手順、判断時刻が残る |
| 更新連絡 | 訂正、差分、次回予定を版管理できるか | 初報から終報まで時系列が切れない |
| 終報 | 根本原因、確定影響、再発防止、残存リスク | 期限と責任者を契約レビューへ戻せる |
演習結果は「通知できた・できなかった」だけで終えず、初報までの分数、受領確認までの分数、影響顧客抽出の時間、未確定項目、更新遅延を測ります。重大な不備がある場合は、条項修正、連絡先更新、技術的な代替策、利用範囲の縮小まで判断します。
よくある質問
SaaS委託先の事故通知条項には何を含めますか？
通知対象、起算時刻、重大度別の初報期限、最低通知項目、未確定情報の表示、連絡経路、更新間隔、証拠保全と調査協力、外部発表の調整、復旧・終報・再発防止を含めます。下位委託先にも同等の通知義務を連鎖させます。
初報の期限と最低限の通知項目をどう決めますか？
自社が顧客・本人・監督機関へ連絡し、保護措置を取るための時間から逆算します。最低項目は、事故ID、認識時刻、対象サービス、影響の可能性、暫定措置、依頼事項、連絡責任者、次回更新時刻です。重大度別の時間は契約と当番体制に合わせます。
影響範囲が未確定でも通知を受けるにはどう設計しますか？
原因や対象件数の確定を初報条件にせず、確認済み・推定・未確認を分ける様式を契約へ組み込みます。未確認項目には調査方法、担当、次回更新時刻を付け、後で訂正できる版管理を定めます。
委託先の更新連絡を自社の顧客通知と復旧判断へどうつなげますか？
委託先の事故IDを自社のインシデントIDへ結び、対象サービス、顧客、契約、データ、連携、保護措置、法令判断を同じ台帳で管理します。更新ごとの差分を顧客連絡版と復旧チェックへ反映し、どの情報で判断したかを残します。
ステータスページの障害通知で契約上の初報を代替できますか？
一般的な稼働状況の共有には有効ですが、顧客固有のデータ・権限・地域・下位委託先・必要な保護措置が含まれない場合があります。契約で必要な事故初報は指定窓口へ送り、ステータスページは補助経路として位置付けます。
法令上の報告期限をそのまま委託先の通知期限にしてよいですか？
そのまま使うと、自社が事実確認や顧客特定を行う時間が残りません。適用法令と顧客契約を確認したうえで、委託先の認識から自社初報まで、自社の判断から外部報告までの時間を分け、委託先にはより早い運用期限を設定します。
公式・公的資料で確認する
- 個人情報保護委員会：漏えい等の対応と報告では、報告が必要となる事態、本人通知、報告期限と様式を確認できます。
- NIST SP 800-61 Rev.3では、インシデント対応をサイバーセキュリティリスク管理へ組み込み、外部サービス事業者との責任、情報流、調整、契約を明確にする考え方を確認できます。
- EUR-Lex：GDPR Article 33では、管理者の監督機関通知と、処理者が侵害を認識した後に不当な遅延なく管理者へ通知する義務を確認できます。
- IPA：中小企業の情報セキュリティ対策ガイドラインでは、委託先やクラウドサービスを含むリスク対策、事故発生時の対応体制、事業継続に関する実務資料を確認できます。
この記事は法的助言ではありません。実際の通知義務、期限、本人・顧客・監督機関への連絡は、適用法令、契約、データ、当事者の役割、事故の内容に応じて法務・プライバシー・セキュリティ担当者と確認してください。
