Ripristino di emergenza, continuità operativa e risposta agli incidenti
Ripristino di emergenza, continuità operativa e risposta agli incidenti di ProcessMind
Data di entrata in vigore: 14 settembre 2026
Il presente documento fornisce una sintesi generale delle procedure di ProcessMind B.V. per il ripristino di emergenza («DR»), la continuità operativa («BCP») e la risposta agli incidenti di sicurezza relativi al proprio servizio cloud. Integra le Misure di sicurezza, la Policy di hosting SaaS, l’Accordo sul livello di servizio e l’Addendum sul trattamento dei dati.
Illustra il nostro approccio attuale e non stabilisce obiettivi contrattuali distinti relativi ai tempi di ripristino, ai punti di ripristino, alle garanzie di durabilità dei dati, ai termini di notifica, ai livelli di servizio o ai criteri di responsabilità, oltre a quanto espressamente previsto dall’accordo, dal DPA o dallo SLA applicabile.
1. Obiettivi e ambito di applicazione
ProcessMind mantiene queste procedure al fine di:
- proteggere la riservatezza, l’integrità e la disponibilità dei Dati del Cliente durante un evento di interruzione
- ripristinare i componenti critici del servizio di produzione dopo guasti nei sistemi sotto il controllo di ProcessMind
- proseguire la gestione degli incidenti, le comunicazioni con i clienti e il processo decisionale operativo durante le interruzioni del servizio
- ripristinare i sistemi in seguito a guasti dell’infrastruttura, della distribuzione, dell’applicazione o del livello dati, utilizzando procedure documentate e definizioni dell’infrastruttura sottoposte a controllo delle versioni
- individuare e valutare gli Incidenti di sicurezza, contenere le minacce, eliminare le cause alla radice, ripristinare i sistemi interessati, comunicare ove richiesto e acquisire gli insegnamenti tratti
Queste procedure si applicano al servizio cloud di produzione di ProcessMind e agli eventi di sicurezza che coinvolgono sub-responsabili del trattamento o servizi cloud, nella misura in cui incidono sul Servizio e rientrano nella ragionevole capacità di ProcessMind di indagare e gestire. Gli ambienti di sviluppo e di test sono separati e non sono considerati obiettivi di ripristino ai fini degli impegni relativi alla produzione destinata ai clienti.
2. Strategia di resilienza
2.1 Progettazione regionale. I servizi di produzione sono ospitati in AWS EU (Francoforte, Germania, eu-central-1). L’architettura si basa sui servizi gestiti AWS all’interno di tale regione, che AWS gestisce su più zone di disponibilità. Il cluster Aurora attualmente utilizza una singola istanza writer; pertanto, il ripristino del database si basa su backup automatici e sul ripristino a un determinato momento, anziché su un’istanza standby nella stessa regione. Attualmente ProcessMind non gestisce una seconda regione attiva per i dati dei clienti.
2.2 Servizi gestiti e serverless. ProcessMind si avvale di AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon Aurora PostgreSQL, Amazon S3, Amazon SQS, Amazon SNS e Amazon CloudWatch. Ciò riduce la dipendenza da server di lunga durata gestiti dai clienti e supporta il ripristino mediante ricostruzione dal codice sorgente dei componenti applicativi e statici.
2.3 Separazione degli ambienti. Gli ambienti di produzione e di sviluppo operano in account AWS separati, con database e stack infrastrutturali distinti. Ciò riduce il rischio che le attività di sviluppo incidano sulle operazioni di ripristino della produzione.
2.4 Monitoraggio e rilevamento. Gli allarmi e i dashboard di CloudWatch, gli avvisi delle code di messaggi non recapitabili, la registrazione centralizzata e il monitoraggio sintetico del servizio supportano il rilevamento, la valutazione iniziale e l’escalation degli incidenti. Potenziali incidenti possono inoltre essere individuati tramite richieste di assistenza, segnalazioni dei dipendenti, notifiche dei fornitori o altri elementi che avviano un’indagine.
3. Priorità di ripristino
Durante un incidente grave, le priorità di ripristino di ProcessMind sono generalmente le seguenti:
- Proteggere l’integrità dei dati dei clienti e prevenire ulteriori danni.
- Contenere l’incidente e stabilizzare i sistemi interessati.
- Ripristinare i percorsi di accesso principali alla produzione e i flussi di lavoro critici.
- Convalidare il funzionamento del servizio, l’integrità dei dati e il monitoraggio prima di dichiarare completato il ripristino.
- Comunicare gli aggiornamenti sullo stato, l’impatto sui clienti e le azioni successive.
La sequenza esatta può variare a seconda della natura dell’incidente, anche in funzione del fatto che questo incida sull’integrità dei dati, sull’accesso dei clienti, sull’elaborazione asincrona o sull’infrastruttura di supporto.
4. Procedure di ripristino di emergenza
4.1 Dichiarazione dell’incidente e coordinamento. Le interruzioni sostanziali del servizio e gli incidenti di sicurezza sono sottoposti a valutazione iniziale nell’ambito delle procedure di risposta agli incidenti. ProcessMind designa un responsabile dell’incidente, limita la partecipazione alla risposta al personale autorizzato, valuta la gravità e la portata, coordina i responsabili tecnici e monitora le azioni di ripristino fino alla risoluzione o alla riclassificazione dell’incidente a un livello inferiore.
4.2 Contenimento. ProcessMind compie sforzi commercialmente ragionevoli per arrestare o ridurre l’impatto in corso prima di avviare un ripristino più ampio. A seconda della modalità del guasto, le misure di contenimento possono comprendere il ripristino di modifiche recenti, la disabilitazione dei percorsi interessati, l’isolamento dei componenti malfunzionanti, la sospensione dell’elaborazione in background durante l’esecuzione di controlli di integrità, la revoca o la rotazione delle credenziali oppure il blocco delle attività abusive.
4.3 Eliminazione della causa. Dopo aver stabilizzato l’impatto immediato, ProcessMind interviene per rimuovere la causa alla radice o la condizione che ha contribuito all’incidente. Ciò può comprendere l’applicazione di correzioni al codice o alla configurazione, la rimozione di artefatti dannosi, la rotazione dei segreti, il ripristino di una configurazione attendibile o la chiusura dei percorsi di accesso esposti.
4.4 Ripristino del database. Aurora PostgreSQL esegue backup automatici continui con un periodo di conservazione di sette (7) giorni e supporta il ripristino a un determinato momento. Qualora un guasto a livello di database, un evento di corruzione o una modifica distruttiva accidentale richiedano un ripristino, ProcessMind può ripristinare il database dal backup idoneo più recente o a un momento selezionato, convalidare l’ambiente ripristinato e reindirizzare il traffico dell’applicazione al database ripristinato.
4.5 Ripristino di oggetti e artefatti. I caricamenti di file dei clienti e gli artefatti operativi sono memorizzati in Amazon S3. Il versioning è abilitato nel bucket dei caricamenti e nei bucket delle risorse per consentire il ripristino in caso di eliminazione o sovrascrittura accidentale. I bucket di distribuzione del sito web e del frontend sono considerati artefatti riproducibili e possono essere ricostruiti dal codice sorgente anziché ripristinati da backup.
4.6 Ripristino dei carichi di lavoro asincroni. I percorsi di elaborazione asincrona utilizzano code di messaggi non recapitabili per conservare gli eventi non riusciti ai fini dell’indagine. Il ripristino può comprendere il nuovo tentativo di invio dei messaggi non riusciti, la riesecuzione della logica di elaborazione o la riproduzione delle attività, laddove il flusso di lavoro sottostante consenta una rielaborazione sicura.
4.7 Ricostruzione dell’applicazione e dell’infrastruttura. L’infrastruttura è gestita tramite definizioni dell’infrastruttura come codice sottoposte a controllo delle versioni. Se è necessario ricreare l’infrastruttura applicativa o le risorse statiche, ProcessMind può ricostruire e ridistribuire i componenti interessati utilizzando definizioni e artefatti di compilazione sottoposti a controllo delle versioni.
4.8 Convalida prima del ripristino del servizio. Prima di chiudere un incidente, ProcessMind convalida lo stato del servizio utilizzando gli strumenti di monitoraggio disponibili, i registri, i controlli sintetici e verifiche funzionali mirate, e ripristina le funzionalità interessate utilizzando procedure convalidate di distribuzione, ripristino e gestione dell’infrastruttura. Può essere effettuata un’ulteriore verifica quando l’incidente ha comportato il ripristino dei dati o un rischio per la loro integrità.
5. Misure di continuità operativa
5.1 Continuità operativa. ProcessMind mantiene procedure operative documentate affinché la gestione degli incidenti, la ricezione delle richieste di assistenza dei clienti, la risposta tecnica e il processo decisionale possano proseguire durante eventi di interruzione.
5.2 Comunicazioni. In caso di incidenti sostanziali che interessano la produzione, ProcessMind compie sforzi commercialmente ragionevoli per fornire aggiornamenti tramite i canali di assistenza clienti e, ove opportuno, la pagina pubblica sullo stato del servizio all’indirizzo processmind.com/status.
5.3 Gestione controllata delle modifiche. Per ridurre le interruzioni evitabili e migliorare nel tempo la continuità, viene utilizzato un ciclo di vita dello sviluppo software basato sulla difesa in profondità, con più livelli indipendenti di convalida automatizzata, distribuzioni controllate, monitoraggio centralizzato e verifiche successive agli incidenti.
5.4 Sicurezza durante il ripristino. Le attività di ripristino sono svolte nel rispetto degli stessi principi generali di sicurezza applicabili durante le normali operazioni, compresi l’accesso con privilegi minimi, la registrazione delle attività operative ove disponibile e l’accesso controllato ai sistemi e ai dati di produzione.
6. Riepilogo dei backup e della protezione dei dati
6.1 Backup dei database. I backup automatici di Aurora sono crittografati e conservati per sette (7) giorni; entro tale periodo di conservazione è disponibile il ripristino a un determinato momento.
6.2 Protezioni S3. Amazon S3 offre un’elevata durabilità per gli oggetti archiviati. I bucket contenenti dati dei clienti modificabili si basano sulla durabilità e sul versioning nella regione primaria. Attualmente ProcessMind non abilita la replica S3 tra regioni per tali bucket.
6.3 Registri e diagnostica. I registri centralizzati, gli allarmi e la telemetria supportano l’analisi dei guasti e la convalida del ripristino. Questi meccanismi supportano le operazioni di continuità, ma non sono presentati come un prodotto di backup separato.
7. Identificazione e valutazione iniziale degli incidenti
7.1 Valutazione iniziale. Gli eventi segnalati sono sottoposti a valutazione iniziale per determinare se soddisfano la definizione di Incidente di sicurezza, quali sistemi o dati potrebbero essere interessati, la probabile portata e gravità e se sia necessario un contenimento immediato. La conservazione delle prove è gestita in modo adeguato alla natura dell’incidente e ai sistemi coinvolti.
7.2 Reperibilità e procedura di escalation. ProcessMind garantisce la reperibilità per gli incidenti di produzione, compresa la copertura 24 ore su 24, 7 giorni su 7 per gli incidenti critici (come definiti nell’Accordo sul livello di servizio), affinché gli incidenti possano essere presi in carico e sottoposti a valutazione iniziale in qualsiasi momento.
7.3 Documentazione. ProcessMind documenta i risultati rilevanti delle indagini, le azioni di risposta e le decisioni di ripristino, affinché la cronologia dell’incidente e le conseguenti azioni correttive possano essere esaminate dopo l’evento.
8. Comunicazioni e notifiche
8.1 Comunicazione interna. ProcessMind coordina i responsabili della risposta, i decisori e i canali di assistenza affinché la risposta tecnica e le comunicazioni ai clienti rimangano allineate durante l’intero ciclo di vita dell’incidente.
8.2 Notifica ai clienti. In caso di Incidente di sicurezza che richieda una notifica ai sensi del DPA o della legge applicabile, ProcessMind informa i clienti interessati senza indebito ritardo e, ove possibile, entro settantadue (72) ore dal momento in cui viene a conoscenza dell’incidente. Le notifiche includono generalmente la natura e la portata dell’incidente, le categorie di dati interessate, se note, le misure adottate per contenere e porre rimedio all’incidente e le azioni raccomandate ai clienti, ove pertinenti.
8.3 Aggiornamenti continui. Se l’incidente è ancora in corso o cambiano fatti rilevanti, ProcessMind fornisce aggiornamenti successivi man mano che diventano disponibili ulteriori informazioni verificate. Per interruzioni più ampie del servizio di produzione, ProcessMind può inoltre utilizzare i canali di assistenza clienti e, ove opportuno, la pagina pubblica sullo stato del servizio all’indirizzo processmind.com/status.
9. Test, riesame e manutenzione
ProcessMind riesamina queste procedure almeno una volta all’anno e dopo incidenti rilevanti o modifiche architetturali significative, sottopone periodicamente a esercitazione gli elementi pertinenti dell’approccio di risposta e ripristino (quali il ripristino dei backup, la ricostruzione delle distribuzioni, il monitoraggio, gli avvisi e le comunicazioni relative agli incidenti) e integra le lezioni apprese nelle proprie procedure di sicurezza, affidabilità e continuità.
10. Limitazioni e limiti contrattuali
Il presente documento è un riepilogo di alto livello e non descrive nel dettaglio operativo ogni procedura interna, percorso di escalation, metodo investigativo o fase di gestione delle prove. Non impegna ProcessMind a predisporre un piano separato di failover tra regioni, a garantire la conservazione in archiviazione immutabile per tutti i bucket modificabili o a fornire garanzie indipendenti di RTO/RPO oltre quanto espressamente indicato nell’accordo o nell’ordine applicabile.
In caso di conflitto tra il presente documento e l’Accordo con il cliente, l’Addendum sul trattamento dei dati, l’Accordo sul livello di servizio o la legge inderogabile applicabili, prevalgono tali fonti.