Blog

Compliance continua: perché il team IT è diventato il nuovo motore operativo del controllo

Per anni la compliance è stata gestita come un esercizio periodico. Si raccoglievano evidenze prima di un audit, si allineavano policy e configurazioni, si produceva documentazione, poi il tema tornava in secondo piano fino alla scadenza successiva. Quel modello oggi regge sempre meno. La pressione normativa, la velocità del cambiamento tecnologico e la dipendenza crescente da cloud, AI, servizi terzi e supply chain software stanno spostando la compliance da attività episodica a capacità operativa continua. NIST definisce il continuous monitoring come il mantenimento di una consapevolezza continua su sicurezza, vulnerabilità e minacce per supportare decisioni di risk management, e questa definizione fotografa bene la direzione presa anche dal mondo enterprise europeo. 

Per i team IT questo cambiamento non è teorico. Significa più logging, più telemetry, più integrazioni con piattaforme GRC, più controlli automatici in pipeline, più tracciabilità delle modifiche, più pressione sulla gestione delle identità e più richieste di evidenze in tempo quasi reale. Significa anche che il reparto IT non è più il soggetto chiamato “a supporto” quando arriva un audit, ma il punto in cui la compliance viene concretamente implementata, verificata e mantenuta. È qui che il ruolo dell’IT consulting cambia profondamente: non basta più implementare soluzioni, bisogna progettare architetture compliance-ready e automatizzare i controlli dentro i sistemi. Questa lettura è coerente sia con l’evoluzione dei framework di monitoraggio continuo di NIST sia con l’approccio di continuous controls monitoring promosso da ISACA e dai principali attori del risk management. 

La compliance continua non è un audit più frequente

Il primo equivoco da superare è che la compliance continua coincida con un aumento del numero di verifiche. In realtà cambia il modello operativo. Non si tratta di fare più audit, ma di spostare il baricentro dal controllo ex post al controllo embedded. In un modello tradizionale si verifica a campione se un requisito è stato rispettato. In un modello di compliance continua si progettano sistemi, pipeline e configurazioni in modo che il requisito sia monitorabile, misurabile e possibilmente auto-applicato. ISACA descrive questo passaggio come il superamento della compliance point-in-time verso uno stato sostenuto nel tempo, in cui tool di configurazione, automazione e reporting producono insight continui sulla postura di conformità. 

Questo sposta il lavoro dal documento al sistema. Una policy che impone MFA su tutte le console cloud non ha più valore soprattutto come testo approvato, ma come regola verificabile via API, con un controllo continuo sul drift e con evidenze esportabili in dashboard o report. Una segregazione dei privilegi non si dimostra più solo con una matrice RACI allegata all’audit, ma con dati su ruoli, eccezioni, approvazioni e rotazione delle credenziali raccolti dai sistemi IAM. La compliance continua, quindi, non è un layer documentale aggiuntivo. È un requisito architetturale.

Perché il carico finisce quasi sempre sul team IT

Il motivo per cui il peso della compliance continua ricade soprattutto sul team IT è semplice: quasi tutte le regole moderne, anche quando nascono in ambito legale o di risk governance, diventano verificabili solo se tradotte in configurazioni, log, controlli applicativi o regole di pipeline. DORA richiede capacità strutturate di gestione del rischio ICT, resilienza operativa, testing e governance dei fornitori terzi per le entità finanziarie. L’AI Act impone obblighi di tracciabilità, trasparenza e governance per i sistemi AI in funzione del rischio. Il Cyber Resilience Act introduce requisiti di sicurezza e reporting per prodotti con elementi digitali, con reporting obligations che iniziano nel 2026 e obblighi principali dal 2027. In tutti questi casi, la conformità dipende da ciò che succede in infrastruttura, nel software e nelle operations, non solo in compliance office. 

È qui che l’IT diventa il punto di intersezione tra governance e tecnologia. I team compliance definiscono il requisito, ma sono DevOps, SRE, cloud engineer, security engineer, sviluppatori e architetti a renderlo eseguibile. La conseguenza, in molte organizzazioni, è che il team IT assorbe lavoro “non pianificato”: richieste di estrazione evidenze, verifiche su configurazioni cloud, revisione di accessi privilegiati, conferme su logging, controllo delle dipendenze software, verifica di retention e proof di remediation. ISACA osserva che l’automazione può supportare raccolta evidenze, project management e continuous monitoring proprio perché il volume informativo richiesto dagli audit moderni è cresciuto sensibilmente. 

Dal 2025 al 2026 la pressione normativa è diventata continua

Il cambio di passo si vede bene osservando il calendario normativo europeo. DORA è applicabile dal 17 gennaio 2025 e richiede alle entità finanziarie di avere un framework completo di resilienza operativa digitale, inclusi registri delle disposizioni contrattuali con i fornitori ICT terzi. L’EBA sottolinea che da quella data le entità in scope devono disporre di registri completi delle relazioni contrattuali con ICT third-party service providers. Questo non è un adempimento documentale isolato: richiede inventari accurati, classificazione dei servizi, ownership e aggiornamento continuo. 

Sul fronte AI, il quadro accelera nel 2026. La Commissione Europea indica che l’AI Act è entrato in vigore il 1° agosto 2024 e sarà generalmente applicabile dal 2 agosto 2026, con alcune eccezioni già scattate nel 2025 e una transizione più lunga per alcuni sistemi ad alto rischio incorporati in prodotti regolati. Questo significa che nel 2026 molte organizzazioni dovranno dimostrare di avere non solo policy AI, ma anche logging, governance dei modelli, supervisione umana, documentazione tecnica e processi di monitoraggio. Anche qui il lavoro vero finisce nei sistemi, nei flussi dati e nelle pipeline. 

Il CRA aggiunge un ulteriore livello di pressione, perché dal 11 settembre 2026 iniziano gli obblighi di reporting previsti dall’articolo 14, mentre gli obblighi principali scatteranno dal 11 dicembre 2027. In pratica, già nel 2026 i produttori di prodotti con elementi digitali devono attrezzarsi per essere in grado di rilevare, classificare e notificare vulnerabilità e incidenti secondo processi formalizzati. Questo richiede telemetria, asset visibility, software inventory, processi di triage e integrazione tra security engineering e funzioni regolatorie. 

La convergenza di queste normative produce un effetto molto concreto: la compliance non arriva più a ondate annuali, ma entra in esercizio continuo.

L’IT non facilita più il controllo, lo implementa

Nel modello tradizionale il team IT era spesso chiamato a “fornire supporto” ai controlli. Nel modello di compliance continua il team IT implementa i controlli. La differenza è sostanziale. NIST, nella guidance sulla sicurezza della software supply chain in pipeline DevSecOps, descrive la CI/CD come il flusso attraverso cui il software attraversa build, test, package e deploy. È esattamente in questo flusso che oggi vanno innestati i controlli di compliance. Se una regola richiede approvazioni su modifiche sensibili, scanning delle dipendenze, verifica di configurazioni sicure o enforcement di baseline, il posto corretto non è un foglio Excel di audit ma la pipeline stessa. 

Questo è il motivo per cui termini come policy-as-code, security-as-code e compliance automation stanno diventando centrali. Anche senza elevare questi concetti a nuova buzzword, la logica è chiara: una regola utile è una regola che può essere tradotta in test, query, controllo o remediation. NIST SP 800-204D insiste proprio sull’integrazione delle misure di sicurezza della supply chain nelle pipeline CI/CD, mentre il SSDF di NIST spinge a integrare la sicurezza lungo l’intero SDLC. La compliance continua porta questa impostazione un passo oltre: i controlli non devono solo esistere, devono produrre evidenza continua. 

In pratica, cambia il modo di progettare. Un’architettura cloud non deve solo essere scalabile e osservabile, ma anche in grado di dimostrare continuamente il rispetto delle baseline. Un sistema IAM non deve solo gestire autenticazione e autorizzazione, ma anche rendere facile verificare least privilege, MFA, segregazione dei ruoli e ciclo di vita degli accessi. Un data platform non deve solo funzionare, ma anche produrre tracce utilizzabili per data retention, audit trail e accountability.

DORA, AI, SBOM e supply chain: i nuovi stress test del team IT

Le aree in cui questo cambiamento si sente di più sono quelle in cui la regolazione incrocia direttamente l’operatività tecnica. DORA è il caso più evidente per il settore finanziario. La normativa non si limita a chiedere policy di continuità o gestione incidenti, ma introduce un quadro strutturato di ICT risk management, digital operational resilience testing e controllo sui fornitori ICT critici. Questo implica asset inventory affidabili, classificazione dei servizi, tracciabilità dei rapporti terzi, logging e capacità di reporting. Per il team IT significa operare con una granularità più alta e con una frequenza di aggiornamento molto più stretta. 

L’AI aggiunge un secondo livello di stress perché porta la compliance dentro il comportamento del software. Quando un sistema AI rientra in categorie regolamentate, non basta documentare il codice o il deployment. Servono governance dei dataset, logging delle decisioni, versioning dei modelli, misure di supervisione umana e monitoraggio post-market. Questo porta il team IT, insieme a data e product team, a doversi occupare di controlli che prima non esistevano nella software engineering classica. L’AI Act rende quindi la compliance più vicina a MLOps, observability e software quality engineering. 

La supply chain software è il terzo ambito critico. ENISA, nelle iniziative più recenti sulla sicurezza della supply chain e nell’advisory sui package manager, insiste sulla necessità di selezionare, integrare e monitorare in modo sicuro pacchetti e dipendenze di terze parti. La stessa logica sottesa allo SBOM è trasformare la visibilità sui componenti software da onere di compliance a vantaggio operativo. Per il team IT questo significa integrare software composition analysis, controllo licenze, gestione delle vulnerabilità e tracciabilità delle dipendenze dentro pipeline e cataloghi applicativi. 

Il vero cambiamento è architetturale, non amministrativo

Molte organizzazioni stanno ancora trattando la compliance continua come un problema di tooling. In realtà il nodo principale è architetturale. Un sistema diventa compliance-ready quando è progettato per generare evidenze, non quando gli si collega un tool GRC a valle. Questo vale per il logging strutturato, per la centralizzazione degli eventi, per la consistenza degli identificativi, per la modellazione degli accessi, per il versioning delle configurazioni, per la separazione dei ruoli operativi e per l’integrazione API con sistemi di inventory, ticketing e governance.

Per questo motivo la compliance continua spinge il ruolo di CTO e architetti verso nuove responsabilità. Devono progettare sistemi flessibili rispetto a nuovi requisiti regolatori, evitare silos che impediscono la raccolta di evidenze, definire standard di naming e tagging che semplifichino la correlazione tra asset, controlli e rischi, e scegliere piattaforme in grado di esporre lo stato dei controlli quasi in tempo reale. Deloitte descrive il continuous controls monitoring come una transizione dai modelli di testing a campione verso il monitoraggio più economico dell’intera popolazione dei controlli, con trasparenza e audit trail. Questa è una definizione che, letta dal lato IT, equivale a dire che l’architettura deve essere pensata per essere interrogabile. 

Dalla pressione normativa all’efficienza operativa

C’è però anche una seconda lettura, meno difensiva. La compliance continua aumenta il carico operativo, ma se implementata bene riduce il costo dell’improvvisazione. ISACA osserva che automazione e reporting possono ridurre il lavoro manuale intorno agli audit e trasformare la conformità in uno stato sostenuto nel tempo. In parallelo, IBM nel Cost of a Data Breach Report 2025 segnala un costo medio globale di 4,44 milioni di dollari per data breach e attribuisce parte della riduzione rispetto all’anno precedente a una identificazione e contenimento più rapidi. Non è corretto dire che la compliance continua da sola abbatta il costo del rischio, ma è ragionevole inferire che maggiore visibilità, raccolta strutturata di eventi e controlli meglio integrati contribuiscano a ridurre tempi di scoperta e contenimento. 

In altre parole, continuous compliance e operational resilience stanno convergendo. Quando un’organizzazione sa in ogni momento chi ha accesso a cosa, quali baseline sono fuori drift, quali pacchetti vulnerabili sono in produzione, quali log sono mancanti e quali eccezioni sono aperte, non sta solo preparando il prossimo audit. Sta gestendo meglio il rischio operativo.

Per una società di IT consulting questo tema è particolarmente rilevante perché mette in evidenza un bisogno che molte aziende hanno già, ma faticano a organizzare: trasformare richieste normative astratte in requisiti tecnici implementabili. È qui che il valore non sta nel produrre ulteriore documentazione, ma nel creare una compliance architecture. Significa partire dall’inventario degli standard rilevanti, mappare dove i controlli si appoggiano realmente in cloud, identity, applicazioni e pipeline, definire quali evidenze possono essere raccolte in automatico, quali controlli devono essere implementati come codice e quali dashboard servono a operations, security e audit.

Il contributo consulenziale più utile, oggi, non è solo “fare readiness” a una norma. È disegnare un modello operativo in cui DORA, AI Act, CRA, controlli di supply chain e requisiti interni non generino richieste spot al team IT ogni due settimane, ma si traducano in capability permanenti. Questo riduce l’attrito tra linee di difesa, alleggerisce la pressione pre-audit e rende il controllo più scalabile.

La compliance continua sta ridefinendo il ruolo del team IT in modo molto più profondo di quanto sembri. Non si tratta di aggiungere qualche report o di collegare un nuovo tool GRC. Si tratta di riconoscere che, nel 2026, il controllo passa sempre più dai sistemi, dalle pipeline e dall’architettura. Per questo il team IT smette di essere supporto occasionale e diventa pilastro operativo del risk management.

Per le aziende che continuano a gestire la compliance come un evento, il risultato sarà quasi certamente un aumento del lavoro manuale, più stress organizzativo e maggiore fragilità davanti ad audit, incidenti e nuove regole. Per quelle che investono in automazione, observability e compliance-by-design, la compliance continua può invece diventare una capacità industriale. Ed è esattamente qui che un IT consulting può fare la differenza: progettando sistemi in cui il controllo non sia un costo intermittente, ma una proprietà nativa dell’operatività digitale. 

Fonti citate:

• European Banking Authority. (2025). Digital Operational Resilience Act.
• European Banking Authority. (2025). Preparations for reporting of DORA registers of information.
• European Commission. (2025). AI Act timeline: Implementation of the EU AI Act.
• European Commission. (2026). Navigating the AI Act.
• European Commission. (2025). AI Act: Regulatory framework.
• European Commission. (2025). Cyber Resilience Act.
• European Commission. (2025). The Cyber Resilience Act: Summary of the legislative text.
• ESMA. (2025). Digital Operational Resilience Act (DORA).
• IBM. (2025). Cost of a Data Breach Report 2025.
• ISACA. (2023). How Automation Can Streamline Your Compliance Journey.
• ISACA. (2024). A proactive, continuous approach to automated compliance.
• NIST. (2011). Special Publication 800-137: Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations.
• NIST. (2022). Special Publication 800-218: Secure Software Development Framework (SSDF) Version 1.1.
• NIST. (2024). Special Publication 800-204D: Strategies for the Integration of Software Supply Chain Security in DevSecOps CI/CD Pipelines.
• ENISA. (2026). Technical Advisory for Secure Use of Package Managers.
• ENISA. (2025). SBOM Landscape Analysis: Towards an Implementation Guide.

Autore: Martina Pegoraro