Cybersecurity e outsourcing: i controlli essenziali nel 2026

Cybersecurity e outsourcing si incontrano ogni volta che un fornitore accede al CRM, gestisce un ticket o consulta un documento del cliente. Una credenziale rimasta attiva dopo un cambio di incarico, un allegato inoltrato al destinatario sbagliato o un recupero account autorizzato senza verifiche possono compromettere il servizio anche quando l’infrastruttura tecnologica funziona.

Per questo la sicurezza riguarda chi affida e chi svolge attività di customer care e back office. La scelta del partner deve essere accompagnata da controlli su dati, accessi, procedure e gestione delle interruzioni. L’obiettivo è rendere verificabile il modo in cui il servizio viene svolto, anche quando interviene un problema.

Perché cybersecurity e outsourcing riguardano anche il customer care?

Cybersecurity e outsourcing riguardano il customer care perché gli operatori possono consultare informazioni riservate e avviare operazioni che incidono sugli account degli utenti. Il contatto con il pubblico diventa quindi un punto di controllo: una richiesta apparentemente ordinaria può essere autentica oppure tentare di ottenere informazioni o modifiche non autorizzate.

Si consideri una persona che chiede di cambiare l’indirizzo email associato a un account perché «non riesce più ad accedere». L’operatore deve poter distinguere il supporto legittimo da un tentativo di prendere il controllo del profilo. Servono una procedura di verifica e limiti chiari alle operazioni consentite, anche in presenza di urgenza. Questo approfondisce il tema dell’outsourcing IT e dei servizi digitali: oltre alla disponibilità degli strumenti, conta ciò che persone e fornitori possono fare attraverso quegli strumenti.

Quali rischi si nascondono nei processi esternalizzati?

I rischi più concreti nascono quando dati e autorizzazioni circolano senza regole verificabili. Un account condiviso impedisce di attribuire con precisione un’operazione; un’esportazione del CRM su un dispositivo non gestito crea una copia difficile da controllare; un allegato inatteso può indurre l’operatore a eseguire azioni pericolose. L’esternalizzazione aggiunge punti di interazione da includere nella valutazione del rischio.

Una prima ricognizione dovrebbe considerare almeno questi scenari:

Accessi eccessivi o non revocati: persone che vedono più dati del necessario o mantengono permessi dopo la fine dell’incarico.
Frode tramite comunicazioni: email, telefonate o messaggi che simulano un cliente, un collega o un responsabile.
Dispersione delle informazioni: documenti, registrazioni ed esportazioni inviati su canali o strumenti non autorizzati.
Dipendenze operative: indisponibilità del CRM, della telefonia o di un fornitore essenziale senza un’alternativa praticabile.

Le best practice ENISA sulla sicurezza della catena di fornitura offrono un riferimento per valutare il rapporto con fornitori e servizi esterni. Nel customer care questa lettura può diventare una mappa semplice: quali dati entrano, chi li usa, dove vengono conservati e quali passaggi dipendono da terzi. Anche gli strumenti AI devono rientrare nella mappa: incollare una conversazione cliente in un servizio non approvato introduce un ulteriore trattamento da valutare.

Chi risponde della protezione dei dati quando il servizio è esternalizzato?

La responsabilità dipende dal ruolo effettivo delle parti nel trattamento e non si trasferisce integralmente con il contratto commerciale. Quando l’azienda determina finalità e mezzi del trattamento e il fornitore opera per suo conto, il rapporto è generalmente tra titolare e responsabile. Il Comitato europeo per la protezione dei dati chiarisce che anche il responsabile ha obblighi propri: i ruoli vanno qualificati sulla base delle attività reali.

L’articolo 28 del GDPR richiede, in questo scenario, un accordo che disciplini il trattamento e garanzie adeguate da parte del fornitore. L’articolo 32 riguarda le misure tecniche e organizzative proporzionate al rischio. Il testo pubblicato dal Garante costituisce il riferimento normativo. In pratica, prima dell’avvio occorre stabilire istruzioni, persone autorizzate, eventuali sub responsabili e gestione dei dati alla fine del servizio. Vanno chiariti anche luoghi di trattamento ed eventuali trasferimenti fuori dallo Spazio economico europeo, che richiedono una valutazione specifica.

La NIS2 aggiunge requisiti di gestione del rischio per le organizzazioni che ricadono nel suo ambito, anche con attenzione alla catena di fornitura. La Commissione europea ne descrive perimetro e obiettivi. Non è corretto presentarla come un obbligo uniforme per qualsiasi PMI o qualsiasi contact center: l’applicabilità va verificata sul singolo soggetto e sulla disciplina nazionale pertinente.

Come controllare accessi, credenziali e strumenti degli operatori?

Gli accessi vanno assegnati a persone identificabili e limitati alle operazioni necessarie per il loro compito. Questo consente di ricostruire chi ha fatto cosa e riduce le conseguenze di un errore o di una compromissione. Un operatore che verifica lo stato di una pratica, per esempio, potrebbe non avere alcuna necessità di esportare l’intero archivio clienti.

Una configurazione operativa da valutare comprende account nominativi, autenticazione a più fattori, dispositivi gestiti, permessi distinti per ruolo e registrazione degli eventi pertinenti. Il NIST (National Institute of Standards and Technology), l’istituto federale statunitense che sviluppa standard e linee guida anche per la sicurezza informatica, spiega il contributo dell’autenticazione a più fattori: aggiungere un ulteriore fattore di verifica limita il rischio legato all’uso della sola password, pur senza rendere impossibili gli attacchi. Le credenziali devono essere revocate o aggiornate quando cambiano incarichi e persone, comprese le risorse aggiunte per un picco di richieste.

La verifica deve comprendere anche il lavoro quotidiano. Chi autorizza una nuova utenza? Chi controlla periodicamente i permessi? Quali allegati possono essere scaricati? Dove si possono usare strumenti AI? La formazione digitale degli operatori va applicata a questi casi, con esercitazioni su richieste sospette e segnalazioni tempestive. La procedura deve essere praticabile: un controllo scomodo e privo di istruzioni favorisce scorciatoie che l’organizzazione fatica poi a rilevare.

Quando conviene affidarsi a servizi gestiti di sicurezza?

Affidarsi a un provider di servizi di sicurezza può essere utile quando mancano competenze, strumenti o copertura per monitorare e affrontare i rischi individuati. Prima di decidere, l’azienda deve però chiarire il risultato atteso: raccogliere segnalazioni, analizzarle, intervenire sulle postazioni o coordinare una risposta sono attività differenti.

Un Managed Security Service Provider, o MSSP, fornisce servizi di sicurezza gestiti; un servizio MDR, Managed Detection and Response, si concentra su rilevazione e risposta secondo un perimetro concordato. L’organizzazione deve chiedere quali sistemi sono coperti, chi valuta gli allarmi e chi può autorizzare azioni come il blocco di un account. Copertura continuativa, aggiornamento specialistico e capacità di ampliare il presidio possono essere vantaggi del modello, ma devono risultare dal servizio acquistato. Come impostazione generale, il Cybersecurity Framework del NIST aiuta a collegare governo del rischio, protezione, rilevazione, risposta e ripristino. L’esternalizzazione dell’assistenza clienti richiede un coordinamento con queste funzioni; non ne implica automaticamente l’erogazione.

Che cosa verificare prima di scegliere un partner?

Prima di scegliere un partner occorre chiedere evidenze sul processo che verrà affidato, oltre alle dichiarazioni generali sulla sicurezza. Una dimostrazione delle autorizzazioni, un esempio anonimizzato di report o il verbale di una prova di continuità permettono di valutare aspetti che una presentazione commerciale lascia spesso indeterminati.

Per un servizio di assistenza, è utile seguire un caso dall’apertura alla chiusura: quali dati vede l’operatore, come verifica l’identità, quando passa la richiesta a un livello superiore e che cosa resta nel sistema. Bisogna poi chiarire quali attività dipendono da subfornitori e come verranno gestite restituzione dei dati e revoca degli accessi al termine del rapporto. Una certificazione può contribuire alla valutazione, ma occorre leggerne campo di applicazione e validità: il possesso di una certificazione di qualità non dimostra da solo l’adeguatezza dei controlli di sicurezza del servizio proposto.

Quali SLA, procedure e report servono per controllare la sicurezza?

Gli SLA (Service Level Agreement), cioè gli accordi che definiscono i livelli di servizio attesi, devono descrivere impegni misurabili, mentre le procedure devono indicare chi agisce e con quali autorizzazioni. Un tempo di risposta al ticket non equivale al tempo di contenimento di un incidente. Per evitare ambiguità, il contratto dovrebbe distinguere presa in carico, escalation, cioè il coinvolgimento dei referenti competenti, aggiornamenti e ripristino, collegando ciascun impegno a gravità, orari e dipendenze.

Un caso utile da discutere è l’accesso sospetto di un operatore. Il fornitore segnala l’evento a un referente nominato; la funzione competente valuta revoca delle sessioni e contenimento; il responsabile del servizio gestisce l’impatto sulle richieste in corso. Nei report devono trovare spazio anomalie, verifiche dei permessi, azioni correttive scadute ed esiti delle prove, con informazioni pertinenti e accessi controllati. Non servono promesse generiche di «sicurezza garantita», ma elementi che permettano di capire dove il processo sta funzionando e dove occorre intervenire.

Per le violazioni di dati personali, i tempi contrattuali devono consentire di rispettare quelli normativi. Il responsabile del trattamento informa il titolare senza ingiustificato ritardo; il titolare, quando la notifica è dovuta, informa l’autorità senza ingiustificato ritardo e, ove possibile, entro 72 ore dalla conoscenza della violazione. Non tutti gli incidenti informatici comportano la stessa notifica. La guida EDPB sui data breach, pubblicata dal Comitato europeo per la protezione dei dati, offre indicazioni pratiche su come gestire le violazioni dei dati personali, dalla valutazione e documentazione dell’evento alle notifiche e comunicazioni necessarie.

Come mantenere il customer care operativo durante un incidente?

La continuità del customer care richiede modalità di lavoro alternative già definite e provate. Se il CRM non è disponibile, gli operatori devono sapere quali richieste possono ancora trattare, quali informazioni possono raccogliere e quali attività devono essere sospese. Creare sul momento archivi personali o spostare documenti su caselle private può aggiungere nuovi rischi all’interruzione.

Un piano operativo dovrebbe indicare canali utilizzabili, referente per gli aggiornamenti e modalità controllate di recupero dell’arretrato. Dove pertinenti, vanno concordati RTO, cioè l’obiettivo di tempo per il ripristino, e RPO, cioè il limite di perdita di dati tollerata espresso come intervallo temporale. Sono obiettivi da verificare sul servizio complessivo: un backup disponibile non dimostra che sia possibile ripristinare sistemi, integrazioni e operatività nei tempi necessari. L’articolo 32 del GDPR richiama, in relazione al rischio, disponibilità, resilienza, ripristino e verifica dell’efficacia delle misure.

Anche la comunicazione sostiene la fiducia del cliente. Gli operatori devono ricevere informazioni confermate su ciò che funziona, sulle alternative e sul prossimo aggiornamento, senza ipotizzare cause o tempi non verificati. Nel contact center, il coordinamento tra front office e reparti competenti permette di mantenere risposte coerenti mentre viene gestito l’incidente. Una prova simulata può mostrare se questo coordinamento regge prima che diventi necessario in una situazione reale.

Cosa verificare prima di affidare un servizio all’esterno?

Prima di affidare un servizio all’esterno, è utile seguire il percorso di una richiesta cliente: quali dati vengono utilizzati, chi può accedervi, come passano tra le organizzazioni e come prosegue l’assistenza in caso di interruzione. Ogni passaggio deve avere un responsabile e una procedura chiara, da definire prima dell’avvio.

Nella gestione dell’assistenza e del back office, il coordinamento tra committente, operatori e referenti tecnici è essenziale per proteggere i dati e garantire continuità al servizio.

Articolo redatto con la supervisione di Outsourcing Group

I dati di un ticket sono dati personali?

Possono esserlo: nomi, recapiti, codici cliente e contenuti riconducibili a una persona rientrano nei dati personali. Alcuni ticket possono contenere anche categorie particolari di dati, per esempio informazioni sanitarie. È opportuno raccogliere soltanto ciò che serve alla richiesta.

Usare un CRM in cloud elimina il bisogno di controllare il fornitore?

No. Occorre verificare configurazioni, accessi, integrazioni, gestione delle copie e responsabilità contrattuali. Le misure della piattaforma devono essere coordinate con quelle dell’azienda e del partner che la utilizza.

Un accordo di riservatezza è sufficiente?

No. La riservatezza è un elemento del rapporto. Quando il fornitore tratta dati personali per conto del titolare, occorre anche disciplinare il trattamento secondo l’articolo 28 del GDPR e attuare misure adeguate al rischio.