Filiera tecnologica utilizzata da STRAXA, con funzione, stato, categorie di dati e indicazioni sui possibili trasferimenti.
Questo registro identifica i principali fornitori che possono trattare dati personali per erogare STRAXA. La qualificazione giuridica dipende dallo specifico flusso: un soggetto può operare come sub-responsabile, responsabile autonomo o titolare autonomo in base alla funzione e al contratto applicabile.
Funzione: Database, autenticazione, storage e servizi backend
Stato: Attivo
Localizzazione/configurazione: Progetto STRAXA configurato in regione UE (eu-central-1)
Dati: Account, workspace, Business/Master Memory, file, dati applicativi e metadati necessari alla funzione utilizzata.
Trasferimenti: Trattamento principale configurato in UE; eventuali servizi accessori del provider seguono il relativo DPA e la documentazione contrattuale.
Funzione: Hosting, deployment, CDN e runtime applicativo
Stato: Attivo
Localizzazione/configurazione: Runtime production osservato attualmente in iad1 (USA)
Dati: Richieste applicative, log tecnici, metadati e dati transitati nelle funzioni server necessarie.
Trasferimenti: Può comportare trasferimenti extra-SEE; si applicano i meccanismi previsti dal DPA del provider e, quando necessario, SCC/garanzie del Capo V GDPR.
Funzione: Elaborazione AI tramite API/business services
Stato: Attivo quando una funzione richiede AI
Localizzazione/configurazione: Infrastruttura internazionale del provider
Dati: Prompt, contesto, istruzioni e output strettamente necessari alla richiesta.
Trasferimenti: Possibile trattamento extra-SEE secondo i termini business/API e il DPA applicabile. STRAXA non abilita volontariamente training generalizzato sui dati cliente.
Funzione: Invio email transazionali, operative e outbound
Stato: Attivo
Localizzazione/configurazione: Infrastruttura internazionale del provider
Dati: Indirizzo email, nome, oggetto, contenuto e metadati minimi dell’invio.
Trasferimenti: Possibile trattamento extra-SEE secondo DPA e meccanismi del provider.
Funzione: Pagamenti, abbonamenti e prevenzione frodi
Quando: Solo quando il modulo pagamenti viene attivato
Dati: Dati di pagamento e transazione gestiti principalmente da Stripe secondo il proprio ruolo e le proprie policy.
Funzione: Advertising, Facebook/Instagram/WhatsApp Business e asset collegati
Quando: Solo dopo OAuth/autorizzazione esplicita
Dati: Ad account, pagine, Instagram account, pixel/dataset, campagne, creatività, WABA e dati necessari agli scope autorizzati.
Funzione: Ads, Analytics, Workspace e servizi autorizzati
Quando: Solo per i prodotti e scope collegati
Dati: Dati pubblicitari, analytics, email, calendario, file o altri contenuti secondo l’integrazione attiva.
Funzione: Ecommerce e dati merchant
Quando: Solo dopo installazione/autorizzazione del merchant
Dati: Prodotti, ordini, clienti, inventario, rimborsi, sconti e fulfillment secondo gli scope concessi.
Funzione: Gestionale, ERP e dati aziendali compatibili con il prodotto/API autorizzato
Quando: Solo dopo disponibilità dell’accesso API appropriato e autorizzazione del Cliente
Dati: Anagrafiche, documenti, ordini, magazzino, contabilità o altri dati limitatamente al modulo effettivamente collegato e agli scope disponibili.
Funzione: Outlook, Calendar, Teams e Microsoft Graph
Quando: Solo per i servizi Microsoft espressamente collegati
Dati: Email, calendario, riunioni, file, team e altri contenuti nei limiti degli scope autorizzati.
Funzione: CRM, advertising, ecommerce, produttività, booking e automazione
Quando: Solo quando il Cliente attiva il relativo connettore
Dati: Esclusivamente le categorie necessarie alla funzione selezionata, secondo principio di minimizzazione e minimo privilegio.
Ogni integrazione production deve seguire uno standard comune STRAXA: autenticazione ufficiale del provider quando disponibile, scope minimi necessari, credenziali conservate esclusivamente lato server, separazione per workspace, possibilità di disconnessione, gestione della scadenza o revoca dei token, tracciabilità degli errori e verifica dei permessi prima di ogni azione ad impatto.
Prima dell’uso production di un provider materialmente rilevante, STRAXA valuta per quanto ragionevolmente applicabile: ruolo privacy, DPA, misure di sicurezza, localizzazione, sub-fornitori, meccanismi di trasferimento, disponibilità di controlli amministrativi, autenticazione, revoca accessi e principio di minimo privilegio.
La presenza di un provider extra-SEE non implica automaticamente illiceità del trattamento. STRAXA verifica il meccanismo applicabile ai sensi del Capo V GDPR: decisione di adeguatezza, SCC o altro strumento valido. Quando necessario vengono considerate misure supplementari e valutazioni del trasferimento.
Quando STRAXA opera come responsabile del trattamento, il Cliente autorizza in via generale i sub-responsabili indicati nel presente registro secondo il DPA. L’aggiunta o sostituzione di fornitori materialmente rilevanti viene riflessa in questo registro e, quando previsto, comunicata secondo il meccanismo contrattuale applicabile.
Nei rapporti soggetti a DPA, un Cliente può sollevare un’obiezione motivata da ragioni concrete di protezione dei dati entro il termine eventualmente previsto dal contratto. STRAXA valuterà in buona fede soluzioni ragionevoli; se non esiste una soluzione tecnicamente o commercialmente praticabile, le parti potranno applicare i rimedi previsti dal rapporto contrattuale.
Il registro viene aggiornato quando un provider viene aggiunto, rimosso o cambia ruolo in modo materialmente rilevante. La data/versione del Trust Center consente di individuare il set documentale corrente.
Russo Giovanni Battista · Ditta individuale
Per esercitare i diritti privacy o chiedere informazioni sul trattamento scrivere a info@straxa.it. Per proteggere l’account, STRAXA può richiedere le sole informazioni necessarie a verificare l’identità del richiedente.