PR19.1 - Gestione del Cambiamento

Procedura di Gestione del Cambiamento

Revisioni

Rev.	Data	Descrizione	Redatto	Approvato
0.0	24/04/2026	Prima emissione	RSGI	Amministratore Unico

Introduzione

Il presente documento definisce il modello adottato da Vectorlab per la gestione dei cambiamenti (o “change”) che possono impattare il SGI. Un processo efficiente di gestione del cambiamento è infatti essenziale al fine di garantire che ciascun cambiamento sia compatibile con le esigenze di business e che i requisiti di sicurezza dei sistemi informativi vengano rispettati e mantenuti nel tempo.

Tale procedura descrive i principi di gestione e di sicurezza del processo di gestione del cambiamento, identificando i principali attori e definendo linee guida, regole e controlli che devono essere implementati al fine di raggiungere l’obiettivo di gestione dell’attività dei processi accompagnato da reportistica e tracciamento dei cambiamenti.

Riferimenti e Allegati

MDPR08.1.A – Elenco Informazioni Documentate

PR33.1 – Processo Analisi del Rischio e Trattamento

PO25 – Sviluppo Sicuro

PO30 – Privacy by design e by default

PR20.1 – Capacità, Logging e Monitoraggio Tecnico.

Definizioni, Acronimi, Abbreviazioni

AdS – Amministratore di Sistema

CDA – Funzioni dell'organo di amministrazione, esercitate dall'Amministratore Unico (società a socio unico e amministratore unico)

CISO – Chief Information Security Officer

CTO - Chief Technical Officer

DPO – Data Protection Officer

RFC – Request for Change (Richiesta di Cambiamento)

RSGI – Responsabile del Sistema di Gestione Integrato

SGI – Sistema di Gestione Integrato.

Procedura di Gestione del Cambiamento

I cambiamenti sono necessari e frequenti nel settore delle tecnologie dell'informazione; ad esempio, aggiornare la configurazione di un server, acquisire nuovi sistemi, aggiornare processi, politiche, procedure, ruoli e responsabilità all'interno dell'organizzazione sono tutti cambiamenti che l’azienda ha necessità di tracciare.

I cambiamenti possono quindi riguardare l’organizzazione, lo sviluppo di nuove funzionalità, l’implementazione di nuovi processi e procedure, il cambiamento o dismissione di un servizio o la dismissione di un’apparecchiatura o l’introduzione di nuovi dispositivi.

I cambiamenti informatici in particolare riguardano tutti gli ambienti: infrastrutture (server e cliente), hardware, software, middleware, applicazioni e sistemi di sicurezza.

I cambiamenti possono essere di diversa complessità:

• un cambiamento hardware o infrastrutturale può riguardare la sostituzione di un singolo hard disk o di un intero server, fino ai progetti di modifica dell'intera rete;

• un cambiamento di sistema operativo (o di un software di base o di un middleware) può riguardare un piccolo cambio di configurazione, l'installazione di un fix, l'aggiornamento della versione o la migrazione su nuove piattaforme;

• un cambiamento al servizio Cloud;

• un cambiamento di un'applicazione può riguardare piccole modifiche grafiche, correzioni di errori, fino a comprendere aggiunte di funzionalità, adattamenti a nuove infrastrutture e l'installazione di interi nuovi servizi.

Un cambiamento può essere correttivo, ossia originato dalla necessità di correggere un errore come un guasto hardware o un difetto software (bug) o evolutivo volto a migliorare le prestazioni o funzionalità esistenti.

L’origine di un cambiamento può anche essere esterna: in particolare, alcune modifiche ad asset fruiti dall’azienda, tra cui infrastruttura e software in modalità cloud, possono causare impatti sulle risorse e sull’operatività di Vectorlab, tali da necessitare la definizione e la successiva implementazione di un cambiamento.

Un tipo di cambiamento è inoltre quello in emergenza e si attua in caso di incidente o rilevazione di gravi vulnerabilità. Questo tipo di cambiamento richiede di essere effettuato molto più velocemente dei precedenti. Ogni cambiamento deve essere tenuto sotto controllo, in modo da non introdurre involontariamente delle vulnerabilità nei sistemi informatici e nel sistema di gestione della sicurezza delle informazioni. Va quindi definito e attuato un processo con ruoli e responsabilità ben definite.

Di seguito le attività che definiscono il processo di gestione dei cambiamenti (change management).

Figura 1 - Fasi del processo

Per registrare i cambiamenti e gestire tutte le fasi di processo viene usato il tool aziendale XX”. Questo permette di tracciare gli stati delle operazioni e i loro responsabili. La registrazione permette di ricostruire quanto è stato fatto in caso di problemi e non saltare i passaggi previsti dal flusso del processo. Nella tabella sottostante sono descritti in dettaglio le fasi del processo ed i relativi owner.

Figura 2 – Flusso attività

Richiesta di cambiamento

Tutti i dipendenti possono suggerire modifiche o cambiamenti al proprio Responsabile di Area che si occuperà di effettuare una prima analisi e valutazione della proposta. Nel caso in cui tale prima analisi risultasse positiva, il Responsabile dell’Area interessata, provvederà ad aprire una change attraverso il tool aziendale XXX.

Analisi

2. 2. 1. Classificazione e tipologie di cambiamento

Dal momento che è la classificazione della change a determinare il flusso di attività che portano alla sua esecuzione, è importante conoscere quali sono le tipologie di cambiamento che è possibile richiedere a fronte di specifiche esigenze di business.

In generale, tutte le richieste relative a change manutentive / infrastrutturali / applicative sono in carico al Reparto IT mentre quelle relative a change organizzative e procedurali sono in carico a RSGI.

Le tipologie di cambiamento sono le seguenti:

• Major change – Sono i cambiamenti ad alto impatto e ad alto rischio che potrebbero influenzare i sistemi di produzione. La loro approvazione da parte del CISO o della Direzione è necessaria. L’impatto sulle attività operative è molto grande e ha anche implicazioni finanziarie.

• Standard change – Sono, di solito, modifiche pre-approvate e hanno un basso impatto e un basso rischio. Queste modifiche avvengono in un intervallo regolare e seguono un modello standard. L’approvazione del CISO o della Direzione non è richiesta in quanto queste modifiche sono valutate e approvate inizialmente.

• Minor change – Sono generalmente normali modifiche che non hanno un grande impatto e non sono rischiose da eseguire. Tra queste si identificano: aggiornamenti di plug-in, sistemi operativi etc.

• Emergency change – Sono interruzioni inaspettate che devono essere risolte il più velocemente possibile. Non seguono il ciclo di vita convenzionale, e la Change viene gestita in termini di registrazioni dopo l’implementazione. CISO e Direzione sono responsabili della gestione delle approvazioni.

TIPOLOGIA CHANGE	GESTIONE
Minor	Risultano tracciate nei log delle attività di sistema o dell’applicativo e non richiedono altra tipologia di registrazione
Major	Tracciate come Service Request sullo strumento di ticketing seguendone il flusso
Standard	Tracciate come Change, chi apre il ticket valorizza il campo “Change type” a “Major” sullo strumento di ticketing
Emergency	Tracciate come Change, chi apre il ticket valorizza il campo “Change type” a “Emergency” sullo strumento di ticketing

Tabella 1 - Classificazione change

Le richieste classificate come Major Change (tra cui ad esempio le modifiche rilevanti sulle componenti critiche, gli adeguamenti in conseguenza di fusioni o scissioni o la migrazione ad altre piattaforme informatiche) devono essere sottoposte all’attenzione del CISO ed all’approvazione della Direzione. Spesso la disponibilità di patch e aggiornamento di software viene notificata direttamente dal produttore. Il personale IT è incaricato di verificare periodicamente che i programmi e le relative caratteristiche di sicurezza siano aggiornate, come descritto in “IT - PR20.1 – Capacità e monitoraggio tecnico”.

Le Emergency Change possono essere gestite con modalità e flussi operativi non pienamente conformi alle politiche ordinarie, ma comunque adeguati alla particolare situazione. In virtù della loro natura eccezionale di urgenza, preventivamente concordata con i vertici aziendali, possono essere documentate anche a posteriori. Tali modifiche sono comunque sottoposte a tracciamento ex post e notificate al CISO e al CTO.

Le classificazioni del change possono essere le seguenti:

• Organizzativi: riguardano la struttura dell’organizzazione, e la documentazione a supporto della stessa (es. ingresso di un nuovo dipendente);

• Tecnologici / Infrastrutturali: riguardano gli strumenti tecnologici usati dal personale per svolgere le proprie attività, e l’infrastruttura IT adottata dall’azienda (es. installazione di nuovo cluster di server).

In generale, a seconda della tipologia di change, il suo ciclo di vita segue le regole definite nella figura sottostante.

Figura 3 - Ciclo di vita della change

Richiesta

1. 1. Identificazione di una esigenza

Qualsiasi stakeholder (dipendente interno, collaboratore esterno, fornitore, cliente) ravvisi la necessità o l’opportunità di un cambiamento relativo all’organizzazione, all’infrastruttura o ai servizi erogati da Vectorlab può sollevare un’esigenza di cambiamento. Ad esempio, essa può essere generata da:

• Insoddisfazione di un Cliente su un servizio

• Modifiche di prodotti o servizi da parte di fornitori

• Presa in carico di un servizio prima erogato da un fornitore

• Ingresso di una nuova risorsa in Azienda

• Risoluzione di incidenti o problemi infrastrutturali

• Messa in esercizio o modifica di una infrastruttura

• Interventi di manutenzione programmata che generano impatti sui servizi.

  1. Formalizzazione della Request For Change (RFC)

L’esigenza di cambiamento perviene al Responsabile della risorsa, il quale si occuperà di effettuare una prima analisi e valutazione della proposta. Nel caso in cui tale prima analisi risultasse positiva, egli provvederà ad aprire una Request for Change (o “RFC”) sul sistema di ticketing aziendale.

Di fondamentale importanza, nell’apertura del ticket, è la compilazione dei campi relativi alla descrizione della change; è infatti necessario indicare più informazioni possibili rispetto all’esigenza dalla quale è scaturita la richiesta. Nello specifico, ogni RFC deve essere sempre corredata da informazioni quali:

• tipologia di change (organizzativo, infrastrutturale, sul servizio) e sua classificazione,

• servizi impattati,

• livello di rischio e di urgenza per la sua esecuzione.

Tutte le informazioni a corredo della RFC sono importanti per poter successivamente effettuare un’analisi più approfondita dell’effort e delle conseguenze del cambiamento sulle attività operative e provvedere alle opportune comunicazioni prima, durante e dopo l’implementazione.

I campi da compilare con le informazioni inerenti alla change e la sua classificazione e qual è l’assegnatario che ha in carico la gestione del ticket sono descritti in “IOPR05.1.B – Utilizzo sistema di ticketing XXX”.

Analisi

A seconda della tipologia di cambiamento, il sistema assegna automaticamente la change ad uno specifico assegnatario, il quale prende in carico il ticket e procede alla sua gestione.

In generale:

• le richieste relative a change organizzativi e procedurali sono in carico a RSGI;

• le richieste relative a change tecnologici/infrastrutturali sono in carico al Resp. IT.

  1. 1. Valutazione dell’impatto e determinazione della priorità

Ricevuta la richiesta di change, l’assegnatario effettua una valutazione dell’impatto per attribuire una priorità di esecuzione del cambiamento proposto, eventualmente coadiuvato dal Responsabile che ha aperto il ticket, considerando elementi quali: requisiti di business (es. esigenze dei Clienti), problematiche di compliance (es. coinvolgimento di dati personali), rischi per la sicurezza delle informazioni (es. per rispondere ad incidenti o risolvere problemi), facilità e rapidità di implementazione (in termini di tempo, effort e costi di attuazione).

La valutazione dell’impatto è importante anche per stabilire il tipo di comunicazione da fare verso gli stakeholders, che siano gli utenti interni all’Organizzazione o i fornitori ma soprattutto i Clienti impattati dalle attività di implementazione della change.

In caso di cambiamenti per cui è previsto il contributo, o la completa esecuzione, da parte di fornitori esterni, le attività di analisi sono commissionate inviando apposita richiesta, previa approvazione della Direzione, e si concludono con la ricezione di uno studio di fattibilità ed eventualmente della quotazione economica per la realizzazione.

1. 2. 2. Analisi di dettaglio per la gestione del rischio

Affinché siano garantite la qualità del cambiamento e la coerenza con la richiesta ricevuta, si rende necessaria un’analisi di fattibilità del cambiamento richiesto, anche in termini di rischio. In particolare, i requisiti di sicurezza vanno stabiliti prima di approvare ed attuare un cambiamento e devono essere adeguati al livello di rischio calcolato per le informazioni trattate dal sistema e per la protezione dei dati personali, qualora trattati.

Questo principio va attuato per:

• lo sviluppo di applicazioni, per cui i requisiti di sicurezza vanno stabiliti sin dalle prime analisi funzionali e tecniche, anche per garantire la corretta protezione dei dati personali (cfr. “PO30 - Privacy by design e by default”);

• la modifica di applicazioni, per cui devono essere sempre valutati gli impatti della modifica sui meccanismi di sicurezza già esistenti e i requisiti da prevedere per i nuovi moduli o oggetti (per esempio, quando si aggiungono moduli ad un'applicazione, l'accesso deve essere controllato in modo simile agli altri moduli);

• l'acquisizione di prodotti hardware e software, per i quali i requisiti di sicurezza devono essere stabiliti prima di avviare la ricerca del prodotto;

• la modifica di configurazioni hardware, software o infrastrutturali (inclusi i ritiri di componenti), per cui è necessario stabilire su quali meccanismi di sicurezza preesistenti potrebbe avere impatto tale modifica;

• la modifica di processi di business o al sistema di gestione per cui, analogamente, è necessario comprendere eventuali criticità sulla sicurezza delle informazioni e rispetto della protezione dei dati personali.

Le analisi di dettaglio che possono essere svolte (anche in base alla tipologia di change) sono:

• analisi funzionale, finalizzata a comprendere la richiesta, a valutare e proporre soluzioni vantaggiose dal punto di vista tecnico-economico e a formalizzare le stesse in un linguaggio che ne definisca in modo quanto più preciso possibile i contenuti e sia facilmente integrabile con tutti i dettagli tecnici necessari alla definizione dell’analisi tecnica; quest’analisi è in carico al Richiedente della change;

• analisi tecnica, finalizzata a declinare i requisiti tecnologici, derivati dall’analisi funzionale, per l’implementazione della richiesta; quest’analisi è in carico a IT (AdS) e al Responsabile dell’Area di competenza a cui afferisce la change;

• analisi di sicurezza, finalizzata a verificare che il cambiamento richiesto non abbia effetti impattanti sulla sicurezza delle informazioni aziendali e dei sistemi e processi relativi al SGI; questa analisi è in carico al CISO, in collaborazione con IT, RSGI e DPO qualora la change avesse impatti o trattasse dati personali.

TIPO ANALISI	PERSONALE COINVOLTO
	Richiedente	Resp. Area	IT	CISO	RSGI	DPO
Funzionale	X
Tecnica		X	X
Sicurezza			X	X	X	X

Tabella 2 - Ruoli e responsabilità per analisi change

L'analisi degli impatti sui sistemi preesistenti deve valutare se i seguenti meccanismi di sicurezza rimangono validi anche dopo il cambiamento:

• sistemi di monitoraggio;

• sistemi di log;

• controllo degli accessi al sistema e ai dati;

• meccanismi di controllo della rete (firewall, IDS, eccetera);

• sistema di backup;

• prestazioni hardware;

• interfacciamenti e comunicazioni con altri sistemi;

• disponibilità servizi SaaS erogati.

Al fine di agevolare l’analisi dei requisiti è stata predisposta una checklist (Allegato A - Requisiti di sicurezza eleggibili) in cui sono riportati i requisiti da considerare quando si apportano cambiamenti ai sistemi informatici.

In caso di Change rivolte verso outsourcer e/o fornitori critici, le attività di analisi sono commissionate inviando una apposita richiesta, previa approvazione da parte di CISO, CTO e della Direzione, e si concludono con la ricezione di uno studio di fattibilità ed eventualmente della quotazione economica per la realizzazione.

Qualora in fase di analisi emerga, come conseguenza della modifica, una variazione del rischio alla sicurezza delle informazioni associato ad una o più risorse IT, è necessario che sia eseguita nuovamente l’analisi del rischio sulla sicurezza delle informazioni associato a tali risorse e che il nuovo rischio residuo sia accettato, secondo i criteri definiti nel processo di analisi e trattamento del rischio definito in “PR33.1 – Processo Analisi del Rischio e Trattamento”.

Le Emergency change possono essere gestite con modalità e flussi operativi non pienamente conformi alle politiche ordinarie, ma comunque adeguati alla particolare situazione. In virtù della loro natura eccezionale di urgenza, preventivamente concordata con i vertici aziendali, possono essere documentate anche a posteriori. Tali modifiche sono comunque sottoposte a tracciamento ex post e notificate al CISO e al CTO.

Autorizzazione

A seguito delle attività di analisi, o della ricezione dello studio di fattibilità e della quotazione economica da parte del fornitore, la change deve essere approvata per poter essere implementata. A seconda del tipo di change, l’autorizzazione (o negazione) all’esecuzione delle attività di cambiamento è demandata a soggetti differenti, secondo la tabella seguente:

TIPOLOGIA DI RFC	SOGGETTI AUTORIZZATORI
Minor change	Autorizzazione non richiesta
Standard change (Service Request)	Responsabile (a seconda del tipo di richiesta: RSGI, Resp. IT, Service Manager)
Major change	Direzione
Emergency	Direzione (ha la responsabilità di avviare il processo di gestione della Emergency change stabilendo l’effettiva situazione di emergenza)

Tabella 3 – Autorizzazioni

Pianificazione ed implementazione

Una volta autorizzato il cambiamento, a seconda della tipologia di change da implementare verranno coinvolte le opportune funzioni aziendali con le competenze necessarie per procedere con le attività di pianificazione e successiva implementazione della change.

L’assegnatario del ticket si assicura che tutta la documentazione inerente alle varie fasi del processo sia correttamente allegata al ticket, in maniera tale da essere sempre disponibile.

Nella fase di pianificazione devono essere indicate le attività previste per attuare il cambiamento, le scadenze e le responsabilità.

Anche per attività di breve o brevissima durata vanno garantiti tempi e risorse sufficienti per determinare i requisiti di sicurezza, sviluppare correttamente quanto necessario e condurre test di sicurezza significativi.

Nei casi di cambiamenti relativi ai servizi, sarà compito del Service Manager (SM) stabilire una pianificazione delle attività e fare da punto di contatto tra l’Azienda ed il Cliente.

Per quanto riguarda le change che richiedono attività di sviluppo, ricevuta l’autorizzazione all’implementazione, il personale dedicato pianifica e avvia le attività finalizzate alla realizzazione della modifica richiesta in maniera conforme a “PO25 – Sviluppo Sicuro”. Qualora siano necessarie competenze afferenti ad altre aree il Responsabile dell’Area organizza le attività.

In tutti i casi in cui la richiesta di cambiamento non riguardi attività di sviluppo, essa verrà pianificata ed eseguita dall’Area di business ritenuta più consona, che la svolgerà nel rispetto delle linee guida stabilite dalle politiche e procedure inerenti al SGI aziendale, sotto la diretta supervisione e il monitoraggio periodico del CISO, o suo delegato. Qualora siano necessarie competenze afferenti ad altre aree, il Responsabile dell’Area organizza le attività.

In ogni caso, eventuali principi di ingegnerizzazione e le tecniche di sviluppo da adottare vanno descritti in procedure distribuite al personale e agli eventuali fornitori coinvolti nelle attività. Gli addetti devono essere adeguatamente competenti per realizzare quanto richiesto senza commettere errori.

Quando il cambiamento è un vero e proprio progetto, il soggetto autorizzatore della change può nominare un Project Manager (PM) con il compito di definire un piano operativo di realizzazione del cambiamento e supervisionare le attività. Il piano sarà allegato al ticket e dovrà contenere l’elenco delle attività previste per attuare il cambiamento, le scadenze e le responsabilità; ove necessario, dovranno essere indicati i riferimenti ai requisiti legislativi o normativi che presuppongono lo svolgimento di quella attività.

L’assegnatario della change supervisiona la realizzazione del cambiamento e mantiene aggiornata la Direzione sui progressi e sugli esiti delle attività svolte.

Riesami, verifiche e test

In corso di implementazione, in particolare di cambiamenti complessi, l’assegnatario della change monitora lo stato di avanzamento delle attività coinvolgendo i gruppi di lavoro e le parti interessate per evidenziare, per tempo, eventuali criticità e necessità di ripianificazione.

A seconda della tipologia e complessità della change, sono effettuati test per verificare la rispondenza del cambiamento ai requisiti e che tutto funzioni correttamente prima che venga effettivamente rilasciato. Relativamente alla sicurezza, i test svolti riguardano:

• test funzionali, in cui sono verificate le funzioni di sicurezza;

• test non funzionali, in cui è verificato il codice e l’architettura;

• test di non regressione, in cui sono verificate funzionalità non oggetto del cambiamento, ma che, a causa delle interrelazioni tra i componenti del sistema, potrebbero presentare errori dovuti al cambiamento;

• vulnerability assessment;

• …..

I test sono pianificati e documentati in un rapporto, allegato al ticket. Sono registrati tutti i test, anche quelli con esito negativo che sarà accompagnato da un piano di rientro.

Rilascio e chiusura

Una volta terminate le fasi di implementazione e test, l’assegnatario notifica il soggetto autorizzatore (tramite strumento di ticketing) del completamento dell’attività, allegando le informazioni necessarie per permetterne l’approvazione al fine della chiusura del ticket.

Il soggetto che ha aperto il ticket (Richiedente) verifica la completezza della documentazione necessaria per il ticket e chiude la change. Nel caso il suo account sul sistema di ticketing aziendale non lo permetta, può richiedere la chiusura all’assegnatario.

Tutta la documentazione prodotta nel corso delle varie attività processuali viene adeguatamente archiviata e conservata al fine di permettere analisi ex-post.

Allegato A - Requisiti di sicurezza eleggibili

R.1 Requisiti funzionali di controllo accessi
Meccanismi per la gestione degli utenti (inserimento, modifica dei diritti di accesso, sospensione, cancellazione) o garanzia di interfacciamento con strumenti già in uso presso l'organizzazione
Livello di dettaglio con cui si possono impostare i diritti di accesso ai sistemi (singola funzionalità, singola transazione, eccetera)
Disponibilità di documentazione sui ruoli predefiniti e di tecniche per disattivarli
Opzione "cambia la password al primo utilizzo" quando si inserisce un nuovo utente o quando la password è modificata dagli amministratori di sistema (per esempio se l'utente l'ha dimenticata);
Campo dove inserire la password tale che sia nascosta
Possibilità di bloccare l'utenza dopo un certo numero di tentativi errati di inserimento della password (da non applicare a tutti gli amministratori di sistema perché, in caso di attacco, nessuno potrebbe più accedere al sistema)
Modalità di recupero delle password di amministrazione, se presenti
Possibilità di assegnazione a più utenti dei poteri di amministrazione, anche su singole parti del sistema
Personalizzazione delle credenziali per gli amministratori di sistema
Controllo automatico delle caratteristiche delle password in modo che gli utenti non le scelgano banali: complessità (devono essere presenti lettere e numeri; oppure lettere minuscole, lettere maiuscole e numeri e caratteri speciali), lunghezza (minimo 8 caratteri), scadenza (anche siano cambiate almeno ogni 3 mesi), blocco in caso di inattività dell'utente (dopo non più di 6 mesi), non ripetibilità delle ultime 5 o 10 password
Controllo automatico della non banalità delle password; es password non nel dizionario, non una variazione della user-id come Cesare1970, non una variazione del nome dell'applicazione come Oracle70, non una password popolare come 12345678 (queste regole sono considerate alternative e più sicure di quelle relative alla complessità descritta sopra);
Configurazione affinché gli utenti siano sconnessi dopo 5 o 10 o più minuti di inattività
Configurazione affinché gli utenti non possano connettersi in specifici orari
R.2 Requisiti sulla connettività
Possibilità di rendere obbligatorio l'uso di connessioni cifrate per accedere al sistema
Modalità di interfacciamento con altri programmi o con l'utente che preveda connessioni cifrate, scambio di certificati digitali, autenticazione reciproca senza utenze di amministrazione o generiche
R.3 Requisiti funzionali relativi alla crittografia
Memorizzazione dei dati con cifratura
Meccanismi di firma o logging se devono essere garantiti certi livelli di non ripudiabilità delle attività
Protocolli crittografici sicuri e adeguati agli standard applicabili (AES per la crittografia a chiave privata, RSA per la crittografia a chiave pubblica, DSS del NIST FIPS 186-3 per le firme, FIPS 140-2 Annex C per la generazione di numeri casuali, eccetera)
Accesso alle chiavi crittografiche limitato ai soli amministratori di sistema o solo a processi interni del software
Chiavi crittografiche generate secondo metodi sicuri, partendo da seed generati casualmente
R.4 Requisiti di monitoraggio
Disponibilità di log applicativi e log delle attività degli amministratori di sistema
Meccanismi per garantire la sicurezza dei log
Meccanismi per stabilire la durata della conservazione dei log
Modalità di collegamento del sistema ai sistemi di monitoraggio già in uso
Clock sincronizzabile con un NTP server
R.5 Requisiti di capacità
Numero di utenti per cui il sistema garantisce prestazioni accettabili
R.6 Requisiti architetturali
Modularità del sistema, in modo che sue diverse componenti possano essere installate in ambienti diversi
Separazione del sistema da altri sistemi, per evitare accessi non autorizzati