Archivio legale

GOCOTECH Ltd · GOAi&digital

Misure tecniche e organizzative

TOMsv1.2In vigore: 8 giugno 2026SHA-256: bf98694df685...

Misure Tecniche e Organizzative (TOMs) — Technical and Organizational Measures

Allegato 2 al DPA · GOCOTECH Ltd · Sofia, Bulgaria · EIK 208828892 · powered by GOAi&digital

**Documento bilingue IT/EN.** La versione italiana precede quella inglese. In caso di conflitto prevale l'**italiano**. *Bilingual document IT/EN. The Italian version precedes the English one. In case of conflict, the **Italian** prevails.* Versione: 1.2 · Data: 8 giugno 2026 · Questo documento costituisce l'**Allegato 2** dell'Accordo sul trattamento dei dati (`03-data-processing-agreement-it-en.md`) e descrive le misure di sicurezza ai sensi dell'**art. 32 GDPR**.

PARTE I — VERSIONE ITALIANA

Premessa

GOCOTECH Ltd adotta le seguenti misure tecniche e organizzative ("**TOMs**") per garantire un livello di sicurezza adeguato al rischio nel trattamento dei Dati del Cliente, ai sensi dell'art. 32 GDPR. Le misure sono allineate ai principi delle norme **ISO/IEC 27001** e ai criteri **SOC 2** (allineamento, non certificazione formale: GOCOTECH è "audit-ready", con eventuale certificazione attivabile su richiesta contrattuale specifica). Le misure descritte riflettono i controlli **effettivamente implementati** nella piattaforma; le voci in fase di roll-out o disponibili come upgrade sono espressamente indicate.

Le misure indicate come "in roadmap", "in roll-out", "upgrade" o equivalenti non sono incluse nella baseline obbligatoria del singolo Cliente salvo conferma nell'Order Form, nel checkout o in un allegato tecnico sottoscritto. Restano invece vincolanti le misure dichiarate come baseline always-on e quelle specificamente incluse nel piano acquistato.

1. Controllo degli accessi (Access Control)

  • **Autenticazione**: login tramite **email + password** (Supabase Auth). **Nessun magic link** (scelta architetturale di sicurezza). Disponibile autenticazione a due fattori (2FA/MFA) come upgrade.
  • **Hashing password**: le password non sono mai memorizzate in chiaro; sono protette mediante algoritmo di hashing robusto con salt (gestito da Supabase Auth / GoTrue, bcrypt).
  • **Gestione ruoli e privilegio minimo**: accessi basati su ruoli (RBAC); ogni utente riceve i soli permessi necessari (principio del minimo privilegio). Le chiavi `service_role` non sono mai esposte lato client.
  • **Protezione anti-brute-force**: policy di retry sui tentativi di login con blocco temporaneo dopo ripetuti tentativi falliti (brick `anti-brute-force-lockout`, baseline obbligatoria).
  • **Rate-limiting** per azione sensibile (login, OTP, OCR, voce) e rate-limit cost-aware per le chiamate LLM.

2. Isolamento e segregazione (Tenant Isolation)

  • **Database dedicato per cliente**: ogni Cliente dispone di un **database Supabase dedicato** (istanza separata), garantendo isolamento totale a livello infrastrutturale tra clienti diversi.
  • **Row Level Security (RLS) multi-tenant**: all'interno di ogni database, ciascuna tabella di business adotta **4 policy RLS granulari** (SELECT/INSERT/UPDATE/DELETE) basate su `tenant_id = get_my_tenant_id()`. È vietato l'uso di policy permissive `USING(true)` su ruoli autenticati.
  • **Test di isolamento verificabile**: test end-to-end automatizzati dimostrano che l'utente A non può mai accedere ai dati dell'utente/tenant B; eseguiti in CI/CD, con blocco del deploy in caso di fallimento (brick `multi-tenant-isolation-test-suite`).
  • **Segregazione delle credenziali**: i token OAuth e i segreti di ogni tenant sono isolati e, per i dati sensibili, cifrati at-rest.

3. Cifratura (Encryption)

  • **In transito**: tutte le comunicazioni avvengono su **TLS** (HTTPS), default applicato su Supabase e Vercel.
  • **At-rest**: i dati a riposo sono cifrati dal provider infrastrutturale (Supabase/AWS, cifratura del volume). Per i dati personali particolarmente sensibili (token OAuth, PII vocali/immagini) è prevista cifratura applicativa aggiuntiva (pgsodium) — attiva sui dati sensibili / in roll-out sui prodotti secondo baseline.

4. Gestione dei segreti (Secrets Management)

  • **Nessun segreto nel codice**: API key, chiavi di servizio e webhook secret sono conservati esclusivamente in **vault / variabili d'ambiente** (Supabase Secrets, env file locali con permessi ristretti `chmod 600`), mai committati nei repository.
  • **Gitleaks pre-commit**: scansione automatica anti-leak in pre-commit e in CI, con blocco delle PR in caso di rilevamento di segreti (brick `gitleaks-precommit-enforce`).
  • **Rotazione segreti**: ciclo di vita dei segreti con rotazione periodica (API key provider ~12 mesi; chiavi `service_role` ~6 mesi; webhook secret ~6 mesi) e alert programmati di scadenza (brick `secret-rotation-lifecycle` — in roadmap operativa).

5. Backup e continuità operativa (Backup & Business Continuity)

  • **Backup**: backup automatici del database. **Nota di onestà**: i **backup giornalieri** e il **Point-in-Time Recovery (PITR)** sono disponibili sui **piani Supabase Pro**; sui piani base il backup è meno granulare. Per i clienti su piattaforma dedicata in produzione è prevista l'attivazione del piano Pro con backup giornalieri e PITR.
  • **Obiettivi indicativi (target operativi, non SLA contrattuali salvo diverso accordo)**: **RPO** (Recovery Point Objective) ≈ 24 ore sui piani con backup giornaliero (fino a pochi minuti con PITR); **RTO** (Recovery Time Objective) ≈ ripristino entro poche ore.
  • **Procedura di disaster recovery** documentata, con test di ripristino periodici (brick `backup-disaster-recovery-procedure` — in roadmap).

6. Logging e audit (Logging & Audit Trail)

  • **Audit log immutabile**: tabelle di audit con trigger che impediscono UPDATE/DELETE (`RAISE EXCEPTION`); il ruolo di servizio può solo inserire, nessuno può modificare o cancellare i record.
  • **Eventi tracciati**: login, cambio password, modifica ruoli/permessi, accessi a dati personali, azioni critiche degli assistenti AI (handoff, approvazioni, azioni di massa), modifiche di `tenant_id`.
  • **Log infrastrutturali**: log di richiesta e accesso forniti da Supabase e Vercel.

7. Sviluppo sicuro (Secure Development)

  • **Code review** prima del merge; **CI/CD** con controlli di sicurezza automatizzati (lint security, test di isolamento, scansione segreti).
  • **Isolamento degli ambienti**: separazione tra ambiente di test e di produzione; le funzionalità di sviluppo (es. login dev) sono disabilitate in produzione.
  • **Portabilità senza hardcode**: niente `tenant_id` o path hardcoded nei componenti riutilizzabili.

8. Gestione vulnerabilità e patch (Vulnerability & Patch Management)

  • **Scansione dipendenze**: monitoraggio delle dipendenze e delle CVE (Dependabot / npm audit), con blocco delle PR su vulnerabilità critiche (brick `dependency-vuln-scan-enforce` — in roadmap).
  • **Patch**: aggiornamenti di sicurezza dell'infrastruttura gestiti dai provider (Supabase, Vercel) con patch tempestive a livello di piattaforma gestita.
  • **Header di sicurezza**: CSP, HSTS, X-Frame-Options, Permissions-Policy, Referrer-Policy (brick `csp-security-headers-template`).
  • **Pen test interno**: esercizio annuale interno (SQL injection, RLS bypass, prompt injection, brute force, replay) con fix dei findings; pen test esterno disponibile come upgrade per clienti regolati.

9. Gestione degli incidenti (Incident Management)

  • **Piano di risposta agli incidenti** scritto: detection → contenimento → valutazione → notifica (al Titolare entro 48h; all'autorità entro 72h ove di competenza del Titolare) → root cause analysis → post-mortem → misure preventive.
  • Si rimanda al documento **Incident Response Plan** e alla clausola 5.7 del DPA per le tempistiche di notifica delle violazioni.

10. Formazione del personale (Personnel Training)

  • Il personale autorizzato è vincolato a obblighi di **riservatezza** e riceve **formazione** periodica in materia di protezione dei dati e sicurezza.
  • Accessi concessi secondo il principio del minimo privilegio e revocati alla cessazione del rapporto.

11. Sicurezza fisica (Physical Security)

  • I dati sono ospitati in **datacenter UE certificati** dei provider infrastrutturali (Supabase/AWS — Francoforte; Vercel edge), che mantengono certificazioni quali ISO 27001 e SOC 2 e adottano controlli fisici (sorveglianza, controllo accessi, ridondanza energetica/ambientale). GOCOTECH non gestisce datacenter propri.

Sintesi della baseline obbligatoria

Ogni prodotto su piattaforma dedicata GOCOTECH adotta, come baseline always-on: auth password (no magic link) + 2FA disponibile; RLS multi-tenant 4 policy + test E2E di isolamento; audit log immutabile; cifratura in transito (TLS) e at-rest; gestione segreti in vault + gitleaks; webhook secret verify; rate-limit; protezione anti-brute-force; backup automatico; piano di risposta agli incidenti.

PART II — ENGLISH VERSION

Introduction

GOCOTECH Ltd implements the following technical and organizational measures ("**TOMs**") to ensure a level of security appropriate to the risk in processing Customer Data, pursuant to Art. 32 GDPR. The measures are aligned with the principles of **ISO/IEC 27001** standards and **SOC 2** criteria (alignment, not formal certification: GOCOTECH is "audit-ready", with certification available on specific contractual request). The measures described reflect the controls **actually implemented** in the platform; items being rolled out or available as upgrades are expressly indicated.

Measures marked as "in roadmap", "rolling out", "upgrade" or equivalent are not included in the mandatory baseline for a specific Customer unless confirmed in the Order Form, checkout or a signed technical annex. The always-on baseline measures and the measures specifically included in the purchased plan remain binding.

1. Access Control

  • **Authentication**: login via **email + password** (Supabase Auth). **No magic link** (security architectural choice). Two-factor authentication (2FA/MFA) available as an upgrade.
  • **Password hashing**: passwords are never stored in plaintext; they are protected by a strong hashing algorithm with salt (managed by Supabase Auth / GoTrue, bcrypt).
  • **Role management and least privilege**: role-based access control (RBAC); each user receives only the permissions needed (least-privilege principle). `service_role` keys are never exposed client-side.
  • **Anti-brute-force protection**: login retry policy with temporary lockout after repeated failed attempts (`anti-brute-force-lockout` brick, mandatory baseline).
  • **Rate-limiting** per sensitive action (login, OTP, OCR, voice) and cost-aware rate-limit for LLM calls.

2. Isolation and Segregation (Tenant Isolation)

  • **Dedicated database per customer**: each Customer has a **dedicated Supabase database** (separate instance), ensuring total infrastructure-level isolation between different customers.
  • **Multi-tenant Row Level Security (RLS)**: within each database, every business table adopts **4 granular RLS policies** (SELECT/INSERT/UPDATE/DELETE) based on `tenant_id = get_my_tenant_id()`. Permissive `USING(true)` policies on authenticated roles are prohibited.
  • **Verifiable isolation testing**: automated end-to-end tests prove that user A can never access user/tenant B's data; run in CI/CD, blocking deployment on failure (`multi-tenant-isolation-test-suite` brick).
  • **Credential segregation**: OAuth tokens and secrets of each tenant are isolated and, for sensitive data, encrypted at-rest.

3. Encryption

  • **In transit**: all communications occur over **TLS** (HTTPS), applied by default on Supabase and Vercel.
  • **At-rest**: data at rest is encrypted by the infrastructure provider (Supabase/AWS, volume encryption). For particularly sensitive personal data (OAuth tokens, voice/image PII), additional application-level encryption (pgsodium) is provided — active on sensitive data / rolling out across products per baseline.

4. Secrets Management

  • **No secrets in code**: API keys, service keys and webhook secrets are stored exclusively in **vault / environment variables** (Supabase Secrets, local env files with restricted `chmod 600` permissions), never committed to repositories.
  • **Gitleaks pre-commit**: automatic anti-leak scanning in pre-commit and CI, blocking PRs upon secret detection (`gitleaks-precommit-enforce` brick).
  • **Secret rotation**: secret lifecycle with periodic rotation (provider API keys ~12 months; `service_role` keys ~6 months; webhook secrets ~6 months) and scheduled expiry alerts (`secret-rotation-lifecycle` brick — in operational roadmap).

5. Backup & Business Continuity

  • **Backup**: automatic database backups. **Honest note**: **daily backups** and **Point-in-Time Recovery (PITR)** are available on **Supabase Pro plans**; on base plans backup is less granular. For customers on a dedicated production platform, the Pro plan with daily backups and PITR is provided.
  • **Indicative targets (operational targets, not contractual SLAs unless otherwise agreed)**: **RPO** (Recovery Point Objective) ≈ 24 hours on daily-backup plans (down to a few minutes with PITR); **RTO** (Recovery Time Objective) ≈ restoration within a few hours.
  • **Disaster recovery procedure** documented, with periodic restore tests (`backup-disaster-recovery-procedure` brick — in roadmap).

6. Logging & Audit Trail

  • **Immutable audit log**: audit tables with triggers preventing UPDATE/DELETE (`RAISE EXCEPTION`); the service role can only insert, no one can modify or delete records.
  • **Tracked events**: login, password change, role/permission changes, access to personal data, critical AI assistant actions (handoff, approvals, mass actions), `tenant_id` changes.
  • **Infrastructure logs**: request and access logs provided by Supabase and Vercel.

7. Secure Development

  • **Code review** before merge; **CI/CD** with automated security checks (security lint, isolation tests, secret scanning).
  • **Environment isolation**: separation between test and production environments; development features (e.g. dev login) are disabled in production.
  • **Hardcode-free portability**: no hardcoded `tenant_id` or paths in reusable components.

8. Vulnerability & Patch Management

  • **Dependency scanning**: monitoring of dependencies and CVEs (Dependabot / npm audit), blocking PRs on critical vulnerabilities (`dependency-vuln-scan-enforce` brick — in roadmap).
  • **Patching**: infrastructure security updates managed by providers (Supabase, Vercel) with timely managed-platform patches.
  • **Security headers**: CSP, HSTS, X-Frame-Options, Permissions-Policy, Referrer-Policy (`csp-security-headers-template` brick).
  • **Internal pen test**: annual internal exercise (SQL injection, RLS bypass, prompt injection, brute force, replay) with remediation of findings; external pen test available as an upgrade for regulated customers.

9. Incident Management

  • **Written incident response plan**: detection → containment → assessment → notification (to the Controller within 48h; to the authority within 72h where it is the Controller's responsibility) → root cause analysis → post-mortem → preventive measures.
  • Reference is made to the **Incident Response Plan** document and to clause 5.7 of the DPA for breach notification timelines.

10. Personnel Training

  • Authorized personnel are bound by **confidentiality** obligations and receive periodic **training** on data protection and security.
  • Access granted on a least-privilege basis and revoked upon termination of the relationship.

11. Physical Security

  • Data is hosted in **certified EU datacenters** of the infrastructure providers (Supabase/AWS — Frankfurt; Vercel edge), which maintain certifications such as ISO 27001 and SOC 2 and apply physical controls (surveillance, access control, power/environmental redundancy). GOCOTECH does not operate its own datacenters.

Summary of the mandatory baseline

Every product on a GOCOTECH dedicated platform adopts, as an always-on baseline: password auth (no magic link) + 2FA available; multi-tenant RLS 4 policies + E2E isolation tests; immutable audit log; encryption in transit (TLS) and at-rest; vault secrets management + gitleaks; webhook secret verify; rate-limit; anti-brute-force protection; automatic backup; incident response plan.

*GOCOTECH Ltd · Sofia, Bulgaria · EIK 208828892 · powered by GOAi&digital*