Un obbligo che esiste sulla carta ma non ha un titolare, per un auditor non esiste. Questo è il nucleo di ciò su cui molte organizzazioni si bloccano. È stato identificato un obbligo di rendicontazione, è stata scritta una policy, ma la domanda su chi si occupa quotidianamente di garantire che la policy venga eseguita, e chi può dimostrare che ciò avviene, resta senza risposta. Senza un nome associato a un obbligo non c'è controllo, e senza controllo non c'è compliance dimostrabile.
La titolarità di un obbligo è più di un nome in un organigramma. Significa che una persona o una funzione è responsabile di tre cose: che l'obbligo venga eseguito, che la relativa prova venga registrata, e che tale prova sia reperibile nel momento in cui qualcuno la richiede. Un titolare che sa soltanto che un compito gli appartiene, ma non riesce a mostrare cosa è stato registrato al riguardo, nella pratica non è un titolare ma un nome su una lista.
Questa distinzione è esattamente il punto in cui molti sistemi di controllo interno risultano carenti. Le policy vengono stabilite a livello di direzione, l'esecuzione avviene a livello di reparto, e il collegamento tra i due raramente viene reso esplicito. Come si può realizzare questo collegamento, e perché policy e prassi divergono senza di esso, è descritto in come dimostrare che la policy è anche prassi.
In un'organizzazione singola il titolare di un obbligo è generalmente ancora individuabile: c'è un'unica entità giuridica, un unico consiglio di amministrazione, un unico set di libri contabili. In un gruppo con più entità, questo cambia. Un obbligo che vale a livello di gruppo deve essere eseguito da qualche parte nell'organizzazione, e questo può avvenire a livello di gruppo, a livello di una società operativa, oppure può essere distribuito su più entità che ciascuna fornisce una parte delle informazioni.
La domanda su chi sia il titolare diventa allora una domanda sulla struttura: quale entità consolida i dati, quale entità fornisce i dati sottostanti, e chi è responsabile se uno di questi anelli manca. Questa domanda si pone così spesso e in modo così specifico nelle strutture di gruppo che esiste una trattazione separata: chi è titolare di un obbligo in un gruppo con più entità approfondisce come si distribuisce tale responsabilità e dove la distribuzione va storta.
Titolarità e prova vanno insieme, ma nella pratica si separano. Un titolare viene designato sulla base di uno schema organizzativo, mentre la prova dell'esecuzione viene registrata altrove: in un'email, in un foglio di calcolo su un disco locale, in un sistema utilizzato solo da una società operativa. Chi a livello di gruppo deve rendere conto, deve prima scoprire dove si trova la prova prima di poter dimostrare che l'obbligo è stato rispettato.
Questo problema non è occasionale, è strutturale in ogni organizzazione composta da più parti. Esattamente su questo punto prosegue dove la prova si disperde in un gruppo con più entità: quali punti dell'organizzazione generano prove senza che nessuno le raccolga centralmente, e perché ciò emerge solo nel momento in cui un auditor le richiede.
Non ogni documento fornito conta come prova per un auditor. Un documento di policy dimostra che esiste un'intenzione, non che tale intenzione sia stata eseguita. Un verbale di una riunione del consiglio dimostra che un argomento è stato discusso, non che una decisione sia stata attuata. La prova deve avere una linea diretta verso l'obbligo che deve sostenere: chi ha fatto cosa, quando, e come è stato registrato.
In un gruppo con più entità questa domanda diventa più complessa, perché la prova può generarsi a livelli diversi e non ogni livello ha lo stesso valore probatorio. Cosa conta specificamente come prova in questa situazione, e perché la prova di un'entità non è automaticamente prova per l'obbligo del gruppo, è approfondito in cosa conta come prova per un obbligo in un gruppo con più entità.
Una lista di titolari è un punto di partenza, non un sistema. Per essere dimostrabilmente in control, ogni obbligo deve essere collegato a un titolare, alla prova che quel titolare produce, e a un controllo che stabilisce se tale prova è completa e aggiornata. Questo collegamento viene spesso registrato in una control matrix, una panoramica che per ogni obbligo mostra chi è responsabile e come viene controllato. Cosa comporta esattamente una control matrix e perché una lista di titolari senza tale matrice non regge in un audit, è trattato in cos'è una control matrix.
Altrettanto importante è la domanda su dove viene conservata tale prova, e se un auditor possa ritrovarla senza l'aiuto dell'organizzazione. Un sistema dipendente dalle conoscenze di un solo collaboratore non è un sistema ma un rischio. Come si conserva la prova in modo che resti reperibile, anche quando un gruppo è composto da più entità, è descritto in come conservare la prova in modo che un auditor la trovi in un gruppo con più entità.
Assegnare la titolarità e organizzare la documentazione probatoria è un lavoro: redigere panoramiche, raccogliere documentazione, tenere traccia di chi ha fornito cosa. Una parte di questo lavoro è ripetibile e segue uno schema fisso, il che lo rende adatto a essere supportato dall'AI. La werkscan di FTE TO AI calcola per ciascun compito quale parte di questo lavoro può essere trasferita, in modo che risulti visibile dove le persone restano necessarie per la valutazione e dove i sistemi possono occuparsi della raccolta e dell'organizzazione delle prove.
Vraag maar welke verplichting op u van toepassing is, en waaraan u dat kunt aantonen.
Answers come from this site’s knowledge base. Not tailored advice, and not a scan of your company.