La residenza dei dati descrive dove i dati sono archiviati o trattati. Un server svizzero non stabilisce la posizione di backup, sistemi di supporto, integrazioni esterne o di ogni persona con accesso; valuta questi componenti separatamente.
Separa la posizione della macchina dal percorso dei dati
Un'etichetta di paese su un piano di hosting risponde a una domanda ristretta: dove si trova la configurazione elencata. La tua applicazione può comunque inviare informazioni altrove. Segnalazione errori, consegna email, elaborazione pagamenti, backup fuori sede e accesso amministrativo fanno parte del servizio anche quando sono assenti dal diagramma dell'infrastruttura. Tratta la destinazione svizzera come una voce in una mappa dei dati, non come una conclusione sull'intero progetto.
Inizia nominando le informazioni che gestisci. Un sito di documentazione pubblico, un portale clienti e un archivio privato richiedono controlli diversi. Distingui contenuti pubblicati, informazioni personali, segreti di autenticazione e registrazioni operative interne. Registra perché esiste ogni categoria e cosa accadrebbe se fosse divulgata, alterata o persa. Questo rende concrete le successive decisioni di localizzazione invece di affidarsi all'attrattiva generale di una giurisdizione.
Crea un piccolo registro dei trattamenti
Segui un'azione rappresentativa dell'utente dal browser all'archiviazione. Annota quale sistema riceve la richiesta, cosa scrive e quali altri servizi vengono notificati. Ripeti l'esercizio per creazione account, recupero password, upload e supporto. Spesso scoprirai copie secondarie nei log, nelle code email e nelle esportazioni diagnostiche. Registrale mentre l'architettura è ancora abbastanza semplice da poter essere modificata.
Usa un registro con scopo, destinazione, titolare dell'accesso e decisione di conservazione per ogni componente. Non serve uno strumento di conformità elaborato per iniziare. La proprietà utile è che qualcuno possa spiegare ogni riga e aggiornarla dopo una nuova integrazione. Un diagramma senza posizioni dei backup o accesso amministrativo è incompleto per una decisione di residenza.
| Componente | Cosa stabilire | Prove utili |
|---|---|---|
| Database primario | Posizione di hosting e accesso consentito | Specifica del servizio e politica di accesso |
| Copia di ripristino | Destinazione, conservazione e cancellazione | Configurazione di backup e procedura di ripristino |
| Esportazione di supporto | Contenuto e destinatari | Campione redatto e politica di supporto |
| Integrazione esterna | Informazioni inviate e termini di trattamento | Configurazione dell'integrazione e documentazione del provider |
Comprendi la responsabilità che rimane a te
L'Incaricato federale della protezione dei dati e della trasparenza spiega che l'esternalizzazione del trattamento non rimuove la responsabilità del titolare per la protezione dei dati. Le sue linee guida coprono la selezione dei responsabili, l'emissione di istruzioni e il controllo del trattamento dei dati personali. Questo è un motivo per esaminare il rapporto di servizio oltre alla posizione del rack. Gli obblighi esatti per la tua organizzazione dipendono dal quadro applicabile e dalle informazioni coinvolte.
Quando le informazioni possono essere divulgate oltre confine, usa le linee guida ufficiali pertinenti e ottieni consulenza per le decisioni che richiedono una valutazione legale. Evita di dichiarare che un nome di paese rende automaticamente l'applicazione conforme. Chiedi chi sono i responsabili e i sub-responsabili, dove avviene il trattamento e quali accordi si applicano. Conserva le risposte con la documentazione operativa del progetto, così la decisione potrà essere riesaminata in seguito.
Riduci le informazioni che richiedono una decisione di localizzazione
Raccogli solo ciò che serve a uno scopo definito. Una newsletter non necessita necessariamente di un indirizzo postale completo, e un report di troubleshooting raramente richiede un intero database clienti. Rimuovere campi non necessari riduce l'esposizione e semplifica la conservazione. Tieni i segreti fuori dagli strumenti diagnostici e valuta se misurazioni aggregate rispondono alla domanda operativa senza riprodurre singoli record.
La crittografia può aiutare a proteggere copie specifiche, ma identifica chi controlla le chiavi e dove avviene la decifratura. Un'applicazione che deve trattare dati leggibili non può essere considerata come se nessuno potesse mai accedervi. Allo stesso modo, un identificatore pseudonimo può comunque collegare record nel tempo. Descrivi con precisione il controllo implementato invece di usare un badge di crittografia come sostituto della mappa dei trattamenti.
Uno scenario pratico: un piccolo portale clienti
Immagina un portale ospitato su un VPS svizzero, con una copia di ripristino indipendente e un servizio email di terze parti. Il database clienti rimane sul VPS durante il normale funzionamento, ma i messaggi di reimpostazione password e le notifiche di supporto lasciano quella macchina. Il team dovrebbe registrare i campi minimi in quei messaggi, la destinazione usata per i backup e le persone autorizzate a esportare i record.
Una revisione sensata potrebbe sostituire un record completo in un report di errore con un riferimento casuale all'incidente, abbreviare la conservazione diagnostica e limitare l'accesso ai backup. Queste modifiche sono utili indipendentemente dal paese selezionato. L'esempio è un esercizio di pianificazione, non un'affermazione che SwissOctet includa queste integrazioni o abbia verificato un particolare accordo di residenza.
Verifica la mappa prima di assumere un impegno pubblico
Prima di promettere una posizione ai tuoi utenti, confronta il registro con la configurazione effettiva e i termini di servizio confermati. Verifica se le procedure di backup e cancellazione funzionano come previsto. Esamina esportazioni, agenti di monitoraggio e job programmati, perché possono introdurre copie che nessuno ricorda durante l'acquisto iniziale. Assegna a qualcuno l'approvazione di nuove destinazioni e l'aggiornamento del registro quando l'architettura cambia.
SwissOctet presenta configurazioni svizzere nel suo catalogo. Gli accordi di trattamento dell'operatore attivo, l'accesso al supporto e le regole di conservazione devono essere confermati separatamente prima di un ordine reale. Scegli l'infrastruttura con quel confine in vista: una chiara posizione svizzera può supportare la tua architettura, mentre una mappa dei dati completa e mantenuta supporta le dichiarazioni che fai al riguardo.
La tua checklist pratica.
- Classifica le informazioni gestite dal progetto.
- Mappa archiviazione primaria, backup, log e integrazioni.
- Identifica responsabili, titolari dell'accesso e decisioni di conservazione.
- Esamina le linee guida ufficiali per le questioni transfrontaliere applicabili.
- Verifica la configurazione effettiva prima di promettere la residenza.
I dettagli che contano.
Un server svizzero significa che ogni copia rimane in Svizzera?+
No. Destinazioni di backup, esportazioni, sistemi di supporto e integrazioni hanno i propri percorsi dati e devono essere verificati separatamente.
La crittografia elimina la necessità di mappare i trattamenti?+
No. Devi comunque sapere dove esistono dati e chiavi, chi può decifrarli e quale trattamento avviene.
Questa guida certifica un deployment SwissOctet?+
No. Fornisce un metodo di pianificazione. I termini di trattamento attivi e i controlli implementati devono essere confermati per il servizio specifico.
Vai alla fonte.
Questi riferimenti supportano i concetti tecnici di questa guida. Segui la documentazione corrente prima di modificare un sistema di produzione.
- FDPIC: trattamento dei dati nel cloud www.edoeb.admin.ch
- IFPDT: Esternalizzazione del trattamento dei dati www.edoeb.admin.ch
- IFPDT: Trasferimento transfrontaliero di dati personali www.edoeb.admin.ch
Guida editoriale di SwissOctet. Gli esempi sono illustrativi. Le specifiche di servizio, le opzioni disponibili e le condizioni contrattuali devono essere verificate separatamente.