Roles within GDPR

1) Basic definitions and principles

Controller: determines the purposes and methods of personal data (PD) processing. Bears primary responsibility for the legality, transparency, rights of subjects, security-TOMs, selection and control of processors.
Processor: Processes PD only as documented by the controller, provides TOMs, assists with entity rights and incidents, maintains records, and allows audits.
Joint Controllers: two + persons jointly define goals and methods; transparent distribution of responsibilities and point of contact for subjects is required.
Sub-Processor: Vendor engaged by the processor is allowed only with prior written approval of the controller and equivalent obligations.

The golden rule: who decides why and how to process is the controller; who only "executes according to instructions" - the processor.

2) How to define a role in practice (decision tree)

1. Who sets the business goals for processing?

→ Are you? Rather a controller.

2. Can you reuse the data for your purposes (analytics, marketing)?

→ Yes → controller (or joint controller if goals are common).

3. Do the other party indicate to you the exact means/limitations and your objectives are derived?

→ Yes → processor.

4. Is there a common product/joint platform with goal setting by both parties?

→ Yes → joint controllers (art needed. 26 arrangement).

5. Do you involve a cloud/vendor on your assignment?

→ Vendor - sub-processor; you are the controller; your primary processor must obtain your permission for it.

3) Roles in the iGaming ecosystem - a matrix of examples

4) Role Responsibilities (High Level RACI)

5) Documents and Agreements

Data Processing Agreement (DPA) -The controller → processor required by the schema.
Minimum: PD subject/categories, objectives/instructions, TOMs, confidentiality, assistance with DSAR/DPIA, incident notifications, data deletion/return, audit, sub-processors (list/consent mechanism).
Art. 26 Arrangement (Joint Controllers): transparent distribution of responsibilities (informing, DSAR, contact point), the essence of roles in public policy.
SCCs/UK IDTA + DTIA: mandatory for non-EEA/UK transmissions if inadequate.
RoPA: register of processing operations at the controller and at the processor (of its own set).
Marketing/SDK terms: no recycling, clear roles and objectives.

6) Critical areas and typical errors

1. Role mixing: the "processor" uses the data for its own purposes → in fact it is a controller/joint controller.
2. Sub-processors without permission: The processor adds a vendor without your consent.
3. "Empty" DPA: No clear retention/deletion/incident/audit instructions.
4. Opaque joint control: no art. 26 - complaints and penalty risks.
5. Marketing SDKs: Providers pull PD for themselves - you are responsible for disclosure and legality.
6. PSP/Banks: it is a mistake to consider them processors; more often these are individual controllers.

7) DPA mini-template (wording fragments)

Goals and nature of processing: "The processor processes PD exclusively for KYC verification as directed by the Controller."

Instructions: "Any change of objectives requires the written consent of the Controller."

Sub-processors: "The processor does not attract sub-processors without prior written permission; maintains and publishes an up-to-date register."

Security: "The processor supports TOMs (encryption, aliasing, access control, logging) not lower than described in Appendix A."

Incidents: "The processor notifies the Controller without undue delay and provides all information for notifications to the regulator and entities."

Deletion/return: "At the end of the service, the processor deletes/returns PD and deletes copies in backups on schedule."

Audit: "The Controller may conduct audits/questionnaires/external reports (SOC2/ISO), with reasonable notice."

8) DPIA/DTIA and cross-border

DPIA: controller starts; processor provides information about systems, risks, TOMs.
DTIA: with SCCs/IDTA - assessment of the recipient's enforcement environment, additional measures (E2EE, client keys, quasi-anonymization, key storage in EC/UK).

9) Working with subject rights (DSAR) in distributed roles

Controller: accepts the request, verifies the identity, coordinates the collection, responds within (usually ≤30 days).
Processor: promptly provides uploads/deletes as directed, does not respond to the subject directly (unless otherwise instructed).
Joint Supervisors: In the agreement, specify the "point of contact" and data exchange for the response.

10) Security and incidents: who does what

Controller: Incident Policy, DPA/User Notification Plan, CAPA Management.
Processor: immediate notification of the controller, technical forensics, containment, logs, assistance with notifications.
Joint Supervisors: agreed notification matrix; a single line of communication.

11) Retention, deletion, test data

Controller: sets storage periods according to goals/laws (AML, accounting), publishes in the policy.
Processor: implements deletion/anonymization on a schedule, separately - cleaning backups; prohibition to use PD in test environment without masking/synthetics.

12) Operational integration (practice)

CAB/Change: any role/sub-processor/territory change - via CAB and DPA/SCCs edits.
Data Map & RoPA: Live Stream Map; the controller has goals and recipients, the processor has categories and operations.
Vendor management: due diligence before onboarding (ISO/SOC2, penetration test, incident policy, data geography).
Audits: checklists, questionnaires, PII access sample logs, deletion logic.

13) Checklist "Defining the role"

• Who sets the goals and key processing parameters?
• Can the PD be reused for its own purposes?
• Does the second party have separate legal grounds?
• Who is responsible to the entity (DSAR)?
• Are DPAs needed (art. 28) or arrangement (art. 26)?
• Are there any sub-processors and matching mechanism?
• Will there be cross-border transmissions and what mechanism (SCCs/IDTA)?

14) Frequently Asked Questions (FAQ)

PSP - Processor or Controller?
Usually a separate controller: own goals (payment services, fraud prevention, regulatory reporting).

KYC provider can store photos for model training?
Only with the status of controller (with separate basis and disclosure) or with your explicit consent and correct legal basis. Otherwise, it is prohibited.

The affiliate that brought the player is a processor?
More often a separate controller: he collects PD for his own purposes. Joint campaigns require explicit role allocation.

Cloud logging server - whose data?
Log processing is the responsibility of the processor to ensure security; reuse for its own purposes requires a separate ground (otherwise not possible).

15) Mini Role Policy (snippet for internal standard)

1. By default, the operator acts as a controller for all PD flows of players/partners.
2. Any vendor with access to PD - is registered as a processor (DPA) or as a separate controller (for its own purposes).
3. Adding a sub-processor requires written consent and registry updates.
4. Any change of roles/territories/objectives - through CAB, DPO and Legal.
5. DSAR and incidents - coordinated by the controller, processors respond to SLAs.

16) Implementation Roadmap

Weeks 1-2: inventory of data flows and roles; a draft "who's who" matrix; RoPA update.
Weeks 3-4: conclusion/update of DPA, art. 26 (where necessary), sub-processor registry; preparation of audit questionnaires.
Month 2: DTIA/SCCs/IDTA, public policy update, team training.
Month 3 +: regular vendor audits, DSAR test, tabletop on incidents, role audits for product/marketing changes.

17) Short template "Role Matrix" (example)

TL; DR

We determine the role through goals and methods of processing: you decide "why/how" - the controller; perform as directed - processor; together you decide - joint controllers. Formalizing this in DPA/art. 26, we conduct RoPA, control sub-processors, provide DPIA/DTIA, subject rights and security. Clear role matrix = fewer regulatory risks, fewer areas of dispute, and faster audits.