ANNEX II - TECHNICAL AND ORGANIZATIONAL MEASURES (TOM)

0. Ambito e applicabilità

Questo allegato descrive le misure tecniche e organizzative ('TOM') che BISC8 adotta come Responsabile del trattamento ai sensi dell'art. 28(3)(c) GDPR e dell'Annex II delle Clausole Contrattuali Standard (Reg. UE 2021/914). Fa parte integrante del Data Processing Agreement tra BISC8 e il Cliente.

Versioning: il documento è aggiornato a ogni cambio rilevante (cifratura, sub-processor, retention). Le versioni precedenti restano archiviate e disponibili su richiesta a privacy@bisc8.app.

1. Pseudonimizzazione e cifratura dei dati personali (art. 32(1)(a))

BISC8 progetta il proprio stack in modo che i dati personali dei visitatori siano pseudonimizzati prima ancora di essere persistiti, e cifrati a riposo e in transito.

Pseudonimizzazione

• L'identificativo del visitatore in consent_logs è SHA-256(IP || User-Agent || pepper). L'IP grezzo e lo User-Agent non sono mai persistiti.
• Il 'pepper' è una chiave segreta caricata da variabile d'ambiente, mai esposta lato client, ruotabile annualmente. La rotazione invalida la possibilità di re-identificare i visitatori dai log esistenti, mantenendo la prova del consenso.
• Il campo geo è limitato al codice ISO-2 del Paese (es. 'IT'): non vengono memorizzati indirizzo IP, coordinate o sub-divisioni geografiche.

Cifratura a riposo

• Il database Postgres ospitato su Supabase eu-west-1 (Dublino, IE) usa AES-256 sui volumi di archiviazione e backup, gestito da Supabase secondo il loro security whitepaper.
• I segreti webhook dei clienti e i 'pepper' dei recovery code sono ulteriormente cifrati a livello applicativo prima di toccare il database (vedi 'Cifratura a livello applicativo' più sotto).

Cifratura in transito

Tutto il traffico HTTPS è servito tramite TLS 1.3 (fallback TLS 1.2). HSTS preload è attivo su tutti i sottodomini (bisc8.app, app.bisc8.app, system.bisc8.app, cdn.bisc8.app). Le connessioni interne tra Vercel e Supabase usano TLS verificato.

Cifratura a livello applicativo

I segreti dei webhook dei clienti (usati per firmare HMAC le notifiche outbound) sono cifrati con AES-256-GCM usando una chiave master conservata in variabile d'ambiente Vercel (WEBHOOK_SECRET_KEY). Ogni segreto ha il proprio nonce. Lo stesso schema è usato per i recovery code peppers.

2. Confidenzialità, integrità, disponibilità (art. 32(1)(b))

Controllo accessi (logico)

• Supabase Row-Level Security (RLS) attivo su tutte le tabelle che contengono dati cliente. Le policy ammettono SELECT solo se l'account proprietario coincide con auth.uid().
• La chiave service_role di Supabase è isolata in un unico modulo server-side (lib/supabase.server.ts) ed è raggiungibile solo da codice eseguito in ambiente Vercel; mai esposta al browser.
• L'accesso super-admin è ulteriormente protetto da una tabella system_admins con RLS attiva e nessuna policy: solo service_role può leggerla, e l'enforcement avviene esclusivamente in un singolo gate (assertSystemAdmin).

Autenticazione

• Gli account Cliente B2B autenticano via Supabase Auth (email magic-link, OAuth Apple, OAuth Google). Cookies di sessione gestiti con @supabase/ssr, SameSite=Lax, HttpOnly.
• Gli accessi super-admin richiedono MFA TOTP (AAL2) al login. I codici di recovery sono hashati con SHA-256 + pepper applicativo prima di essere persistiti.
• Gli IP sorgente dei login sono hashati con pepper prima di essere conservati nel log degli accessi; nessun IP plaintext è mai persistito.

Sicurezza di rete

• Vercel Edge Network gestisce la terminazione TLS e il routing nella regione fra1 (Francoforte) come default.
• Tutti gli endpoint pubblici /api/v1/* sono rate-limited per IP-hash con tetti differenziati (consent 1000/min, scan 12/min, verify 6/min, pageview multi-layer per IP/dominio).
• CORS è gestito dinamicamente: ogni richiesta inbound viene validata contro la tabella dei domini registrati prima di essere accettata.

Integrità dei dati

• La tabella consent_logs è INSERT-only. Trigger BEFORE DELETE blocca le cancellazioni dirette sui domini (occorre soft-delete tramite deleted_at).
• Le partizioni mensili di consent_logs permettono retention granulare e archivio long-tail senza degradare le tabelle hot.
• system_access_log è append-only: ogni operazione super-admin produce una riga immutabile con timestamp, esito, motivo, IP-hash.

3. Ripristino della disponibilità e accesso dopo incidente (art. 32(1)(c))

• Backup Supabase Point-In-Time Recovery (PITR) con finestra di 7 giorni. Snapshot logici notturni archiviati separatamente dai volumi di runtime.
• RPO target: 24 ore. RTO target: 8 ore. Misurati durante test di restore semestrali.
• Runbook di disaster recovery mantenuto in docs/internal/IRP.md, con responsabilità, contatti e steps tecnici esplicitati.

4. Test, valutazione, valutazione regolare (art. 32(1)(d))

• Supabase Advisors eseguiti pre-deploy: identificano RLS mancanti, indici inefficienti, policy weak.
• Review trimestrale dell'elenco system_admins: chi non è più necessario viene rimosso.
• Audit annuale interno delle TOM rispetto a questo documento.
• Penetration test esterno pianificato post-raggiungimento soglia di fatturato (clausole contrattuali con clienti enterprise potrebbero anticiparlo).

5. Gestione dei sub-processor (art. 28(2)(4))

I sub-processor sotto elencati operano per conto di BISC8. Ognuno ha sottoscritto il proprio DPA con BISC8; ognuno è coperto da meccanismo di trasferimento adeguato per i flussi extra-UE (Data Privacy Framework + Clausole Contrattuali Standard 2021/914).

L'elenco aggiornato e datato è pubblicato su /legal/sub-processors. Ogni cambio di sub-processor è notificato al Cliente con almeno 30 giorni di preavviso e dà diritto di obiezione ai sensi del DPA.

6. Risposta agli incidenti (artt. 33-34 GDPR)

• Runbook IRP completo: ruoli, contatti, steps tecnici, modelli di comunicazione.
• Notifica al Garante entro 72 ore dalla scoperta di un data breach che comporti rischio per i diritti e le libertà degli interessati.
• Notifica al Cliente (Titolare) entro 48 ore dalla scoperta, in anticipo rispetto al termine al Garante, per consentire al Cliente di adempiere ai propri obblighi.
• Audit trail completo dell'incidente in system_access_log + log dedicati. Conservato per almeno 6 anni.

7. Minimizzazione dei dati e retention

• Nessun IP o User-Agent in chiaro è mai persistito.
• Il campo geografico è limitato al Paese ISO-2 (es. 'IT'), nessun dato di sub-divisione geografica.
• La retention dei consent_logs è calcolata al momento dell'INSERT in base al tier del Cliente: Free 30 giorni, Starter 3 anni, Pro 6 anni, Business 6 anni, Enterprise custom. Downgrade del tier non riduce la retention dei log raccolti precedentemente.
• pg_cron purga le partizioni scadute mensilmente in base al campo retention_until calcolato all'INSERT.

8. Misure organizzative su personale

• Obblighi di confidenzialità contrattualmente vincolanti per tutto il personale che ha accesso ai sistemi produttivi.
• Principio del minimo privilegio: l'accesso super-admin è limitato al personale strettamente necessario; ogni azione è loggata.
• Formazione annuale GDPR e sicurezza per personale tecnico.

9. Governance e accountability

• Registro delle attività di trattamento (ROPA) mantenuto e aggiornato in docs/internal/ROPA.md.
• DPIA per i trattamenti su larga scala mantenuta in docs/internal/DPIA.md.
• Contatto privacy@bisc8.app monitorato attivamente.

Questo allegato è parte integrante del Data Processing Agreement ( vedi DPA). Le definizioni e i termini sono mutuati dal DPA.