データ侵害の手順

1）目的と範囲

目的：損害を最小限に抑えるため、法的要件を遵守し、個人/支払/運用データの確認または漏洩の可能性のある通常の操作を迅速に復元します。
適用範囲：PIIプレーヤーと従業員、支払いアーティファクト、アクセスログ/トークン、KYC/AMLドキュメント、アフィリエイト/パートナーデータ、機密製品およびインフラストラクチャのアーティファクト。

2）「リーク」の定義と基準

データ侵害-セキュリティインシデントまたはプロセスエラーによる個人データ（またはその他の保護された情報）の機密性、完全性または可用性の違反。
確認されたvs疑わしい：任意の指標（SIEM異常、ベンダー/ユーザーからのメッセージ、貼り付けサイト）は、反論する前に手順を開始します。

3）重大度の分類（例）

4） SLAと「インシデントブリッジ」

開始：Medium+では、ウォールルーム（チャット/コール）が作成され、インシデントコマンダー（IC）が割り当てられます。

SLA： 低-24 h·中-4 h·高-1 h·クリティカル-15分

更新のCadence： 30-60分ごと（内部）、2-4時間ごと（外部利害関係者）。

5） RACI（拡大）

6）応答のプロシージャ（ステップバイステップ）

1.識別とプライマリ検証

SIEM/EDR/不正防止/ベンダー/ユーザーからのシグナル→インシデントレジスタ内のエントリ。
最小限の事実の収集：what/when/where/how much、データタイプと管轄区域が影響を受けました。

2.Containment（封じ込め）

脆弱なエンドポイント/機能、ジオセグメント、時間制限、フリーズするリリースを無効にします。
キー/トークンの回転、アクセスの取り消し、侵害されたアカウントのブロック。

3.消去（Eradication）

パッチ/構成の修正、悪意のあるアーティファクトのクリーニング、イメージの再構築、サブプロセッサのチェック。

4.復旧（復旧）

カナリアのトラフィックエントリ、回帰モニタリング、整合性チェックの通過。

5.フォレンジックとインパクトアセスメント

体積、感度、地理、被験者のリスクの計算。影響を受けるレコードの確認。

6.通知とコミュニケーション

DPO/Legalは通知の義務とタイミングを定義します。テキストの準備；住所への配布。

7.死後とCAPA

根本原因分析（5 Whys）、オーナーとタイムラインとの是正/予防アクションプラン。

7）72時間の窓口と法定住所（ランドマーク）

データ監視（DPA）-被験者の権利/自由へのリスクが除外されていない場合、重大な漏洩を検出した後72時間以内に通知します。
ユーザー-「過度の遅延なし」高リスクで（明確な推奨事項を含む）。
ギャンブルレギュレータ-プレイヤー/サステナビリティ/レポートに影響を与える場合。
銀行/PSP-支払い/トークンの妥協/疑わしい取引のリスクがあります。
パートナー/ベンダー-共通のフロー/データに影響がある場合、またはアクションが必要です。

8）鑑識と「証拠の保護の連鎖」

ボリューム/ログのスナップショット、ハッシュ付きアーティファクトのエクスポート（SHA-256）。
コピー/スナップショットのみでの作業;ソースシステム-読み取り専用。
アクションのプロトコル：who/when/what、 commands/tools。
WORM/オブジェクトストレージ内のストレージ。制限されたアクセス、監査。

9）コミュニケーション（内部/外部）

原則：事実→対策→推奨事項→次の更新。
それは不可能です：PIIを公開し、テストされていない仮説を構築し、制御せずに期限を約束する。

• 何が見つかりましたか？·スケール/カテゴリ·現在の対策·リスク·次のステップ·HHの次の更新：MM。

10）ベンダー/サブプロセッサとの相互作用

インシデントレジスタ、アクセスログ、通知SLA、サブプロセッサのリストを確認します。
レポートをリクエスト（ペンテスト/レート）、データ削除/返却の記録確認。
DPAミスマッチの場合-エスカレーションと一時的な分離/統合の停止。

11）通知テンプレート（フラグメント）

11.1監督機関（DPA）

検出のイベントと時間の簡単な説明、データのカテゴリ/おおよその量、被験者のグループ、地理、結果とリスク、対策/計画、DPO連絡先、アプリケーション（タイムライン、ハッシュ要約）。

11.2ユーザー

何が起こったのか；影響を受けた可能性のあるデータ；私たちがしたこと;あなたができること（パスワードの変更、トランザクションの制御、フィッシングのヒント）。どのように連絡するか；FAQ/サポートセンターへのリンク。

11.3 パートナー/PSP/レギュレータ

事実と影響を受けるインターフェイス；期待されるパートナーの行動の締め切り；コンタクトパーソン。

12）インシデントレジスタ（最小フィールド）

ID・発見/確認時間・重大度・出所・システム/データ・範囲/カテゴリ・地域・ベンダー・関与するアクション（時間内）・発生した通知（to/when）・責任者（RACI）・アーティファクトへの参照・CAPA/締め切り・ステータス。

13）指標とターゲット

MTTD/MTTC/MTTR（検出/封じ込め/回復）。
72時間で通知の％-100％。
根本原因が特定されたインシデントの割合≥ 90％です。
CAPAは95％ ≥閉じられています。
1つの理由で繰り返されるインシデント≤ 5％です。
SLA （Medium/High/Critical）で閉じられたインシデントの割合：90/95/99％。

14）チェックリスト

14.1スタート（最初の60分）

• 割り当てられたICおよび戦争部屋開いた
• 安定化対策（切断/限界/キー回転）
• 最小限の事実とスクリーンショット/ログを収集する
• DPO/Legal notified、 preliminary class defined
• リリースとログクリーニングプロトコルのフリーズ

14.2 24時間まで

• フォレンジック：スコープ/カテゴリ/地理（ドラフト）
• 通知の決定、テキストの作成
• リカバリ/インテグリティプラン
• WORM証拠パッケージ、イベントタイムライン

14.3最大72時間

• DPA/レギュレータ/PSP通知（必要に応じて）
• ユーザーへのComm（高リスク）
• CAPAプラン、オーナー、タイムラインの更新

15）典型的なシナリオと対策

A）オープンストレージセグメントへのサポートチャットデータベースのエクスポート

対策：クローズアクセス、在庫のダウンロード、影響を受ける通知、S3/ACLポリシーの強化、DLP輸出ルール。

B） APIアクセストークンの妥協

対策：即時回転、リフレッシュトークンのリコール、通話ログの検証、webhook再署名、トラフィックセグメンテーション。

C）ベンダーを介したKYCスキャンの漏洩

対策：統合の分離、削除の確認、リスクの高いクライアントの手動での再検証、DPA/控除の改訂。

D）パブリックダンプ出版

対策：アーティファクト（ハッシュ）の修正、リンクの法的削除（テイクダウン）、通知、さらなる出版物の監視。

16）コンプライアンスとプライバシーの統合

GDPRプロセスとバンドル：DSAR、 RoPA、 DPIA/DTIA；サプライヤー/目標が変更された場合のポリシーおよびクッキー/CIWの更新。
インシデントをリスクマトリックスに含め、しきい値/コントロールを修正します。

17） CAPAおよび死後（安定化の後の≤ 72時間）

レポート構造：facts/timeline・impact・root cause・what worked/not・CAPA list（所有者、用語、成功基準）・有効性チェックの日付（30-60日）。

18）プロセス成熟度ロードマップ

月1：プレイブック、連絡先、テンプレート、WORMアーカイブ、通知テストを更新します。
月2：卓上演習（PIIリーク/ベンダー/トークン）、SOARプレイブック。
月3+：四半期ごとのレトロスペクティブ、ベンダー監査、不正防止/検出モデルのバイアステスト、しきい値の定期的な改訂。

TL；DRについて

漏洩の場合：迅速に（封じ込め）を安定させ、正確に（フォレンジック）を確認し、時間通りに通知し（DPA/ユーザー/パートナー）、透明に文書化（レジストリ、タイムライン、証拠）し、根本原因（CAPA）を修正します。その結果、プレイヤーやパートナーの損傷、コンプライアンス、信頼回復が少なくなります。