ISO 27701: Privacy Management

1) What is ISO 27701 and why is it an iGaming operator

ISO 27701 is an add-on to ISO 27001 and 27002 that extends ISMS to PIMS (Privacy Information Management System).
For iGaming: proven compliance with privacy requirements (GDPR/UK GDPR/ePrivacy, etc.), accelerated work with regulators/banks/KYC/PSP partners, reduced risk of fines and simplified vendor management.

2) PIMS Scope and Context

• Roles and boundaries: in which processes you are Controller, where is Processor; which brands/regions/processes are included in Scope.
• Data categories: registration, payments, KYC/AML/sanctions, behavioral events, RG signals, support, marketing/SDK.
• Legal obligations: local privacy laws, licensing conditions, agreements with partners.

Output: PIMS Scope & Context document + stakeholder map.

3) Key roles and responsibilities

4) ISO 27701 ↔ ISO 27001 bundle

ISMS (27001/27002): security base (assets, risks, controls).
PIMS (27701): adds privacy policies, legality of processing, rights of subjects, data lifecycle, contractual and cross-border mechanisms.
SoA/Statement of Applicability: Extended by PIMS private controls.

5) Processing Register (RoPA) and Data Map

For each process: purpose, legal basis, categories of subjects/data, shelf life, recipients/subprocessors, geography, TOMs, DPIA flag.

yaml process: account_registration controller_role: controller purpose: account creation and contract execution lawful_basis: contract data_categories: [PII_basic, contact, device_fingerprint]
recipients: [psp, kyc_provider]
retention: P + 5y # storage policy locations: [EU, UK]
toms: [mTLS, encryption_at_rest, RBAC+ABAC, MFA, masking]
dpia_required: false

6) Legitimate Basis & Consent

Contract/Legal Obligation: Payments, KYC/AML, Fraud Prevention.
Legitimate Interest: basic analytics/security (with lead scoring and opt-out where required).
Consent: marketing, cookies/SDK for non-strictly necessary purposes, certain types of profiling.
Special categories: only with clear grounds and enhanced measures.

CIW/consent management: recording of policy version/banners, granularity by purpose, provability of recall.

7) DPIA/PIA - Privacy Impact Assessment

When: new technology, large-scale processing, sensitive data, systematic profiling, cross-border.
Content: description of processing, necessity and proportionality, risks to the rights of subjects, mitigation measures.
Exit: decision (go/rework/reject) + CAPA plan and date control.

8) Data Subject Rights (DSAR)

Rights: access, correction, deletion, restriction, portability, objection, refusal of profiling/marketing.
SLA: confirmation of the request quickly and execution within the scheduled period.
Flow of execution: receipt → verification of identity → collection of data → response/execution → log.

Ban on "blind unloading": only through windows with camouflage and logs; privacy thresholds.

9) Minimization, masking and retention

Data Minimization: store only what you need for your purposes; regularly delete/anonymize "dead" fields.
Masking/aliasing: default for PII; unmasking - JIT + 'purpose' + audit.
Retention matrix: retention period per process/category, stop factors (legal), auto-deletion/archive.

10) Cross-border transmissions and sub-processors

Contractual arrangements: DPA, SCCs/IDTA, DTIA (transmission assessment).
Location of data/keys: where physically data/keys (KMS/HSM), VUOK policy/regional keys.
Register of sub-processors: notification of changes, right of objection, TOMs level not lower than ours.

11) Privacy by Design / by Default

At the design stage: Data Protection Requirements in PRD, threat modeling template with private threats.
Implemented: RLS/CLS, tokenization, encryption, minimal API scopes, telemetry without PII.
By default: optional trackers are disabled, individual keys/namespaces per region/tenant.

12) PIMS Logging, Provability and Auditing

Логи (WORM+подпись): `READ_PII`, `EXPORT_DATA`, `PII_UNMASK`, `CONSENT_UPDATE`, `DSAR_`, `BREACH_`.
Reporting: RoPA status, DPIA campaigns, DSAR SLA/backlog, retention deletions, vendor changes, violations/incidents.
Audit: annually (or with changes), Design/Operating Effectiveness check of private controls.

13) PIMS Metrics (KPI/KRI)

• DSAR on-time ≥ 95%
• Relevance of RoPA ≥ 98%
• DPIA coverage by risk entity = 100%
• Proportion of automatic removals by retention ≥ 95%
• CMP inclusion level (recorded consent records) = 100%

• PII access without 'purpose' = 0
• Unauthorized export/transfer = 0
• Incidents/Leaks Late = 0
• Missing DPA/SCCs for active transmission = 0

14) Integration with existing controls

IGA/RBAC/ABAC/JIT/PAM: rights minimization and contextual access conditions.
Log policy and audit trails: proof of actions with PII.
TPRM and contracts: DPA/SCCs/DTIA, audit rights, SLA notifications ≤ 72 h.
ISO 27001/ISMS: general risk model, SoA and internal audits.
Incidents and leaks: playbook breach, joint war-room with vendors.

15) Artifact patterns (fragments)

15. 1 Privacy policy (internal excerpt)

yaml privacy_policy:
principles: [lawfulness, fairness, transparency, minimization, accuracy, storage_limitation, integrity_confidentiality, accountability]
roles: {controller: true, processor: true}
data_subject_rights: enabled consent_management: CMP_v2 retention_policy: matrix_ref:v1. 4

15. 2 Unmasking policy

yaml pii_unmask:
allowed_roles: [aml_officer, dpo, fraud_analyst_jit]
approvals: [data_owner, privacy]
ttl_minutes: 30 logging: [PII_UNMASK, READ_PII]

15. 3 DSAR process

yaml dsar:
intake_channels: [portal, email]
verification: kyc_level>=2 sla_days: 30 export_mechanism: curated_vitrines_only audit_events: [DSAR_OPEN, DSAR_VERIFY, DSAR_FULFILL, DSAR_CLOSE]

15. 4 Retention matrix (fragment)

yaml retention:
registration_logs: {basis: legal, period: "P5Y"}
marketing_events: {basis: consent, period: "P12M", on_withdraw: "delete"}
kyc_documents:   {basis: legal, period: "P5Y", storage: "vault_encrypted"}

16) SOP (procedures)

16. 1 RoPA update

1. Product/Owner → Process Card → Legal/Privacy Review → Security TOMs → Publication and Version.

16. 2 DPIA

1. Risk Screening → DPIA Template → DPO Consultation → CAPA → Decision and Timing

16. 3 DSAR

1. Accept → verify → collect and filter through showcases → response/execution → logging and closing.

16. 4 Vendors/Transfers

1. Due diligence → DPA/SCCs/DTIA → sub-processor registry → change monitoring → offboarding and confirmation of deletion.

17) RACI (enlarged)

18) Implementation Roadmap (8-10 weeks)

Weeks 1-2: Scope/Context, Roles and RACI, Process/Data Inventory, Draft RoPA and Retention Matrices.
Weeks 3-4: privacy policy, CMP/consent flow, DSAR process, DPIA templates, DPA/SCCs/DTIA update with vendors.
Weeks 5-6: TOMs implementation (masking, RLS/CLS, JIT/PAM), showcases for DSAR, WORM logs, KPI/KRI reporting.
Weeks 7-8: DPIA on high-risk, close CAPA, PIMS internal audit, Management Review (PIMS).
Weeks 9-10: adjustments, launch of regular reporting, preparation for external assessment (if necessary).

19) Frequent mistakes and how to avoid them

RoPA "for show": link each entry to goals, bases and retentions; keep a live version.
DSAR through "raw" databases: only through showcases/exports with masking and logs.
No DTIA when cross-border: issue in advance, fix the location of data/keys.
Non-CMP marketing SDKs: Ban until CMP and contractual TOMs are included.
No Pbd/PbD: Include privacy requirements in PRD and Definition of Done.

20) Run PIMS

Monthly: KPI/KRI reports, RoPA change audits, sub-processor monitoring, DSAR SLAs.
Quarterly: review of retention/deletions, thematic checks (marketing, SDK, KYC).
Annual: PIMS Internal Audit, Context/Risk Update, Staff Training, Management Review.

TL; DR

ISO 27701 = PIMS over ISMS: RoPA + legal grounds/consents + DPIA/DSAR + minimization/retention + cross-border and sub-processors + provable TOMs. We build logs and TPRM into existing RBAC/ABAC/JIT/and get managed, measurable privacy, ready for internal and external checks.