GH GambleHub

GDPR内の役割

1)基本的な定義と原則

コントローラー:個人データ(PD)処理の目的と方法を決定します。合法性、透明性、被験者の権利、セキュリティTOM、プロセッサの選択と制御のための主な責任を負います。
プロセッサ:PDの処理はコントローラによって文書化されたものに限られ、TOMを提供し、エンティティの権利とインシデントを支援し、記録を維持し、監査を可能にします。
共同コントローラー:2+人が共同で目標と方法を定義します。被験者の責任と接点の透明な分布が必要です。
サブプロセッサ:プロセッサが従事するベンダーは、コントローラと同等の義務を事前に書面で承認した場合にのみ許可されます。

黄金のルール:誰がなぜ、どのように処理するかを決定するコントローラです。誰が唯一の「指示に従って実行する」-プロセッサ。


2)実際に役割を定義する方法(意思決定ツリー)

1.誰が処理のためのビジネス目標を設定しますか?

→あなたですか?むしろコントローラー。

2.データを目的(分析、マーケティング)に再利用できますか?

→はい→コントローラー(または目的が共通なら共同コントローラー)。

3.相手はあなたに正確な手段/制限を示し、あなたの目的は導き出されますか?

→はい→プロセッサ。

4.両者が目標を設定した共通の製品/共同プラットフォームはありますか?

→はい→共同コントローラー(必要な芸術。26アレンジ)。

5.課題にクラウド/ベンダーが関与していますか?

→ベンダー-サブプロセッサ;あなたはコントローラーです。あなたのプライマリプロセッサはそれのためのあなたの許可を得なければなりません。


3) iGamingエコシステムの役割-例のマトリックス

インタラクション典型的な役割コメントする
iGamingオペレータ↔プレイヤーコントローラー↔データ件名オペレータは、目的(アカウント、レート、RG、 AML)を定義します)
オペレーター↔ CCM/制裁プロバイダースーパーバイザ↔プロセッサ私たちはDPA+の指示を書きます、データの再利用の禁止
PSP ↔オペレーター/銀行より頻繁に個々の監督者PSPには独自の規制目的とストレージがあります
オペレーター↔ Antifraudプラットフォーム通常はプロセッササービスが独自の目的のために集約されたインサイトを「共有」する場合、共同コントローラまたは個別のコントローラが可能
オペレーター↔ ホスティング/クラウド/CDNプロセッサ/サブプロセッサ強力なセキュリティとアクセスログ。テリトリアリティ
オペレーター↔アナリティクス/マーケティング-SDKミックス:プロセッサまたはシングルコントローラプロバイダが独自の目的でPDを使用できるかどうかによって異なります
オペレーター↔アフィリエイト多くの場合、個々のスーパーバイザーリード/クリックはアフィリエイトの目標によって処理されます。PD転送-DPA/契約+最小化
プロセッサ↔サブプロセッサプロセッサ↔サブプロセッサコントローラの平等な義務と許可が必要です
パートナーとの共同プロモーションジョイントコントローラアートが必要です。26責任との合意

4)役割責任(高レベルRACI)

アクティビティコントローラープロセッサ共同スーパーバイザー
法的根拠、通知A/RC (C)A/R(結合される)
DSAR処理(アクセス、削除など)A/RR(ヘルプ)A/R(ディストリビューション別)
DPIA/DTIAA/RC/R(ヘルプ)A/R(結合される)
インシデント/リーク(DPA/ユーザー通知)A/RR(コントローラ、アシスタントを通知)A/R(結合される)
プロセッサ/サブプロセッサの選択と監査A/RR(メンテナンスレジスタ、通知)A/R(各ゾーン)
クロスボーダー伝送(SCCs/IDTA)A/RR(実行)A/R(結合される)
保持/削除A/RR(命令の実行)A/R(結合される)

5)書類・契約書

データ処理契約(DPA)-スキーマに必要なコントローラ→プロセッサ。
最小:PDの件名/カテゴリ、目的/指示、TOM、機密性、DSAR/DPIAのサポート、インシデント通知、データ削除/返却、監査、サブプロセッサ(リスト/同意メカニズム)。
Art。 26 Arrangement (Joint Controllers):責任の透明な分配(情報、DSAR、コンタクトポイント)、公共政策における役割の本質。
SCCs/UK IDTA+DTIA: EEA/UK以外の送信が不十分な場合は必須です。
RoPA:コントローラとプロセッサ(独自のセット)での処理操作のレジスタ。
マーケティング/SDK用語:リサイクルなし、明確な役割と目的。


6)重大な区域および典型的な間違い

1.ロールミキシング:「プロセッサ」はデータを独自の目的で使用します→実際にはコントローラ/ジョイントコントローラです。
2.許可なしのサブプロセッサ:プロセッサはあなたの同意なしにベンダーを追加します。
3.「空」DPA:明確な保持/削除/インシデント/監査手順はありません。
4.不透明な共同制御:no art。 26-苦情とペナルティリスク。
5.マーケティングSDK:プロバイダーは自分自身のためにPDを引き出します-あなたは開示と合法性に責任があります。
6.PSP/Banks:それらをプロセッサと見なすのは間違いです。より頻繁にこれらは個々のコントローラーです。


7) DPAミニテンプレート(文章断片)

処理の目標と性質: 「プロセッサは、コントローラが指示するKYC検証専用のPDを処理します。」

指示: 「目的の変更には、管理者の書面による同意が必要です。」

サブプロセッサ: "プロセッサは事前の書面による許可なしにサブプロセッサを引き付けません。最新のレジスタを維持し、公開します"

セキュリティ:"プロセッサはTOM(暗号化、エイリアシング、アクセス制御、ロギング)をサポートしています。
インシデント:"プロセッサは、過度の遅延なしにコントローラに通知し、レギュレータとエンティティに通知するためのすべての情報を提供します。

削除/返却: 「サービスの終了時、プロセッサはPDを削除/返却し、予定通りバックアップのコピーを削除します。」

監査: 「管理者は、合理的な通知をもって、監査/アンケート/外部レポート(SOC2/ISO)を実施することができます。」


8) DPIA/DTIAおよびクロスボーダー

DPIA:コントローラーは始まります;プロセッサは、システム、リスク、TOMに関する情報を提供します。
DTIA: SCCs/IDTAで-受信者の執行環境の評価、追加の対策(E2EE、クライアントキー、準匿名化、EC/UKのキーストレージ)。


9)分散ロールにおける主体権(DSAR)の操作

コントローラー:リクエストを受け付け、アイデンティティを検証し、コレクションを調整し、(通常は30日≤)以内に応答します。
プロセッサ:指示されたようにアップロード/削除をすみやかに提供し、(特に指示されていない限り)被験者に直接応答しません。
共同監督者:契約では、応答のための「接点」とデータ交換を指定します。


10)セキュリティとインシデント: 誰が何をするか

コントローラ:インシデントポリシー、DPA/ユーザー通知計画、CAPA管理。
プロセッサ:コントローラの即時通知、テクニカルフォレンジック、封じ込め、ログ、通知の支援。
共同監督者:合意された通知マトリックス;一行のコミュニケーションです。


11)保持、削除、テストデータ

コントローラー:目標/法律(AML、会計)に従って保存期間を設定し、ポリシーに公開します。
プロセッサ:スケジュールに削除/匿名化を実装、別途-バックアップのクリーニング;マスク/合成なしでテスト環境でPDを使用することを禁止します。


12)運用統合(実践)

CAB/Change: CABおよびDPA/SCCによるロール/サブプロセッサ/テリトリーの変更。
データマップ&RoPA:ライブストリームマップ;コントローラには目標と受信者があり、プロセッサにはカテゴリと操作があります。
ベンダー管理:オンボーディング前のデューデリジェンス(ISO/SOC2、浸透テスト、インシデントポリシー、データ地理)。
監査:チェックリスト、アンケート、PIIアクセスサンプルログ、削除ロジック。


13)チェックリスト「役割の定義」

  • 誰が目標と主要な処理パラメータを設定しますか?
  • PDは独自の目的で再利用できますか?
  • 第二者は別の法的根拠を持っていますか?
  • エンティティ(DSAR)に責任があるのは誰ですか?
  • DPAは必要ですか(art。 28)またはアレンジメント(art。 26)?
  • サブプロセッサとマッチング機構はありますか?
  • 国境を越えた伝達があり、どのようなメカニズム(SCCs/IDTA)がありますか?

14)よくある質問(FAQ)

PSP-プロセッサまたはコントローラ?
通常、個別のコントローラ:独自の目標(決済サービス、詐欺防止、規制報告)。

KYCプロバイダはモデルトレーニング用の写真を保存できますか?
管理者のステータス(別途根拠と開示がある場合)またはお客様の明示的な同意と正しい法的根拠がある場合に限ります。それ以外の場合は禁止されています。

プレイヤーを連れてきたアフィリエイトはプロセッサですか?
より頻繁に別のコントローラー:彼は彼自身の目的のためのPDを集めます。共同キャンペーンには明示的な役割の割り当てが必要です。

クラウドロギングサーバー-誰のデータ?
ログ処理は、セキュリティを確保するためのプロセッサの責任です。独自の目的のために再利用するには、別のグラウンドが必要です(そうでなければ不可能です)。


15)小型役割の方針(内部標準のためのスニペット)

1.デフォルトでは、オペレータはプレイヤー/パートナーのすべてのPDフローのコントローラとして機能します。
2.PDにアクセスできるベンダー-プロセッサ(DPA)または個別のコントローラ(独自の目的のため)として登録されています。
3.サブプロセッサを追加するには、書面による同意とレジストリの更新が必要です。
4.CAB、 DPO、 Legalを通じた役割/地域/目的の変更。
5.DSARとインシデント-コントローラによって調整され、プロセッサはSLAに応答します。


16)実装ロードマップ

週1-2:データフローと役割のインベントリ;草案「who's who」行列;RoPAアップデート。
週3-4: DPAの結論/更新、アート。26(必要に応じて)、サブプロセッサレジストリ;監査アンケートの準備。
月2: DTIA/SCCs/IDTA、公共政策の更新、チームトレーニング。
月3+:通常のベンダー監査、DSARテスト、インシデントのテーブルトップ、製品/マーケティングの変更のための役割監査。


17)ショートテンプレート「ロールマトリックス」(例)

ストリーミングオペレータの役割カウンターパーティの役割[ドキュメント]コメントする
CCM/制裁コントローラープロセッサDPA+手順再使用はありません
支払い(PSP)DEP。コントローラDEP。コントローラプライバシーポリシー個別の責任
ホスティング/クラウドコントローラープロセッサ/サブプロセッサDPA、 SCCs/IDTAデータ地理
マーケティング-SDKコントローラープロセッサまたはデパートコントローラDPA/ジョイント/ToS再利用を確認する
アナリティクスコントローラープロセッサDPA、目標の制限仮名化(仮名化)

TL;DR(ドクター)

私たちは、目的と処理方法を通じて役割を決定します:あなたは「なぜ/どのように」-コントローラを決定します。指示に従って実行-プロセッサ;一緒にあなたが決める-ジョイントコントローラ。これをDPA/artで形式化します。26、私たちはRoPA、制御サブプロセッサを行い、DPIA/DTIA、主体権とセキュリティを提供します。明確なロールマトリックス=規制リスクの削減、紛争領域の削減、監査の迅速化。

Contact

お問い合わせ

ご質問やサポートが必要な場合はお気軽にご連絡ください。いつでもお手伝いします!

統合を開始

Email は 必須。Telegram または WhatsApp は 任意

お名前 任意
Email 任意
件名 任意
メッセージ 任意
Telegram 任意
@
Telegram を入力いただいた場合、Email に加えてそちらにもご連絡します。
WhatsApp 任意
形式:+国番号と電話番号(例:+81XXXXXXXXX)。

ボタンを押すことで、データ処理に同意したものとみなされます。