Una storia che nessuno può riscrivere.

"Log immutabile" è una di quelle espressioni che compaiono in ogni scheda prodotto e quasi mai vengono spiegate. Nella maggior parte dei sistemi significa che l'applicazione non espone una funzione per cancellare i log — il che lascia intatta la possibilità che qualcuno con accesso al database lo faccia comunque, senza lasciare traccia.

In Vector la garanzia sta un livello più in basso. Un trigger definito sul database PostgreSQL rifiuta le operazioni di UPDATE e DELETE sulla tabella dei log di workflow: è il database stesso a respingere la scrittura, indipendentemente da chi la tenta e da quale strada. Non è una regola applicativa che un amministratore può aggirare passando dietro l'applicazione.

È una distinzione che conta quando la traccia deve reggere davanti a un terzo. La non-ripudiabilità di una decisione vale quanto la difficoltà di alterarla, e una regola scritta nel software è più facile da aggirare di un vincolo scritto nel motore di persistenza.

Ogni azione su una richiesta lascia una riga: chi l'ha compiuta, che cosa ha fatto, quando, e con quali dati davanti in quel momento. Approvazioni e rifiuti, passaggi di step, deleghe esercitate, commenti, allegati, avvii automatici di processi a valle.

La parte spesso sottovalutata è il "con quali dati". Sapere che un responsabile ha approvato una richiesta il 14 marzo serve a poco se nel frattempo l'importo è stato modificato: la domanda vera è che cosa aveva davanti quando ha deciso. È esattamente l'informazione che una catena di email non conserva in forma verificabile.

Qui serve precisione, perché il confine viene raccontato male di frequente. Vector fornisce due strumenti concreti previsti dal Regolamento: un endpoint che esporta in formato JSON tutti i dati personali di un utente, e uno che cancella l'account applicando l'anonimizzazione a cascata sui record collegati. Sono le funzioni che servono a rispondere a una richiesta di accesso o di cancellazione da parte di un interessato.

Quanto al registro delle attività di trattamento previsto dall'art. 30, va detto con chiarezza: nessun software lo compila al posto vostro. È un adempimento organizzativo che compete al titolare del trattamento. Ciò che Vector aggiunge è l'evidenza documentata di chi ha fatto cosa dentro i processi che gestisce — cioè esattamente il tipo di prova che una gestione via posta elettronica non produce, e che rende sostenibile il principio di accountability.

Sul piano infrastrutturale: i dati risiedono su PostgreSQL gestito, con regione selezionabile in Unione Europea, e i segreti delle integrazioni sono cifrati con AES-256-GCM tramite una chiave dedicata.

Per le aziende dotate di un modello organizzativo ai sensi del D.Lgs. 231/2001, i processi autorizzativi sono uno dei punti in cui il modello si dimostra o si sgretola. Un flusso di spesa senza evidenza di chi abbia autorizzato che cosa è, in pratica, un controllo dichiarato ma non documentabile.

Vector non vi rende conformi — la conformità è un fatto organizzativo, non un acquisto. Rende però verificabile il tratto di processo che governa: le soglie configurate esistono nel sistema e non nella buona volontà delle persone, la segregazione dei compiti è imposta dalle assegnazioni, e ogni deroga passa da una delega registrata.

• SSO OIDC con Microsoft Entra ID: le identità restano quelle aziendali, con provisioning dai claim.
• MFA con TOTP attivabile per singolo utente.
• Blocco dell'account dopo tentativi di accesso falliti, con soglie configurabili.
• Policy di password con lunghezza minima, requisiti di complessità e divieto di riuso delle ultime password.
• Durata della sessione impostabile dalle impostazioni di sicurezza dell'organizzazione.
• Isolamento multi-tenant verificato da test automatici: rifiuto degli accessi incrociati, creazione fail-closed, liste e ricerche sempre filtrate per azienda.
• L'isolamento copre anche gli utenti con ruolo amministratore e i canali WebSocket in tempo reale.
• Limitazione della frequenza delle richieste, intestazioni di sicurezza HTTP e lista di origini consentite per le chiamate cross-origin.

Un fornitore che elenca solo i propri punti di forza vi sta chiedendo di scoprire da soli il resto, di solito nel momento sbagliato. Ecco quindi il lato scomodo, per intero:

• Nessuna certificazione ISO 27001 e nessun attestato SOC 2: non sono in perimetro in questa fase.
• Nessun penetration test esterno completato: è pianificato, ma a oggi non possiamo mostrarvene il report.
• Autenticazione federata disponibile via OIDC; SAML non è supportato.
• Non sono implementati scadenza programmata delle password, limite di sessioni concorrenti e restrizione degli accessi per indirizzo IP.
• Il monitoraggio copre gli errori applicativi, non le metriche di performance; gli obiettivi formali di ripristino (RPO/RTO) non sono ancora documentati.

Se una di queste voci è un requisito bloccante per la vostra organizzazione, è meglio saperlo adesso che al terzo incontro. Diteci quale: in alcuni casi è pianificata, in altri vi indirizzeremo altrove.

Va chiarito, perché genera confusione nelle valutazioni. Un'autorizzazione interna non si prova con una firma crittografica: si prova con un'identità autenticata e una traccia che quell'identità ha compiuto quell'azione in quel momento. Nessuna organizzazione chiede una firma digitale qualificata per una richiesta di ferie o per un ordine da poche migliaia di euro — sarebbe sproporzionato, e infatti non lo fa nessuno, comprese le grandi multinazionali che gestiscono le approvazioni su piattaforme low-code.

Firma qualificata, PEC e conservazione sostitutiva servono a un'esigenza diversa: dare valore legale a documenti diretti verso l'esterno e archiviare a norma ciò che il fisco richiede — la fatturazione elettronica prima di tutto. È il ciclo di vita del documento, non il percorso della decisione.

Vector si occupa del secondo, e non prova a coprire il primo. Se il vostro processo, a valle dell'approvazione, produce un documento che richiede valore legale ai sensi del CAD, quel passaggio resterà a carico dei sistemi che già usate: Vector consegna l'evento di approvazione via webhook e loro fanno il resto.

Molte aziende arrivano qui avendo già una forma di tracciabilità: la cronologia versioni di un elenco SharePoint, i log di audit di una piattaforma low-code, lo storico di un gestionale. Sono strumenti utili, e per l'operatività quotidiana spesso bastano.

La differenza emerge quando la traccia deve reggere davanti a un terzo. Quei registri sono protetti da controlli amministrativi: esiste un ruolo — proprietario del sito, amministratore dell'ambiente — che può modificarli, epurarli o vederli scadere per criteri di conservazione. La garanzia coincide con la fiducia riposta in chi detiene quel ruolo.

Il vincolo di Vector è di natura diversa: il rifiuto di UPDATE e DELETE è imposto dal motore di database, non dall'applicazione che ci sta sopra. Non esiste un ruolo applicativo che lo aggiri, perché non è l'applicazione a farlo rispettare. È una distinzione tecnica sottile e una distinzione sostanziale in sede di verifica.

Un'ultima considerazione che conta più delle precedenti. Un audit log completo è la conseguenza di un processo che passa dal sistema; non è una funzione che si attiva su un processo che vive altrove. Finché una parte delle autorizzazioni continua a viaggiare per email "solo per le urgenze", quella parte semplicemente non esiste nel registro.

Per questo la tracciabilità e l'adozione sono lo stesso problema, affrontato da due lati. Ne parliamo nella pagina sull'alternativa alle approvazioni via email, dove il passaggio più delicato — chiudere il canale vecchio — è anche quello che determina la completezza delle vostre evidenze.