GDPR中的角色

1）基本定义和原则

控制器（控制器）：独立定义处理个人数据（PD）的目标和方法。它主要负责合法性，透明度，主体权利，安全-TOM，处理器的选择和控制。
处理器（Processor）：仅在记录的主计长指示下处理PD,提供TOMs,帮助处理主体权限和事件,维护记录并允许审核。
联合控制者（联合控制者）：两个+个人共同定义目标和方法；对受试者需要透明的职责分配和联系点。
子处理器（子处理器）：处理器吸引的供应商；只允许事先获得主计长的书面许可和同等义务。

黄金规则：谁决定为什么以及如何处理-控制者；谁只是"按照指令执行"-处理器。

2）如何在实践中定义角色（决策树）

1.谁设定了处理业务目标?

→你吗？而是控制者。

2.您能否为自己的目的（分析、营销）重复使用数据？

→是→主计长（或联合主计长，如果目标相同）。

3.确切的手段/限制是否指向另一方，目标是衍生的？

→是的→处理器。

4.是否有一个共同的产品/协作平台来确定双方的目标？

→是→联合控制器（需要艺术。26 arrangement).

5.您是否根据您的任务吸引了云/供应商?

→ Vendor是子处理器；你是主计长；您的主处理器必须获得您的许可。

3）在iGaming生态系统中的作用-示例矩阵

4）角色职责（高级RACI）

5）文件和协议

DPA（数据处理协议）：电路的必备控制器→处理器。
最低限度：PD主题/类别，目标/说明，TOMs，隐私，DSAR/DPIA帮助，事件通知，数据删除/退回，审计，子处理器（列表/同意机制）。
Art.26 Arrangement（联合控制器）：透明的职责分配（信息、DSAR、联系点）,公共政策中角色的本质。
SCCs/UK IDTA+DTIA：在欧洲经济区/UK之外进行传输时是强制性的，除非足够。
RoPA：控制器和处理器（其拨号）的处理操作注册表。
营销条款/SDK：禁止二次使用，明确角色和目标。

6）关键区域和类型错误

1.角色混合："处理器"将数据用于自己的目的→实际上是控制者/联合控制者。
2.未经许可的子处理器：处理器在未经您同意的情况下添加供应商。
3."空白"DPA：没有关于撤回/删除/事件/审计的明确说明。
4.不透明的联合控制：没有艺术。26-投诉和罚款风险。
5.营销SDK：提供商为自己拉动PD-您负责披露和合法性。
6.PSP/Bank：算作处理器是一个错误；通常是单独的控制器。

7）DPA迷你模板（措辞片段）

处理目的和性质： "处理器仅在主计长的指导下处理KYC验证的PD。"

指示： "任何目的变更均须经主计长书面同意。"

子处理器： "未经事先书面许可，处理器不会吸引子处理器；维护和发布最新的登记册。"

安全性： "处理器支持TOM（加密，别名，访问控制，日志），不低于附录A中所述。"

事件： "处理器在没有不当延迟的情况下通知主计长，并提供所有信息以通知监管机构和实体。"

删除/返回： "在服务结束时,处理器会删除/返回PD,并按计划删除备份中的副本。"

审计： "主计长有权在合理通知下进行审计/问卷/外部报告（SOC2/ISO）。"

8） DPIA/DTIA和跨界性

DPIA：主计长启动；处理器提供有关系统，风险，TOM的信息。
DTIA：在SCCs/IDTA中-评估接收者的执法环境，其他措施（E2EE，客户端密钥，准匿名，在EC/UK中存储密钥）。

9）在分布式角色中处理主体权利（DSAR）

主计长：接受请求，验证身份，协调收集，按时响应（通常为≤30天）。
处理器：按指示快速提供卸载/卸载,不直接响应对象（除非另有规定）。
联合主计长：在协议中指定"联系点"和数据交换以进行响应。

10）安全与事件： 谁在做什么

主计长：事件策略，DPA/用户通知计划，CAPA管理。
处理器：立即向控制器发出警报,技术力量,容器,日志,通知协助。
联合控制者：统一通知矩阵；一条通信线路。

11）重建,删除,测试数据

主计长：根据目标/法律设定保留期限（AML，bukuchet），并在政策中发布。
处理器：实现按计划删除/匿名化,单独清除bap；禁止在不伪装/合成的情况下在测试环境中使用PD。

12）操作集成（实践）

CAB/更改：通过CAB和DPA/SCC编辑来更改角色/子处理器/区域。
数据地图和RoPA：实时线程图；控制器有目标和收件人，处理器有类别和操作。
供应商管理：在登机之前进行尽职调查（ISO/SOC2，pentest，事件策略，数据地理）。
审计：支票单，问卷，选择性PII访问日志，删除逻辑。

13）"定义角色"支票清单"

• 谁设定了处理目标和关键参数?
• PD是否可用于其目的?
• 第二方有独立的法律依据吗？
• 谁对实体（DSAR）负责?
• 是否需要DPA（艺术。28）或arrangement（艺术。26)?
• 是否有子处理器和匹配机制？
• 是否会有跨境转移和什么机制（SCCs/IDTA）？

14）常见问题（FAQ）

PSP-处理器还是控制器?

通常是一个单独的控制者：自己的目标（支付服务，防止欺诈，监管报告）。

KYC提供商可以存储照片来训练模型吗?

仅在主计长身份（有单独的理由和披露）或您明确同意和正确的法律依据的情况下。否则-禁止。

引用玩家的关联是处理器吗？
通常是一个单独的控制者：他为自己的目的收集PD。联合运动需要明确的角色分配。

云计算服务器-数据是谁?

处理日志是处理器的安全责任；为其目的重新使用需要单独的理由（否则不可行）。

15）迷你角色策略（内部标准的片段）

1.默认情况下，操作员充当所有玩家/合作伙伴的PD流的控制器。
2.任何具有PD访问权限的供应商-都被设计为处理器（DPA）或单独的控制器（出于自己的目的）。
3.添加子处理器需要获得书面同意并更新注册表。
4.角色/领土/目标的任何变化-通过CAB，DPO和Legal。
5.DSAR和事件-由控制器协调，处理器在SLA中响应。

16）实施路线图

第一至第二周：数据流和角色清单；"谁是谁"矩阵草稿；RoPA更新。
第三至第四周：DPA的结论/更新，艺术。26（必要时）,子处理器注册表；准备审计问卷。
第二个月：DTIA/SCCs/IDTA，公共政策更新，团队培训。
3+月：定期供应商审核、DSAR测试、事件控制台、产品更改/营销角色审核。

17）简短的"角色矩阵"模板（示例）

TL;DR

我们通过目标和处理方式定义角色：决定"为什么/如何"-控制者；按照指示执行-处理器；共同决定-联合控制器。我们将此形式化为DPA/art。26、领导RoPA、控制子处理器、确保DPIA/DTIA、主体权利和安全。清晰的角色矩阵=减少监管风险，减少争议区域，并加快审核速度。