Moduli condizionali nelle applicazioni aziendali: logica dei moduli basata sul contesto per Solution Builder

Per Solution Builder ciò significa che le regole di business possono essere direttamente integrate nella struttura del modulo. Gli utenti non devono decidere autonomamente quali parti di un processo applicare al proprio caso. Il modulo è infatti in grado di tenere conto delle condizioni definite per il processo in questione.

Scopo dei moduli condizionali

I moduli condizionali sono particolarmente utili nei casi in cui determinate informazioni siano necessarie solo a determinate condizioni. Possono contribuire a limitare il numero di campi visualizzati al caso specifico ed evitare domande non rilevanti per il processo in questione.

Ad esempio, non è necessario porre domande sui trasferimenti internazionali di dati se non avviene alcun trasferimento internazionale. I campi relativi all’escalation di un incidente non sono necessari se l’incidente non soddisfa i criteri di rischio previsti a tal fine. Le sezioni relative alle autorizzazioni aggiuntive possono rimanere nascoste se il caso in questione non richiede alcuna autorizzazione supplementare.

È quindi fondamentale che le informazioni vengano richieste quando sussistono i presupposti per la loro Necessità sono disponibili.

Ciò può rivelarsi utile soprattutto quando un'applicazione deve rappresentare diversi scenari, paesi, ruoli, classificazioni di rischio o requisiti normativi all'interno di un unico processo.

In caso di un Elenco delle attività di trattamento Ad esempio, a seconda del Paese selezionato, possono essere visualizzate domande diverse relative ai trasferimenti di dati. In un processo DPIA possono essere visualizzate ulteriori aree di rischio qualora siano coinvolti dati sensibili. In caso di segnalazione di incidenti, le fasi di escalation possono dipendere dalla gravità dell’incidente, mentre in una valutazione ISMS possono essere previste ulteriori domande di sicurezza per i sistemi classificati come critici.

Anche nel caso di una valutazione dei fornitori possono rendersi necessarie verifiche aggiuntive qualora il fornitore di servizi Dati personali che opera o ha sede al di fuori dell'UE.

Il modulo si limita quindi alle informazioni rilevanti per il caso specifico, ma può al contempo tenere conto di requisiti più ampi non appena vengono soddisfatti i presupposti necessari.

Significato pratico per i processi aziendali

I moduli condizionali non servono solo a rendere più chiara la struttura di un modulo. La loro importanza fondamentale risiede nella strutturazione dei processi aziendali.

Se i campi non rilevanti non vengono visualizzati, gli utenti devono controllare e modificare un numero minore di domande. Ciò può semplificare l’elaborazione dei dati e ridurre il rischio che vengano inserite informazioni in campi non pertinenti al caso specifico.

Anche la qualità dei dati può trarne vantaggio, poiché gli utenti hanno meno motivi per inserire dati inesatti o casuali solo perché un campo è visibile. Allo stesso tempo, è possibile richiedere ulteriori informazioni non appena una regola di business definita lo richieda.

Per Conformità-Nei processi, ciò può risultare particolarmente rilevante quando i requisiti di documentazione dipendono dalle circostanze del singolo caso. È possibile visualizzare sezioni aggiuntive qualora siano soddisfatte le condizioni specificate in ciascun caso, anziché riportare tutti i requisiti possibili già all’inizio del processo.

Dal punto di vista della gestione di un'applicazione, i moduli condizionali consentono inoltre di rappresentare diverse combinazioni di casi all'interno di un unico modulo, senza dover creare un modulo separato per ogni scenario.

Questo aspetto è rilevante perché le applicazioni aziendali possono diventare inutilmente complesse se, già all'inizio di un processo, vengono richieste tutte le informazioni potenzialmente necessarie. I moduli condizionali consentono invece di distinguere in base al rispettivo contesto funzionale.

Principio fondamentale della logica dei moduli

Il principio di base di una sezione condizionale di un modulo può essere descritto con una semplice regola:

Una sezione viene visualizzata solo se è soddisfatta una determinata condizione.

La condizione si basa sulle informazioni già disponibili per l'elemento in questione. Il Solution Builder definisce quale campo deve essere verificato, quale criterio è determinante e quale valore o stato determina la visualizzazione della rispettiva sezione.

Alcune regole aziendali tipiche potrebbero essere, ad esempio:

• La sezione dedicata a Valutazione dell'impatto del trasferimento viene visualizzato se il Paese di destinazione si trova al di fuori dell'UE.
• Se il rischio viene classificato come elevato, viene visualizzata una sezione aggiuntiva relativa all'approvazione.
• La sezione relativa alla sicurezza dei fornitori viene visualizzata quando è coinvolto un fornitore di servizi esterno.
• Viene visualizzata una motivazione relativa al periodo di conservazione qualora il termine di conservazione previsto superi il periodo standard.
• La sezione relativa alla segnalazione di un incidente viene visualizzata quando si prevede che l'incidente abbia ripercussioni su colpiti persone.

L'utente non deve conoscere la regola sottostante. Il modulo visualizza la sezione corrispondente non appena viene soddisfatta la condizione definita.

Tradurre le regole di business nella logica dei moduli

I Solution Builder partono solitamente da un requisito funzionale e non dai dettagli tecnici di implementazione. I moduli condizionali supportano questo approccio, poiché occorre innanzitutto stabilire in quali circostanze sia necessaria una determinata sezione del modulo.

Il punto di partenza potrebbe quindi essere la seguente domanda:

In quali circostanze questa sezione dovrebbe essere visibile?

La regola aziendale che ne deriva può poi essere tradotta in una condizione all'interno del modulo.

Ad esempio, una sezione può essere visualizzata solo se un’attività di trattamento riguarda categorie particolari di dati personali, se un sistema è stato classificato come critico per l’attività aziendale, se un fornitore di servizi selezionato ha sede in un paese terzo o se il tipo di richiesta riguarda la cancellazione dei dati.

In questo modo è possibile integrare le conoscenze relative al processo nel funzionamento del modulo, senza che gli utenti debbano decidere autonomamente quali parti del modulo siano rilevanti per il loro caso specifico.

Condizioni che vanno oltre le semplici decisioni sì/no

I moduli condizionali non si limitano alle scelte binarie. A seconda della logica del modulo disponibile, le condizioni possono anche verificare se i campi sono vuoti o compilati, se un valore selezionato corrisponde a una determinata opzione, se un valore numerico è superiore o inferiore a una soglia, se un testo contiene determinati contenuti o se una data è precedente o successiva a un'altra data.

Ciò consente di soddisfare diverse esigenze aziendali.

Una sezione relativa alla verifica può essere visualizzata, ad esempio, quando è stata superata la data prevista per la verifica successiva. Una sezione relativa all'escalation può diventare rilevante quando il numero di persone coinvolte supera una soglia prestabilita. Una sezione relativa alle misure correttive può essere visualizzata quando un controllo è stato valutato come inefficace.

Lo stesso principio può essere applicato alle procedure di motivazione o di deroga. Una sezione dedicata alla motivazione può rendersi necessaria qualora non siano disponibili le informazioni richieste. Una sezione relativa all’approvazione di una deroga può essere opportuna qualora una misura pianificata si discosti dalla procedura standard prevista.

Il modulo non serve quindi solo a raccogliere informazioni. La sua struttura può adattarsi alle informazioni già disponibili relative alla specifica transazione.

Logica condizionale basata su campi di riferimento

La nuova funzionalità relativa ai campi di ricerca estende questo approccio alle informazioni provenienti da record collegati.

Un campo di riferimento stabilisce una relazione tra un elemento e un altro. Un’attività di elaborazione può, ad esempio, essere collegata a un sistema, a un fornitore, a un paese, a un’unità organizzativa o a un controllo.

I moduli condizionali possono tenere conto di queste relazioni al momento di decidere quali sezioni visualizzare. In questo modo, il modulo può reagire non solo alle informazioni inserite direttamente dall'utente, ma anche ai dati già disponibili per un oggetto collegato.

Se, ad esempio, un utente seleziona un fornitore, nella scheda del fornitore corrispondente potrebbero essere già presenti informazioni relative alla sede, alla classificazione del rischio e al tipo di servizio. Queste informazioni possono poi essere utilizzate per stabilire se siano necessarie sezioni aggiuntive.

Se è già disponibile una classificazione del rischio relativa al fornitore, l’utente non è tenuto a inserire nuovamente tale informazione solo per il modulo in questione. L’utilizzo delle informazioni già presenti in record di dati correlati consente quindi di evitare doppie richieste e contribuisce a un impiego più coerente dei dati esistenti.

Utilizzo nel registro delle attività di trattamento

In una soluzione RoPA, un utente può, ad esempio, selezionare il Paese in cui si trova una Elaborazione si svolge. Se il Paese selezionato, in base alle regole definite nell'applicazione, fa scattare ulteriori requisiti relativi al trasferimento, potrebbero essere visualizzate ulteriori domande relative alle garanzie e alle valutazioni di trasferimento.

Se i requisiti necessari non sono soddisfatti, queste sezioni rimangono nascoste.

In questo modo è possibile rappresentare diverse situazioni operative all’interno dello stesso modulo, senza che ogni utente debba compilare tutte le domande relative al trasferimento dei dati, indipendentemente dalla situazione concreta.

Applicazione nella gestione dei fornitori

I moduli condizionali possono essere utilizzati anche nella gestione dei fornitori.

Se un utente seleziona un fornitore di servizi già classificato all’interno dell’applicazione, nel caso in cui tale fornitore sia stato classificato come “critico”, possono essere visualizzate ulteriori sezioni relative alla due diligence. In assenza di una classificazione corrispondente, tali sezioni non devono necessariamente far parte della verifica standard.

L'ambito della verifica può quindi basarsi sulle informazioni già disponibili relative al fornitore di servizi in questione.

Applicazione nella governance dell'IA

Lo stesso principio può essere applicato ai processi di governance dell'IA.

Se viene selezionato uno strumento di IA, possono essere visualizzate sezioni aggiuntive relative alla governance qualora lo strumento venga utilizzato per prendere decisioni con conseguenze di ampia portata oppure Dati personali elaborati. Se i requisiti definiti per una documentazione più approfondita dei rischi non sono soddisfatti, queste sezioni possono rimanere nascoste.

I moduli condizionali consentono quindi di differenziare i requisiti di documentazione in base alle caratteristiche del rispettivo caso d'uso dell'IA.

Applicazione nei processi ISMS

In una soluzione ISMS, è possibile associare un sistema a un determinato processo aziendale. Se tale processo è classificato come critico, all’interno del modulo possono essere visualizzati ulteriori requisiti relativi ai controlli.

Se il processo non soddisfa i criteri previsti, la valutazione standard può rimanere invariata.

Ciò consente di identificare quali requisiti di verifica si applicano in base alla classificazione tecnica di un processo aziendale, senza che gli utenti debbano determinare autonomamente l'ambito di verifica necessario.

Gestione dei valori nelle sezioni nascoste

I Solution Builder dovrebbero inoltre tenere conto di come vengono gestite le informazioni già inserite in una sezione che verrà successivamente nascosta.

Se un utente modifica un dato e, di conseguenza, non viene più soddisfatto il requisito per la visualizzazione di una sezione, i valori contenuti in tale sezione rimangono inizialmente invariati fintanto che l'utente continua a modificare l'elemento. In questo modo, i dati non vengono cancellati immediatamente a seguito di una modifica effettuata durante il processo di modifica.

Se però l'elemento viene salvato mentre la sezione rimane nascosta, i valori in essa contenuti vengono rimossi. Il campo di identificazione principale rimane invariato.

Questo comportamento è rilevante per il modello di dati sottostante, poiché le informazioni che non rientrano più nello scenario applicativo attuale non vengono conservate in modo permanente solo perché sono state inserite in una fase precedente del processo.

Nella progettazione dei moduli condizionali, è quindi necessario tenere conto di questo comportamento, in particolare quando gli utenti possono modificare in un secondo momento le opzioni selezionate in precedenza.

Progettazione basata su regole tecniche

Nella progettazione dei moduli condizionali, è spesso opportuno partire non dai campi esistenti, ma dalle regole aziendali sottostanti.

In particolare, occorre verificare quanto segue:

• In quali casi è necessario un procedimento diverso?
• Quali informazioni sono richieste solo a determinate condizioni?
• Quali domande non sono rilevanti per una parte significativa degli utenti?
• Quali requisiti dipendono dal Paese, dal rischio, dal ruolo, dalla categoria, dal sistema, dal fornitore o dallo stato?
• Quali sezioni diventano rilevanti solo quando viene raggiunta una determinata soglia?

Da queste regole è quindi possibile ricavare la struttura del modulo e la relativa logica condizionale.

La logica condizionale non dovrebbe servire esclusivamente a nascondere il maggior numero possibile di campi. Il nesso tra i dati inseriti dall’utente e il comportamento del modulo che ne deriva dovrebbe rimanere comprensibile. L’obiettivo è quello di strutturare la complessità funzionale esistente secondo le regole aziendali pertinenti.

Casi d'uso tipici

I “Conditional Forms” trovano applicazione in particolare nei settori della governance, del rischio, Conformità-, protezione dei dati, sicurezza, Audit- e nei processi di gestione operativa, qualora la portata delle informazioni richieste dipenda dal caso specifico.

Esempi tipici di utilizzo sono:

• requisiti specifici per paese nel Elenco delle attività di trattamento,
• Valutazioni d'impatto dei trasferimenti,
• Logica di attivazione della DPIA,
• Escalation degli incidenti,
• Due diligence del fornitore,
• Classificazione dei casi d'uso dell'IA,
• Applicabilità dei controlli ISMS,
• Requisiti relativi a Audit-Documentazione,
• Piani di gestione dei rischi,
• Sezioni di approvazione e di sign-off, nonché
• Processi eccezionali.

Il principio comune consiste nel visualizzare le sezioni in base alle esigenze del caso specifico, anziché presentare a ogni utente tutti i campi potenzialmente rilevanti.

I moduli condizionali come parte integrante della progettazione della soluzione

Senza la logica condizionale, i Solution Builder potrebbero dover creare moduli molto complessi, contenenti anche sezioni rilevanti solo per singoli casi specifici. Gli utenti devono quindi valutare autonomamente quali parti del modulo siano applicabili alla loro situazione specifica.

I moduli condizionali consentono di trasferire questa differenziazione nell'applicazione. Il modulo può riprodurre la logica di processo e visualizzare richieste di informazioni aggiuntive non appena vengono soddisfatti i rispettivi prerequisiti.

Ciò può verificarsi in particolare nel caso di Conformità-possono essere rilevanti per alcune applicazioni. Conformità-I processi contengono spesso requisiti che si applicano solo a determinate condizioni. Se tutti i potenziali requisiti vengono presentati contemporaneamente, i moduli possono diventare molto voluminosi, anche se nel caso specifico ne è rilevante solo una parte.

I moduli condizionali consentono una differenziazione adeguata. Vengono richieste informazioni aggiuntive solo se la condizione definita in ciascun caso è soddisfatta. Le sezioni non pertinenti, invece, rimangono escluse dal modulo corrente.

Classificazione pratica

I moduli condizionali consentono ai Solution Builder di strutturare le applicazioni aziendali in base alle circostanze specifiche di ciascun caso. La loro importanza pratica risiede in particolare nella capacità di collegare il comportamento di un modulo alle regole aziendali e alle informazioni già presenti all’interno dell’applicazione.

In questo modo è possibile ridurre i campi superflui, evitare doppie richieste, rendere più coerente l'acquisizione dei dati e rappresentare diverse varianti di processo all'interno dello stesso modulo.

Occorre prestare particolare attenzione alla definizione delle condizioni di base, all’utilizzo delle informazioni provenienti da set di dati collegati e alla gestione dei valori quando vengono nascoste sezioni condizionali. Se questi aspetti vengono presi in considerazione già in fase di progettazione, i moduli condizionali possono contribuire a creare processi aziendali e Conformità-Rappresentare in modo strutturato i requisiti all'interno di un'applicazione.