Risposta breve
Nel contesto di una gara d'appalto (RFP), i software Privacy-IRM non dovrebbero essere valutati esclusivamente sulla base di elenchi generici di funzionalità. È invece determinante verificare se la soluzione in questione sia in grado di mappare i processi di governance durante il funzionamento in modo tracciabile, duraturo e scalabile.
Occorre tenere conto in particolare di ruoli e autorizzazioni, approvazioni, escalation, documentazioni, dati strutturati, possibilità di esportazione, integrazioni e del modello operativo sottostante. Una logica di valutazione solida dovrebbe quindi collegare ogni funzione richiesta a una prova concreta, al rischio operativo ad essa associato e al beneficio riconoscibile per la gestione aziendale.
Valore informativo limitato degli elenchi generali di caratteristiche
Richieste di offerta relative alla protezione dei dati, Conformità- e i software di gestione integrata del rischio spesso includono un ampio ventaglio di funzionalità. Ad esempio, viene chiesto se siano presenti flussi di lavoro, funzioni di reporting, dashboard, modelli di ruolo, esportazioni, API, multilingua o Audit Sono presenti sentieri.
Nella pratica, questo approccio porta spesso a una situazione in cui quasi tutti i fornitori soddisfano formalmente gran parte dei requisiti. I risultati sono molto simili tra loro, anche se le soluzioni possono differire notevolmente nella fase operativa successiva.
Il motivo risiede non tanto nel numero delle funzioni esaminate, quanto piuttosto nell’astrazione dei termini utilizzati. Una semplice spunta generica relativa a una funzionalità non consente di solito di trarre conclusioni attendibili su quanto la funzione in questione sia effettivamente completa, configurabile e adatta all’uso pratico.
Ciò risulta evidente, ad esempio, nel caso del termine „workflow“. Con esso si può intendere sia una semplice notifica via e-mail sia un processo configurabile con ruoli, condizioni, scadenze, escalation, richiami, punti decisionali e Audit Trail. Se entrambe le varianti vengono registrate in una matrice di valutazione semplicemente come „flusso di lavoro presente“, si crea una comparabilità che riflette in modo insufficiente l’effettivo ambito delle prestazioni.
Le decisioni relative alla selezione del personale nelle grandi aziende
Le grandi aziende acquistano regolarmente software di governance non solo per un singolo utente o per un processo isolato. La soluzione deve piuttosto essere integrata in un modello operativo organizzativo e tecnico già esistente.
A tal fine occorre tenere conto, tra l’altro, di diversi settori specialistici, regioni, società, ruoli, lingue e requisiti normativi. A ciò si aggiungono competenze mutevoli, requisiti di auditabilità, possibilità di importazione ed esportazione, modelli di autorizzazione, nonché la necessità di continuare a sviluppare i processi anche in caso di cambiamenti delle condizioni quadro giuridiche o organizzative.
In questo contesto, la semplice domanda se un software offra in linea di principio una determinata funzione non è sufficiente ai fini della valutazione. Occorre piuttosto verificare se l’organizzazione sia in grado di gestire il processo sottostante con tale soluzione in modo duraturo, tracciabile e scalabile.
Il criterio di valutazione si sposta quindi dalla semplice interfaccia funzionale ai rischi e ai requisiti legati al successivo funzionamento.
Controllabilità nelle soluzioni di governance
La gestibilità significa che un’organizzazione non solo documenta le informazioni, ma è anche in grado di gestire in modo affidabile i processi sulla base di competenze, verifiche e decisioni ben definite.
Questa differenza può essere compresa prendendo come esempio un elenco delle attività di trattamento. Una valutazione basata esclusivamente sulla funzione si concentrerebbe in particolare su:,
- se le attività di trattamento possano essere incluse,
- se sono presenti campi obbligatori e
- se è possibile esportare i report.
Una valutazione più orientata all'azienda tiene inoltre conto di,
- chi è autorizzato a creare un'attività di trattamento,
- quali informazioni devono essere disponibili nella loro interezza prima di un esame,
- in quale momento occorre coinvolgere il responsabile della protezione dei dati,
- chi ne ha la responsabilità tecnica,
- quali modifiche comportano una nuova verifica,
- come vengono monitorate le misure aperte,
- come vengono documentate le autorizzazioni,
- quale versione fosse quella di riferimento in quel momento,
- quali società o regioni possano accedere a quali informazioni,
- come prova di un Audit viene prodotto e
- come reagisce il sistema se il responsabile non interviene entro il termine previsto.
Nel primo caso si valuta essenzialmente la registrazione di un record di dati. Nel secondo caso, la questione principale è se il processo di governance sottostante possa essere attuato in modo affidabile nell'ambito delle operazioni correnti.
Significato dei criteri di eliminazione
Molte valutazioni delle richieste di offerta (RFP) trattano i requisiti in modo sostanzialmente identico. Una funzionalità accessoria può quindi ricevere un peso simile a quello di un problema sostanziale relativo alle autorizzazioni, all’integrazione o all’esportazione. Ciò può portare a una situazione in cui un punto debole sostanziale venga compensato, dal punto di vista matematico, da diverse funzionalità di minore importanza.
Per determinate esigenze, tuttavia, tale compensazione non è di norma adeguata.
Se, ad esempio, una soluzione non è in grado di separare adeguatamente i clienti, le società o i dati sensibili, un dashboard aggiuntivo non dovrebbe compensare tale carenza. Lo stesso vale in caso di dati incompleti Audit Percorsi, possibilità di esportazione insufficienti o mancanza di portabilità dei dati. Anche la questione se i processi centrali possano essere adattati solo tramite sviluppi personalizzati per il cliente incide direttamente sui costi futuri, sulla velocità di reazione e sulla dipendenza dal fornitore.
Le richieste di offerta (RFP) dovrebbero quindi definire innanzitutto quei requisiti il cui mancato rispetto comporta l'esclusione.
Tra i criteri di esclusione si possono considerare in particolare:
- Requisiti in materia di sicurezza delle informazioni e di hosting,
- Ubicazione dei dati,
- Modello dei ruoli e delle autorizzazioni,
- Separazione dei clienti o delle società,
- Audit Sentiero,
- Esportabilità e portabilità dei dati,
- Capacità di integrazione,
- documenti richiesti dalla normativa,
- Scalabilità,
- Disponibilità e assistenza,
- requisiti minimi contrattuali, nonché
- Possibilità di uscita definite.
Solo una volta soddisfatti questi requisiti minimi, si dovrebbe procedere a una valutazione a punti più approfondita e differenziata.
Distinzione tra elementi indispensabili e caratteristiche di differenziazione
In una matrice di valutazione, le funzioni standard non dovrebbero essere sovraponderate. Il fatto che una soluzione di gestione della privacy sia una Elenco delle attività di trattamento La possibilità di visualizzare tali dati costituisce solitamente un requisito fondamentale. Lo stesso vale per la creazione di utenti o la generazione di semplici report in formato PDF.
Chi assegna punteggi elevati a tali elementi indispensabili aumenta la probabilità di parità aritmetiche, senza riflettere adeguatamente le effettive differenze tra le soluzioni.
Gli elementi di differenziazione emergono piuttosto in relazione a questioni quali:
- In che misura è possibile personalizzare il modello di dati?
- È possibile limitare l'accesso dei dipartimenti alle sole informazioni necessarie per lo svolgimento delle loro mansioni?
- È possibile modificare i processi senza ricorrere allo sviluppo di software?
- È possibile che più aree di governance utilizzino oggetti comuni?
- In che modo vengono rappresentate le relazioni tra attività di trattamento, rischi, fornitori di servizi, sistemi e misure?
- È possibile impostare autorizzazioni con condizioni e richieste di riesame?
- Le escalation possono essere innescate da scadenze o rischi?
- Il percorso decisionale è completamente tracciabile?
- In quanto tempo è possibile adeguarsi ai nuovi requisiti normativi?
- I team interni potranno in seguito continuare a sviluppare autonomamente la soluzione?
Queste domande riguardano non tanto la presenza di singole funzioni, quanto piuttosto la compatibilità con le piattaforme e l'operatività della soluzione.
I documenti giustificativi come parte integrante della valutazione
La semplice indicazione della presenza di una funzione non dovrebbe essere sufficiente in caso di requisiti critici. È invece necessario richiedere regolarmente una prova concreta.
Se, ad esempio, un fornitore dichiara di disporre di un modello di ruoli flessibile, ciò dovrebbe essere verificato sulla base di uno scenario applicativo realistico. Un caso del genere potrebbe prevedere che un dipartimento possa gestire esclusivamente le proprie attività di trattamento, mentre il responsabile della protezione dei dati possa verificare tutte le operazioni rilevanti. Un referente regionale ha accesso solo alla società a lui assegnata. Il reparto legale può consultare le revisioni contrattuali senza avere automaticamente accesso a tutte le Dati sui dipendenti da ottenere. Il management ha una visione d’insieme delle informazioni sullo stato di avanzamento e dei rischi, ma non necessariamente di ogni singolo dettaglio operativo.
Nell'ambito della valutazione occorre quindi verificare se,
- se il fornitore sia effettivamente in grado di configurare questo scenario,
- come si tramandano i diritti,
- come vengono documentate le modifiche e
- se il cliente potrà effettuare autonomamente tali modifiche in un secondo momento.
Solo grazie a tale prova un'affermazione generica sul funzionamento si trasforma in una base di valutazione attendibile.
| Domanda generale sulle funzionalità | Domanda RFP più articolata | Documentazione richiesta |
|---|---|---|
| Esistono dei flussi di lavoro? | È possibile configurare i processi con ruoli, scadenze, condizioni, approvazioni, rinvii e escalation? | Dimostrazione dal vivo di un processo di approvazione completo. |
| Esiste un modello di riferimento? | È possibile gestire gli accessi in base a oggetti, ruoli, società e processi? | Configurazione di uno scenario realistico di autorizzazioni. |
| È prevista la rendicontazione? | Il management è in grado di, Audit e i dipartimenti possano ottenere report diversi a partire dagli stessi dati strutturati? | Tre report specifici per i diversi gruppi target generati da un'unica operazione. |
| Esiste un Audit Sentiero? | I cambiamenti, le decisioni, i ruoli, le tempistiche e i valori precedenti vengono documentati in modo trasparente? | Visualizzazione della cronologia completa delle modifiche. |
| Ci sono esportazioni? | I clienti possono esportare i propri dati in modo completo, strutturato e senza una dipendenza evitabile dal produttore? | Esempio di esportazione completa dei dati. |
| Esistono delle API? | Quali oggetti, azioni ed eventi sono disponibili tramite le interfacce documentate? | API-Documentazione e un caso concreto di integrazione. |
| Il sistema è configurabile? | Quali modifiche può apportare il cliente autonomamente, senza dover commissionare uno sviluppo al produttore? | Adattamento in tempo reale di un oggetto e di un flusso di lavoro. |
| La soluzione supporta RoPA? | Come vengono gestiti i trattamenti, i sistemi, i fornitori di servizi, i rischi, i TOM, Base giuridica e le autorizzazioni sono collegate tra loro? | Presentazione di un modello di governance coerente. |
| Ci sono dei compiti? | È possibile avviare, assegnare, inoltrare a un livello superiore e monitorare automaticamente le attività? | Processo con superamento dei termini e escalation. |
| La soluzione supporta il multilinguismo? | L'interfaccia, i contenuti, i campi dati e i report sono disponibili in più lingue? | Presentazione dello stesso processo in diverse lingue. |
Rispondere a questo tipo di domande richiede un maggiore impegno da parte dei fornitori. Tuttavia, ciò consente una valutazione più attendibile della soluzione in questione.
Script standardizzati per le dimostrazioni dei prodotti
Una dimostrazione gratuita del prodotto è utile solo in misura limitata ai fini della scelta. I fornitori tendono infatti a mettere in evidenza quelle funzionalità in cui la loro soluzione è particolarmente performante. Può trattarsi di un dashboard, di un’interfaccia utente o di un determinato sistema di reportistica.
In termini di comparabilità, il vantaggio è quindi limitato, poiché non tutti i fornitori gestiscono lo stesso caso d'uso.
Una dimostrazione nell'ambito di una richiesta di offerta (RFP) dovrebbe quindi basarsi su un copione standardizzato. Uno scenario di questo tipo può, ad esempio, comprendere le seguenti fasi:
- Un dipartimento notifica una nuova attività di trattamento.
- Mancano le informazioni obbligatorie.
- L'operazione viene restituita al responsabile competente.
- In base a determinate risposte, viene avviata una verifica sulla protezione dei dati.
- Viene assegnato un fornitore di servizi.
- Si procede alla valutazione di un rischio.
- Viene creata una misura.
- L'autorizzazione è soggetta a determinate condizioni.
- Dopo sei mesi viene attivato un promemoria.
- Un revisore richiede il percorso decisionale completo.
Ogni operatore dovrebbe illustrare in modo esaustivo lo stesso caso. A tal fine, non occorre valutare solo il risultato. Occorre tenere conto, in particolare, delle seguenti questioni:
- Quanti passaggi manuali sono necessari?
- In quali punti si verificano le interruzioni di formato?
- Quali informazioni devono essere aggiornate più volte?
- In che misura è comprensibile lo stato di elaborazione in questione?
- Come si configurano le deviazioni?
- Quali modifiche richiedono l'assistenza del produttore?
- Quali documenti vengono generati automaticamente?
Con questo approccio, la dimostrazione del prodotto diventa parte integrante dell'esame tecnico e aziendale.
La dipendenza dall'adeguamento come fattore di costo
Il prezzo della licenza indicato in un bando di gara riflette solitamente solo in parte i costi effettivi di una soluzione di governance.
Ulteriori costi possono derivare in particolare da:
- sviluppo su misura,
- adeguamenti tecnici,
- Consulenza,
- Migrazione dei dati,
- Integrazioni,
- Relazioni,
- Corsi di formazione,
- Modifiche alla versione,
- Test,
- Assistenza e
- un futuro cambio di operatore.
È quindi particolarmente importante capire in che misura l'organizzazione possa adattare autonomamente la soluzione.
I processi normativi e organizzativi non rimangono immutati. Le aziende riorganizzano le competenze, incorporano nuove società o modificano i percorsi interni di verifica e approvazione. A ciò si aggiungono nuovi campi, report e requisiti tecnici.
Se ogni adattamento deve essere commissionato come progetto di sviluppo, ciò si ripercuote regolarmente sui costi, sui tempi e sulla dipendenza dal produttore. La configurabilità non va quindi considerata solo come una funzione di comodità, ma come una caratteristica economicamente rilevante del modello operativo.
Valutazione dell'idoneità alla piattaforma
Un'applicazione RoPA specializzata può essere un Elenco delle attività di trattamento rappresentarle in modo esaustivo dal punto di vista tecnico. Le grandi aziende, tuttavia, presentano spesso ulteriori requisiti di governance.
Tra questi possono figurare:
- Valutazioni d'impatto sulla protezione dei dati,
- Verifiche dei fornitori di servizi,
- Valutazioni dei trasferimenti,
- Rischi e misure,
- Richieste delle persone interessate,
- Gestione degli incidenti,
- Governance dell'IA,
- Gestione della sicurezza delle informazioni,
- Linee guida,
- Autorizzazioni e
- Audit Gestione.
Se questi processi vengono gestiti in applicazioni separate, possono crearsi nuovi silos di dati e una gestione multipla dei dati. Sistemi, fornitori di servizi, rischi e Persone responsabili devono quindi, se necessario, essere registrati in più soluzioni indipendentemente l'una dall'altra.
La compatibilità con la piattaforma si manifesta quindi in particolare nella possibilità di utilizzare oggetti di governance comuni in modo trasversale tra i diversi settori. Un fornitore di servizi non dovrebbe necessariamente essere tenuto a Protezione dei dati, la governance dell’IA e la sicurezza delle informazioni devono essere registrate più volte. I rischi dovrebbero poter essere collegati ai rispettivi processi, misure e controlli interessati. Un caso d’uso dell’IA può essere collegato all’attività di trattamento, al fornitore, al modello, alla verifica della protezione dei dati, alla revisione della sicurezza e all’approvazione.
È proprio in questa interconnessione che risiede la differenza tra un’applicazione specialistica isolata e una piattaforma di governance.
Creazione di una matrice di valutazione
Una matrice di valutazione efficace dovrebbe collegare tra loro quattro livelli:
Funzione – Verifica – Rischio operativo – Vantaggi gestionali
1. Funzione
Innanzitutto occorre stabilire quale competenza tecnica o specialistica sia necessaria.
Esempio: flussi di lavoro di approvazione configurabili.
2. Prova
Occorre quindi stabilire in che modo il fornitore debba dimostrare l'effettiva disponibilità di tale capacità.
Esempio: configurazione in tempo reale di un processo di approvazione con due ruoli di revisore, condizioni e procedura di escalation.
3. Rischio operativo
Occorre inoltre valutare quale rischio derivi dall’assenza o dalla limitazione di tale capacità.
Esempio: le decisioni rimangono nelle e-mail, le scadenze vengono trascurate e in seguito non è possibile ricostruire completamente il processo di approvazione.
4. Vantaggi gestionali
Infine, occorre valutare quali vantaggi operativi o strategici tale capacità comporti per l'organizzazione.
Esempio: tempi di elaborazione più brevi, minore onere di coordinamento manuale, maggiore facilità di verifica e minore dipendenza dal produttore.
Solo la combinazione di questi quattro livelli consente una valutazione che va oltre la semplice analisi delle singole funzioni.
| Criterio di valutazione | Prova | Rischio operativo in caso di debolezza | Vantaggi gestionali | Ponderazione |
|---|---|---|---|---|
| Ruoli e autorizzazioni | Scenario realistico di autorizzazione | Accessi non autorizzati, mancanza di separazione, elevato onere amministrativo | Delega sicura e funzionamento scalabile | 10 % |
| Configurazione del flusso di lavoro | Processo in tempo reale con condizioni ed escalation | Procedure relative alle e-mail, mancato rispetto delle scadenze, monitoraggio manuale | Tempi di elaborazione più brevi e responsabilità ben definite | 12 % |
| Modello dei dati e relazioni | Collegamento tra attività di trattamento, sistema, fornitore di servizi e rischio | Cura duplicata e mancanza di un contesto specialistico | Visione unitaria della governance | 10 % |
| Audit Sentiero | Cronologia completa delle modifiche | Le decisioni non sono sufficientemente comprensibili | Trasparenza e responsabilità | 8 % |
| Reportistica ed esportazioni | Gestione, Audit- e relazione operativa | Creazione manuale di report | Controllo più rapido e verifiche attendibili | 8 % |
| Configurabilità | Adeguamento da parte del team di assistenza clienti | Dipendenza dal produttore e costi di gestione elevati | Adattamento più rapido e costi operativi inferiori | 12 % |
| Integrazione e API | Caso concreto di integrazione | Discontinuità tra i diversi supporti e doppia gestione dei dati | Automazione e maggiore qualità dei dati | 8 % |
| Migrazione dei dati | Piano di mappatura, test e convalida | Perdita di dati, ritardi e scarsa accettazione | Avvio strutturato del progetto | 8 % |
| Sicurezza delle informazioni | Documentazione tecnica e organizzativa | Sicurezza e Conformità-Rischi | Azienda affidabile | KO / 10 % |
| Modello operativo e assistenza | SLA, struttura di supporto e processo di rilascio | Ritardi nella risoluzione dei problemi e dipendenza dal progetto | Prevedibilità e sicurezza operativa | 7 % |
| Compatibilità con le piattaforme | Utilizzo di oggetti condivisi tramite diverse soluzioni | Creazione di ulteriori silos di governance | Espandibilità e tutela dell'investimento | 7 % |
La ponderazione concreta deve essere adeguata alle esigenze della singola azienda. È fondamentale che rifletta l’effettiva rilevanza operativa dei criteri.
La controllabilità come componente del vantaggio economico
Il ritorno sull'investimento dei software di governance viene spesso ridotto al risparmio di tempo ottenuto nelle singole attività di documentazione. Ad esempio, ci si chiede quante ore di lavoro sia possibile risparmiare nella redazione di una relazione RoPA.
Questa analisi è valida, ma non riflette appieno i benefici economici. Una parte significativa dei benefici può risiedere nella maggiore controllabilità dei processi sottostanti.
Ciò riguarda in particolare i seguenti aspetti:
- I dipartimenti sanno quali informazioni e attività ci si aspetta da loro.
- Le responsabilità rimangono chiare.
- Gli esami vengono avviati nelle date previste.
- È possibile monitorare le scadenze e le misure.
- Le decisioni vengono documentate.
- Il management ottiene una visione d'insieme affidabile.
- La documentazione relativa all'audit viene redatta già durante lo svolgimento del processo.
- I nuovi requisiti normativi possono essere implementati più rapidamente.
- Le conoscenze rimangono nel sistema e non solo nelle caselle di posta elettronica dei singoli utenti.
Questo vantaggio è spesso più difficile da esprimere con un unico indicatore rispetto al semplice risparmio di tempo. Per l'organizzazione, tuttavia, può risultare economicamente più significativo.
Una soluzione che si limiti a generare più rapidamente i report migliora innanzitutto un’attività amministrativa. Una soluzione che metta in relazione ruoli, rischi, decisioni e documentazione può inoltre sostenere la capacità di governance dell’organizzazione.
Punti chiave per l'approvvigionamento
Il reparto Approvvigionamenti valuta regolarmente il prezzo, il contratto, il capitolato d'appalto e l'affidabilità dell'offerente. Nel caso delle piattaforme di governance, è opportuno esaminare anche alcune questioni operative:
- Quali servizi sono inclusi nel pacchetto standard?
- Quali funzioni richiedono moduli aggiuntivi?
- Quali modifiche rientrano nella configurazione e quali nello sviluppo?
- Chi è autorizzato ad apportare modifiche alle configurazioni?
- Quali sono i costi relativi all'assistenza fornita dal produttore?
- Come sono strutturati i processi di rilascio e aggiornamento?
- Le configurazioni personalizzate vengono mantenute durante gli aggiornamenti?
- Quali sono le opportunità di esportazione?
- Come è regolata un'uscita successiva?
- Quali sono i costi relativi a volume di dati aggiuntivo, utenti supplementari, società o moduli?
- Quali servizi dipendono da un partner di implementazione?
- Quali impegni previsti dalla roadmap sono vincolanti dal punto di vista contrattuale e quali costituiscono semplicemente dichiarazioni di intenti?
Il prezzo di licenza più basso non rappresenta necessariamente l'offerta più conveniente dal punto di vista economico. I costi a lungo termine sono determinati in misura significativa dal modello operativo e dall'adattabilità della soluzione.
Punti da verificare in materia di aspetti legali e protezione dei dati
Gli aspetti legali e relativi alla protezione dei dati non dovrebbero limitarsi a valutare esclusivamente i contratti o i contenuti tecnici dei singoli moduli. Occorre inoltre verificare se la piattaforma supporti la necessaria tracciabilità.
Tra questi figurano in particolare:
- responsabilità ben definite,
- autorizzazioni documentate,
- il coinvolgimento tempestivo dei soggetti interessati,
- Controllo delle versioni,
- ambiti di applicazione definiti,
- modifiche comprensibili,
- Tenuta conto delle raccomandazioni tecniche,
- accettazioni del rischio documentate,
- misure aperte,
- Casi da riesaminare e
- Portabilità dei dati.
Una soluzione di governance non dovrebbe limitarsi a memorizzare singole affermazioni o risultati, ma dovrebbe anche essere in grado di illustrare in modo tracciabile come è stata presa una decisione.
Punti chiave per i CIO e il reparto IT
Per i CIO e il reparto IT, le esigenze tecniche e operative sono spesso in primo piano. È necessario verificare in particolare i seguenti punti:
- L'architettura si integra nel panorama aziendale esistente?
- Quanto è flessibile il modello di integrazione?
- In che modo vengono associati identità e ruoli?
- Quali API ed eventi sono disponibili?
- Come vengono trasferite e testate le configurazioni?
- Come è strutturata la separazione tra i clienti o tra le società?
- Come vengono gestite le versioni?
- Quali database e tecnologie sono rilevanti?
- In che modo vengono effettuati il monitoraggio, la registrazione e Disponibilità È garantito?
- In che misura si riscontra una dipendenza dal produttore o dal partner di implementazione?
Una piattaforma può offrire un'ampia gamma di funzionalità e comportare comunque notevoli costi di gestione. La valutazione tecnica non dovrebbe quindi limitarsi al numero di funzioni.
Classificazione di Ailance
Nel contesto di una gara d'appalto, Ailance non dovrebbe essere valutata in base al numero di caselle relative a funzionalità generiche che è possibile spuntare in un elenco. È invece determinante verificare se la piattaforma sia in grado di rispecchiare la logica di governance e il modello operativo del singolo cliente.
Ailance opera secondo l'approccio basato su piattaforma qui descritto:
- oggetti di governance configurabili,
- Relazioni tra i dati,
- Ruoli e autorizzazioni,
- Flussi di lavoro,
- Verifiche e approvazioni,
- Rischi e misure,
- Report e dashboard,
- Audit Percorsi e
- API e integrazioni.
Questo approccio può risultare particolarmente rilevante per le aziende che desiderano rappresentare diversi ambiti di governance su una base comune.
Ailance RoPA non si limita alla Documentazione relative alle operazioni di trattamento. Le operazioni di trattamento possono riguardare sistemi, fornitori di servizi, rischi, misure tecniche e organizzative, Base giuridica, alle autorizzazioni, alle azioni in sospeso e alle valutazioni del responsabile della protezione dei dati.
Ai fini della valutazione occorre quindi verificare se da tali collegamenti emerga un processo di governance soggetto a tassazione e se questo sia conforme ai requisiti organizzativi della rispettiva impresa.
Verifica della propria matrice RFP
Le aziende dovrebbero verificare le matrici di valutazione esistenti, in particolare nel caso di requisiti formulati in termini generici.
Nel caso di una riga come „Flusso di lavoro esistente“, ad esempio, occorre specificare quale prestazione concreta un fornitore debba fornire per ottenere il punteggio massimo. Occorre chiarire se sia sufficiente una conferma generica del funzionamento o se il fornitore debba dimostrare come interagiscano tra loro ruoli, scadenze, condizioni, escalation, approvazioni e documentazioni.
Se ciò non risulta chiaramente dalla matrice di valutazione, è possibile che vengano valutati più i termini che le competenze effettivamente dimostrate.
Conclusione
Nella scelta di un software di governance, una valutazione basata su elenchi generici di funzionalità spesso non è sufficiente.
Una logica solida nella stesura di una richiesta di offerta (RFP) dovrebbe innanzitutto definire i criteri di esclusione e successivamente distinguere tra requisiti di base e caratteristiche effettive di differenziazione. I requisiti critici dovrebbero essere comprovati da prove concrete. Inoltre, occorre tenere conto dei rischi operativi, dei costi conseguenti, delle dipendenze di adattamento e del modello operativo sottostante.
La questione fondamentale non è quindi solo se un software metta a disposizione un flusso di lavoro. Occorre piuttosto verificare se, grazie a tale flusso di lavoro, l’organizzazione sia in grado di gestire in modo duraturo e tracciabile ruoli, decisioni, rischi, escalation e documentazione.
Un segno di spunta relativo a una funzionalità attesta inizialmente solo che un fornitore ha confermato formalmente un requisito. Per stabilire se l’attività organizzativa sottostante possa essere effettivamente svolta nella fase operativa successiva, è necessaria un’ulteriore verifica.
Domande e risposte
Come si valuta un software IRM per la protezione della privacy in una richiesta di offerta (RFP)?
La valutazione dovrebbe tenere conto contemporaneamente dei criteri di esclusione, delle competenze specialistiche, dei requisiti tecnici, delle prove concrete, dei rischi operativi e dei benefici per la gestione aziendale. A tal fine, le semplici spunte relative alle caratteristiche generali spesso non sono sufficienti.
Quali sono i criteri eliminatori da tenere in considerazione per i software Privacy-IRM?
Tra i criteri di esclusione figurano in particolare la sicurezza delle informazioni, l'ubicazione dei dati, il modello dei ruoli e delle autorizzazioni, Audit Trail, portabilità dei dati, integrabilità, scalabilità, assistenza e requisiti contrattuali minimi.
Perché gli elenchi di funzionalità non sono sufficienti?
I fornitori utilizzano talvolta gli stessi termini per indicare funzionalità molto diverse tra loro. Un “workflow”, ad esempio, può riferirsi sia a una semplice notifica sia a un processo di governance completamente configurabile.
Come dovrebbero essere condotte le dimostrazioni dei prodotti nell'ambito della procedura di richiesta di offerta (RFP)?
Tutti i fornitori dovrebbero elaborare uno scenario prestabilito in modo uniforme. In questo modo è possibile confrontare meglio la qualità dei processi, l'usabilità, la configurabilità, le discontinuità multimediali e la tracciabilità.
Qual è la differenza tra “must-have” e “caratteristica distintiva”?
Un requisito indispensabile è la registrazione delle attività di trattamento dei dati. Un elemento di differenziazione indica il grado di flessibilità, scalabilità e controllabilità con cui la soluzione può essere implementata durante il funzionamento.
Perché la configurabilità è importante?
I processi di governance sono soggetti a continui cambiamenti. Se ogni adeguamento richiede uno sviluppo da parte del produttore, i costi, i tempi e le dipendenze possono aumentare. La configurabilità può ridurre questi rischi.
Cosa si intende per "compatibilità con le piattaforme" nel contesto dei software di governance?
La compatibilità con le piattaforme significa che diversi processi di governance possono utilizzare oggetti, ruoli e dati comuni. In questo modo è possibile evitare la creazione di ulteriori silos di dati e la duplicazione della gestione dei dati.
Quali documenti deve presentare un offerente nell'ambito di una procedura di richiesta di offerta (RFP)?
I requisiti critici dovrebbero essere illustrati sulla base di scenari concreti. Ciò riguarda, ad esempio, i modelli di ruolo, i flussi di lavoro di approvazione, le escalation, Audit Percorsi, esportazioni di dati, integrazioni e modifiche alla configurazione.
Come si può valutare il ROI di una piattaforma di governance?
Oltre al risparmio di tempo, occorre tenere conto anche di una riduzione degli oneri di coordinamento, di decisioni più rapide, di una maggiore verificabilità, di una minore dipendenza dai fornitori, di una migliore qualità dei dati e di un controllo gestionale ottimizzato.
Qual è l'importanza del modello operativo?
Il modello operativo determina le modalità di gestione, personalizzazione, integrazione, assistenza e sviluppo di una soluzione. Può influire sui costi a lungo termine in misura maggiore rispetto al semplice prezzo della licenza.
In che modo Ailance RoPA può favorire la gestibilità?
Ailance RoPA integra le attività di trattamento con i sistemi, i fornitori di servizi, i rischi, le misure tecniche e organizzative, Base giuridica, attività in corso, responsabili, approvazioni e documentazione. In questo modo, la soluzione può andare oltre la semplice funzione di un elenco puramente elettronico.
A quale aspetto occorre prestare particolare attenzione in una richiesta di offerta (RFP)?
Di particolare importanza è la questione relativa alle modifiche che l'azienda potrà apportare autonomamente in un secondo momento, senza dover commissionare un ulteriore progetto di sviluppo o di consulenza.
German 
English 
Italian 
French