Obiettivi di apprendimento
- Descrivere la genesi e la struttura del quadro ISPS Code.
- Distinguere i ruoli di CSO, SSO e PFSO e le rispettive responsabilità.
- Comprendere i tre livelli di sicurezza e le loro implicazioni operative.
- Ricostruire il processo dallo Ship Security Assessment allo Ship Security Plan.
- Riconoscere la crescente convergenza tra sicurezza fisica e cyber security a bordo.
- Comprendere la struttura di un percorso di risposta a un evento di sicurezza.
Genesi del quadro ISPS
Distinguere campo di applicazione, gerarchia e natura giuridica di SOLAS XI-2, Parte A e Parte B dell’ISPS Code, Regolamento (CE) n. 725/2004 e guidance di settore.
Campo internazionale: navi passeggeri, incluse unità veloci; navi da carico, incluse unità veloci, di almeno 500 GT; unità mobili di perforazione offshore, impegnate in viaggi internazionali, e impianti portuali che le servono. Navi da guerra, ausiliarie navali e altre navi governative adibite esclusivamente a servizi non commerciali sono escluse. Nell’UE il Regolamento 725/2004 estende il regime anche alle navi passeggeri di classe A in servizio nazionale e prevede decisioni nazionali per altre categorie domestiche. Non ogni nave né ogni intera area portuale ricade automaticamente nello stesso perimetro.
L'International Ship and Port Facility Security (ISPS) Code nasce come risposta diretta agli attacchi dell'11 settembre 2001, che hanno spinto la comunità marittima internazionale a introdurre un quadro di sicurezza specificamente dedicato alla protezione da atti dolosi, distinto dalla safety già disciplinata dall'ISM Code.
Il percorso normativo
Il quadro nasce dalla Conferenza dei Governi contraenti alla SOLAS tenutasi a Londra dal 9 al 13 dicembre 2002, che ha creato il nuovo capitolo XI-2 — rinumerando in XI-1 il capitolo XI preesistente — e ha adottato il Codice. L'ISPS è entrato in vigore il 1° luglio 2004.
Il Codice si concentra sulla prevenzione di atti dolosi contro navi e impianti portuali. I §§1.2 e 1.3 della Parte A ne fissano obiettivi e requisiti funzionali in termini di security threats e security incidents: raccogliere e scambiare informazioni sulle minacce, mantenere protocolli di comunicazione, impedire l'accesso non autorizzato a navi, impianti e aree ad accesso ristretto, impedire l'introduzione di armi, dispositivi incendiari o esplosivi, disporre di mezzi per dare l'allarme, fondare i piani su valutazioni di sicurezza e assicurare addestramento ed esercitazioni.
La Parte A è obbligatoria nel regime SOLAS XI-2. La Parte B contiene guidance da tenere in considerazione; specifici paragrafi diventano obbligatori anche attraverso norme regionali o nazionali. Nell’UE l’articolo 3(5) del Regolamento (CE) n. 725/2004 rende vincolanti, fra gli altri, B/13.6 e B/13.7 su drills ed exercises. Verificare insieme campo di applicazione, disposizioni della bandiera e SSP approvato.
La distinzione tra safety (sicurezza da eventi accidentali, disciplinata dall'ISM Code) e security (sicurezza da atti intenzionali, disciplinata dall'ISPS Code) è concettualmente netta, anche se in pratica i due sistemi di gestione si intrecciano e si sovrappongono a bordo.
Non è corretto escludere la pirateria dal perimetro della valutazione security ISPS. La Parte B §8.9 contempla, fra gli scenari da considerare, dirottamento o sequestro della nave e delle persone e attacchi dal mare. Le BMP Maritime Security forniscono guidance operativa aggiuntiva per le minacce del viaggio: non sostituiscono SSA e SSP e non sono, in quanto tali, testo del Codice. La loro applicazione va coordinata con disposizioni della bandiera e piano approvato.
Gerarchia applicabile. La Parte A contiene i requisiti obbligatori internazionali; la Parte B è guidance che i Governi contraenti devono considerare. Nell’Unione europea, però, il Regolamento (CE) n. 725/2004 rende obbligatori specifici paragrafi della Parte B, inclusi standard dell’SSP e frequenze di drills ed exercises. Occorre quindi leggere insieme SOLAS XI-2, Parte A, Parte B, diritto UE, regole di bandiera e SSP approvato.
- Il regime internazionale obbligatorio deriva da SOLAS XI-2 e dalla Parte A del Codice.
- La Parte B è guidance a livello internazionale, ma nell’Unione europea alcuni suoi paragrafi sono resi obbligatori dal Regolamento (CE) n. 725/2004.
- BMP e altra guidance di settore integrano l’applicazione operativa, senza diventare per questo testo dell’ISPS Code.
I ruoli chiave: CSO, SSO, PFSO
Distinguere responsabilità, interfacce e limiti di CSO, SSO, PFSO, Comandante, Amministrazione e RSO, evitando di trasferire compiti fra nave, compagnia e port facility.
Il quadro ISPS si regge su tre figure chiave, ciascuna con un ambito di responsabilità distinto, che devono coordinarsi efficacemente per garantire la continuità della sicurezza dalla nave al porto.
| Ruolo | Ambito | Responsabilità principale |
|---|---|---|
| CSO — Company Security Officer | A terra, per una o più navi identificate dalla compagnia | Assicura SSA e sviluppo, presentazione per approvazione, attuazione, mantenimento e modifica degli SSP delle navi identificate |
| SSO — Ship Security Officer | A bordo, per la singola nave | Implementazione dello Ship Security Plan (SSP); addestramento dell'equipaggio; segnalazione di incidenti |
| PFSO — Port Facility Security Officer | Presso l'impianto portuale | Sicurezza dell'impianto; coordinamento con le navi in arrivo/partenza |
Tabella 2.1 — I tre ruoli chiave del quadro ISPS.
Le criticità più comuni nel quadro ISPS non nascono dall'assenza dei ruoli, ma da un coordinamento insufficiente tra loro: un SSO che non comunica tempestivamente con il PFSO all'arrivo in porto, o un CSO che non aggiorna gli SSO su minacce emergenti, indeboliscono l'intero sistema anche se ogni singolo ruolo è formalmente presidiato.
Ruoli e deleghe. Il CSO assicura SSA e sviluppo, presentazione per approvazione, attuazione, mantenimento e modifica degli SSP delle navi identificate: l’ISPS non istituisce un piano security di compagnia equivalente all’SSP. Il PFSO opera per una port facility. Una RSO può assistere nella preparazione di PFSA/PFSP ma non approvarli; se prepara SSA o SSP non deve approvare lo stesso piano. I sei compiti del §4.3 restano non delegabili.
- Il CSO assicura SSA e SSP per le navi identificate; l’ISPS non prevede un “piano security di compagnia” equivalente all’SSP.
- Il PFSO opera per una port facility, non automaticamente per l’intero porto.
- La delega a un RSO è limitata dalle decisioni riservate e dai requisiti d’indipendenza fra preparazione e approvazione.
I livelli di sicurezza
Comprendere chi stabilisce i security level, come si applicano nelle interfacce ship/port facility e quali poteri restano al Comandante.
Il quadro ISPS definisce tre livelli di sicurezza crescenti, che determinano l'intensità delle misure da applicare a bordo e presso l'impianto portuale in base al livello di minaccia percepito.
| Livello | Implicazioni operative tipiche |
|---|---|
| 1 — Normale | Misure minime costantemente mantenute: controllo accessi, sorveglianza generale, verifica documentale |
| 2 — Intensificato | Misure aggiuntive per un periodo limitato: maggiore frequenza di ronde, restrizioni di accesso più severe |
| 3 — Eccezionale | Ulteriori misure specifiche per un periodo limitato, quando un incidente è probabile o imminente, anche senza un bersaglio identificato |
Tabella 3.1 — I tre livelli di sicurezza e le loro implicazioni operative.
Il livello di sicurezza applicabile viene comunicato dall'Amministrazione di bandiera o dallo Stato costiero/portuale competente; la nave non decide autonomamente di innalzare o abbassare il livello, ma deve essere pronta ad applicare rapidamente le misure corrispondenti a ciascun livello, come previsto dal proprio SSP.
Livelli e decisioni del Comandante. La nave applica il livello dell’Amministrazione e, prima dell’ingresso o in porto, quello eventualmente più alto del Governo contraente competente. In caso di conflitto tra requisiti safety e security, XI-2/8.2 impone al Comandante di dare effetto ai requisiti necessari alla safety: può adottare misure security temporanee e deve informare immediatamente l’Amministrazione e, se pertinente, il Governo del porto in cui opera o intende entrare. Non è una facoltà di ridefinire autonomamente il livello.
- L’Amministrazione fissa il livello della nave; in porto prevale il livello più alto fissato dal Governo contraente competente.
- Nave e SSO applicano le misure del livello comunicato, ma non dichiarano autonomamente un nuovo security level.
- L’autorità professionale del Comandante resta protetta dalla SOLAS XI-2/8.
Ship Security Assessment e Ship Security Plan
Ricostruire il ciclo di governance dalla SSA all’SSP approvato, distinguendo accettazione, approvazione, attuazione, riesame e accesso controllato alle informazioni sensibili.
Accesso all’SSP nei controlli: A/9.8 lo esclude di regola. A/9.8.1 consente eccezionalmente accesso limitato alle sezioni pertinenti solo con clear grounds, quando è l’unico mezzo per verificare o rettificare la non conformità, e con consenso del Governo di bandiera o del Comandante. Per le sezioni A/9.4.2, .4, .5, .7, .15, .17 e .18 occorre invece l’accordo dei Governi contraenti interessati.
Ogni nave soggetta al Codice deve disporre di uno Ship Security Plan (SSP), sviluppato a partire da uno Ship Security Assessment (SSA) che ne identifica le vulnerabilità specifiche.
Cosa contiene tipicamente un SSP
- Misure per prevenire l'introduzione di armi, dispositivi pericolosi o persone non autorizzate a bordo.
- Procedure di controllo degli accessi, differenziate per i tre livelli di sicurezza.
- Procedure di risposta a minacce specifiche, coerenti con le vulnerabilità identificate nell'SSA.
- Modalità di comunicazione con CSO, PFSO e autorità competenti.
A differenza di molta documentazione ISM, l'SSP contiene informazioni sulle vulnerabilità della nave che, se divulgate, potrebbero facilitare un atto ostile. Il Codice prevede quindi restrizioni sulla sua accessibilità, limitata al personale autorizzato.
Governance SSA–SSP. La SSA è documentata, riesaminata e accettata dalla compagnia. L’SSP che ne deriva è approvato dall’Amministrazione o da un RSO autorizzato e indipendente dalla sua preparazione, quindi attuato, provato e riesaminato. La riservatezza limita l’accesso alle sezioni sensibili, ma non sottrae tutto il piano ai controlli previsti dalla XI-2/9 e dalla Parte A.
- La SSA è documentata, riesaminata e accettata dalla compagnia; l’SSP è approvato dall’Amministrazione o da un RSO indipendente autorizzato.
- L’SSP è specifico della nave e deve essere mantenuto, protetto e aggiornato secondo il regime applicabile.
- La riservatezza non rende il piano totalmente sottratto al controllo: l’accesso è limitato e regolato dalla XI-2/9 e dalla Parte A.
Gli strumenti operativi: allarme di sicurezza e Declaration of Security
Distinguere finalità e gestione dello Ship Security Alert System dalla Declaration of Security e riconoscere le circostanze nelle quali una DoS può essere richiesta.
SSAS e DoS hanno funzioni diverse: il primo trasmette a terra un allarme quando la security della nave è minacciata o compromessa; la seconda concorda le responsabilità nelle interfacce nave–impianto portuale o nave–nave. Una differenza di livello è solo una delle circostanze nelle quali la nave può richiedere una DoS.
Il sistema di allarme di sicurezza della nave
Lo Ship Security Alert System è previsto dalla SOLAS XI-2/6. La MSC.147(77) raccomanda gli standard rivisti per i sistemi installati dal 1° luglio 2004 e rinvia alla MSC.136(76) per quelli installati prima. Verificare lo standard applicabile all’impianto e le istruzioni della bandiera; data di installazione del sistema e calendario di adeguamento della nave sono criteri distinti.
| Il sistema di allarme di sicurezza | |
|---|---|
| Che cosa fa | Trasmette un allarme a un’autorità competente designata dall’Amministrazione di bandiera, identificando la nave, la sua posizione e segnalando che la sicurezza della nave è minacciata o è stata compromessa |
| Che cosa non fa | Non emette alcun segnale acustico o visivo a bordo; non allerta le navi vicine; non invia alcun segnale alle unità in zona. È un allarme covert per costruzione |
| Punti di attivazione | Almeno due, di cui uno in plancia e almeno un altro in una posizione immediatamente accessibile |
| Protezione contro l’attivazione involontaria | I punti devono essere progettati per non essere azionati per errore, ma senza chiave o codice che ne rallentino l’uso in emergenza |
Tabella 5.1 — Il sistema di allarme di sicurezza secondo la regola SOLAS XI-2/6.
| Nave | Entro quando |
|---|---|
| Costruita dal 1° luglio 2004 | Dotata fin dall’entrata in servizio |
| Costruita prima: navi passeggeri, comprese le unità veloci da passeggeri | Non oltre il primo survey dell’impianto radio successivo al 1° luglio 2004 |
| Costruita prima: petroliere, chimichiere, gasiere, bulk carrier e unità veloci da carico di 500 GT e oltre | Non oltre il primo survey dell’impianto radio successivo al 1° luglio 2004 |
| Costruita prima: altre navi da carico di 500 GT e oltre e unità mobili di perforazione offshore | Non oltre il primo survey dell’impianto radio successivo al 1° luglio 2006 |
Tabella 5.2 — Calendario di installazione del sistema di allarme di sicurezza.
La scelta di rendere l’SSAS silenzioso non è un dettaglio tecnico, è il punto. In uno scenario di dirottamento o di abbordaggio ostile, un allarme che squilla in plancia informa per primi coloro da cui ci si sta difendendo, e viene disattivato prima che serva a qualcosa. Da questa scelta discendono due conseguenze gestionali che ricadono interamente sulla compagnia. La prima: la catena di ricezione a terra deve essere reale e presidiata: qualcuno deve rispondere alle tre di notte, sapere quale nave è, e sapere chi chiamare. La seconda: il sistema va provato periodicamente, e ogni prova va concordata in anticipo con i destinatari dell’allarme — un test non annunciato attiva una risposta vera, con conseguenze proporzionate.
La Declaration of Security
La Declaration of Security (DoS), disciplinata dalla Parte A §5 del Codice, è l’accordo scritto fra una nave e un impianto portuale — o fra due navi — su chi adotta quali misure di sicurezza, e per quanto tempo. È lo strumento che si usa quando l’interfaccia non è simmetrica: il §5.1 affida ai Governi contraenti la determinazione dei casi in cui è richiesta, valutando il rischio che l’interfaccia nave-porto o l’attività nave-nave pone a persone, beni o ambiente.
Il §5.2 elenca le circostanze in cui è la nave a poterne chiedere il completamento.
| Circostanza (§5.2) | Perché serve una DoS |
|---|---|
| La nave opera a un livello di sicurezza più alto dell’impianto portuale o dell’altra nave con cui si interfaccia | È il caso tipico: il divario di livello va colmato da qualcuno, e la DoS dice da chi e come |
| Esiste un accordo fra Governi contraenti su una DoS per certi viaggi internazionali o per navi specifiche | Obbligo che precede la valutazione della singola nave |
| C’è stata una minaccia o un incidente di sicurezza che coinvolge la nave o l’impianto portuale | Le misure ordinarie non sono più sufficienti a definire l’interfaccia |
| La nave si trova in un porto non tenuto ad avere e attuare un piano di sicurezza approvato | La DoS concorda le responsabilità dell’interfaccia; non sostituisce un PFSP quando richiesto |
| La nave svolge operazioni nave-nave con un’unità non tenuta ad avere e attuare un SSP approvato | Stesso principio, applicato al trasbordo |
Tabella 5.3 — Le cinque circostanze in cui la nave può richiedere una Declaration of Security.
La DoS è completata, per la nave, dal comandante o dall’SSO, e per l’impianto portuale dal PFSO o, se il Governo contraente dispone diversamente, da altro organismo responsabile della sicurezza a terra (§5.4). Il periodo minimo di conservazione è fissato dai Governi contraenti per gli impianti portuali situati nel proprio territorio e dalle Amministrazioni per le navi di bandiera (§§5.6-5.7): non è un termine uniforme, va verificato caso per caso.
Nel Modulo 03 i livelli di sicurezza sono uno schema ordinato. La DoS è il punto in cui quello schema incontra la realtà di un porto che opera al livello 1 mentre la nave, per istruzione della propria Amministrazione, sta al livello 2. Da quel momento le misure aggiuntive non sono più «previste dall’SSP» in astratto: sono un elenco firmato da due persone con nome e cognome, con l’indicazione di chi fa che cosa e fino a quando. Ed è anche il documento che, in una ispezione successiva o dopo un incidente, dimostra che il divario di livello era stato riconosciuto e gestito, invece di essere semplicemente subito.
Due strumenti distinti. Uso e prova dell’SSAS seguono SSP approvato, istruzioni dell’Amministrazione e guidance applicabile: XI-2/6 non fissa una cadenza universale. La DoS può essere richiesta per cinque circostanze del §5.2 — livello più alto, incidente o minaccia, port facility non normalmente soggetta, interfaccia con nave non soggetta o ship-to-ship — non soltanto per un disallineamento dei livelli.
- L’SSAS trasmette un allarme covert verso terra senza generare un allarme a bordo.
- Frequenze e modalità di prova dipendono da SSP, Amministrazione e guidance applicabile: la XI-2/6 non stabilisce un unico intervallo universale.
- La DoS attribuisce responsabilità nell’interfaccia e non è limitata al solo disallineamento dei security level.
Il Continuous Synopsis Record e la documentazione
Distinguere il Continuous Synopsis Record previsto dalla SOLAS XI-1/5 dai record ISPS e individuare quali registrazioni devono essere protette e rese disponibili.
I record A/10 devono essere conservati a bordo per almeno il periodo fissato dall’Amministrazione, tenendo conto della XI-2/9.2.3. Si usano le lingue di lavoro della nave; se non comprendono inglese, francese o spagnolo, è richiesta una traduzione in una di queste lingue.
Il Continuous Synopsis Record (CSR) è un documento che accompagna la nave per tutta la sua vita operativa, riportando la storia della sua identità, proprietà e gestione, incluso ogni cambiamento di bandiera, proprietario, gestore o società di classificazione. Serve a garantire tracciabilità storica a fini di sicurezza. È emesso esclusivamente dall’Amministrazione di bandiera, si applica alle navi passeggeri e alle navi da carico di 500 GT e oltre impiegate in viaggi internazionali, ed è obbligatorio dal 1° luglio 2004.
È l’equivoco più comune su questo documento, e ha una conseguenza pratica: chi lo cerca nel Codice non lo trova. Il CSR discende dalla regola SOLAS XI-1/5, cioè dal capitolo XI-1, non dal capitolo XI-2 e non dall’ISPS Code. Nasce dallo stesso pacchetto di emendamenti del dicembre 2002 ed entra in vigore lo stesso giorno, ma è un obbligo autonomo, con un proprio regime di emissione e di modifica. Un ISSC scaduto e un CSR incompleto sono due carenze di natura diversa, sollevate su basi diverse.
Documentazione essenziale in ambito ISPS
| Documento | Funzione |
|---|---|
| ISSC — International Ship Security Certificate | Certifica la conformità della nave al Codice |
| SSP — Ship Security Plan | Piano operativo di sicurezza della nave (documento sensibile) |
| CSR — Continuous Synopsis Record | Storico di identità, bandiera e gestione della nave |
| Registro delle attività di sicurezza | Log delle attività ISPS svolte a bordo (esercitazioni, controlli, incidenti) |
Tabella 6.1 — Documentazione essenziale in ambito ISPS.
Record e CSR. La Parte A §10 richiede registrazioni di training, drills ed exercises; minacce, incidenti e breaches; cambi di livello; comunicazioni rilevanti; audit e riesami; revisioni di SSA/SSP; emendamenti; manutenzione, calibrazione e prova delle apparecchiature, SSAS incluso. Il CSR resta invece un documento autonomo della SOLAS XI-1/5, non un documento emesso dall’ISPS.
- Il CSR è un documento SOLAS separato che conserva la storia identificativa e gestionale della nave.
- I record ISPS richiesti dalla Parte A §10 riguardano, fra l’altro, addestramento, incidenti, violazioni, cambi di livello, comunicazioni e verifiche.
- Registrazioni cartacee ed elettroniche devono essere protette da accessi, modifiche e divulgazioni non autorizzate.
Certificazione, verifica e controllo
Spiegare il ciclo ISSC e Interim ISSC e distinguere verifica di certificazione, controllo SOLAS XI-2/9 e strumenti di verifica remota.
Il modulo precedente ha elencato i documenti. Questo riguarda il loro ciclo di vita: chi verifica la nave, con quale cadenza, quali poteri possono essere delegati a un soggetto privato e quali no, e che cosa succede quando in un porto qualcuno ritiene che la nave non sia conforme.
Il ciclo di vita dell’ISSC
La Parte A §19 disciplina verifica e certificazione con uno schema che chi ha seguito il corso ISM riconoscerà: è lo stesso impianto del DOC e dell’SMC, applicato alla security.
| Verifica | Quando |
|---|---|
| Iniziale | Prima che la nave entri in servizio o prima del primo rilascio dell’ISSC: verifica completa del sistema di sicurezza e dell’SSP approvato |
| Intermedia | Almeno una, fra il secondo e il terzo anniversario del certificato |
| Aggiuntive | Nei casi determinati dall’Amministrazione |
| Di rinnovo | A intervalli non superiori a cinque anni |
Tabella 7.1 — Le verifiche dell’ISSC secondo la Parte A §19.
L’ISSC provvisorio ha una disciplina propria, e più stretta di quella del DOC provvisorio dell’ISM: vale al massimo sei mesi — o fino al rilascio del certificato definitivo, se anteriore — non può essere prorogato, e non può essere rilasciato consecutivamente quando ciò servirebbe a rinviare la piena conformità.
L’ISSC ha validità determinata dall’Amministrazione, non superiore a cinque anni. Se è prevista una sola verifica intermedia, questa si svolge fra il secondo e il terzo anniversario. Non confondere il ciclo con il DOC, che ha verifiche annuali. L’Interim ISSC richiede le condizioni A/19.4.2, dura al massimo sei mesi e non è prorogabile; il divieto di rilascio consecutivo riguarda i casi in cui si cerca di evitare la piena conformità (A/19.4.5).
Chi verifica: le organizzazioni di sicurezza riconosciute
La Parte A §4.3 consente ai Governi contraenti di delegare a una Recognized Security Organization (RSO) parte dei propri compiti in materia di sicurezza — l’approvazione dell’SSP e le verifiche della nave sono tipicamente fra questi. Ma la delega ha un limite tassativo, ed è l’elenco di ciò che non può essere delegato.
| Non delegabile a una RSO (§4.3) |
|---|
| Fissare il livello di sicurezza applicabile |
| Approvare una valutazione di sicurezza di un impianto portuale e le sue successive modifiche |
| Determinare quali impianti portuali devono designare un PFSO |
| Approvare un piano di sicurezza di un impianto portuale e le sue successive modifiche |
| Esercitare le misure di controllo e conformità ai sensi della regola XI-2/9 |
| Stabilire i requisiti della Declaration of Security |
Tabella 7.2 — I sei poteri che restano allo Stato.
La distinzione non coincide semplicemente con nave contro porto. Anche decisioni che riguardano direttamente la nave, come fissare il livello o applicare misure XI-2/9, non sono delegabili a una RSO. Le attività tecniche delegabili richiedono autorizzazione, competenza e rispetto dell’indipendenza prevista; il Governo conserva la responsabilità del sistema.
Il controllo: la regola XI-2/9
Il controllo SOLAS XI-2/9 è esercitato da funzionari debitamente autorizzati, che possono coincidere con gli ispettori PSC. Il controllo iniziale riguarda la presenza di un ISSC o Interim ISSC valido, da accettare salvo clear grounds di non conformità. Non occorrono clear grounds per il semplice controllo del certificato; la loro presenza può giustificare ulteriori misure proporzionate, secondo la regola.
| Misura | Effetto |
|---|---|
| Ispezione della nave | Verifica in loco delle misure di sicurezza applicate |
| Ritardo della nave | La partenza è sospesa fino alla rettifica |
| Fermo (detention) | La nave non lascia il porto |
| Restrizione delle operazioni | Comprese le operazioni commerciali in banchina |
| Limitazione dei movimenti in porto | Assegnazione a un ormeggio determinato o divieto di spostamento |
| Espulsione dal porto | La misura estrema: la nave viene allontanata |
Tabella 7.3 — Le misure di controllo e conformità della regola XI-2/9.
Prima dell’ingresso in porto, inoltre, alla nave possono essere richieste informazioni che il PSC ordinario non chiede: oltre ai dati dell’ISSC e del suo rilascio, l’elenco delle ultime dieci port facility visitate e le misure di sicurezza speciali o aggiuntive adottate in ciascuna, comprese quelle relative a eventuali operazioni nave-nave svolte nel periodo.
È la disposizione che coglie di sorpresa la prima volta, e ha una conseguenza documentale precisa. Il registro delle attività di sicurezza a bordo — quello che il modulo precedente elenca fra i documenti essenziali — non serve solo a dimostrare che le prove sono state fatte: serve a rispondere a questa domanda. Va quindi tenuto in modo da poter ricostruire, scalo per scalo, quale impianto portuale, a quale livello di sicurezza, con quali misure aggiuntive e se sono state svolte operazioni nave-nave. Un registro compilato per l’audit interno, ma non strutturato per scalo, obbliga a ricostruire dieci porti a memoria mentre l’autorità aspetta.
Controllo proporzionato. Le misure XI-2/9 non sono una scala automatica: dipendono da clear grounds, gravità e informazioni disponibili. L’espulsione è ammessa solo quando vi siano ragionevoli motivi per ritenere che la nave ponga una minaccia immediata e nessun altro mezzo appropriato. Le informazioni pre-arrival non equivalgono a un unico elenco standard. La MSC-MEPC.5/Circ.17 (2026) disciplina la valutazione dell’uso di metodi remoti nelle verifiche.
- Il ciclo ISSC comprende verifica iniziale, intermedia e di rinnovo; l’Interim ISSC è temporaneo e non può diventare un modo per eludere la conformità piena.
- Le misure XI-2/9 sono selezionate in modo proporzionato: non costituiscono una scala automatica e sequenziale.
- L’expulsion richiede una minaccia immediata e l’assenza di altri mezzi appropriati; la guida 2026 disciplina anche verifiche remote ammissibili.
Esercitazioni e addestramento
Collegare drills, exercises, familiarizzazione e qualifiche STCW alla corretta fonte normativa e al regime internazionale o unionale applicabile.
Come per la safety, anche la security richiede esercitazioni periodiche che mantengano l'equipaggio pronto a reagire efficacemente, e non solo formalmente consapevole delle procedure scritte.
Tipologie di esercitazione tipiche
- Esercitazioni di controllo accessi e verifica documentale in condizioni simulate.
- Simulazioni di innalzamento del livello di sicurezza, con verifica della prontezza delle misure aggiuntive.
- Esercitazioni di risposta a scenari specifici (intrusione, minaccia bomba, tentativo di imbarco non autorizzato).
- Addestramento generale di security awareness per tutto l'equipaggio, non solo per l'SSO.
Le frequenze: cosa impone la Parte A e cosa raccomanda la Parte B
È il punto in cui la distinzione fra le due parti del Codice diventa concreta. La Parte A, §13.4, impone soltanto che le prove siano svolte a intervalli appropriati, tenendo conto del tipo di nave, dei cambi di equipaggio, degli impianti portuali da visitare e delle altre circostanze rilevanti; il §13.5 chiede al CSO di partecipare a esercitazioni a intervalli appropriati. I numeri che tutti citano stanno invece nella Parte B.
| Attività | Cosa dice la Parte A (obbligatoria) | Cosa raccomanda la Parte B |
|---|---|---|
| Prove (drills) | §13.4 — «a intervalli appropriati» | §13.6 — almeno una ogni tre mesi; inoltre, se oltre il 25% dell’equipaggio è cambiato in una sola volta con personale che non ha partecipato ad alcuna prova su quella nave negli ultimi tre mesi, una prova entro una settimana dal cambio |
| Esercitazioni (exercises) | §13.5 — partecipazione del CSO «a intervalli appropriati» | §13.7 — almeno una per anno solare, con non più di 18 mesi fra l’una e l’altra |
Tabella 8.1 — Frequenze di prove ed esercitazioni: obbligo e raccomandazione a confronto.
La Parte A usa la formula «a intervalli appropriati»; il Regolamento (CE) n. 725/2004 rende però obbligatori nell’UE i §§B/13.6 e B/13.7. Fuori da quel perimetro vanno verificate le regole di bandiera e l’SSP approvato.
Le qualifiche: dove la formazione security diventa certificata
I requisiti STCW hanno origini distinte: VI/5 per lo Ship Security Officer deriva dagli emendamenti del 2006, entrati in vigore il 1° gennaio 2008; VI/6 per security awareness e compiti security designati deriva da Manila 2010, in vigore dal 1° gennaio 2012. Familiarizzazione a bordo, formazione e certificazione sono requisiti collegati ma distinti.
| Regola | A chi si applica | Cosa richiede |
|---|---|---|
| STCW VI/5 | Chi è designato Ship Security Officer | Certificate of Proficiency (certificato di addestramento) per SSO secondo STCW VI/5. |
| STCW VI/6 — compiti di sicurezza designati | Chi ha compiti di sicurezza assegnati nell’SSP, incluse le misure antipirateria | Addestramento dedicato e relativo certificato |
| STCW VI/6 — security awareness | Tutto il resto dell’equipaggio, in qualsiasi qualifica, senza compiti designati | Formazione o istruzione di consapevolezza security |
Tabella 8.2 — Qualifiche security STCW: emendamenti 2006 e Manila 2010.
Un equipaggio in cui solo l'SSO conosce realmente le procedure di sicurezza, mentre il resto del personale le ignora, è vulnerabile quanto un equipaggio senza SSP: la sicurezza reale richiede una consapevolezza diffusa, non concentrata in una sola figura.
Frequenze e qualifiche. La Parte A richiede intervalli appropriati; nell’UE i §§B/13.6 e B/13.7 sono obbligatori: drill almeno ogni tre mesi e nei casi di cambio equipaggio previsti, exercise almeno ogni anno solare con massimo 18 mesi fra due esercitazioni. La regola STCW VI/5 per SSO nasce dagli emendamenti 2006, in vigore dal 2008; Manila ha introdotto la VI/6, in vigore dal 2012.
- La Parte A richiede drills a intervalli appropriati; nell’UE le frequenze dei paragrafi B/13.6 e B/13.7 sono rese obbligatorie dal Regolamento (CE) n. 725/2004.
- I requisiti STCW per SSO risalgono agli emendamenti entrati in vigore nel 2008; la Manila 2010 ha introdotto VI/6 per awareness e designated security duties dal 2012.
- L’SSP approvato può rendere vincolanti per la nave cadenze e modalità operative più specifiche.
Aree di elevato rischio security
Separare la SSA dell’ISPS dalla valutazione di minaccia e rischio del viaggio e usare fonti geografiche e operative aggiornate per decidere le misure BMP.
Alcune aree geografiche presentano storicamente un profilo di rischio security più elevato, richiedendo misure aggiuntive specifiche durante il transito. Queste misure non vengono dall’ISPS Code, che non le contiene: vengono da un corpo di guidance di settore, oggi consolidato nelle BMP Maritime Security, la cui prima edizione del marzo 2025 ha ritirato le BMP5 e riunito in un unico documento le guide regionali fino ad allora separate; l’aggiornamento del 2026 vi ha aggiunto una sezione sull’abbordaggio da parte di attivisti.
La Indian Ocean piracy HRA è stata rimossa il 1° gennaio 2023. Restano però VRA, corridoi, aree di minaccia e advisory dinamici pubblicati da autorità e coalizioni. Per ogni viaggio serve una voyage threat and risk assessment aggiornata, distinta dalla SSA ISPS che fonda l’SSP.
Il profilo di rischio delle diverse aree geografiche non è statico: evolve con la situazione politica, militare ed economica locale. Prima di ogni transito in un'area storicamente sensibile, è essenziale consultare gli avvisi aggiornati di organismi competenti (come UKMTO, IMB, o i bollettini della propria Amministrazione di bandiera), non affidarsi a informazioni datate.
Geografia dinamica. La specifica Indian Ocean piracy HRA è stata rimossa nel 2023, ma restano VRA, corridoi, aree di minaccia e advisory dinamici. BMP Maritime Security richiede una voyage threat and risk assessment aggiornata per ciascun viaggio: è distinta dalla Ship Security Assessment della Parte A §8 che fonda l’SSP.
- La rimozione della precedente piracy HRA non ha eliminato il rischio né ogni advisory geografico o corridoio operativo.
- La valutazione del viaggio deve essere dinamica, route-specific e alimentata da avvisi e reporting correnti.
- Tale valutazione integra l’SSP e le BMP, ma non sostituisce né coincide con la SSA della nave.
Risposta a un evento di sicurezza
Applicare un modello di risposta coerente con SSP, autorità del Comandante e competenze delle autorità, senza trasformare una buona pratica in una sequenza normativa inesistente.
La capacità di reagire in modo ordinato ed efficace a un evento di sicurezza dipende dalla chiarezza del percorso di escalation e dalla familiarità dell'equipaggio con le proprie responsabilità in quel momento.
I principi guida della risposta
- Rilevare e segnalare tempestivamente qualunque anomalia sospetta, anche minima.
- Attivare l'SSO, che valuta la gravità e coordina la risposta a bordo.
- Informare CSO, PFSO e autorità secondo l’SSP; applicare il livello comunicato dall’autorità competente.
- Coordinarsi con le autorità competenti (PFSO, autorità portuali, forze dell'ordine).
- Conservare evidenze e registrazioni; condurre il riesame post-evento previsto da SSP, SMS e guidance applicabile.
Risposta non lineare. Protezione di persone e nave secondo SSP e autorità del Comandante, comunicazioni a SSO/CSO/PFSO e autorità, eventuale attivazione covert dell’SSAS e misure fisiche possono procedere in parallelo. La nave non innalza autonomamente il livello. Evidenze, reporting e riesame post-evento seguono SSP, SMS e guidance applicabile; il debrief è buona pratica, non una sequenza prescritta dal Codice.
- Protezione di persone e nave, comunicazioni, coordinamento e applicazione dell’SSP possono procedere in parallelo secondo lo scenario.
- L’SSO non innalza il security level: un nuovo livello è comunicato dall’autorità competente.
- Conservazione delle evidenze, reporting e riesame post-evento seguono SSP, SMS e guidance applicabile.
La convergenza tra sicurezza fisica e cyber security
Integrare physical e cyber security distinguendo la base ISPS, il requisito ISM/SMS della MSC.428(98), la guidance IMO corrente e le IACS UR E26/E27.
La crescente digitalizzazione della nave rende sempre più labile il confine tra sicurezza fisica e sicurezza informatica: un accesso fisico non autorizzato può abilitare un attacco cyber, e un attacco cyber può avere conseguenze fisiche dirette.
Perché questa convergenza è rilevante per l'ISPS
La risoluzione IMO MSC.428(98), adottata dal Comitato per la sicurezza marittima nel giugno 2017, chiede alle Amministrazioni di assicurare che i rischi cyber siano adeguatamente affrontati nell'ambito del Safety Management System non oltre la prima verifica annuale del Document of Compliance della compagnia successiva al 1° gennaio 2021. Le implicazioni si estendono naturalmente anche alla pianificazione di sicurezza ISPS: un accesso fisico incontrollato a sale apparati o postazioni di controllo può rappresentare la porta d'ingresso più semplice per un attacco cyber, indipendentemente da quanto sofisticate siano le difese informatiche.
| Strumento | Natura | Da quando |
|---|---|---|
| Risoluzione MSC.428(98) | Gestione del rischio cyber dentro l'SMS dell'ISM Code | Prima verifica annuale del DOC dopo il 1° gennaio 2021 |
| MSC-FAL.1/Circ.3/Rev.4 | Linee guida IMO sulla gestione del rischio cyber marittimo — raccomandazioni di alto livello ed elementi funzionali | Revisione in vigore |
| IACS UR E26 — cyber resilience of ships | Requisito unificato di classe sulla nave come sistema | Navi contrattualizzate dal 1° luglio 2024 |
| IACS UR E27 — cyber resilience of on-board systems and equipment | Requisito unificato di classe sui singoli sistemi e apparati | Navi contrattualizzate dal 1° luglio 2024 |
Tabella 11.1 — Il quadro cyber applicabile: dalla gestione del rischio ai requisiti di progetto.
La gestione cyber nell’SMS si coordina con gli obblighi di security già esistenti: la Parte B §§8.3 e 8.4 include sistemi informatici e reti nella SSA e nelle competenze necessarie. Le UR IACS E26/E27 aggiungono requisiti di classe per le navi e i sistemi nel rispettivo campo di applicazione, secondo data del contratto di costruzione e regole della società competente. Non si applicano indistintamente a ogni nave e non istituiscono un certificato cyber universale.
Un equipaggio formato solo sulla sicurezza fisica tradizionale (controllo accessi, sorveglianza) ma privo di consapevolezza sui rischi cyber lascia scoperta una superficie di attacco crescente. La formazione di security awareness più efficace oggi integra entrambe le dimensioni.
Tre piani normativi. La MSC.428(98) tratta il cyber risk attraverso ISM/SMS e non modifica l’ISPS. La MSC-FAL.1/Circ.3/Rev.4 è la guidance IMO corrente. Le IACS UR E26/E27 sono requisiti di classe nel proprio campo di applicazione e non creano un certificato cyber universale.
- MSC.428(98) opera attraverso il Safety Management System ISM e non modifica direttamente l’ISPS Code.
- MSC-FAL.1/Circ.3/Rev.4 è il riferimento IMO corrente ad agosto 2026.
- E26/E27 sono requisiti unificati di classe nel proprio campo applicativo, non un certificato cyber universale né una nuova parte dell’ISPS.
ISPS e gli altri sistemi di controllo
Distinguere controllo security XI-2/9, PSC ordinario, vetting e ISM/SMS, riconoscendone interfacce senza confonderne autorità, certificati e conseguenze.
Come l'ISM Code, anche il quadro ISPS si intreccia con gli altri sistemi di controllo visti nei corsi precedenti.
| Sistema | Relazione con l'ISPS |
|---|---|
| Port State Control | Un ISSC scaduto o carenze security gravi possono comportare fermo della nave, analogamente a carenze ISM |
| Vetting | Alcuni programmi di vetting includono elementi di security nella propria valutazione (si veda TMSA, elemento dedicato alla maritime security) |
| ISM Code | I due sistemi condividono spesso infrastrutture documentali e canali di reporting a bordo, pur restando concettualmente distinti |
Tabella 12.1 — Relazione dell'ISPS Code con altri sistemi di controllo.
Sistemi coordinati, basi distinte. ISPS, ISM/SMS, SOLAS, STCW, controlli PSC e guidance di settore si incrociano ma non sono intercambiabili. Per navigare le conseguenze nel Port State Control è disponibile la mappa formativa PSC Easy Maps.
- XI-2/9 è un regime speciale esercitato da duly authorised officers; non coincide con una normale escalation PSC.
- Vetting e TMSA possono valutare maturità e pratica, ma non approvano l’SSP e non rilasciano l’ISSC.
- Processi condivisi con l’ISM non annullano le diverse basi giuridiche e la protezione delle informazioni security.
La cultura della security awareness
Collegare consapevolezza, compiti assegnati, familiarizzazione e fattore umano ai requisiti STCW e alle responsabilità operative previste dall’SSP.
Come per la safety, anche la security dipende in larga misura dalla cultura organizzativa: procedure scritte senza consapevolezza diffusa producono conformità solo apparente.
Costruire una cultura di security awareness efficace
- Formazione periodica e non solo all'imbarco, con aggiornamenti su minacce emergenti.
- Segnalazione facilitata di comportamenti o situazioni sospette, senza timore di apparire eccessivamente cauti.
- Coerenza tra le procedure dichiarate e la pratica quotidiana (un controllo accessi rigoroso solo quando arriva un'ispezione non costruisce sicurezza reale).
Un equipaggio che percepisce le procedure di sicurezza come un mero adempimento burocratico tenderà ad applicarle in modo superficiale proprio nei momenti in cui servirebbero di più. Spiegare il «perché» delle misure, non solo il «come», rafforza l'adesione reale.
- La security awareness riguarda tutti i marittimi, mentre chi ha designated security duties necessita della preparazione specifica prevista dalla STCW VI/6.
- Una cultura efficace rende riconoscibili anomalie, canali di reporting e responsabilità senza divulgare informazioni sensibili.
- Awareness e comportamento sostengono, ma non sostituiscono, controlli, addestramento, record e autorità formali.
Tendenze emergenti
Distinguere gli aggiornamenti già applicabili dalle proposte di revisione e valutare come minacce evolute incidano su guidance, assessment e procedure senza inventare nuovi obblighi ISPS.
Il quadro della maritime security continua a evolvere in risposta a minacce nuove ed emergenti.
Direzioni da osservare
- La guidance antipirateria si è consolidata. Dal marzo 2025 le BMP Maritime Security sostituiscono le BMP5 e raccolgono in un unico documento le guide regionali fino ad allora separate; l'aggiornamento del 2026 ha aggiunto una sezione sull'abbordaggio da parte di attivisti.
- Geografia del rischio. La rimozione della specifica Indian Ocean piracy HRA dal 1° gennaio 2023 non ha eliminato altre aree di reporting, advisory o minaccia. Aggiornare la valutazione del viaggio con fonti correnti e riesaminare la SSA quando cambiano minacce o vulnerabilità; le due valutazioni hanno finalità diverse.
- Il cyber è entrato nelle regole di costruzione. Le IACS UR E26 ed E27 sulla cyber resilience di nave e di sistemi di bordo si applicano alle navi contrattualizzate dal 1° luglio 2024: non più solo gestione del rischio nell'SMS, ma requisiti di progetto verificati dalla classe.
- Le linee guida IMO sul rischio cyber sono alla quarta revisione (MSC-FAL.1/Circ.3/Rev.4), e restano il riferimento con cui si costruisce la parte cyber dell'SSA.
Un piano di sicurezza redatto alcuni anni fa può non riflettere più adeguatamente le minacce attuali. La revisione periodica dello Ship Security Assessment, non solo la sua esistenza formale, è ciò che mantiene l'SSP realmente utile nel tempo.
Stato al 2026. MSC 111 ha sostenuto ulteriori valutazioni dell’ISPS rispetto a minacce evolute, ma non ha modificato il Codice né reso obbligatorie nuove misure. Rev.4 cyber, MSC-MEPC.5/Circ.17 e BMP Maritime Security 2026 sono sviluppi applicativi o di guidance, non emendamenti già incorporati nel testo obbligatorio ISPS.
- BMP Maritime Security 2026, MSC-FAL.1/Circ.3/Rev.4 e MSC-MEPC.5/Circ.17 sono sviluppi correnti da recepire nel rispettivo perimetro.
- MSC 111 ha sostenuto ulteriori valutazioni sull’ISPS, ma non ha ancora modificato il testo obbligatorio del Codice.
- Minacce dinamiche richiedono fonti aggiornate e riesame delle misure, non l’attribuzione anticipata di requisiti futuri.
Glossario degli acronimi
| Sigla | Definizione |
|---|---|
| BMP | Best Management Practices — dal marzo 2025 BMP Maritime Security, guidance di settore in transito |
| CSO | Company Security Officer |
| CSR | Continuous Synopsis Record (SOLAS XI-1/5) |
| DoS | Declaration of Security (ISPS Parte A §5) |
| IMB | International Maritime Bureau |
| ISPS | International Ship and Port Facility Security Code |
| ISSC | International Ship Security Certificate |
| PFSO | Port Facility Security Officer |
| RSO | Recognized Security Organization (ISPS Parte A §4.3) |
| SSA | Ship Security Assessment |
| SSAS | Ship Security Alert System (SOLAS XI-2/6) |
| SSO | Ship Security Officer |
| SSP | Ship Security Plan |
| UKMTO | United Kingdom Maritime Trade Operations |
Riferimenti e fonti
Elenco consolidato delle fonti citate. Riesaminato il 15 settembre 2026; consultare sempre il testo ufficiale in vigore e gli avvisi aggiornati per le aree a rischio.
| Fonte | Ambito |
|---|---|
| SOLAS capitolo XI-2 | Base normativa dell'ISPS Code: livelli di sicurezza, obblighi della compagnia, sistema di allarme di sicurezza (reg. 6), misure di controllo e conformità (reg. 9) |
| SOLAS regola XI-1/5 | Continuous Synopsis Record — capitolo XI-1, non XI-2 |
| ISPS Code, Parte A (obbligatoria) | §§1.2-1.3 obiettivi e requisiti funzionali; §4.3 organizzazioni di sicurezza riconosciute; §5 Declaration of Security; §13 addestramento, prove ed esercitazioni; §19 verifica e certificazione |
| ISPS Code, Parte B (guidance internazionale; overlay UE) | Guidance di attuazione; specifici paragrafi, inclusi B/13.6 e B/13.7, sono obbligatori nell’UE per il Regolamento (CE) n. 725/2004 |
| Conferenza SOLAS, Londra 9-13 dicembre 2002 | Adozione del capitolo XI-2 e del Codice; entrata in vigore 1° luglio 2004 |
| STCW, regole VI/5 e VI/6 | VI/5 per SSO dagli emendamenti 2006, in vigore dal 2008; VI/6 Manila per awareness e compiti designati, in vigore dal 2012 |
| Risoluzioni MSC.136(76) e MSC.147(77) | Standard di prestazione del sistema di allarme di sicurezza della nave |
| Risoluzione MSC.428(98) (giugno 2017) | Gestione del rischio cyber nell'SMS, non oltre la prima verifica annuale del DOC successiva al 1° gennaio 2021 |
| MSC-FAL.1/Circ.3/Rev.4 | Linee guida IMO sulla gestione del rischio cyber marittimo |
| IACS UR E26 ed E27 | Cyber resilience della nave e dei sistemi di bordo, per navi contrattualizzate dal 1° luglio 2024 |
| BMP Maritime Security (edizione aggiornata giugno 2026) | Guidance di settore consolidata contro pirateria e minacce in transito; sostituisce le BMP5 |
| UKMTO / IMB | Avvisi aggiornati e reporting; Voluntary Reporting Area |
| Guide to Maritime Security and the ISPS Code, edizione 2021 (IMO) | Compendio di risoluzioni e circolari in materia di maritime security |
| Codice di condotta ILO/IMO sulla sicurezza nei porti (2004) | Sicurezza dell'area portuale più ampia, a complemento dell'ISPS |
| Regulation (EC) No 725/2004 | Articolo 3: campo di applicazione e paragrafi della Parte B obbligatori nell’UE; allegati SOLAS XI-2 e ISPS. |
Questo corso è materiale didattico a scopo formativo e non costituisce certificazione professionale né titolo abilitante. Leggi le avvertenze complete.