L’acquisto di software whistleblowing spesso inizia da una lista di parole chiave: anonimato, AI, GDPR, audit, direttiva UE. Quella lista non risponde alla domanda centrale: il team saprà gestire in modo sicuro e coerente un caso dalla prima informazione alla chiusura documentata?
Una buona selezione fornitore non cerca un badge “conforme a tutto”. Traduce il proprio modello operativo in requisiti verificabili. Il software sostiene il processo; non sostituisce procedura, responsabili né analisi legale.
Per il contesto italiano di obbligo e canale interno: D.Lgs. 24/2023.
Parti dallo scenario, non dalla checklist di feature
Chiedi agli stakeholder di descrivere un caso realistico end-to-end. Esempio: una persona segnala tramite modulo; un soggetto autorizzato deve fare due domande; arriva un documento; emerge un conflitto di interesse e un altro gestore prende in carico; alla fine serve un registro della decisione.
Se il fornitore non sa mostrare questo percorso, le icone delle funzioni dicono poco sul rischio operativo.
| Fase | Domanda al team | Cosa verificare nel sistema |
|---|---|---|
| Ricezione | Come il segnalante trasmette l’informazione? | Modulo chiaro, sicuro, usabile sui dispositivi reali |
| Triage | Chi verifica completezza e assegna? | Stati, owner, code controllate |
| Follow-up | Come si fanno domande e aggiornamenti? | Comunicazione legata al caso, non a caselle sparse |
| Istruttoria | Come si conservano note, prove e decisioni? | Ruoli, allegati, storia, export |
| Chiusura | Chi conferma l’esito e cosa resta in archivio? | Stati chiari e controllo accessi dopo chiusura |
Sette aree di valutazione
1. Canale di ricezione
Parti dall’utente che non conosce gli acronimi interni. Il canale deve spiegare a cosa serve, quali informazioni aiutano e dove trovare la policy. Verifica che il modulo non forzi dati inutili.
Se valuti l’anonimato, non chiedere solo “esiste la funzione anonymous?”. Chiedi: come si torna al caso, come arriva la risposta, come sono protetti i dati e cosa succede senza email. Vedi Segnalazioni anonime e confidenzialità.
2. Follow-up e ownership
Senza follow-up restano informazioni incomplete ed escalation inutili. Una buona demo mostra messaggistica legata all’ID caso, storia domande/risposte e owner esplicito — anche nei casi anomali (assenza, conflitto di interesse, passaggio di consegne).
3. Ruoli, permessi e limiti di amministrazione
Il rischio più frequente non è la mancanza di una feature, ma l’accesso eccessivo. Chiarisci:
- l’amministratore di sistema vede automaticamente ogni caso?
- esistono ruoli di sola lettura / audit?
- come si revoca l’accesso?
4. Gestione dei casi
Stati, scadenze, allegati, note e report devono riflettere il modello di lavoro. Approfondimento: Gestione dei casi nel software whistleblowing.
5. Sicurezza e privacy
Cifratura, log, export, retention e documentazione a supporto della DPIA. Domande strutturate: GDPR e domande al fornitore. Consulta anche il Centro sicurezza.
6. Implementazione e lingue
Chi configura testi, ruoli e flussi? Serve multilingua? Vedi software whistleblowing multilingue.
7. Prezzo e ambito
Confronta cosa è incluso, limiti e costi nascosti. Guida: Costo del software whistleblowing e Prezzi.
Criterio di decisione
Preferisci il fornitore che dimostra il tuo scenario con controlli chiari, non quello che moltiplica le promesse di conformità. Il risultato atteso è un canale di segnalazione e una gestione dei casi che il team riesce a usare ogni giorno.