ISO 27701 Gestione della privacy

1) Cos'è ISO 27701 e perché è iGaming

ISO 27701 è un componente aggiuntivo ISO 27001 e 27002 che estende ISMS a PIMS (gestione delle informazioni sulla privacy).
Per : conformità dimostrata ai requisiti di privacy (GDPR/UK), accelerazione del lavoro con i regolatori/banche/partner KYC/PSP, riduzione del rischio di multe e semplificazione della gestione dei vendor.

2) Ambito e contesto PIMS

• Ruoli e bordi: in quali processi sei Controller, Dove - Processor; quali marchi/regioni/processi sono inclusi in Scope.
• Categorie di dati: registrazione, pagamenti, KYC/AML/sanzioni, eventi comportamentali, segnali RG, zapport, marketing/SDK.
• Obblighi legali: leggi locali sulla privacy, condizioni di licenza, contratti con partner.

Risultato: PIMS Scope & Text + Mappa delle parti interessate.

3) Ruoli e responsabilità fondamentali

4) Collegamento ISO 27701 ↔ ISO 27001

ISMS (27001/27002) - Base di sicurezza (asset, rischi, controllo).
PIMS (27701): aggiunge politica di privacy, legittimità di elaborazione, diritti dei soggetti, ciclo di vita dei dati, meccanismi contrattuali e transfrontalieri.
SoA/Statement of Applicability: espandibile con controlli PIMS privati.

5) Registro di elaborazione (RoPA) e mappa dati

Per ciascun processo: obiettivo, base legale, categorie di soggetti/dati, conservazione, destinatari/sottoprocessori, geografia, TOMs, flag DPIA.

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) Legittimi motivi e consenso (Lawful Basis & Consent)

Contract/Legale Oblazione: pagamenti, KYC/AML, prevenzione delle frodi.
Legitimate Interest: analisi/sicurezza di base (con valutazione degli interessi e opt-out, se necessario).
Consent: marketing, cookies/SDK per scopi non richiesti, specifici tipi di profilassi.
Categorie speciali: solo con motivi chiari e misure rafforzate.

CMR/Gestione dei consensi: scrittura della versione dei criteri/banner, granularità degli obiettivi, prova della revoca.

7) DPIA/PIA - valutazione dell'impatto sulla privacy

Quando: nuova tecnologia, elaborazione su larga scala, dati sensibili, profilassi sistematica, transfrontaliera.
Contenuto: descrizione dell'elaborazione, necessità e proporzionalità, rischi per i diritti dei soggetti, misure di riduzione.
Uscita: soluzione (andare/perfezionare/rifiutare) + piano CAPE e controllo date.

8) Diritti dei soggetti dati (DSAR)

Diritti: accesso, correzione, rimozione, limitazione, portabilità, obiezione, rifiuto di profilazione/marketing.
SLA conferma la richiesta in tempi rapidi e l'esecuzione entro la data di scadenza.
Flusso di esecuzione: acquisizione, verifica dell'identità, raccolta dei dati, risposta/esecuzione del registro.

Divieto di scaricamento cieco solo attraverso vetrine mascherate e cassetti; limitazione dei piccoli campionamenti (privacy thresholds).

9) Minimizzare, mascherare e ritoccare

Data Minimization - Conservare solo ciò che è necessario per scopi eliminare/anonimizzare regolarmente i campi morti.
Maschera/alias predefinito per PII; Demascensione - JIT + «purpose» + controllo.
Data di conservazione per processo/categoria, fattori di stop (legali), rimozione automatica/archivio.

10) Trasferimenti transfrontalieri e sottoprocessori

I meccanismi contrattuali sono DPA, SCCS/IDTA, DTIA.
Posizione dati/chiavi: dove sono fisicamente i dati/chiavi (KMS/HSM), il criterio VOC/chiavi regionali.
Registro dei sottoprocessori: notifica delle modifiche, diritto di obiezione, livello TOMs non inferiore al nostro.

11) Privacy by Design / by Default

In fase di progettazione: Data Protection Prescrizioni in PRD, modello di threat modeling con minacce private.
In implementazione: RLS/CLS, tokenizzazione, crittografia, API minime, telemetry senza PII.
Per impostazione predefinita, i tracker opzionali, le chiavi singole/neimspace per regione/tenante sono spenti.

12) Loging, validità e verifica PIMS

Логи (WORM+подпись): `READ_PII`, `EXPORT_DATA`, `PII_UNMASK`, `CONSENT_UPDATE`, `DSAR_`, `BREACH_`.
Rendicontazione: stato di RoPA, campagne DPIA, DSAR SLA/backlog, rimozioni, cambiamenti di vendetta, violazioni/incidenti.
Controllo annuo (o in caso di modifiche), verifica Design/Operating Efficieness dei controlli privati.

13) Metriche (KPI/KRI) PIMS

• DSAR on-time ≥ 95%
• Rilevanza del 98%
• Copertura DPIA per oggetto a rischio = 100%
• La percentuale di rimozione automatica per retino è pari al 95%
• Livello di inclusione CMP (voci di consenso registrate) = 100%

• Accesso al PII senza «purpose» = 0
• Esportazione/trasferimento non autorizzata = 0
• Incidenti/fughe notificati dopo il termine = 0
• DPA/SCCS mancanti per il trasferimento attivo = 0

14) Integrazione con i controlli esistenti

IGA/RBAC/ABAC/JIT/PAM: riduzione dei diritti e contestuali condizioni di accesso.
Criteri dei logi e registri di revisione: dimostrazione dell'azione con il PII.

TPRM e contratti: DPA/SCCS/DTIA, diritti di verifica, notifiche SLA da 72 ore

ISO 27001/ISMS: modello comune di rischio, SoA e verifiche interne.
Incidenti e fughe: playbook breach, war-room congiunta con venditori.

15) Modelli di manufatti (sezioni)

15. 1 Politica di privacy (estratto interno)

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 Criteri di demascolarizzazione

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

15. Processo DSAR 3

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 Retensch matrice (frammento)

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 (procedure)

16. 1 Aggiornamento RoPA

1. Iniziatore di modifiche (Product/Owner): la scheda del processo di Legale/Privacy è stata creata da un Security TOMs per la pubblicazione e la versione.

16. 2 Esecuzione DPIA

1. Lo screening del rischio il modello DPIA, la consulenza DPO di CAPE per la soluzione e il controllo dei tempi.

16. 3 DSAR

1. Accetta

16. 4 Venditori/trasmissioni

1. Due diligence DPA/SCCS/DTIA il registro dei subprocessori per monitorare le modifiche di offboarding e confermare l'eliminazione.

17) RACI (ingrandito)

18) Road map di implementazione (8-10 settimane)

Settimane 1-2: Scope/contesto, ruoli e RACI, inventario dei processi/dati, bozza di e matrice di .
Settimane 3-4: criteri di privacy, CMP/consent-flow, processo DSAR, modelli DPIA, aggiornamento DPA/SCCS/DTIA con venditori.
Settimane 5-6: implementazione di TOMs (masking, RLS/CLS, JIT/PAM), vetrine per DSAR, logi WORM, report KPI/KRI.
Settimane 7-8: eseguire DPIA su high-risk, chiudere CAPE, controllo interno PIMS, Gestione Review (PIMS).
Settimane 9-10: regolazioni, avvio di rapporti regolari, preparazione per la valutazione esterna (se necessario).

19) Errori frequenti e come evitarli

RoPA «per il segno di spunta»: aggancia ogni voce agli obiettivi, ai motivi e alle righe; Tieni viva la versione.
DSAR tramite OBD «crudi», solo attraverso vetrine/espositori mascherati e loghi.
Nessun DTIA per la transfrontaliera: fissa in anticipo la posizione dei dati/chiavi.
SDK di marketing senza CMP: impedisce l'attivazione di CMP e TOMs contrattuali.
Nessuna Pbd/PbD: includere i requisiti di privacy in PRD e Definition of Done.

20) Mantenimento della conformità (Run PIMS)

Ogni mese: report KPI/KRI, controllo delle modifiche al sistema, monitoraggio dei sottoprocessori, DSAR SLA.
Trimestrale: rigonfiamento/rimozione, controlli tematici (marketing, SDK, KYC).
Ogni anno: controllo PIMS interno, aggiornamento del contesto/rischio, formazione del personale, gestione della revisione.

TL; DR

ISO 27701 = PIMS sopra ISMS: RoPA + legittimi motivi/consenso + DPIA/DSAR + minime/retensioni + transfrontaliera e subprocessori + dimostrabili TOMs. Incorporiamo RBAC/ABAC/JIT/Logi e TPRM esistenti e otteniamo una privacy controllabile e misurabile, pronta per controlli interni ed esterni.