01
Capitolo uno
Perché le approvazioni ad-hoc falliscono gli audit
Le approvazioni via email sembrano funzionare fino al momento in cui un auditor chiede di ricostruire chi ha approvato cosa, in quale ruolo, rispetto a quale versione. Quel momento è dove il programma si rompe.
Il pattern di approvazione ad-hoc è quasi universale nelle organizzazioni che non hanno ancora strutturato la gestione documentale. Un autore scrive una bozza. La invia via email a tre colleghi con “Per favore rivedi”. Riceve risposte. Qualcuno risponde “OK”. Qualcun altro aggiunge commenti. L’autore incorpora le modifiche e invia la versione finale con “Approvato?”. Riceve un’altra serie di email con “Sì, va bene”. Il documento viene caricato nella cartella condivisa come versione “finale”.
Questo processo sembra funzionare. Per l’uso quotidiano, funziona. Il problema emerge quando un auditor arriva e chiede: “Chi ha approvato la versione 3.0 di questo SOP? In quale ruolo? Contro quale versione hanno revisionato? Quando esattamente?”
Caselle email separate
Ogni approvazione vive nella casella email dell'approvatore. Ricostruire la sequenza completa significa accedere a più caselle, cercare thread specifici, e sperare che nessuno abbia eliminato niente.
Quale bozza è stata approvata?
Se l'autore ha modificato il documento dopo aver ricevuto alcune approvazioni ma prima di riceverne altre, le approvazioni si riferiscono a versioni diverse. Nessuno può ricostruire quale versione fosse "quella approvata".
Chi era il Quality Manager?
L'email dice "Mario Rossi ha risposto OK". Non dice che Mario Rossi stava agendo nella sua capacità di Quality Manager, non come collega. La distinzione è cruciale per la compliance e impossibile da ricostruire.
Ordine non tracciato
Se la policy richiede che Quality approvi dopo Regulatory Affairs, l'email non cattura se questo ordine è stato rispettato. L'auditor chiede; non c'è risposta definitiva.
Il problema con le approvazioni via email non è che siano false — è che sono irricostruibili. E in compliance, quello che non puoi ricostruire non è mai successo.
02
Capitolo due
Cosa rende un flusso di approvazione difendibile
Cinque proprietà strutturali che separano un flusso di approvazione difendibile da uno decorativo. Ognuna indirizza un punto di fallimento specifico nelle approvazioni ad-hoc.
Un flusso di approvazione difendibile non è semplicemente “più formale” di un’email. È strutturalmente diverso in cinque modi che gli auditor sanno come testare.
Un passaggio alla volta
Il passaggio 2 non può iniziare finché il passaggio 1 non è completato. L'ordine è strutturalmente applicato, non dipende dalla memoria o dalla buona volontà.
Persona specifica, ruolo specifico
Ogni passaggio è attribuito a un'identità Entra nominata — non un gruppo, non una lista di distribuzione. Il registro di audit cattura chi ha agito e in quale capacità.
3
VINCOLATO ALLA VERSIONE
Check-out automatico
Il documento è bloccato durante il flusso. Nessuna modifica può avvenire mentre le approvazioni sono in corso. La versione approvata è garantita essere quella revisionata.
Registro di audit automatico
Ogni evento del flusso scrive nel registro di audit: chi, quando, in quale ruolo, con quale commento, contro quale versione. Non richide azioni manuali dall'utente.
Accesso immediato
Il Quality Manager può aprire il registro del documento e produrre l'intera sequenza di approvazione in meno di 30 secondi. Nessuna preparazione richiesta, nessun ticket IT.
03
Capitolo tre
Esecuzione sequenziale vs parallela
I flussi paralleli sembrano più efficienti. In ambienti regolamentati, producono prove più difficili da difendere — e a volte impossibili.
In un flusso di approvazione sequenziale, ogni approvatore agisce in ordine. Quando il Passo 1 è completato, il documento passa automaticamente al Passo 2. Nessun approvatore vede il documento finché i passaggi precedenti non sono stati risolti.
I flussi paralleli inviano il documento a tutti gli approvatori contemporaneamente. Questo sembra più veloce — tutti revisionano in parallelo, il flusso è completo quando tutti hanno risposto. Ma produce un problema specifico durante l’audit.
Sequenziale
Ordine applicato strutturalmente
Ogni approvazione avviene nel suo contesto: l'approvatore al Passo 2 sa cosa ha approvato l'approvatore al Passo 1 (può vedere eventuali commenti). La sequenza è tracciata. L'auditor vede chi ha approvato in quale ordine, con quali commenti, contro quale versione.
Parallelo
Ordine inferito, non tracciato
Tutti approvano lo stesso documento, ma non esiste sequenza registrata. Se la policy richiede "Quality approva dopo Regulatory Affairs", il flusso parallelo non può dimostrare che questo sia avvenuto — anche se in pratica è successo. L'auditor non ha prove; ha solo affermazioni.
Perché questo importa sotto ISO 9001 e Part 11. ISO 9001 clausola 7.5.2 richiede che la documented information sia “approvata per adeguatezza e idoneità”. Implica che qualcuno ha effettivamente giudicato sia l’adeguatezza che l’idoneità — nel proprio ruolo. Un flusso parallelo dove tutti approvano contemporaneamente senza vedere i commenti degli altri non fornisce questa evidenza con la stessa chiarezza.
Sotto Part 11, il problema è più acuto. §11.10(e) richiede un registro di audit che cattura le operazioni degli operatori. Se l’audit log non mostra la sequenza delle approvazioni, ma solo un insieme di timestamp, manca del contesto che gli ispettori FDA cercano.
04
Capitolo quattro
Identità Entra nominate per ogni passaggio
Il requisito di attribuzione più citato fallisce nei sistemi legacy: "approvato dal team QA" non è attribuzione. Part 11 richiede esplicitamente una persona specifica.
Ogni evento nel registro di audit si risolve in un’identità Microsoft Entra (Azure AD) specifica — una persona con un nome, un ruolo, e una sessione autenticata che ha prodotto l’evento. Questo è strutturale. Non può essere aggirato dall’utente, dagli amministratori, o dal prodotto stesso.
Il contrasto con come funzionano molti sistemi legacy di gestione documentale è netto. Negli ultimi sistemi, gli account di servizio condivisi erano comuni — “qualityapproval@azienda.com” come casella condivisa usata da più membri del team Quality. In quei sistemi, le voci del registro di audit attribuiscono all’account condiviso, non alla persona che ha effettivamente agito. Sotto il requisito di persona nominata di Part 11, ogni tale voce è un fallimento di attribuzione in attesa di essere contestato.
✗
FALLISCE L'ATTRIBUZIONE
Account di servizio condiviso
"qualityapproval@azienda.com" usato da più persone. Le voci del registro di audit non possono identificare chi ha effettivamente agito. Non difendibile sotto Part 11 §11.10(g).
✗
FALLISCE L'ATTRIBUZIONE
Approvazione di gruppo
"Reparto QA" come approvatore invece di una persona specifica. Qualsiasi membro del team può approvare; il registro non può dire quale.
Identità Entra nominata
"Mario Rossi, Quality Manager, mario.rossi@azienda.com" — attribuzione a una persona specifica autenticata tramite Entra con le proprie credenziali individuali.
Identità nominata con ruolo
Attribuzione a una persona specifica che agisce in un ruolo specifico in un momento specifico. "Mario Rossi, nel ruolo di Quality Manager, ha approvato alle 14:15".
05
Capitolo cinque
Check-out automatico e integrità della versione
Il problema silenzioso nei flussi senza controllo della versione: il documento cambia tra i passaggi di approvazione, e nessuno se ne accorge fino all'audit.
In un flusso di approvazione senza controllo della versione, c’è una finestra pericolosa: dopo che il Passo 1 ha approvato ma prima che il Passo 2 riveda, l’autore può modificare il documento. Il Passo 2 approva una versione diversa rispetto a quella che ha approvato il Passo 1. Il documento pubblicato è diverso da quello che nessuno dei due approvatori ha esattamente revisionato.
Il check-out automatico elimina questa finestra strutturalmente. Nel momento in cui viene avviato un flusso di approvazione, il documento viene estratto automaticamente — bloccato contro modifiche. L’autore non può modificarlo mentre il flusso è in corso. Nessuna versione può essere “scivolata” tra i passaggi di approvazione.
Check-out automatico
Nel momento in cui l'autore invia per l'approvazione, il documento viene estratto automaticamente. L'autore non può modificarlo; i revisori possono solo visualizzarlo.
Versione bloccata
Ogni approvatore revede la stessa versione. Il Passo 2 approva esattamente ciò che ha approvato il Passo 1 — non una variante silenziosa. L'integrità è strutturale.
Check-in su pubblicazione
Quando l'ultimo approvatore firma, il documento viene archiviato automaticamente come nuova versione principale. La versione approvata diventa la versione pubblicata. Il check-out si risolve senza azione manuale.
Check-in su rifiuto
Se un approvatore rifiuta, il check-out viene rilasciato automaticamente. L'autore può accedere nuovamente al documento per incorporare il feedback. Nessun lock orphan.
06
Capitolo sei
Approvatori fissi come policy codificata
Le policy organizzative sui requisiti di approvazione devono essere strutturalmente applicate, non affidate a se le persone ricordano di includerle.
Gli approvatori fissi codificano la policy organizzativa nel flusso di approvazione stesso. Per ogni tipo di documento, certi ruoli devono sempre approvare — indipendentemente dall’autore, dal progetto o dall’urgenza. “Quality su ogni SOP. Direttore Medico su ogni protocollo clinico. Legale su ogni contratto esterno.” Queste non sono linee guida che le persone potrebbero dimenticare — sono configurazioni del sistema che si applicano strutturalmente.
Approvatori fissi
Policy come configurazione
Il Quality Manager è configurato come approvatore fisso per tutti gli SOP. Ogni volta che qualsiasi autore invia un SOP per l'approvazione, il Quality Manager è automaticamente nel flusso — al passaggio corretto, con la priorità corretta. Non è possibile per l'autore "dimenticare" di includere Quality.
Approvatori variabili
Policy come prassi
L'autore seleziona gli approvatori ogni volta che invia. Se la policy dice "includi sempre Quality", dipende dall'autore ricordarlo ogni volta. Gli auditor che campionano 50 approvazioni troveranno quelle dove Quality era assente — e chiederanno perché.
Il caso di audit. Quando un auditor esamina un campione di approvazioni SOP e chiede “è sempre presente il Quality Manager come approvatore?”, la risposta con approvatori fissi è definitiva: “Sì, il Quality Manager è configurato come approvatore fisso per tutti gli SOP — il sistema non consente il completamento del flusso senza di loro.” Non c’è un’eccezione da spiegare, nessuna deviazione da giustificare.
Con gli approvatori variabili, la risposta è “di solito, ma dipende dall’autore includerli”. Quella risposta ha una frequenza di eccezioni che gli auditor indagheranno.
07
Capitolo sette
Gestione dei rifiuti
I rifiuti non sono fallimenti del processo — sono il processo che funziona. La captura delle motivazioni dei rifiuti è dati di qualità preziosi.
Un approvatore che rifiuta un documento sta esercitando esattamente il giudizio che il processo di approvazione è progettato per catturare. Il rifiuto non è un problema — la mancanza di prove del motivo per cui è avvenuto un rifiuto lo è.
1
Passaggio uno
L'approvatore rifiuta con motivazione
Quando un approvatore rifiuta, gli viene richiesto di fornire una motivazione. Questo campo è obbligatorio — non opzionale. La motivazione viene catturata nel registro di audit.
2
Passaggio due
Il flusso si ferma, l'autore viene notificato
Il flusso di approvazione si ferma immediatamente al rifiuto. L'autore riceve una notifica con la motivazione del rifiuto. Il documento viene restituito alla fase di bozza.
3
Passaggio tre
L'autore rivede e reinvia
L'autore affronta il feedback dell'approvatore, fa le modifiche necessarie, e invia nuovamente il documento. Il nuovo flusso inizia dall'inizio — nessun passaggio precedente "eredita" lo stato approvato.
4
Passaggio quattro
L'intero ciclo è nel registro di audit
Il rifiuto, la motivazione, la revisione e il nuovo flusso di approvazione sono tutti nel registro di audit. Un auditor può vedere l'intera storia di revisione: primo tentativo rifiutato al Passo 2 per "sezione sulla gestione dei rischi insufficiente", secondo tentativo approvato.
Il rifiuto come dati di qualità. I tassi di rifiuto aggregati per tipo di documento, passaggio di approvazione e revisore rivelano dove il processo di authoring produce costantemente output sotto lo standard. Un tasso di rifiuto del 40% al Passo 2 per gli SOP clinici suggerisce che gli autori di quell’area non capiscono i requisiti del Direttore Medico. Questo è un dato di coaching — non un fallimento del flusso.
08
Capitolo otto
Mappatura di compliance
Quale capacità di flusso di approvazione soddisfa quale clausola regolamentare — specifica e precisa.
| Regime |
Clausola |
Aspettativa |
| ISO 9001 |
7.5.2 |
La documented information deve essere approvata per adeguatezza e idoneità. L'evento di approvazione cattura chi ha revisionato, in quale ruolo, rispetto a quale versione, con quali commenti. |
| FDA Part 11 |
§11.10(e) |
Registro di audit sicuro, generato dal computer, con timestamp che cattura ogni azione dell'operatore che crea, modifica o elimina record elettronici. Il flusso di approvazione sequenziale produce questo automaticamente. |
| FDA Part 11 |
§11.10(g) |
Utilizzo di autorità checks per garantire che solo persone autorizzate possano usare il sistema. Identità Entra nominate + MFA al livello tenant soddisfano questo. |
| HIPAA |
§164.312(b) |
Implementare meccanismi di registrazione dei controlli hardware, software e attività procedurali. Il registro di audit delle approvazioni fornisce questa evidenza per le procedure governate. |
| ISO 9001 |
7.5.3 |
Le modifiche alle documented information devono essere controllate. Il check-out automatico durante il flusso garantisce che nessuna modifica avvenga non approvata durante la revisione. |
09
Capitolo nove
Pattern di firma PAdES nei flussi di approvazione
La firma crittografica come tipo di passaggio di approvazione — non un flusso separato. Quando aggiunge valore, quando non lo aggiunge.
Non ogni approvazione ha bisogno di una firma crittografica. L’approvazione standard tramite il registro di audit è evidenza sufficiente per la maggior parte dei flussi di documenti regolamentati. La firma PAdES aggiunge un binding crittografico che è appropriato per specifici scenari di alto valore o ad alto rischio.
Approvazione standard
Sufficiente per la maggior parte
SOP interni, policy che si applicano solo all'interno dell'organizzazione, procedure riviste dal team di compliance. Il registro di audit è l'evidenza. La firma PAdES non aggiunge valore.
Firma PAdES giustificata
Quando è richiesto il binding crittografico
Contratti esterni, invii regolatori, attestazioni firmate a terze parti, accordi rivolti al cliente. La firma viaggia al di fuori del tenant; il binding crittografico è la difesa.
La firma DocuSign è configurata come tipo di passaggio di approvazione — non come flusso separato. Quando il flusso raggiunge un passaggio configurato come “firma DocuSign”, il sistema costruisce una busta DocuSign e la invia al firmatario. Il PDF firmato torna in SharePoint come versione autorevole. Il registro di audit cattura l’evento di firma con tutti i metadati crittografici.
10
Capitolo dieci
Implementazione
Le tre decisioni che trasformano la configurazione del flusso di approvazione in una policy applicabile.
Decisione 1
Mappa i passaggi per tipo di documento
Ogni tipo di documento (SOP, Policy, Protocollo clinico, Contratto) ottiene il proprio schema di flusso di approvazione. I passaggi, i ruoli e gli approvatori fissi sono definiti per tipo — non per documento.
Decisione 2
Identifica gli approvatori fissi
Per ogni tipo di documento: quali ruoli devono sempre essere nel flusso di approvazione, indipendentemente dall'autore o dal progetto? Questi vengono configurati come approvatori fissi. Documenta la scelta nel Manuale Qualità.
Decisione 3
Determina quando è richiesta la firma
Identifica quali tipi di documento richiedono la firma PAdES come passaggio finale. Configura il tipo di passaggio corrispondente. La maggior parte dei documenti interni non ne ha bisogno; documenti esterni e invii regolatori spesso sì.
La migliore configurazione del flusso di approvazione è quella che un auditor può capire dal solo guardare la configurazione — senza che nessuno debba spiegarla. "Quality approva sempre al Passo 2" non richiede spiegazioni.
Se il tuo attuale programma di approvazione dipende dalla memoria delle persone per includere gli approvatori giusti, dall’email per conservare le prove, o dall’inferenza per ricostruire la sequenza, il gap non è cosmético — è strutturale. Una conversazione di 30 minuti con il nostro team è di solito sufficiente per mappare la tua pratica attuale rispetto alle cinque proprietà di questo capitolo, e per identificare dove i punti di fallimento sono più probabili in superficie.
