Preparazione TISAX per i fornitori automotive

Un cliente del settore automotive vi chiede un risultato TISAX. Prima di assegnare le attività, stabilite quali obiettivi di assessment e quali sedi il cliente si aspetta di vedere. Questa richiesta determina il lavoro di assurance che dovete organizzare: sistemi, ambienti fisici, team responsabili ed evidenze.

TISAX è un meccanismo di assessment e scambio gestito da ENX, che utilizza il VDA Information Security Assessment (ISA). Produce risultati di assessment e label secondo le proprie regole, non un certificato sul modello ISO. Per un CTO, prepararsi significa collegare le aspettative del cliente ai controlli implementati, non semplicemente compilare un questionario.

Traducete la richiesta del cliente in un perimetro di assessment

Le richieste possono arrivare da un OEM o da un altro fornitore. Chiedete gli obiettivi esatti, le label attese, le tempistiche richieste e le sedi da coprire. Verificate quali persone giuridiche partecipano e se uffici di progettazione, stabilimenti produttivi, modalità di lavoro da remoto e servizi di supporto incidono sul confine.

Gli obiettivi di assessment determinano i requisiti pertinenti e la profondità dell’assurance. Sicurezza delle informazioni, protezione dei prototipi e protezione dei dati sono dimensioni importanti, ma non sostituiscono la selezione degli obiettivi specifici previsti dalle linee guida ENX in vigore.

I livelli di assessment descrivono la profondità dell’esame:

• AL1: autovalutazione per scopi interni; i risultati non vengono condivisi tramite TISAX e non ricevono label TISAX.
• AL2: una verifica di plausibilità dell’autovalutazione e delle evidenze a supporto.
• AL3: un assessment completo, comprensivo di esame in loco.

Consultate le informazioni TISAX e le linee guida per i partecipanti di ENX per confermare gli obiettivi applicabili, le modalità di assessment e la versione dell’ISA. Registrate il perimetro e selezionate un assessment provider autorizzato attraverso il processo previsto. Discutete per tempo prerequisiti e disponibilità; la scadenza fissata da un cliente non è una data di assessment garantita.

Il deliverable è una registrazione del perimetro con i criteri di accettazione del cliente, le sedi, gli obiettivi, le dipendenze, i responsabili e l’approccio di assessment concordato. Evitate sia ampliamenti del perimetro non necessari sia esclusioni che tralascino servizi a supporto delle informazioni protette.

Trasformate l’autovalutazione ISA in lavoro di implementazione

Compilate l’autovalutazione applicabile sulla base delle pratiche operative effettive. Quando un requisito prevede un livello di maturità obiettivo, spiegate in che modo la vostra implementazione sostiene la risposta anziché assegnare un punteggio in base alla sola esistenza di una politica.

Usate un registro di lavoro con requisito, descrizione dell’implementazione, responsabile, sede, riferimento all’evidenza, lacuna e azione correttiva. Assegnate la responsabilità del riesame oltre a quella della realizzazione: qualcuno dovrebbe verificare criticamente se l’evidenza dimostra l’affermazione.

Proteggete le informazioni di progettazione e l’IT di supporto

Seguite disegni riservati, codice sorgente, specifiche e dati dei clienti dalla ricezione attraverso collaborazione, archiviazione, consegna ed eliminazione. Verificate classificazione, permessi, condivisione esterna, accessi privilegiati, protezione degli endpoint, logging, ripristino dei backup e gestione degli incidenti.

Per esempio, un processo approvato per lo scambio di disegni dovrebbe indicare il canale consentito, i destinatari autorizzati, la scadenza degli accessi e la responsabilità per la rimozione degli accessi obsoleti. Una politica che vieta i link pubblici è un’evidenza debole se i team di progetto continuano a utilizzarli.

Valutate anche i fornitori esterni. Registrate quali servizi supportano il perimetro, chi li amministra, quali aspettative contrattuali di sicurezza si applicano e quali evidenze potete ottenere. Esternalizzare un servizio non vi esime dal comprenderne i controlli.

Stabilite controlli fisici locali e di protezione dei prototipi

Le politiche centrali possono valere per più sedi, ma ogni sede ha bisogno di evidenze dell’implementazione. Collegate le regole di accesso ai permessi dei badge, alle registrazioni dei visitatori, alle modalità di accompagnamento e alla rimozione degli accessi quando il personale lascia l’azienda.

Laddove si applichi la protezione dei prototipi, esaminate l’ambiente di gestione: zone ad accesso limitato, visibilità dall’esterno, divieti di fotografare, trasporto, deposito temporaneo e smaltimento approvato. Individuate il personale responsabile e documentate le consegne ove opportuno. I soli log di accesso digitali non dimostrano il controllo su un componente fisico.

Affrontate le persone e la protezione dei dati

L’HR dovrebbe supportare l’onboarding, gli impegni di riservatezza, la formazione specifica per ruolo e il coordinamento delle uscite del personale. Procurement, facility management ed engineering hanno bisogno di compiti espliciti anziché di un’istruzione generica a «supportare l’IT».

Laddove si applichino obiettivi di protezione dei dati, valutate i trattamenti e le responsabilità contrattuali pertinenti. Un risultato TISAX non attesta la conformità al GDPR; gli obblighi di legge dipendono comunque dal vostro ruolo e dalle vostre attività di trattamento.

Raccogliete evidenze che dimostrino il funzionamento

Le evidenze dovrebbero stabilire che cosa è accaduto, dove, quando e sotto la responsabilità di chi. Come raccomandazione pratica, usate le seguenti distinzioni quando riesaminate la prontezza:

Registrate le date delle evidenze, i sistemi di origine, le sedi e i revisori. Conservate le registrazioni storiche quando servono a spiegare il funzionamento e i cambiamenti. Uno screenshot vecchio non è automaticamente inutile, ma non può dimostrare la configurazione attuale senza un contesto a supporto.

Mantenete sotto controllo degli accessi le evidenze riservate dell’assessment. Evitate di raccogliere progetti dei clienti o informazioni personali non necessari quando una registrazione oscurata può dimostrare il controllo.

Automatizzate la raccolta ripetibile, non la responsabilità

Partite da attività ricorrenti con input e output chiari: esportazioni dei permessi, aggiornamenti dell’inventario degli asset, registrazioni della formazione, promemoria dei riesami e verifiche dell’attualità delle evidenze. Documentate prima il processo manuale, così che l’automazione non si limiti a riprodurre più velocemente un flusso di lavoro poco chiaro.

Per ogni raccolta automatizzata, specificate fonte, perimetro, frequenza, gestione degli errori e responsabile del riesame. Verificate se le esportazioni includono tutte le sedi e tutti i tipi di account pertinenti. Un job di raccolta riuscito può comunque tralasciare le identità dei collaboratori esterni o la rete di uno stabilimento gestita separatamente.

Quando valutate gli strumenti, mettete alla prova la tracciabilità delle evidenze, la titolarità per sede, la gestione delle versioni, le decisioni di riesame e l’usabilità delle esportazioni. Chiedete separatamente come vengono rappresentate le evidenze sui prototipi; una mappatura della sicurezza delle informazioni non dimostra la protezione fisica dei prototipi. Non date per scontato che il formato di output di uno strumento venga accettato senza aver discusso con l’assessor le aspettative sulle evidenze.

Esempio pratico: due sedi, un unico processo di progettazione

Supponiamo, a titolo illustrativo, che un fornitore gestisca un ufficio di progettazione e un’officina prototipi. Il suo cliente richiede obiettivi che coprano le informazioni riservate di sviluppo e la protezione dei prototipi in entrambe le sedi.

Il team di engineering individua il repository dei progetti e il servizio di scambio. Il facility management mappa gli accessi all’officina e la gestione dei visitatori. Un riesame rileva che i permessi del repository vengono riesaminati a livello centrale, ma che gli accessi all’officina includono ancora due dipendenti trasferiti.

L’azione correttiva rimuove quei permessi, assegna un revisore locale e registra la data del prossimo riesame. Le evidenze comprendono le registrazioni degli accessi prima e dopo, la decisione di approvazione e la procedura aggiornata dell’officina. La risposta dell’autovalutazione fa riferimento a queste registrazioni e indica la sede interessata. In questo modo rilievo, rimedio e implementazione diventano tracciabili, senza trattare la politica centrale come prova valida per entrambe le sedi.

Mantenete utilizzabile il ciclo di assessment

Prima dell’assessment, provate con i responsabili dei controlli il recupero delle evidenze e concordate chi gestisce i rilievi. Seguite le azioni correttive fino all’implementazione e alla nuova valutazione, come richiesto dal processo del provider. Verificate come i risultati verranno condivisi con il cliente richiedente nel rispetto delle regole ENX. Le label TISAX hanno in genere una validità di tre anni; mantenete i controlli e considerate le modifiche del perimetro tra un assessment e l’altro.

Secani offre uno spazio di lavoro integrato per requisiti, responsabili, attività ed evidenze. I team possono collegare ai controlli registrazioni specifiche per sede, tenere traccia delle lacune e conservare le decisioni di riesame umane. Una preparazione strutturata agli audit aiuta a riutilizzare il lavoro comune senza perdere il contesto locale.

Partite dagli obiettivi richiesti dal cliente, poi selezionate un flusso di informazioni critico e seguite le registrazioni che ne dimostrano la protezione in ogni sede inclusa.