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 objectiveTrace the ISPS Code back to the attacks of 11 September 2001 and its adoption under SOLAS, and recognise the objectives the Code sets for itself.
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.
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.
This is the distinction to keep in mind for the rest of the course. Part A is mandatory: it holds the requirements Contracting Governments, port authorities and companies must meet. Part B is recommendatory: it gives guidance on how to meet them, and is to be «taken into account» when implementing. Many of the figures routinely quoted as ISPS obligations — starting with drill frequencies — sit in Part B, and become binding only if the flag Administration makes them so, or if the ship’s own plan adopts them.
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.
The ISPS Code is often presented as the framework that also governs piracy. It does not: the Code does not name piracy among its objects, and the measures a ship takes in transit — planning, hardening, citadel, reporting — come from a separate body of guidance, today consolidated in BMP Maritime Security, in dedicated MSC circulars and in reporting centres such as UKMTO. The two meet in the SSP, but they have different sources: looking in the ISPS Code for an obligation to follow the BMP means not finding one.
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.
Key takeaways
- Part A is mandatory and Part B recommendatory: many figures quoted as ISPS obligations actually sit in Part B.
- Safety and security are distinct disciplines, one under the ISM Code and one under the ISPS, yet the two systems overlap on board.
- Counter-piracy is not in the ISPS Code: measures taken in transit come from BMP Maritime Security and separate guidance.
The key roles: CSO, SSO, PFSO
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 the entire fleet | Ensures the SSA and the development, 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, 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
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 | Maximum measures for a limited period, in response to a probable or imminent incident |
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.
Who sets the level. The Administration sets the ship’s security level; in port, the higher level set by the competent Contracting Government applies. The ship and SSO implement the communicated measures and do not declare a new level. The Master retains professional judgement and overriding authority under SOLAS XI-2/8 and may take necessary temporary measures, informing the Administration where these create an inconsistency with applicable instructions.
- 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
Reconstruct the governance cycle from SSA to approved SSP, distinguishing acceptance, approval, implementation, review and controlled access to sensitive information.
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 objectiveRecognise when the ship security alert system is activated and when a Declaration of Security between ship and port facility is needed.
Distinguish the purpose and management of the Ship Security Alert System from the Declaration of Security and identify when a DoS may be requested.
The previous modules established who answers, at which levels and under which plan. Two instruments remain that the framework imposes and that the SSP must be able to bring into play: one technical, used when the ship’s security is already compromised, and one documentary, used at the moment ship and port facility are not operating at the same level.
The ship security alert system
The Ship Security Alert System (SSAS) is required by SOLAS regulation XI-2/6, with the performance standards of resolution MSC.136(76), as amended by MSC.147(77). It is the most distinctive requirement of the whole security regime, and also the most often misunderstood, because it does the opposite of what an alarm normally does.
| 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 planned counterpart is missing: the DoS stands in for it |
| 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.
Key takeaways
- The security alert system is covert by design: it raises no signal on board but transmits to a competent authority.
- The shore receiving chain must be manned and every test agreed in advance with the recipients of the alert.
- The Declaration of Security sets down in writing who takes which security measures at the interface, and for how long.
The Continuous Synopsis Record and documentation
Distinguish the Continuous Synopsis Record under SOLAS XI-1/5 from ISPS records and identify which records must be protected and available.
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
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.
Five years' validity, an intermediate verification between the second and third anniversary, an interim certificate for transitional situations: the scheme is the one already seen for ISM certification, which makes it easy to remember. The difference is the interim. The ISM interim DOC can run to twelve months and the interim SMC is extendable by a further six; the interim ISSC cannot be extended at all, and the Code expressly closes the door on serial issuance. A ship changing flag or manager has six months, no more, to reach full certification.
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.
Read the list and a symmetry appears: everything concerning the ship — approving the SSP, verifying, certifying — is delegable; almost everything concerning the port facility and the exercise of a public power is not. It is a coherent choice: a ship's plan is a technical document a qualified body can assess, whereas setting a country's security level, deciding which ports fall under the Code, or detaining a ship are acts of sovereignty.
Control: regulation XI-2/9
The security control regime is distinct from ordinary Port State Control, and lives in SOLAS regulation XI-2/9. The trigger is the same as in PSC — clear grounds, that is, grounds for believing the ship is non-compliant — but the scale of measures reaches higher.
| 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
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 2010 Manila amendments to the STCW Convention introduced two distinct regulations, with VI/5 in force since 1 January 2008 and VI/6 since 1 January 2012, which the ISPS framework presupposes but does not contain.
| Regulation | Who it applies to | What it requires |
|---|---|---|
| STCW VI/5 | Those designated Ship Security Officer | A specific certificate of proficiency |
| 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 — The security qualifications introduced by the 2010 Manila 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
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 objectiveRecognise the escalation path for a security event and the responsibilities the crew must have clear at that moment.
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.
Key takeaways
- Even a minor suspicious anomaly must be detected and reported promptly.
- The SSO assesses severity and coordinates on board; the CSO is notified and the security level raised per the SSP if necessary.
- The response includes coordination with the PFSO, port authorities and law enforcement, and a post-event debrief.
The convergence between physical security and cyber security
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.
For the first years the only obligation was MSC.428(98): address cyber risk within the SMS, with the flexibility typical of a management system. IACS UR E26 and E27 change the nature of the obligation. They are class unified requirements, applicable to ships contracted for construction on or after 1 July 2024, and they address design: network segmentation, access control to on-board systems, recovery capability. For a company this means that, on newbuildings, the cyber element is no longer written only into a procedure: it is verified at the yard, and class certifies it.
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 August 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
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 objectiveRecognise why security depends on organisational culture and which behaviours build widespread awareness on board.
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.
Key takeaways
- Rigorous access control only when an inspection is arriving does not build real security.
- Training is repeated over time rather than given only at joining, and updated on emerging threats.
- Explaining the «why» of measures, not just the «how», strengthens the crew's genuine buy-in.
Emerging trends
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.
- The risk map has been redrawn. The Indian Ocean High Risk Area was removed at 00:01 UTC on 1 January 2023, following the announcement of 22 August 2022: the UKMTO Voluntary Reporting Area remains, as does the duty to carry out a risk assessment for every voyage. An SSA still reasoning in terms of predefined «high risk areas» describes a map that no longer exists.
- 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 August 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 (1st ed., March 2025) | 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 |
This course is educational material for training purposes and does not constitute a professional certification or qualifying credential. Read the full disclaimer.