Nel 2026 il Garante per la protezione dei dati personali ha sanzionato Dedalus Italia S.p.A. per un’anomalia del software WHR-Time che, all’interno del portale del dipendente, ha reso visibili a lavoratori e consulenti di ciascuna azienda le richieste attive di altri colleghi relative ad assenze, timbrature e richieste giornaliere.
Non è un incidente tecnico da archiviare con la formula “era solo un bug”.
Il caso è utile perché colpisce un’illusione diffusa in chi progetta o usa portali HR: l’idea che i dati su presenze e assenze siano solo operativi, quindi meno delicati. Quando un portale mostra a soggetti non autorizzati causali di assenza e richieste che possono rivelare dati particolari, il problema diventa di architettura del permesso, sicurezza applicativa, visibilità interna e governo del processo.
Aggiornamento al 24 aprile 2026 con taglio operativo. Non sostituisce la valutazione del legale privacy o del consulente sul caso concreto.
| Aspetto | Sintesi operativa |
|---|---|
| Cosa è successo | Un’anomalia di WHR-Time ha reso visibili nel portale dipendente le richieste attive di altri colleghi in 11 aziende sanitarie e ospedaliere dell’Emilia-Romagna. |
| Perché conta | Non parliamo di un semplice disservizio, ma di un difetto di sicurezza che ha esposto dati su presenze e assenze, comprese causali potenzialmente collegate alla salute. |
| Cosa controllare subito | Profili autorizzativi, test sugli aggiornamenti, tracciamento accessi, gestione delle causali e separazione tra dati visibili al lavoratore, al responsabile e agli operatori di supporto. |
| Cosa evitare | Trattare il portale dipendente come un’area “a bassa sensibilità” solo perché parla di richieste interne del personale. |
Cosa è successo davvero
Il provvedimento del Garante del 26 febbraio 2026 nasce dalle notifiche di violazione presentate da 11 aziende sanitarie e ospedaliere della Regione Emilia-Romagna. Al centro del caso c’è l’applicativo WHR-Time, inserito nel portale del dipendente e usato per gestire richieste del personale.
| Momento | Evento | Impatto |
|---|---|---|
| 4:54 | Installazione di un aggiornamento software. | La modifica introduce un’anomalia nel sistema. |
| 7:32 | Le prime segnalazioni vengono prese in carico da Dedalus. | Il problema viene rilevato nella finestra operativa del mattino. |
| 9:33 | Installazione della correzione. | Il fornitore interviene sul comportamento anomalo. |
| 9:54 | Risoluzione definitiva del problema. | La finestra temporale resta limitata, ma l’esposizione si è già verificata. |
| Provvedimento 26 febbraio 2026 | Il Garante dichiara illecito il trattamento effettuato da Dedalus Italia come responsabile del trattamento. | Violazione dell’art. 32 GDPR e sanzione amministrativa di 32.000 euro. |
Per alcune ore, il personale di ciascuna azienda ha potuto vedere richieste attive di altri colleghi della stessa azienda. Il punto critico non era solo sapere che un collega fosse assente o avesse una richiesta aperta: alcune informazioni includevano causali di assenza.
| Tipo richiesta | Dato visibile | Rischio |
|---|---|---|
| Richieste di assenza | Causale e stato della richiesta. | Possibile esposizione di informazioni personali o collegate alla salute. |
| Richieste di timbratura | Correzioni o eventi legati alla presenza. | Visibilità non necessaria su comportamento e gestione oraria di altri lavoratori. |
| Richieste giornaliere | Richieste operative del singolo dipendente. | Allargamento della visibilità interna oltre il ruolo autorizzato. |
| Permessi ex legge 104/1992 | Informazioni riferibili al dipendente o a familiari, inclusi soggetti vulnerabili. | Possibile trattamento di categorie particolari di dati personali. |
C’è un dettaglio che peggiora il quadro: non è stato possibile ricostruire il numero esatto degli utenti che avevano effettivamente visualizzato quei dati. L’applicativo non prevedeva un tracciamento esplicito di chi e quanti utenti avessero aperto le richieste di altre persone.
Perché riguarda anche chi non è in sanità
L’errore sarebbe liquidare il caso con “lì c’erano dati sanitari e aziende sanitarie”. Il punto più utile del provvedimento è un altro: i dati di workforce management non sono automaticamente dati banali.
Un sistema di richieste del personale può sembrare innocuo dalla dashboard di prodotto. Poi basta una causale, una nota, una tipologia di permesso o una combinazione di campi e il dato cambia peso.
| Dove passa il dato | Perché può diventare delicato | Domanda da farsi |
|---|---|---|
| Assenze per malattia | Possono rivelare informazioni sulla salute o su condizioni personali. | La causale è visibile solo a chi deve gestirla? |
| Permessi ex legge 104 | Possono riguardare il dipendente o familiari vulnerabili. | Stai mostrando il minimo necessario per approvare o pianificare? |
| Richieste con note libere | Possono contenere dettagli personali non necessari. | Il campo serve davvero o sta raccogliendo contesto in eccesso? |
| Metadati organizzativi | Combinati tra loro possono ricostruire vicende individuali. | Chi può vedere lo storico e per quanto tempo? |
Questo riguarda chi usa o vende software per presenze, ferie e permessi, workflow HR, portali dipendente, app team, richieste, turni e sostituzioni. La lezione operativa è netta: non basta dire “mostro solo richieste del personale”. Devi sapere chi vede cosa, in quale ruolo, dopo quale filtro, con quale log e cosa succede se un aggiornamento elimina una condizione di segregazione.
I 5 errori operativi che il caso mette a nudo
| Errore | Perché pesa | Controllo da fare |
|---|---|---|
| Trattare presenze e assenze come dati a bassa sensibilità | La causale di assenza può rivelare molto più del semplice stato “assente”. | Classifica causali, note e richieste in base al rischio reale, non alla comodità operativa. |
| Fare aggiornamenti senza test sui permessi reali | Nel caso concreto l’anomalia nasce da una modifica che ha inciso sul filtro autorizzativo. | Testa ogni rilascio anche su lavoratore, responsabile, collaboratori, supporto e altri profili. |
| Non sapere chi ha visto cosa | Senza log utili non misuri impatto, risposta all’incidente e perimetro dell’esposizione. | Traccia le visualizzazioni rilevanti e separa accesso tecnico, accesso operativo e consultazione. |
| Pensare che la visibilità interna sia un danno minore | Il dato resta esposto a soggetti non autorizzati, anche se non esce dall’organizzazione. | Riduci la platea a chi deve davvero agire sul dato. |
| Disegnare workflow troppo ricchi per troppi occhi | Più campi, note e metadati mostri, più un filtro saltato fa danni. | Mostra il minimo necessario al ruolo giusto, nel momento giusto. |
Quando il rischio diventa più serio
Ci sono situazioni in cui un incidente come questo diventa ancora più difficile da difendere. Non basta dire che la finestra è durata poco se il sistema ha permesso una visibilità non autorizzata su dati sensibili o difficili da ricostruire.
| Scenario | Perché aumenta il rischio | Verifica |
|---|---|---|
| Causali di assenza troppo specifiche | Possono esporre salute, familiari o condizioni personali. | Riduci le causali visibili e usa livelli di dettaglio diversi per ruoli diversi. |
| Ruoli applicativi larghi o confusi | Troppe persone vedono dati che non servono al loro compito. | Mappa ruoli, permessi e viste effettive, non solo profili nominali. |
| Richieste con dati non necessari | Ogni campo inutile diventa materiale esposto in caso di errore. | Elimina campi liberi o dettagli che non servono alla decisione. |
| Aggiornamenti testati solo sul flusso funzionale | La funzione può funzionare mentre la segregazione dati si rompe. | Aggiungi test autorizzativi prima di rilasciare modifiche HR. |
| Log insufficienti | Non ricostruisci chi ha visualizzato cosa. | Registra gli accessi rilevanti in modo utile per incident response e audit. |
| Molti lavoratori, sedi o enti | L’impatto potenziale cresce e diventa più difficile da delimitare. | Verifica separazione tra organizzazioni, sedi, reparti e aziende. |
| Contesti sensibili | Sanità, scuola, PA e ambienti simili amplificano il peso dei dati. | Applica minimizzazione e accessi restrittivi già in fase di design. |
Checklist pratica 2026 per portali dipendente, assenze e richieste
Prima di dire che il tuo portale HR è sotto controllo, verifica almeno questi punti.
| Controllo | Domanda pratica | Esito atteso |
|---|---|---|
| Causali minimizzate | Le causali di assenza visibili ai diversi ruoli sono davvero ridotte al necessario? | Ogni ruolo vede solo il livello di dettaglio che serve al proprio compito. |
| Test autorizzativi | I test sugli aggiornamenti coprono anche i profili reali? | Un rilascio non passa se rompe vista lavoratore, responsabile, supporto o tecnico. |
| Viste separate | Sai distinguere vista lavoratore, vista responsabile e vista supporto? | Le logiche non si sovrappongono e non creano scorciatoie di accesso. |
| Log utili | Hai un tracciamento affidabile delle visualizzazioni rilevanti? | In caso di incidente puoi stimare perimetro, soggetti e dato esposto. |
| Campi e note ridotti | Le richieste includono dettagli che potresti togliere? | Ogni informazione visibile ha una finalità chiara. |
| Incident response | Hai procedure chiare per gestire violazioni e supportare i titolari del trattamento? | Fix tecnica, comunicazioni e analisi impatto non dipendono dall’improvvisazione. |
| Dati particolari indiretti | Hai mappato workflow che possono rivelare dati particolari anche senza diagnosi esplicite? | Legge 104, malattia e assenze particolari sono trattate con perimetro dedicato. |
Se oggi richieste, assenze e coordinamento passano ancora da strumenti dispersi, può essere utile riportare il flusso in un sistema più governato come app team e richieste invece di lasciare pezzi sensibili in processi ibridi, poco tracciati e difficili da verificare.
Come impostarla in modo più pulito lato processo e prodotto
Il criterio più sano è progettare i workflow del personale come sistemi che possono esporre dati delicati, non come semplici pannelli operativi.
| Area | Regola da applicare | Come riduce il rischio |
|---|---|---|
| Ruoli | Costruisci permessi restrittivi, non generosi. | Riduci la visibilità ai soli soggetti che devono agire. |
| Rilasci | Testa ogni modifica anche sul confine tra ciò che un utente deve e non deve vedere. | Eviti che un aggiornamento rompa la segregazione dati. |
| Contenuto visibile | Mostra il minimo necessario per il compito specifico. | Limiti il danno se un filtro o una vista si comportano male. |
| Assistenza tecnica | Separa il perimetro del supporto da quello dell’operatività ordinaria. | Eviti accessi tecnici larghi e poco governati. |
| Log | Mantieni tracce utili a ricostruire l’effettiva esposizione. | Migliori incident response, audit e valutazione dell’impatto. |
| Design del processo | Progetta il workflow pensando già al giorno in cui qualcosa andrà storto. | Il sistema regge meglio bug, errori configurativi ed eccezioni. |
La domanda non è solo “il portale funziona?”. La domanda è: se un filtro salta, quanto male può fare?
Chi lavora su turni, presenze e richieste del personale dovrebbe prenderla sul serio. Il valore del sistema non sta solo nell’automatizzare. Sta nel reggere quando la complessità prova a romperlo.
Collegamenti coerenti
Per tenere il tema dentro un quadro più ampio:
- assenze e sostituzioni in bacheca: cosa puoi mostrare davvero;
- email aziendale ex dipendente: cosa fare dopo il rapporto;
- badge biometrico e presenze: perché l’impronta digitale al lavoro è un rischio alto;
- sicurezza e GDPR.
Il prossimo passo pratico
Se il portale del dipendente gestisce richieste, assenze, timbrature e workflow interni, la domanda utile non è se il layout è pulito o se il processo è comodo.
La domanda utile è questa:
hai progettato davvero il confine di visibilità tra persone, ruoli e dati, oppure stai solo sperando che il filtro non salti mai?
Se la risposta onesta è la seconda, serve un controllo serio su ruoli, test, log e minimizzazione.
Fonti ufficiali
- Garante per la protezione dei dati personali, provvedimento del 26 febbraio 2026, doc. web n. 10234928
https://www.garanteprivacy.it/home/docweb/-/docweb-display/docweb/10234928
Quando applichi il metodo
Ora che hai chiarito portale dipendente data breach assenze causali colleghi 2026, cosa chiudi prima del mese?
Su portale dipendente data breach assenze causali colleghi 2026, non serve leggere un concetto in più: va chiarito quali controlli chiudere prima di consegnare il dato alle paghe o al consulente.
Usala per fissare un punto preciso del processo: chi verifica le anomalie, quando il dato può considerarsi consolidato e quale eccezione non deve più arrivare a fine mese.
Il risultato atteso è arrivare al controllo finale con meno rettifiche, meno dubbi sulle timbrature e un passaggio più pulito verso amministrazione.
Quando hai chiaro il test da fare, passa a Vedi App team e richieste oppure puoi prova guidata se vuoi provarlo sul tuo team.
Da verificare subito
Hai validato il processo? Porta il test su dati reali.
Mantieni la logica operativa costruita nelle guide e applicala in un ambiente con regole automatiche, visibilità condivisa e collaborazione centralizzata.