Hotel Technology & Innovation

La sicurezza informatica negli hotel nel 2026: cosa richiedono realmente la direttiva NIS2 e il ransomware

Il ransomware è la causa più comune per cui un hotel indipendente perde una settimana di ricavi, e la normativa NIS2 ha trasformato un problema informatico di secondaria importanza in un obbligo legale a livello di consiglio di amministrazione, con responsabilità personale per i dirigenti. Questo è il quadro che si prospetta per il 2026 per gli operatori, non per i tecnici: se la direttiva NIS2 vi riguarda, come una violazione raggiunge il PMS passando per la reception e un fornitore, i tempi di segnalazione da rispettare, i controlli che riducono effettivamente il rischio e un piano di preparazione da attuare entro 30 giorni.

Mika Takahashi
Mika TakahashiTeam editoriale

Pubblicato 19 giu 2026

24 min di lettura

A cel-shaded editorial illustration of a night auditor standing at a dim hotel front desk during a security incident: the reception monitor shows a red padlock and a ransom-style lock screen over the property management system, the keyboard is pushed aside, the auditor holds a desk phone to one ear while reading a printed incident-response runbook held in the other hand, a router with a blinking amber light sits behind the desk, and a small wall clock reads just past 3 a.m., conveying the human reality of a hotel ransomware attack rather than abstract code, all rendered in the warm cream, taupe, sage, terracotta and deep navy palette.

Perché gli hotel sono obiettivi facili, non danni collaterali

Un hotel è un bersaglio particolarmente allettante, e alla maggior parte dei gestori non è mai stato spiegato il perché. Si conservano una grande quantità di dati personali relativi a migliaia di sconosciuti: nomi, indirizzi di residenza, scansioni di passaporti e documenti d’identità, date di viaggio, dettagli di pagamento e, talvolta, note relative alla salute e alle preferenze alimentari. Gestite un edificio pieno di dispositivi degli ospiti collegati alla vostra rete. Operate 24 ore su 24 con una reception presidiata da personale addestrato ad essere disponibile con gli sconosciuti, che è proprio l’istinto che un ingegnere sociale sfrutta. Inoltre, dipendete da una serie di sistemi sempre attivi: il sistema di gestione della struttura che gestisce il registro contabile e archivia i dati degli ospiti, il channel manager, le serrature delle porte, il punto vendita; sistemi che non possono tollerare tempi di inattività senza che l’attività si fermi. Gli aggressori sanno tutto questo. Non si imbattono negli hotel per caso; li scelgono. I sistemi che contengono i dati dei vostri ospiti, a cominciare dal sistema di gestione della struttura, sono il vero obiettivo di un aggressore.

Per anni la sicurezza informatica è stata considerata un problema del reparto IT o, in un hotel indipendente privo di tale reparto, un problema di nessuno finché non si verificava un guasto. Questo approccio non è più sostenibile nel 2026 per due ragioni che si intrecciano. La prima è il ransomware, che si è industrializzato trasformandosi in un’attività di servizi che colpisce in modo sproporzionato gli operatori di medie dimensioni con dati di valore e difese deboli, esattamente il profilo di un hotel indipendente. La seconda è la NIS2, la direttiva dell’UE sulla sicurezza delle reti e dell’informazione, che ha trasformato la sicurezza informatica da una spesa IT discrezionale a un obbligo legale con responsabilità personale per la direzione. Anche il flusso dei pagamenti rientra nel quadro: il modo in cui gestite i dati delle carte di credito attraverso il vostro sistema di pagamento determina la quantità di dati utilizzabili che un aggressore può effettivamente sottrarre quando – non «se», ma «quando» – riuscirà a penetrare nel sistema.

Scrivo per Prostay, e il nostro team dedica molto tempo al confine tra i sistemi alberghieri che realizziamo e gli obblighi di sicurezza che i nostri clienti devono ora rispettare; pertanto, i modelli di minaccia, le scadenze normative e le priorità di controllo riportati di seguito provengono dal quadro normativo pubblicato della NIS2, dai dati sugli incidenti segnalati dalle aziende di sicurezza nel settore alberghiero e dalla realtà pratica di aiutare le strutture a riprendersi quando qualcosa va storto. Questo articolo è rivolto al direttore generale e al proprietario, non al tecnico della sicurezza. Spiega se la normativa NIS2 si applica alla vostra struttura, come avviene effettivamente una violazione in un hotel, i tempi di segnalazione da rispettare, le poche misure di controllo che riducono realmente il rischio e un piano di 30 giorni per passare da una situazione di vulnerabilità a una di sicurezza. Nulla di tutto ciò richiede una laurea in informatica. La maggior parte richiede semplicemente di decidere che questo è ora il vostro compito, perché, dal punto di vista legale e pratico, lo è.

Che cos’è effettivamente la NIS2 e se riguarda il vostro hotel

La NIS2 è la seconda versione della Direttiva UE sulla sicurezza delle reti e dell’informazione. La prima direttiva NIS (2016) riguardava una ristretta cerchia di operatori critici: energia, acqua, grandi infrastrutture digitali. La NIS2, che gli Stati membri erano tenuti a recepire nel diritto nazionale entro il 17 ottobre 2024, amplia notevolmente il campo di applicazione, innalza la soglia minima delle misure di sicurezza richieste, inasprisce gli obblighi di segnalazione degli incidenti e, cosa fondamentale, prevede sanzioni concrete e responsabilità personale dei dirigenti. Non si tratta di una legge specifica per il settore alberghiero, ed è proprio per questo che molti albergatori non si sono resi conto che potrebbe applicarsi anche a loro.

La sua applicabilità dipende da tre fattori: il settore di appartenenza, le dimensioni della struttura e il recepimento della normativa da parte del proprio paese. Gli alberghi non figurano nell’elenco principale dei settori “essenziali” come invece avvengono per l’energia e la sanità, pertanto un singolo hotel non è automaticamente un soggetto regolamentato nella maggior parte dei paesi. Ma i confini sono più sfumati di quanto suggerisca questa sintesi: le soglie dimensionali coinvolgono direttamente le strutture e i gruppi di maggiori dimensioni, mentre le disposizioni relative alla catena di approvvigionamento si estendono ben oltre l’ambito di applicazione formale. Il risultato è un panorama in cui alcuni hotel rientrano direttamente nell’ambito di applicazione, molti altri sono indirettamente vincolati tramite partner e quasi nessuno è realmente esente dall’aspettativa di fondo di gestire il rischio informatico.

Enti essenziali vs enti importanti e il criterio delle dimensioni

La NIS2 suddivide le organizzazioni soggette a regolamentazione in due livelli. Gli enti essenziali sono gli operatori con il più alto grado di criticità e sono sottoposti alla supervisione più rigorosa. Gli enti importanti costituiscono un gruppo più ampio che deve comunque adempiere agli obblighi di sicurezza e di segnalazione, ma è soggetto a una vigilanza meno rigorosa, in genere a seguito di un incidente piuttosto che in modo proattivo. Questa distinzione è rilevante soprattutto per quanto riguarda l’intensità della pressione esercitata dall’autorità di regolamentazione e l’entità delle sanzioni massime previste.

A ciò si aggiunge un filtro basato sulle dimensioni. Gli obblighi previsti dalla direttiva sono pensati per le organizzazioni di medie e grandi dimensioni, in linea di massima quelle con 50 o più dipendenti, oppure con un fatturato annuo e uno stato patrimoniale superiori a 10 milioni di euro, operanti nei settori contemplati. Un piccolo hotel sul mare con 18 dipendenti di solito non raggiunge tale soglia e non rientra direttamente nell’ambito di applicazione. Un hotel congressuale in città con 250 camere, o una società di gestione che amministra una dozzina di strutture, può facilmente superare la soglia e rientrare direttamente nell’ambito di applicazione. Il punto chiave per la pianificazione è che le dimensioni vengono valutate a livello di persona giuridica e, talvolta, a livello del gruppo più ampio; pertanto, una piccola struttura di proprietà di un operatore più grande potrebbe ereditare obblighi che non avrebbe se operasse da sola. Verificate la vostra posizione specifica con un consulente locale, poiché i dettagli del recepimento e l’esatta mappatura settoriale variano a seconda dello Stato membro.

La clausola sulla catena di approvvigionamento che coinvolge i piccoli hotel

Ecco la parte che coglie di sorpresa gli operatori indipendenti. La NIS2 rende la sicurezza della catena di approvvigionamento e dei fornitori un obbligo esplicito per i soggetti che rientrano nel campo di applicazione. Un gruppo alberghiero regolamentato, una piattaforma di viaggi, un acquirente di viaggi aziendali o una società di gestione deve garantire la sicurezza dei propri fornitori e partner, e il modo più semplice per adempiere a tale obbligo è quello di trasferire i requisiti a valle tramite contratto. Pertanto, un hotel indipendente da 40 camere che accetta clienti aziendali da una società regolamentata, opera sotto un marchio in franchising o si collega a una piattaforma regolamentata si vedrà sempre più spesso presentare un addendum sulla sicurezza: applicare l’autenticazione a più fattori (MFA), mantenere backup testati, segnalarci gli incidenti entro X ore, consentirci di effettuare un audit. Si rispettano i controlli previsti dalla NIS2 non perché ci sia stata una richiesta da parte di un’autorità di regolamentazione, ma perché perdere il contratto non è un’opzione.

Ecco perché «siamo troppo piccoli per la NIS2» è il modo sbagliato di pensare al 2026. La domanda realistica non è se la direttiva menzioni la vostra realtà; è quando i controlli vi riguarderanno, tramite designazione diretta, attraverso il vostro gruppo o tramite il contratto di un partner, e se preferite implementarli con calma adesso o affrettarvi sotto la pressione di una scadenza imposta da qualcun altro. Il resto di questo articolo parte dal presupposto che ne avrete bisogno, perché per la grande maggioranza degli operatori con una qualsiasi attività commerciale, sarà così.

La superficie di attacco di un hotel, mappata

Per difendere un hotel devi vederlo con gli occhi di un aggressore: come un insieme di porte, la maggior parte delle quali hai dimenticato di chiudere. La superficie di attacco è più ampia del PC della reception, e identificare ogni parte è il primo passo per chiuderla.

A diagram of a hotel's cyber attack surface showing entry points feeding toward the property management system at the centre: a phishing email arriving at the front-desk inbox, an exposed Remote Desktop and VPN login, a third-party vendor connection such as a channel manager or maintenance contractor, the guest Wi-Fi network, and unpatched devices like door-lock controllers and the point-of-sale terminal, with arrows converging on the PMS and the stored guest data and payment records behind it.
Ogni sistema connesso è una porta. Gli aggressori contano quelle che avete dimenticato di chiudere a chiave, non quelle che avete chiuso.

Il personale della reception. Il personale della reception è addestrato a fidarsi e ad aiutare. Spesso basta una telefonata convincente (“qui è il reparto IT della sede centrale, abbiamo bisogno che installiate un rapido aggiornamento”) o una fattura via e-mail ben congegnata. Il phishing e l’ingegneria sociale sono il punto di ingresso iniziale più comune in ogni settore, e la cultura dell’ospitalità, improntata alla disponibilità, peggiora la situazione.

Accesso remoto. Qualcuno deve accedere al PMS da fuori sede: un proprietario, un responsabile del turno di notte, un fornitore di software che offre assistenza. Troppo spesso quell’accesso è un semplice Desktop Remoto esposto direttamente a Internet, protetto da una sola password riutilizzata. È il punto debole sfruttato con maggiore certezza negli attacchi ransomware alle piccole imprese, punto e basta.

Connessioni di terze parti. Il vostro channel manager, il motore di prenotazione, il gateway di pagamento, il sistema di chiusura delle porte e gli appaltatori addetti alla manutenzione si collegano tutti al vostro ambiente. Ognuno di essi rappresenta un potenziale punto di accesso, e una violazione presso un fornitore può trasformarsi in una violazione ai vostri danni. Questo è il rischio della catena di fornitura su cui si concentra la direttiva NIS2, visto dal vostro punto di vista.

Reti ospiti e operative. Se il Wi-Fi per gli ospiti, i sistemi di prenotazione, i terminali di pagamento e i computer del back-office condividono tutti un’unica rete piana, allora il portatile compromesso di un ospite o un dispositivo infettato da malware nella hall può raggiungere il PMS. Le reti piane trasformano una piccola intrusione in una totale.

Dispositivi non aggiornati e dimenticati. Il controller della serratura che utilizza un firmware vecchio di dieci anni, il terminale POS che nessuno aggiorna, il vecchio PC nel back-office che utilizza ancora un sistema operativo per il quale non vengono più rilasciate patch di sicurezza. Gli aggressori cercano proprio questi dispositivi e li sfruttano per penetrare nel sistema. La superficie di attacco di un hotel non è un unico grande muro da difendere, ma è costituita da decine di piccoli muri, e all’aggressore basta che uno solo sia debole.

Come si svolge effettivamente una violazione in un hotel

Il ransomware non si attiva nell’istante stesso in cui qualcuno clicca su un link dannoso. Si sviluppa in fasi nell’arco di ore o giorni, e comprendere la sequenza permette di capire dove si ha ancora la possibilità di fermarlo.

Di solito inizia con l’accesso iniziale: credenziali ottenute tramite phishing, un account RDP esposto e violato provando password comuni, oppure un punto d’appoggio ereditato da un fornitore compromesso. A questo punto l’autore dell’attacco è all’interno con l’identità di un utente, spesso senza che nessuno se ne accorga. Seguono l’escalation e il movimento laterale: l’autore cerca un account amministratore, si sposta dal computer della reception verso i server e mappa le risorse disponibili. Questa è la fase silenziosa, che a volte dura giorni, ed è qui che un buon monitoraggio e la segmentazione della rete possono ancora intercettarlo e contenerlo.

Poi l’esfiltrazione: i moderni gruppi di ransomware rubano una copia dei dati degli ospiti prima ancora di crittografare qualsiasi cosa, perché i dati rubati costituiscono una leva anche se i backup sono perfetti. Questo è il passaggio alla cosiddetta doppia estorsione. Solo alla fine arrivano la crittografia e la richiesta di riscatto: file bloccati, il PMS inutilizzabile, una richiesta sullo schermo e una reception che improvvisamente non è più in grado di effettuare il check-in o il check-out di nessuno. Il motivo per cui questa sequenza è importante è che la parte più evidente e clamorosa (la schermata di blocco) è l’ultimo atto, non il primo. Quando la vedete, l’autore dell’attacco di solito è già presente nel vostro ambiente da un po’ di tempo e ha già preso ciò che voleva. Le difese che reagiscono solo alla crittografia reagiscono troppo tardi; le vittorie si ottengono prima, al momento dell’accesso e del movimento laterale.

L’impatto economico di un attacco ransomware a un hotel

Gli operatori si fissano sull’importo del riscatto, ma raramente questo rappresenta il costo maggiore. Se si sommano le conseguenze effettive di un incidente grave per un hotel, la cifra che conta è l’interruzione totale dell’attività, non la richiesta visualizzata sullo schermo.

Cominciamo dai tempi di inattività. Se il PMS viene crittografato, la reception torna a usare carta e penna, se possibile, il channel manager smette di sincronizzarsi, le OTA continuano a vendere camere che non è possibile visualizzare e nel giro di poche ore si verificano doppie prenotazioni e si devono far andare via gli ospiti. Un'interruzione di più giorni durante un periodo di punta può costare di più in termini di prenotazioni perse o gestite in modo errato rispetto a qualsiasi riscatto. Poi ci sono i costi di ripristino: specialisti nella risposta agli incidenti, indagini forensi, ricostruzione dei sistemi da backup puliti e straordinari del personale per gestire manualmente le operazioni nel frattempo. Poi c’è l’aspetto normativo e legale: le sanzioni NIS2 per le entità interessate sono elevate (per le entità essenziali, le multe possono raggiungere i 10 milioni di euro o il 2% del fatturato annuo globale, a seconda di quale sia il valore più alto), l’esposizione al GDPR in caso di violazione dei dati degli ospiti e il costo della notifica e dell’assistenza agli ospiti coinvolti.

E poi il costo che nessun foglio di calcolo riesce a quantificare con precisione: la reputazione. «Questo hotel ha divulgato i dati del mio passaporto e della mia carta di credito» è il tipo di storia che perseguita una struttura nelle recensioni e sulla stampa per anni. Pagare il riscatto non risolve nulla in modo affidabile: gli strumenti di decrittazione forniti dai criminali sono spesso lenti o incompleti, il pagamento ti contrassegna come bersaglio facile per il prossimo gruppo di hacker e non risolve in alcun modo il problema dei dati già rubati. Le ragioni economiche a favore della prevenzione sono schiaccianti proprio perché le conseguenze negative sono molto più gravi e complesse di quanto suggerisca la cifra del riscatto riportata dai media. Spendere qualche migliaio per l’autenticazione a più fattori (MFA), i backup e la segmentazione è un’assicurazione economica contro un mese nero da sei o sette cifre.

I tempi di segnalazione: 24 ore, 72 ore, un mese

Per le entità interessate, la direttiva NIS2 non si limita a richiedere di garantire la sicurezza, ma impone anche la rapidità con cui si devono informare le autorità in caso di violazione. I tempi sono più stretti di quanto la maggior parte degli operatori supponga e decorrono dal momento in cui qualcuno all’interno della struttura si rende conto che è in corso un incidente significativo.

A horizontal incident-reporting timeline for NIS2 starting at the moment a hotel becomes aware of a significant incident: an early warning to the national authority or CSIRT due within 24 hours, a fuller incident notification within 72 hours, and a final report within one month, shown alongside a parallel track noting the GDPR 72-hour personal-data breach notification that runs at the same time.
Il conto alla rovescia inizia dal momento in cui si viene a conoscenza dell’incidente, non dalla sua risoluzione. Ore, non giorni, per la prima segnalazione.

Entro 24 ore: l’allerta precoce. Una volta venuti a conoscenza di un incidente significativo, è necessario fornire all’autorità nazionale o al CSIRT una rapida segnalazione di allerta precoce, anche prima di comprendere appieno cosa sia accaduto. Ciò che conta è la rapidità, non la completezza; l’autorità di regolamentazione vuole sapere tempestivamente che è in corso qualcosa di grave.

Entro 72 ore: la notifica dell’incidente. Segue un rapporto più completo, con una valutazione iniziale della gravità, dell’impatto e di eventuali indicatori di compromissione. A questo punto dovreste aver attivato la vostra squadra di risposta agli incidenti e avere un quadro operativo della portata dell’evento.

Entro un mese: il rapporto finale. Una descrizione dettagliata dell’incidente, della causa principale, delle misure adottate e dell’impatto. Questo chiude il ciclo con l’autorità di regolamentazione. Parallelamente, se sono stati esposti dati personali (e in una violazione che coinvolge un hotel è quasi sempre così), si applica anche il termine di 72 ore previsto dal GDPR per notificare l’autorità garante della protezione dei dati, e potrebbe essere necessario informare direttamente gli ospiti interessati. Si tratta di obblighi distinti nei confronti di autorità diverse, che si sovrappongono nel tempo: proprio per questo motivo non è possibile stabilire chi debba contattare chi durante lo svolgimento dell’incidente stesso.

La lezione operativa è chiara: le decisioni relative alla segnalazione devono essere prese in anticipo. Chi segnala un incidente, chi contatta l’autorità, quale autorità, con quali informazioni, a quale numero: tutto questo deve essere definito in un piano scritto che si possa attuare alle 3 del mattino senza avere un avvocato tra le chiamate rapide. Una struttura che non ha mai pensato a questo supererà il limite delle 24 ore semplicemente perché nessuno sapeva che fosse proprio suo compito effettuare la chiamata.

Responsabilità della direzione e perché il direttore generale non può delegare questo compito

Il cambiamento nella NIS2 che dovrebbe preoccupare maggiormente i proprietari e i direttori generali non è affatto di natura tecnica. Si tratta del fatto che la direttiva attribuisce la governance della sicurezza informatica direttamente all’organo di gestione e rende tale responsabilità personale. La direzione deve approvare le misure di gestione dei rischi informatici dell’organizzazione, supervisionarne l’attuazione e può essere ritenuta responsabile in caso di inadempienza. La direttiva prevede inoltre che i dirigenti seguano una formazione sulla sicurezza informatica, in modo da poter comprendere effettivamente i rischi che stanno approvando.

In parole povere: un direttore generale non può più dire «questo è compito del reparto IT» e considerare la questione chiusa. È possibile delegare il lavoro a un team interno o a un fornitore esterno, ma la responsabilità di garantire che venga svolto, e le conseguenze in caso contrario, ricadono su di voi. I recepimenti nazionali rafforzano questo principio con la minaccia di multe significative e, in alcuni casi, la possibilità di escludere temporaneamente le persone da ruoli dirigenziali in caso di gravi inadempienze. Si tratta di una scelta progettuale deliberata da parte dell’UE: l’esperienza ha dimostrato che alla sicurezza venivano destinate risorse insufficienti fintanto che rimaneva due livelli al di sotto di chi gestiva il bilancio, quindi la direttiva NIS2 l’ha portata in cima all’organigramma.

Per un hotel indipendente non si tratta tanto di paura quanto piuttosto di assunzione di responsabilità. Qualcuno con autorità deve assumersi la responsabilità del rischio informatico così come si assume quella della sicurezza antincendio o dell’igiene alimentare: come una responsabilità ben definita, dotata di un budget, di un piano e di revisioni periodiche, non come un ripensamento che emerge solo quando qualcosa va storto. La buona notizia è che i controlli che soddisfano questo obbligo sono per lo più banali e alla portata di tutti, ed è proprio questo l’argomento del resto di questo articolo. L’obbligo è serio; adempiervi non è affatto complicato.

I controlli che fanno davvero la differenza

Il marketing della sicurezza informatica vuole vendervi una valanga di acronimi. La verità è che un numero esiguo di misure di controllo poco appariscenti blocca la grande maggioranza degli attacchi reali agli hotel, e queste sono ben più importanti di qualsiasi singolo prodotto. Ecco quelle a cui vale la pena dedicare per prime la vostra attenzione e il vostro budget.

Identità, MFA e il problema dell’RDP

La maggior parte delle violazioni negli hotel non è ingegnosa; si tratta semplicemente di una password valida utilizzata in un contesto in cui non avrebbe dovuto funzionare. Due misure risolvono la maggior parte di questi casi. Innanzitutto, applicate l’autenticazione a più fattori (MFA) su ogni account rilevante: accessi al PMS, e-mail, accesso remoto, account amministrativi, ecc. Con l’MFA, una password rubata da sola è inutile. In secondo luogo, eliminate l’accesso a Remote Desktop dalla rete Internet aperta. Se il personale o i fornitori necessitano di accesso remoto, fatelo passare attraverso una VPN o un gateway zero-trust con MFA, e non esponete mai direttamente l’RDP. Abbinate a ciò alcune buone pratiche di base relative alle password (niente accessi condivisi, niente "Welcome2024" sull’account amministratore, un gestore di password in modo che le persone possano disporre di password forti e uniche) e avrete chiuso la porta attraverso cui passano gli attacchi più comuni. Questo è l’intervento di sicurezza con il massimo ritorno che un hotel possa intraprendere, e costa pochissimo.

Backup da cui è effettivamente possibile ripristinare i dati

I backup sono ciò che determina se un attacco ransomware si traduce in una settimana difficile o nella fine dell’attività. Ma il dettaglio che spesso sfugge è che il backup deve essere sia offline o immutabile, sia testato. Gli aggressori cercano specificatamente e crittografano i backup collegati prima di attivare il ransomware, quindi un’unità di backup collegata in modo permanente al server non offre alcuna protezione. Servono copie che l’autore dell’attacco non possa raggiungere: offline o in un archivio cloud immutabile che non possa essere alterato o cancellato entro un periodo di conservazione prestabilito. Inoltre, è necessario testare il ripristino a intervalli regolari, perché il momento peggiore per scoprire che i backup sono danneggiati o incompleti è proprio la mattina in cui se ne ha effettivamente bisogno. Un backup da cui non si è mai effettuato un ripristino è una speranza, non un piano.

Segmentazione del PMS, del POS e del Wi-Fi per gli ospiti

La segmentazione della rete è il controllo che limita la portata di diffusione di un'intrusione. Il principio è semplice: ciò che non deve comunicare tra di sé non dovrebbe trovarsi sulla stessa rete. Il Wi-Fi per gli ospiti deve essere isolato da tutto ciò che è operativo, in modo che il portatile infetto di un ospite non possa raggiungere il PMS. I terminali di pagamento devono trovarsi in un proprio segmento. I sistemi di back-office e PMS dovrebbero essere separati dalla navigazione generale del personale. Quando il computer della reception viene compromesso, è la segmentazione a impedire all’autore dell’attacco di raggiungere i server e i sistemi di pagamento in un solo salto. Trasforma una potenziale violazione totale in una contenuta, ed è soprattutto una questione di configurare correttamente le apparecchiature già in vostro possesso piuttosto che acquistare qualcosa di nuovo.

Dati di pagamento, tokenizzazione e riduzione del raggio d’azione

I dati più pericolosi da conservare sono quelli che non è necessario conservare. I numeri di carta grezzi ne sono l’esempio più evidente. Se i vostri sistemi memorizzano o gestiscono, anche solo per un breve periodo, i dati completi delle carte, una violazione li espone e la vostra responsabilità è grave. La soluzione è la tokenizzazione: il vostro gestore dei pagamenti conserva i dati reali della carta nel proprio archivio protetto e fornisce al vostro PMS un token privo di significato che rappresenta la carta senza essere utilizzabile in caso di furto. Se eseguita correttamente, il numero sensibile della carta non risiede mai sulla vostra rete.

Questa è la logica di sicurezza alla base dello standard PCI DSS, ed è il motivo per cui una moderna infrastruttura di pagamento basata sulla tokenizzazione rappresenta un controllo di sicurezza tanto quanto una comodità per i pagamenti. Quando un malintenzionato penetra nel sistema alla ricerca di dati delle carte da rubare, non trova nulla di utilizzabile da sottrarre. Quella singola scelta architettonica elimina completamente dal vostro profilo di rischio la categoria di dati più appetibile e soggetta a regolamentazione più rigorosa. Questo non vi rende invincibili, poiché il resto dei dati degli ospiti (passaporti, indirizzi, cronologia dei soggiorni) rimane comunque prezioso e deve essere protetto, ma elimina il "tesoro più prezioso" dal quadro. Qualsiasi hotel che permetta ancora che i numeri completi delle carte di credito entrino in contatto con il proprio PMS o rimangano in un foglio di calcolo dovrebbe considerare la risoluzione di questo problema una priorità assoluta, non una voce da inserire in un piano a lungo termine.

Fornitori, Channel Manager e rischi legati a terze parti

La vostra sicurezza è forte solo quanto il fornitore più debole collegato ai vostri sistemi, e un hotel ne ha molti. Il channel manager, il motore di prenotazione, il gateway di pagamento, la piattaforma per le serrature, gli strumenti di marketing, l’azienda di supporto IT: ciascuno di essi detiene accessi o dati, e una violazione presso uno qualsiasi di essi può trasformarsi in una violazione ai vostri danni. La NIS2 formalizza questo aspetto come un obbligo di gestione del rischio dei fornitori, ma si tratta semplicemente di buon senso, indipendentemente dal fatto che la direttiva menzioni o meno la vostra struttura.

Gestirlo non richiede un reparto acquisti. Richiede di porre ai vostri fornitori chiave una serie di domande brevi e mirate e di agire in base alle risposte. Dove sono archiviati i nostri dati e sono crittografati? Applicate l’autenticazione a più fattori (MFA) per l’accesso al nostro ambiente? Avete subito una violazione e come l’avete gestita? Quali certificazioni o valutazioni di sicurezza indipendenti potete mostrarmi? Con quale rapidità ci avviserete in caso di compromissione? Un fornitore serio risponde prontamente a queste domande e potrebbe fornire spontaneamente una panoramica sulla sicurezza o una certificazione riconosciuta. Un fornitore che assume un atteggiamento difensivo o vago vi sta comunicando qualcosa di importante. Privilegiate i partner che considerano la sicurezza una caratteristica di cui andare fieri piuttosto che una questione che li infastidisce, perché in un ambiente interconnesso la loro igiene diventa il vostro rischio.

Redigere un piano di risposta agli incidenti che un revisore notturno possa attuare

L’unico documento che distingue un incidente gestito da uno caotico è un piano di risposta scritto che un membro del personale non tecnico possa seguire nel momento peggiore possibile. Gli attacchi non rispettano l’orario di lavoro; spesso colpiscono di notte e nei giorni festivi proprio perché il personale ridotto al minimo è meno preparato. Pertanto, il piano deve essere utilizzabile da chiunque sia effettivamente in turno, non solo dal tecnico IT che sta dormendo.

Siate concreti. Il piano dovrebbe indicare i primi tre passaggi che chiunque può compiere: scollegare le macchine colpite dalla rete (staccare il cavo, disattivare il Wi-Fi) per fermare la diffusione senza spegnerle, cosa che potrebbe distruggere le prove forensi; chiamare il referente designato per gli incidenti; e avviare un semplice registro scritto di ciò che è stato osservato e quando. Dovrebbe elencare chi chiamare, con nomi e numeri di telefono reali: il responsabile interno, il fornitore IT o il servizio di risposta agli incidenti, la hotline dell’assicuratore informatico e l’autorità competente per la denuncia legale. Dovrebbe ricordare al personale cosa non fare: non pagare nulla, non negoziare, non cancellare i dati dai dispositivi, non parlare con la stampa. E dovrebbe coprire la continuità operativa: come effettuare manualmente il check-in e il check-out degli ospiti, come incassare i pagamenti se il sistema è fuori uso, come impedire alle OTA di vendere in eccesso camere che non sono più disponibili.

Poi fate ciò che quasi nessuno fa: provatelo. Un’esercitazione teorica di 30 minuti in cui guidate il team della reception attraverso lo scenario «il PMS è bloccato e c’è una richiesta di riscatto, cosa fare adesso?» fa emergere le lacune quando sono ancora facili da colmare. Un piano che non è mai stato letto ad alta voce è un piano che verrà ritrovato, non letto, proprio durante l’evento per cui è stato scritto. Stampatelo. Mettetene una copia alla reception. Assicuratevi che il personale notturno sappia che esiste e dove si trova.

Un piano di preparazione informatica in 30 giorni

Un mese è sufficiente per far passare una tipica struttura indipendente da una situazione di vulnerabilità a una di effettiva difesa, senza consulenti e senza un budget elevato. Un solo manager con l’autorità necessaria può guidarlo, coinvolgendo il fornitore IT per le fasi tecniche.

Giorni da 1 a 5: fate un inventario di ciò che avete. Elencate ogni sistema che contiene dati degli ospiti o gestisce i pagamenti, ogni account con accesso remoto o amministrativo e ogni fornitore con una connessione in entrata. Non potete proteggere ciò che non avete inventariato, e questo elenco costituisce anche la base della valutazione dei rischi prevista dalla normativa NIS2. Prendete nota delle macchine su cui è in esecuzione software che non riceve più aggiornamenti di sicurezza.

Giorni da 6 a 12: chiudete le porte più vulnerabili. Attivate l’autenticazione a più fattori (MFA) ovunque sia disponibile, a partire dall’e-mail, dall’accesso remoto e dal PMS. Eliminate l’accesso RDP dalla rete Internet pubblica. Eliminate gli accessi condivisi e reimpostate le password amministrative deboli. Questa settimana da sola elimina le vulnerabilità più sfruttate, e si tratta principalmente di configurazione, non di acquisti.

Giorni dal 13 al 18: sistemare i backup. Verificare di disporre di backup del PMS e dei sistemi critici che siano offline o immutabili, quindi testare effettivamente un ripristino. Se l’unico backup è un’unità collegata al server, risolvere prima questo problema. Documentare i passaggi di ripristino in modo che possano essere seguiti anche in situazioni di stress.

Giorni dal 19 al 23: segmentare e applicare le patch. Separare la rete Wi-Fi per gli ospiti dai sistemi operativi, collocare i pagamenti in un segmento dedicato e applicare gli aggiornamenti di sicurezza in sospeso ai sistemi che possono riceverli. Pianificare la sostituzione di qualsiasi sistema che utilizzi software a fine ciclo di vita per cui non è possibile applicare patch.

Giorni dal 24 al 28: redigere il piano di gestione degli incidenti e verificare i fornitori. Redigere una bozza del piano di risposta di una pagina con nomi e numeri reali e inviare ai fornitori critici il breve questionario sulla sicurezza. Valutare se un’assicurazione contro i rischi informatici sia opportuna in base alle dimensioni dell’azienda e al livello di rischio.

Giorni dal 29 al 30: assegnare le responsabilità e fare delle simulazioni. Nominare la persona responsabile del rischio informatico, inserire nel calendario una revisione trimestrale ed eseguire un’esercitazione teorica di 30 minuti con il team della reception. Alla fine del mese non sarete invulnerabili, nessuno lo è, ma avrete chiuso le porte da cui passano gli attacchi reali e avrete un piano per il giorno in cui uno di essi riuscirà a sfondarle. Questa è la definizione realistica di “completato”.

Il ruolo di Prostay, in breve e con sincerità

Scrivo per Prostay, quindi ecco la versione schietta. Un sistema di gestione alberghiera (PMS) è al centro di questo quadro perché contiene i dati degli ospiti che gli hacker cercano ed è il sistema il cui malfunzionamento blocca l’attività. Quindi la posizione di sicurezza del vostro fornitore di PMS fa parte del vostro rischio, che lo consideriate in questo modo o meno. Prostay opera come piattaforma cloud con i controlli che ci si aspetterebbe da un fornitore serio: crittografia dei dati in transito e inattivi, autenticazione a più fattori (MFA) all’accesso, pagamenti tokenizzati in modo che i dati grezzi delle carte di credito non entrino mai nell’ambiente della struttura, infrastruttura sottoposta a audit e backup gestiti, così che gran parte dell’onere sopra descritto sia sostenuto dalla piattaforma anziché ricadere sulla reception. Nulla di tutto ciò è esclusivo di Prostay; fornitori di PMS cloud affidabili come Mews e Cloudbeds assumono impegni simili, e dovreste porre a tutti loro le stesse domande difficili riportate nella sezione dedicata ai fornitori qui sopra.

L’argomento più valido a favore di una moderna piattaforma cloud rispetto a un server on-premise di vecchia generazione nel back office è che essa trasferisce gran parte del lavoro più impegnativo in materia di sicurezza (applicazione di patch, rafforzamento dell’infrastruttura, backup, gestione dei dati di pagamento) a un fornitore che se ne occupa a tempo pieno, cosa che un hotel da 40 camere senza reparto IT non può fare bene da solo. Ciò non cancella i vostri obblighi: siete comunque responsabili dell’autenticazione a più fattori (MFA) sui vostri account, del piano di gestione degli incidenti, della formazione del personale e della gestione dei fornitori. Tuttavia, riduce l’area che dovete difendere personalmente. Se volete vedere come il PMS Prostay gestisce i dati degli ospiti e i pagamenti, trovate qui i dettagli del prodotto; se invece preferite che il nostro team esamini la vostra attuale infrastruttura alla luce della checklist di preparazione sopra riportata, prenotate una demo e affronteremo le questioni concrete, anziché vendervi un aggiornamento dettato dalla paura.

Domande frequenti

Le cinque domande più frequenti poste dagli albergatori indipendenti in merito alla sicurezza informatica e alla direttiva NIS2, con risposte basate sulla direttiva stessa e su come si svolgono effettivamente gli attacchi, anziché sulle campagne allarmistiche dei fornitori.

FAQ

Domande frequenti

  • Un piccolo hotel indipendente rientra davvero nell’ambito di applicazione del NIS2?
    Forse direttamente, ma molto probabilmente indirettamente. La NIS2 stabilisce una soglia minima basata sulle dimensioni: gli obblighi ricadono direttamente sulle organizzazioni di medie e grandi dimensioni, in linea di massima quelle con almeno 50 dipendenti o con un fatturato annuo e un bilancio superiori a 10 milioni di euro, nei settori elencati dalla direttiva. Molti hotel indipendenti si collocano al di sotto di tale soglia e non sono direttamente interessati. Tuttavia, due fattori coinvolgono comunque le strutture più piccole. In primo luogo, gli Stati membri hanno recepito la NIS2 nel diritto nazionale secondo le proprie tempistiche e alcuni ne hanno ampliato l’ambito di applicazione rispetto ai requisiti minimi dell’UE, pertanto la soglia esatta dipende dal Paese in cui si opera. In secondo luogo, e cosa ancora più importante nella pratica, la NIS2 rende la sicurezza della catena di fornitura un obbligo esplicito per le entità di maggiori dimensioni che rientrano nel campo di applicazione. Se il vostro hotel fa parte di un gruppo, di un franchising, di una società di gestione, o se vende tramite partner a loro volta soggetti a regolamentazione, questi vi imporranno per contratto i requisiti di sicurezza. Pertanto, anche una struttura indipendente da 30 camere spesso finisce per adottare controlli in linea con la NIS2 perché richiesto da un partner, non perché un’autorità di regolamentazione abbia indicato direttamente la struttura. L’ipotesi di pianificazione più realistica per il 2026 è che tali controlli vi saranno imposti in un modo o nell’altro.
  • Qual è la misura più efficace che un hotel possa adottare per ridurre il rischio di ransomware?
    Applicare l’autenticazione a più fattori (MFA) a ogni accesso remoto e amministrativo, quindi disabilitare l’accesso diretto a Internet tramite Desktop remoto (RDP). La stragrande maggioranza degli incidenti di ransomware negli hotel ha origine da una password rubata o indovinata e riutilizzata su un punto di accesso remoto esposto, spesso un RDP lasciato aperto per consentire a un fornitore o a un responsabile fuori sede di accedere al PMS. L’aggiunta dell’MFA significa che una password rubata da sola non è sufficiente, mentre proteggere l’accesso remoto tramite una VPN o un gateway zero-trust elimina completamente questa porta aperta. Non è una misura affascinante né costosa, ma se dovete fare una sola cosa in questo trimestre, fate questa. La seconda misura più efficace è quella di eseguire backup offline e testati, perché determinano se un attacco si tradurrà in una settimana difficile o nella chiusura dell’attività; tuttavia, l’autenticazione a più fattori (MFA) unita alla chiusura dell’accesso RDP è ciò che impedisce fin dall’inizio il successo dell’attacco più comune.
  • Se veniamo colpiti, entro quanto tempo siamo tenuti per legge a segnalarlo?
    Ai sensi del NIS2, i tempi sono stretti per i soggetti interessati. È necessario inviare un preavviso all’autorità nazionale o al CSIRT entro 24 ore dal momento in cui si viene a conoscenza di un incidente significativo, una notifica più completa dell’incidente entro 72 ore e una relazione finale entro un mese. Inoltre, in caso di violazione dei dati personali, si applica anche l’obbligo di notifica entro 72 ore previsto dal GDPR all’autorità garante della protezione dei dati, e potrebbe essere necessario informare gli ospiti interessati. Questi obblighi sono paralleli, non si sostituiscono a vicenda, e la notifica preventiva entro 24 ore prevista dalla NIS2 è più rapida di quanto molti operatori si aspettino. La conseguenza pratica: la decisione su chi debba contattare l’autorità di regolamentazione, e quando, non può essere improvvisata alle 3 del mattino durante l’incidente. Deve essere prevista in anticipo in un piano di risposta agli incidenti, con nomi e numeri di telefono, poiché il termine per la segnalazione decorre dal momento in cui qualcuno presso la struttura si rende conto che c’è qualcosa di gravemente sbagliato.
  • Il fatto di accettare pagamenti con carta tramite un gestore conforme alle normative esclude la nostra responsabilità in caso di violazione?
    Riduce significativamente la tua esposizione al rischio, ma non elimina la tua responsabilità. Se la vostra configurazione di pagamento tokenizza i dati della carta in modo che il numero della carta in chiaro non finisca mai nel vostro PMS o sulla vostra rete (il processore lo conserva, voi conservate un token privo di significato), allora una violazione dei vostri sistemi non espone dati della carta utilizzabili, il che è esattamente lo scopo della tokenizzazione e l’obiettivo alla base dello standard PCI DSS. Ciò riduce drasticamente l’entità del danno. Tuttavia, rimani comunque il titolare del trattamento per il resto dei dati relativi agli ospiti: nomi, indirizzi, scansioni di passaporti e documenti d’identità, dati relativi ai programmi fedeltà, cronologia dei soggiorni e dati di categorie speciali come le note relative all’accessibilità o alle esigenze alimentari. Un gruppo di autori di ransomware che non riesce a rubare i numeri delle carte di credito sarà ben felice di rubare e ricattarvi utilizzando invece quei dati personali. Pertanto, i pagamenti conformi e tokenizzati sono essenziali e rimuovono i dati più pericolosi dalla vostra rete, ma costituiscono solo un livello di protezione, non uno scudo contro le responsabilità per l’intera scheda dell’ospite.
  • Abbiamo affidato i servizi IT a una piccola azienda locale. La sicurezza informatica è ora una loro responsabilità?
    No. È possibile esternalizzare il lavoro, ma non la responsabilità, e la NIS2 specifica chiaramente che la governance e la gestione dei rischi sono di competenza della direzione dell’entità. Ai sensi della direttiva, gli organi direttivi devono approvare le misure relative ai rischi di sicurezza informatica e possono essere ritenuti personalmente responsabili in caso di inadempienze; inoltre, sono tenuti a seguire corsi di formazione. Un fornitore IT competente è parte della soluzione, ma è comunque necessario sapere cosa gli si sta pagando per proteggere, verificare che i backup siano testati e conservati offline, assicurarsi che l’autenticazione a più fattori (MFA) sia applicata e disporre di un piano di risposta agli incidenti che definisca cosa deve fare il fornitore e cosa deve fare l’hotel quando si verifica un attacco. La situazione peggiore in cui ci si possa trovare è scoprire, durante un incidente, che tutti davano per scontato che la responsabilità della risposta ricadesse su qualcun altro. Considerate la vostra azienda IT come un partner da gestire attivamente sulla base di una checklist, non come una casella da spuntare.
Continua a leggere

Prova Prostay

Gestisci il tuo hotel sulla piattaforma di cui scriviamo.

Porta i tuoi dati e le abitudini del tuo team. Ti mostreremo una configurazione Prostay equivalente sui tuoi ultimi 30 giorni.

A proposito di questo articolo

Categoria: Hotel Technology & Innovation. Pubblicato il 19 giu 2026 da Mika Takahashi.