ISPS Code
Maritime security: from the ship to cyber security
Learning objectives
- Describe the genesis and structure of the ISPS Code framework.
- Distinguish the roles of CSO, SSO and PFSO and their respective responsibilities.
- Understand the three security levels and their operational implications.
- Reconstruct the process from the Ship Security Assessment to the Ship Security Plan.
- Recognise the growing convergence between physical security and cyber security on board.
- Understand the structure of a response process to a security event.
Genesis of the ISPS framework
Module objectiveDistinguish SOLAS XI-2, mandatory Part A requirements, Part B guidance and provisions made binding by the applicable regime.
Distinguish the scope, hierarchy and legal nature of SOLAS chapter XI-2, ISPS Code Parts A and B, Regulation (EC) No 725/2004 and industry guidance.
International scope: passenger ships including high-speed craft; cargo ships including high-speed craft of 500 GT and above; mobile offshore drilling units engaged on international voyages, and port facilities serving them. Warships, naval auxiliaries and other government ships used only for non-commercial service are excluded. In the EU, Regulation 725/2004 also covers Class A passenger ships on domestic services and provides for national decisions on other domestic categories. Not every ship or entire port area automatically falls within the same scope.
The International Ship and Port Facility Security (ISPS) Code arose as a direct response to the attacks of 11 September 2001, which prompted the international maritime community to introduce a security framework specifically dedicated to protection against malicious acts, distinct from safety, already governed by the ISM Code.
The regulatory path
The framework came out of the Conference of Contracting Governments to SOLAS held in London from 9 to 13 December 2002, which created the new chapter XI-2 — renumbering the pre-existing chapter XI as XI-1 — and adopted the Code. The ISPS Code entered into force on 1 July 2004.
The Code focuses on preventing malicious acts against ships and port facilities. Sections 1.2 and 1.3 of Part A set out its objectives and functional requirements in terms of security threats and security incidents: gathering and exchanging threat information, maintaining communication protocols, preventing unauthorized access to ships, port facilities and their restricted areas, preventing the introduction of unauthorized weapons, incendiary devices or explosives, providing means for raising the alarm, basing plans on security assessments, and ensuring training, drills and exercises.
Part A is mandatory under SOLAS XI-2. Part B contains guidance to be taken into account; specified paragraphs also become mandatory through regional or national rules. In the EU, Article 3(5) of Regulation (EC) No 725/2004 makes B/13.6 and B/13.7 on drills and exercises binding, among other provisions. Check scope, flag requirements and the approved SSP together.
The distinction between safety (protection from accidental events, governed by the ISM Code) and security (protection from intentional acts, governed by the ISPS Code) is conceptually clear-cut, even though in practice the two management systems intertwine and overlap on board.
Piracy should not be excluded from ISPS security assessment. Part B section 8.9 includes hijacking or seizure of the ship and persons, and attacks from seaward among the scenarios to consider. BMP Maritime Security provides additional operational guidance for voyage threats: it does not replace the SSA or SSP and is not itself Code text. Coordinate its application with flag instructions and the approved plan.
Applicable hierarchy. Part A contains mandatory international requirements; Part B is guidance that Contracting Governments must take into account. In the European Union, however, Regulation (EC) No 725/2004 makes specified Part B provisions mandatory, including SSP standards and drill and exercise frequencies. SOLAS XI-2, Parts A and B, EU law, flag rules and the approved SSP must therefore be read together.
- The mandatory international regime derives from SOLAS chapter XI-2 and Part A of the Code.
- Part B is guidance internationally, while the European Union makes specified paragraphs mandatory through Regulation (EC) No 725/2004.
- BMP and other industry guidance support implementation but do not thereby become ISPS Code text.
The key roles: CSO, SSO, PFSO
Module objectiveAllocate duties, authority and delegation limits correctly among the CSO, SSO, PFSO, Administration and Recognized Security Organization.
Distinguish the responsibilities, interfaces and limits of the CSO, SSO, PFSO, Master, Administration and RSO without transferring duties between ship, company and port facility.
The ISPS framework rests on three key figures, each with a distinct area of responsibility, who must coordinate effectively to ensure continuity of security from ship to port.
| Role | Scope | Main responsibility |
|---|---|---|
| CSO — Company Security Officer | Ashore, for one or more ships identified by the company | Ensures the SSA and the development, submission for approval, implementation, maintenance and amendment of SSPs for identified ships |
| SSO — Ship Security Officer | On board, for the individual ship | Implementation of the Ship Security Plan (SSP); crew training; incident reporting |
| PFSO — Port Facility Security Officer | At the port facility | Security of the facility; coordination with arriving/departing ships |
Table 2.1 — The three key roles of the ISPS framework.
The most common issues in the ISPS framework do not arise from the absence of roles, but from insufficient coordination between them: an SSO who does not communicate promptly with the PFSO on arrival in port, or a CSO who does not update SSOs on emerging threats, weaken the whole system even if each individual role is formally in place.
Roles and delegation. The CSO ensures the SSA and the development, submission for approval, implementation, maintenance and amendment of SSPs for identified ships: ISPS does not establish a company security plan equivalent to the SSP. The PFSO serves a port facility. An RSO may assist with PFSA/PFSP preparation but may not approve them; an organisation preparing an SSA or SSP must not approve that same plan. The six section 4.3 duties remain non-delegable.
- The CSO ensures SSAs and SSPs for identified ships; ISPS does not create a company security plan equivalent to an SSP.
- The PFSO acts for a port facility, not automatically for an entire port.
- RSO delegation remains subject to reserved decisions and independence between SSP preparation and approval.
Security levels
Module objectiveApply security levels communicated by the competent authority while preserving the Master’s professional judgement and overriding authority.
Understand who sets security levels, how they apply at the ship/port-facility interface and which powers remain with the Master.
The ISPS framework defines three increasing security levels, which determine the intensity of the measures to be applied on board and at the port facility based on the perceived threat level.
| Level | Typical operational implications |
|---|---|
| 1 — Normal | Minimum measures constantly maintained: access control, general surveillance, document verification |
| 2 — Heightened | Additional measures for a limited period: increased frequency of patrols, stricter access restrictions |
| 3 — Exceptional | Further specific measures for a limited period when an incident is probable or imminent, even without an identified target |
Table 3.1 — The three security levels and their operational implications.
The applicable security level is communicated by the Flag Administration or by the competent coastal/port State; the ship does not autonomously decide to raise or lower the level, but must be ready to quickly apply the measures corresponding to each level, as set out in its own SSP.
Levels and master’s decisions. The ship applies the Administration’s level and, before entry or in port, any higher level set by the competent Contracting Government. If safety and security requirements conflict, XI-2/8.2 requires the master to give effect to the requirements necessary for safety: temporary security measures may be taken, and the Administration and, where appropriate, the Government of the current or intended port must be informed immediately. This does not authorize the ship to redefine the security level.
- The Administration sets the ship’s level; in port, the higher level set by the competent Contracting Government prevails.
- The ship and SSO apply the communicated level but do not independently declare a new security level.
- The Master’s professional authority remains protected by SOLAS XI-2/8.
Ship Security Assessment and Ship Security Plan
Module objectiveConnect SSA threats and vulnerabilities to SSP measures while distinguishing plan development, approval, access and protection.
Reconstruct the governance cycle from SSA to approved SSP, distinguishing acceptance, approval, implementation, review and controlled access to sensitive information.
SSP access during control: A/9.8 normally excludes inspection. A/9.8.1 exceptionally allows limited access to relevant sections only with clear grounds, where this is the only means to verify or rectify non-compliance, and with consent of the flag Government or master. For sections A/9.4.2, .4, .5, .7, .15, .17 and .18, agreement of the Contracting Governments concerned is required instead.
Every ship subject to the Code must have a Ship Security Plan (SSP), developed from a Ship Security Assessment (SSA) that identifies its specific vulnerabilities.
What an SSP typically contains
- Measures to prevent the introduction of weapons, dangerous devices or unauthorised persons on board.
- Access control procedures, differentiated for the three security levels.
- Response procedures for specific threats, consistent with the vulnerabilities identified in the SSA.
- Communication arrangements with the CSO, PFSO and competent authorities.
Unlike much ISM documentation, the SSP contains information on the ship's vulnerabilities that, if disclosed, could facilitate a hostile act. The Code therefore provides for restrictions on its accessibility, limited to authorised personnel.
SSA–SSP governance. The SSA is documented, reviewed and accepted by the company. The resulting SSP is approved by the Administration or an authorised RSO independent of its preparation, then implemented, exercised and reviewed. Confidentiality restricts access to sensitive sections but does not remove the entire plan from the controls allowed by XI-2/9 and Part A.
- The SSA is documented, reviewed and accepted by the company; the SSP is approved by the Administration or an authorised independent RSO.
- The SSP is ship-specific and must be maintained, protected and updated under the applicable regime.
- Confidentiality does not make the plan wholly immune from control: access is limited and governed by XI-2/9 and Part A.
The operational instruments: security alert system and Declaration of Security
Module objectiveUse the SSAS and Declaration of Security according to their purpose, activation, communications and responsibilities under the applicable regime.
Distinguish the purpose and management of the Ship Security Alert System from the Declaration of Security and identify when a DoS may be requested.
SSAS and DoS serve different purposes: the former sends a shore-side alert when ship security is threatened or compromised; the latter agrees responsibilities at ship–port facility or ship–ship interfaces. A difference in security level is only one circumstance in which a ship may request a DoS.
The ship security alert system
The Ship Security Alert System is required by SOLAS XI-2/6. MSC.147(77) recommends revised standards for systems installed on or after 1 July 2004 and refers to MSC.136(76) for earlier installations. Check the standard applicable to the installation and flag instructions; system installation date and the ship’s compliance schedule are distinct criteria.
| The ship security alert system | |
|---|---|
| What it does | Transmits an alert to a competent authority designated by the flag Administration, identifying the ship, its location and indicating that the security of the ship is under threat or has been compromised |
| What it does not do | It raises no audible or visual signal on board; it does not alert nearby ships; it sends no signal to units in the area. It is a covert alarm by design |
| Activation points | At least two, one of them on the navigation bridge and at least one other in an immediately accessible position |
| Protection against inadvertent activation | The points must be designed against accidental operation, but without a key or code that would slow their use in an emergency |
Table 5.1 — The ship security alert system under SOLAS regulation XI-2/6.
| Ship | By when |
|---|---|
| Constructed on or after 1 July 2004 | Fitted from entry into service |
| Constructed earlier: passenger ships, including high-speed passenger craft | Not later than the first survey of the radio installation after 1 July 2004 |
| Constructed earlier: oil tankers, chemical tankers, gas carriers, bulk carriers and cargo high-speed craft of 500 GT and above | Not later than the first survey of the radio installation after 1 July 2004 |
| Constructed earlier: other cargo ships of 500 GT and above and mobile offshore drilling units | Not later than the first survey of the radio installation after 1 July 2006 |
Table 5.2 — Fitting schedule for the ship security alert system.
Making the SSAS silent is not a technical detail, it is the whole point. In a hijacking or hostile boarding, an alarm ringing on the bridge informs first the very people you are defending against, and gets disabled before it achieves anything. Two management consequences follow, and both fall squarely on the company. First, the shore receiving chain must be real and manned: someone has to answer at three in the morning, know which ship it is, and know whom to call. Second, the system must be tested periodically, and every test agreed in advance with the recipients of the alert — an unannounced test triggers a real response, with proportionate consequences.
The Declaration of Security
The Declaration of Security (DoS), governed by Part A section 5 of the Code, is the written agreement between a ship and a port facility — or between two ships — on who takes which security measures, and for how long. It is the instrument used when the interface is not symmetrical: section 5.1 leaves it to Contracting Governments to determine when a DoS is required, by assessing the risk the ship/port interface or ship-to-ship activity poses to persons, property or the environment.
Section 5.2 lists the circumstances in which the ship may request one.
| Circumstance (5.2) | Why a DoS is needed |
|---|---|
| The ship is operating at a higher security level than the port facility or another ship it is interfacing with | The typical case: the gap in level has to be closed by someone, and the DoS says by whom and how |
| There is an agreement between Contracting Governments on a DoS covering certain international voyages or specific ships | An obligation that precedes any assessment by the individual ship |
| There has been a security threat or a security incident involving the ship or the port facility | Ordinary measures no longer suffice to define the interface |
| The ship is at a port not required to have and implement an approved port facility security plan | The DoS agrees interface responsibilities; it does not replace a PFSP where required |
| The ship is conducting ship-to-ship activities with a ship not required to have and implement an approved SSP | The same principle, applied to transfer operations |
Table 5.3 — The five circumstances in which a ship may request a Declaration of Security.
The DoS is completed, on behalf of the ship, by the master or the SSO, and on behalf of the port facility by the PFSO or, where the Contracting Government determines otherwise, by another body responsible for shore-side security (5.4). The minimum retention period is set by Contracting Governments for port facilities within their territory and by Administrations for ships of their flag (5.6-5.7): it is not a uniform period and must be checked case by case.
In Module 03 the security levels are a tidy scheme. The DoS is the point where that scheme meets the reality of a port operating at level 1 while the ship, on instruction from its own Administration, sits at level 2. From that moment the additional measures are no longer «provided for in the SSP» in the abstract: they are a list signed by two named people, setting out who does what and until when. It is also the document that, at a later inspection or after an incident, shows the gap in level was recognised and managed rather than simply endured.
Two distinct instruments. SSAS use and testing follow the approved SSP, Administration instructions and applicable guidance: XI-2/6 sets no universal interval. A DoS may be required in the five section 5.2 circumstances — higher level, incident or threat, non-standard port facility, interface with a non-SOLAS ship or ship-to-ship activity — not only for a level mismatch.
- The SSAS sends a covert alert ashore without raising an onboard alarm.
- Testing frequency and method follow the SSP, Administration and applicable guidance; XI-2/6 sets no single universal interval.
- A DoS allocates interface responsibilities and is not limited to mismatched security levels.
The Continuous Synopsis Record and documentation
Module objectiveDistinguish the Continuous Synopsis Record from operational ISPS records and assure their availability, integrity and protection.
Distinguish the Continuous Synopsis Record under SOLAS XI-1/5 from ISPS records and identify which records must be protected and available.
A/10 records must be kept on board for at least the period specified by the Administration, bearing in mind XI-2/9.2.3. Use the ship’s working languages; if these do not include English, French or Spanish, include a translation into one of those languages.
The Continuous Synopsis Record (CSR) is a document that accompanies the ship throughout its operational life, recording the history of its identity, ownership and management, including every change of flag, owner, manager or classification society. It serves to ensure historical traceability for security purposes. It is issued solely by the flag Administration, applies to passenger ships and cargo ships of 500 GT and above on international voyages, and has been mandatory since 1 July 2004.
This is the most common misunderstanding about it, and it has a practical consequence: anyone looking for it in the Code will not find it. The CSR comes from SOLAS regulation XI-1/5, that is from chapter XI-1, not chapter XI-2 and not the ISPS Code. It comes out of the same December 2002 package of amendments and enters into force on the same day, but it is a free-standing obligation with its own issuing and amendment regime. An expired ISSC and an incomplete CSR are two different kinds of deficiency, raised on different bases.
Essential documentation in the ISPS area
| Document | Function |
|---|---|
| ISSC — International Ship Security Certificate | Certifies the ship's compliance with the Code |
| SSP — Ship Security Plan | The ship's operational security plan (sensitive document) |
| CSR — Continuous Synopsis Record | History of the ship's identity, flag and management |
| Security activity log | Log of ISPS activities carried out on board (drills, checks, incidents) |
Table 6.1 — Essential documentation in the ISPS area.
Records and CSR. Part A section 10 requires records of training, drills and exercises; threats, incidents and breaches; level changes; relevant communications; audits and reviews; SSA/SSP reviews; amendments; and maintenance, calibration and testing of security equipment, including SSAS. The CSR is instead a separate SOLAS XI-1/5 document, not one issued under ISPS.
- The CSR is a separate SOLAS document preserving the ship’s identification and management history.
- ISPS Part A section 10 records include training, incidents, breaches, level changes, communications and verification activities.
- Paper and electronic records require protection against unauthorised access, alteration and disclosure.
Certification, verification and control
Module objectiveDistinguish the ISSC certification cycle, system verification and SOLAS XI-2/9 control measures applicable in port.
Explain the ISSC and Interim ISSC cycle and distinguish certification verification, SOLAS XI-2/9 control and remote-verification tools.
The previous module listed the documents. This one covers their life cycle: who verifies the ship, how often, which powers may be delegated to a private body and which may not, and what happens when someone in a port considers the ship non-compliant.
The life cycle of the ISSC
Part A section 19 governs verification and certification with a scheme anyone who took the ISM course will recognise: it is the same structure as the DOC and the SMC, applied to security.
| Verification | When |
|---|---|
| Initial | Before the ship enters service or before the ISSC is first issued: a full verification of the security system and of the approved SSP |
| Intermediate | At least one, between the second and third anniversary of the certificate |
| Additional | As determined by the Administration |
| Renewal | At intervals not exceeding five years |
Table 7.1 — ISSC verifications under Part A section 19.
The Interim ISSC has its own, tighter regime than the ISM interim DOC: it is valid for at most six months — or until the full certificate is issued, if earlier — cannot be extended, and cannot be issued consecutively where that would serve to postpone full compliance.
The Administration determines ISSC validity, not exceeding five years. If only one intermediate verification is carried out, it takes place between the second and third anniversary. Do not confuse this with the DOC’s annual verifications. An Interim ISSC requires the conditions in A/19.4.2, lasts no more than six months and cannot be extended; consecutive issuance is prohibited where intended to avoid full compliance (A/19.4.5).
Who verifies: recognized security organizations
Part A section 4.3 allows Contracting Governments to delegate certain of their security-related duties to a Recognized Security Organization (RSO) — approving the SSP and verifying the ship are typically among them. But the delegation has a hard limit, and it is the list of what may not be delegated.
| Not delegable to an RSO (4.3) |
|---|
| Setting the applicable security level |
| Approving a port facility security assessment and subsequent amendments |
| Determining which port facilities must designate a PFSO |
| Approving a port facility security plan and subsequent amendments |
| Exercising control and compliance measures under regulation XI-2/9 |
| Establishing the requirements for a Declaration of Security |
Table 7.2 — The six powers that stay with the State.
The boundary is not simply ship versus port. Decisions directly affecting ships, such as setting security levels or exercising XI-2/9 controls, also cannot be delegated to an RSO. Delegable technical activities require authorization, competence and the prescribed independence; the Government retains responsibility for the system.
Control: regulation XI-2/9
SOLAS XI-2/9 control is exercised by duly authorized officers, who may also be PSC officers. Initial control checks for a valid ISSC or Interim ISSC, which must be accepted unless there are clear grounds of non-compliance. Clear grounds are not required for the certificate check itself; they may justify further proportionate measures under the regulation.
| Measure | Effect |
|---|---|
| Inspection of the ship | On-site verification of the security measures applied |
| Delaying the ship | Departure is suspended pending rectification |
| Detention | The ship does not leave the port |
| Restriction of operations | Including commercial operations alongside |
| Limitation of movement within the port | Assignment to a given berth, or a prohibition on moving |
| Expulsion from port | The extreme measure: the ship is required to leave |
Table 7.3 — Control and compliance measures under regulation XI-2/9.
Before entering port, moreover, a ship may be required to provide information that ordinary PSC does not ask for: besides the ISSC particulars and its issuing details, a list of the last ten port facilities visited and the special or additional security measures taken at each, including any ship-to-ship activities carried out in that period.
This is the provision that catches people out the first time, and it has a precise documentary consequence. The shipboard security activity log — the one the previous module lists among the essential documents — is not only there to show that drills were held: it is there to answer this question. It must therefore be kept so that, call by call, it can reconstruct which port facility, at which security level, with which additional measures, and whether ship-to-ship activities took place. A log written for the internal audit but not structured by call forces you to reconstruct ten ports from memory while the authority waits.
Proportionate control. XI-2/9 measures are not an automatic ladder: they depend on clear grounds, severity and available information. Expulsion is permitted only where there are reasonable grounds to believe the ship poses an immediate threat and no other appropriate means. Pre-arrival information is not one fixed standard list. MSC-MEPC.5/Circ.17 (2026) guides assessment of remote methods in verification.
- The ISSC cycle includes initial, intermediate and renewal verification; the Interim ISSC is temporary and cannot be used to bypass full compliance.
- XI-2/9 measures are selected proportionately rather than forming an automatic sequence.
- Expulsion requires an immediate threat and no other appropriate means; 2026 guidance also addresses permissible remote verification.
Drills and training
Module objectiveDesign role-appropriate familiarisation, drills and exercises while checking frequencies and requirements in the applicable source.
Link drills, exercises, familiarisation and STCW qualifications to the correct source and to the applicable international or EU regime.
As with safety, security also requires periodic drills that keep the crew ready to react effectively, not just formally aware of written procedures.
Typical types of drill
- Access control and document verification drills under simulated conditions.
- Simulations of raising the security level, with verification of the readiness of additional measures.
- Response drills for specific scenarios (intrusion, bomb threat, attempted unauthorised boarding).
- General security awareness training for the whole crew, not just the SSO.
Frequencies: what Part A requires and what Part B recommends
This is where the distinction between the two parts of the Code becomes concrete. Part A, section 13.4, requires only that drills be carried out at appropriate intervals, taking into account the ship type, personnel changes, port facilities to be visited and other relevant circumstances; 13.5 asks the CSO to participate in exercises at appropriate intervals. The figures everyone quotes sit in Part B instead.
| Activity | What Part A requires (mandatory) | What Part B recommends |
|---|---|---|
| Drills | 13.4 — «at appropriate intervals» | B/13.6 — at least once every three months; in addition, where more than 25 per cent of the ship’s personnel has been changed at any one time with personnel that has not previously participated in any drill on that ship within the last three months, a drill within one week of the change |
| Exercises | 13.5 — CSO participation «at appropriate intervals» | B/13.7 — at least once each calendar year, with no more than 18 months between exercises |
Table 8.1 — Drill and exercise frequencies: requirement and recommendation compared.
Part A uses «appropriate intervals»; Regulation (EC) No 725/2004 nevertheless makes B/13.6 and B/13.7 mandatory in the EU. Outside that scope, flag-State rules and the approved SSP must be checked.
Qualifications: where security training becomes certificated
The STCW requirements have different origins: VI/5 for ship security officers derives from the 2006 amendments, effective 1 January 2008; VI/6 for security awareness and designated security duties derives from Manila 2010, effective 1 January 2012. Shipboard familiarization, training and certification are related but distinct requirements.
| Regulation | Who it applies to | What it requires |
|---|---|---|
| STCW VI/5 | Those designated Ship Security Officer | Certificate of Proficiency for SSO under STCW VI/5. |
| STCW VI/6 — designated security duties | Those with security duties assigned in the SSP, including anti-piracy measures | Dedicated training and the corresponding certificate |
| STCW VI/6 — security awareness | Everyone else in the crew, in any capacity, without designated duties | Security awareness training or instruction |
Table 8.2 — STCW security qualifications: 2006 and Manila 2010 amendments.
A crew in which only the SSO really knows the security procedures, while the rest of the personnel are unaware of them, is as vulnerable as a crew without an SSP: real security requires widespread awareness, not awareness concentrated in a single figure.
Intervals and qualifications. Part A requires appropriate intervals; in the EU, B/13.6 and B/13.7 are mandatory: drills at least every three months and after the specified crew change, exercises at least once per calendar year with no more than 18 months between them. STCW VI/5 for SSOs came from the 2006 amendments, in force in 2008; Manila introduced VI/6, in force in 2012.
- Part A requires drills at appropriate intervals; in the EU, the frequencies in B/13.6 and B/13.7 are made mandatory by Regulation (EC) No 725/2004.
- STCW SSO requirements entered into force in 2008; the 2010 Manila Amendments introduced VI/6 security awareness and designated duties from 2012.
- An approved SSP may make more specific frequencies and methods operationally binding for the ship.
High security-risk areas
Module objectiveIntegrate current operational information and BMP guidance into voyage-risk assessment without confusing it with the Ship Security Assessment.
Separate the ISPS SSA from voyage threat and risk assessment and use current geographic and operational sources to determine BMP measures.
Certain geographical areas historically present a higher security risk profile, requiring specific additional measures during transit. Those measures do not come from the ISPS Code, which does not contain them: they come from a body of industry guidance, today consolidated in BMP Maritime Security, whose first edition of March 2025 withdrew BMP5 and brought the previously separate regional guides into a single document; the 2026 update added a section on boarding by activists.
The Indian Ocean piracy HRA was removed on 1 January 2023. VRAs, corridors, threat areas and dynamic advisories published by authorities and coalitions remain. Each voyage needs an updated voyage threat and risk assessment, distinct from the ISPS SSA underpinning the SSP.
The risk profile of different geographical areas is not static: it evolves with the local political, military and economic situation. Before every transit through a historically sensitive area, it is essential to consult updated advisories from competent bodies (such as UKMTO, IMB, or bulletins from your own Flag Administration), not to rely on outdated information.
Dynamic geography. The specific Indian Ocean piracy HRA was removed in 2023, but VRAs, corridors, threat areas and dynamic advisories remain. BMP Maritime Security calls for an updated voyage threat and risk assessment for each voyage: it is distinct from the Part A section 8 Ship Security Assessment underpinning the SSP.
- Removal of the former piracy HRA did not remove risk or every geographic advisory and operational corridor.
- Voyage assessment must be dynamic, route-specific and informed by current advisories and reporting.
- It supports the SSP and BMP measures but neither replaces nor constitutes the ship’s SSA.
Response to a security event
Module objectiveCoordinate response, communications and escalation under the approved SSP, actual conditions and the Master’s authority.
Apply a response model consistent with the SSP, the Master’s authority and competent authorities without presenting good practice as a prescribed legal sequence.
The ability to react in an orderly and effective way to a security event depends on the clarity of the escalation path and the crew's familiarity with their responsibilities at that moment.
The guiding principles of the response
- Detect and promptly report any suspicious anomaly, however minor.
- Activate the SSO, who assesses severity and coordinates the response on board.
- Inform the CSO, PFSO and authorities under the SSP; apply the level communicated by the competent authority.
- Coordinate with the competent authorities (PFSO, port authorities, law enforcement).
- Preserve evidence and records; conduct the post-event review required by the SSP, SMS and applicable guidance.
Non-linear response. Protecting people and ship under the SSP and Master’s authority, communications to SSO/CSO/PFSO and authorities, possible covert SSAS activation and physical measures may proceed in parallel. The ship does not independently raise the level. Evidence, reporting and post-event review follow the SSP, SMS and applicable guidance; debrief is good practice, not a prescribed Code sequence.
- Protection, communications, coordination and SSP measures may proceed in parallel according to the scenario.
- The SSO does not raise the security level; the competent authority communicates any new level.
- Evidence preservation, reporting and post-event review follow the SSP, SMS and applicable guidance.
The convergence between physical security and cyber security
Module objectiveCoordinate physical security and cyber risk while keeping ISPS, ISM/SMS bases, responsibilities and applicable plans distinct.
Integrate physical and cyber security while distinguishing the ISPS basis, the MSC.428(98) ISM/SMS requirement, current IMO guidance and IACS UR E26/E27.
The ship's growing digitalisation makes the boundary between physical security and information security increasingly blurred: unauthorised physical access can enable a cyber attack, and a cyber attack can have direct physical consequences.
Why this convergence matters for ISPS
IMO Resolution MSC.428(98), adopted by the Maritime Safety Committee in June 2017, asks Administrations to ensure that cyber risks are appropriately addressed within the Safety Management System no later than the first annual verification of the company’s Document of Compliance after 1 January 2021. The implications naturally extend to ISPS security planning as well: uncontrolled physical access to equipment rooms or control stations can represent the easiest entry point for a cyber attack, regardless of how sophisticated the IT defences are.
| Instrument | Nature | From when |
|---|---|---|
| Resolution MSC.428(98) | Cyber risk management within the ISM Code SMS | First annual DOC verification after 1 January 2021 |
| MSC-FAL.1/Circ.3/Rev.4 | IMO guidelines on maritime cyber risk management — high-level recommendations and functional elements | Revision in force |
| IACS UR E26 — cyber resilience of ships | Class unified requirement addressing the ship as a system | Ships contracted for construction on or after 1 July 2024 |
| IACS UR E27 — cyber resilience of on-board systems and equipment | Class unified requirement addressing individual systems and equipment | Ships contracted for construction on or after 1 July 2024 |
Table 11.1 — The applicable cyber framework: from risk management to design requirements.
Cyber management in the SMS is coordinated with existing security requirements: Part B sections 8.3 and 8.4 include computer systems and networks in the SSA and relevant expertise. IACS UR E26/E27 add class requirements for ships and systems within their respective scope, according to construction contract date and the applicable class rules. They do not apply indiscriminately to every ship or establish a universal cyber certificate.
A crew trained only in traditional physical security (access control, surveillance) but lacking awareness of cyber risks leaves a growing attack surface uncovered. The most effective security awareness training today integrates both dimensions.
Three regulatory layers. MSC.428(98) addresses cyber risk through the ISM/SMS and does not amend ISPS. MSC-FAL.1/Circ.3/Rev.4 is the current IMO guidance. IACS UR E26/E27 are class requirements within their scope and do not create a universal cyber certificate.
- MSC.428(98) operates through the ISM Safety Management System and does not directly amend the ISPS Code.
- MSC-FAL.1/Circ.3/Rev.4 is the current IMO reference at 15 September 2026.
- E26/E27 are unified class requirements within their scope, not a universal cyber certificate or a new part of ISPS.
ISPS and other control systems
Module objectiveDistinguish ISPS non-conformities, ISM findings, PSC control and vetting observations by authority, evidence and consequence.
Distinguish XI-2/9 security control, ordinary PSC, vetting and the ISM/SMS while recognising their interfaces without merging authorities, certificates or consequences.
Like the ISM Code, the ISPS framework is also intertwined with the other control systems seen in previous courses.
| System | Relationship with ISPS |
|---|---|
| Port State Control | An expired ISSC or serious security deficiencies can lead to detention of the ship, similarly to ISM deficiencies |
| Vetting | Some vetting programmes include security elements in their assessment (see TMSA, the element dedicated to maritime security) |
| ISM Code | The two systems often share documentary infrastructure and onboard reporting channels, while remaining conceptually distinct |
Table 12.1 — Relationship of the ISPS Code with other control systems.
Coordinated systems, distinct legal bases. ISPS, ISM/SMS, SOLAS, STCW, PSC controls and industry guidance interact but are not interchangeable. PSC Easy Maps provides a learning map for navigating Port State Control consequences.
- XI-2/9 is a special regime exercised by duly authorised officers and is not identical to ordinary PSC escalation.
- Vetting and TMSA may assess maturity and practice but do not approve the SSP or issue the ISSC.
- Shared ISM processes do not erase distinct legal bases or the protection of security-sensitive information.
The culture of security awareness
Module objectiveDefine role-appropriate security awareness and competence and verify them through observable decisions and behaviour.
Link awareness, assigned duties, familiarisation and human performance to STCW requirements and operational responsibilities under the SSP.
As with safety, security also largely depends on organisational culture: written procedures without widespread awareness produce only apparent compliance.
Building an effective security awareness culture
- Periodic training, not only at joining, with updates on emerging threats.
- Easy reporting of suspicious behaviour or situations, without fear of appearing overly cautious.
- Consistency between stated procedures and daily practice (rigorous access control only when an inspection is arriving does not build real security).
A crew that perceives security procedures as a mere bureaucratic obligation will tend to apply them superficially precisely in the moments when they are most needed. Explaining the «why» of the measures, not just the «how», strengthens genuine buy-in.
- Security awareness applies to all seafarers, while personnel with designated security duties require the specific training under STCW VI/6.
- Effective culture makes anomalies, reporting paths and responsibilities recognisable without disclosing sensitive information.
- Awareness and behaviour support but do not replace controls, training, records and formal authority.
Emerging trends
Module objectiveMonitor threats and ISPS developments while distinguishing proposal, adoption, entry into force, applicability and incorporation into plans.
Distinguish applicable updates from proposals for future revision and assess how evolving threats affect guidance, assessment and procedures without inventing new ISPS duties.
The maritime security landscape continues to evolve in response to new and emerging threats.
Directions to watch
- Counter-piracy guidance has consolidated. Since March 2025, BMP Maritime Security replaces BMP5 and gathers the previously separate regional guides into a single document; the 2026 update added a section on boarding by activists.
- Risk geography. Removal of the specific Indian Ocean piracy HRA from 1 January 2023 did not remove other reporting, advisory or threat areas. Update voyage assessment using current sources and review the SSA when threats or vulnerabilities change; the two assessments serve different purposes.
- Cyber has entered the construction rules. IACS UR E26 and E27 on the cyber resilience of ships and of on-board systems apply to ships contracted for construction on or after 1 July 2024: no longer only risk management within the SMS, but design requirements verified by class.
- The IMO cyber risk guidelines are at their fourth revision (MSC-FAL.1/Circ.3/Rev.4), and remain the reference for building the cyber part of the SSA.
A security plan drafted a few years ago may no longer adequately reflect current threats. Periodic review of the Ship Security Assessment, not merely its formal existence, is what keeps the SSP genuinely useful over time.
Status in 2026. MSC 111 supported further consideration of ISPS against evolved threats, but did not amend the Code or make new measures mandatory. Cyber Rev.4, MSC-MEPC.5/Circ.17 and BMP Maritime Security 2026 are implementation or guidance developments, not amendments already incorporated into mandatory ISPS text.
- BMP Maritime Security 2026, MSC-FAL.1/Circ.3/Rev.4 and MSC-MEPC.5/Circ.17 are current developments within their respective scopes.
- MSC 111 supported further consideration of ISPS but has not yet amended the mandatory Code text.
- Dynamic threats require updated sources and review of measures, not premature attribution of future requirements.
Glossary of acronyms
| Acronym | Definition |
|---|---|
| BMP | Best Management Practices — since March 2025 BMP Maritime Security, industry guidance in transit |
| CSO | Company Security Officer |
| CSR | Continuous Synopsis Record (SOLAS XI-1/5) |
| DoS | Declaration of Security (ISPS Part A section 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 Part A section 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 |
References and sources
Consolidated list of the sources cited. Updated as of 15 September 2026; always consult the official text in force and updated advisories for risk areas.
| Source | Scope |
|---|---|
| SOLAS chapter XI-2 | Regulatory basis of the ISPS Code: security levels, company obligations, ship security alert system (reg. 6), control and compliance measures (reg. 9) |
| SOLAS regulation XI-1/5 | Continuous Synopsis Record — chapter XI-1, not XI-2 |
| ISPS Code, Part A (mandatory) | 1.2-1.3 objectives and functional requirements; 4.3 recognized security organizations; 5 Declaration of Security; 13 training, drills and exercises; 19 verification and certification |
| ISPS Code, Part B (international guidance; EU overlay) | Implementation guidance; specified provisions, including B/13.6 and B/13.7, are mandatory in the EU under Regulation (EC) No 725/2004 |
| SOLAS Conference, London 9-13 December 2002 | Adoption of chapter XI-2 and of the Code; entry into force 1 July 2004 |
| STCW regulations VI/5 and VI/6 | VI/5 for SSOs from the 2006 amendments, in force in 2008; Manila VI/6 for awareness and designated duties, in force in 2012 |
| Resolutions MSC.136(76) and MSC.147(77) | Performance standards for the ship security alert system |
| Resolution MSC.428(98) (June 2017) | Cyber risk management in the SMS, no later than the first annual verification of the DOC after 1 January 2021 |
| MSC-FAL.1/Circ.3/Rev.4 | IMO guidelines on maritime cyber risk management |
| IACS UR E26 and E27 | Cyber resilience of ships and of on-board systems, for ships contracted for construction on or after 1 July 2024 |
| BMP Maritime Security (updated June 2026 edition) | Consolidated industry guidance against piracy and threats in transit; replaces BMP5 |
| UKMTO / IMB | Updated advisories and reporting; the Voluntary Reporting Area |
| Guide to Maritime Security and the ISPS Code, 2021 edition (IMO) | Compendium of maritime security resolutions and circulars |
| ILO/IMO Code of practice on security in ports (2004) | Security of the wider port area, complementing the ISPS Code |
| Regulation (EC) No 725/2004 | Article 3: scope and Part B provisions mandatory in the EU; SOLAS XI-2 and ISPS annexes. |
This course is educational material for training purposes and does not constitute a professional certification or qualifying credential. Read the full disclaimer.