ISPS and Port-Facility Security: The Regime

A security regime drafted, adopted, and brought into force in about 19 months now governs every cargo ship above 500 gross tonnage, every passenger ship, and every mobile offshore drilling unit on an international voyage, plus the port facilities that serve them. The International Ship and Port Facility Security Code was adopted on 12 December 2002, a little over a year after the attacks of 11 September 2001, and it entered into force on 1 July 2004, an unusually fast turn for an instrument that rewrote how ships and ports approach security. It does not work alone. It rides on SOLAS Chapter XI-2, the new chapter the same 2002 Diplomatic Conference bolted onto the 1974 Safety of Life at Sea Convention, and it sits on a criminal-law foundation laid 14 years earlier by the SUA Convention 1988. This article is the hub for the ISPS and port-facility-security cluster: it explains the regime end to end, from the legal scaffolding down to the single document a master surrenders to a port-state control officer, and it routes to the deeper articles that carry the detail.

The logic of the regime is worth stating once, because the rest follows from it. The ISPS Code answers one question at three levels: who is responsible for security, on the ship, in the company, and at the port facility, and what each of them must do as the threat rises. Every other piece, the plans, the officers, the certificate, the alert system, the declaration, exists to make that allocation of responsibility concrete and auditable. Hold that frame and the whole structure reads as one machine: an assessment finds the vulnerabilities, a plan fixes the measures, a named officer owns the plan, a certificate proves the plan was approved, and an alert system covers the moment the plan fails. The one cluster leaf below, SUA Convention 1988, supplies the criminal-law backstop that prosecutes the offender the ISPS measures were meant to keep out.

The post-9/11 origin and the SOLAS XI-2 scaffolding

The ISPS Code is a direct product of 11 September 2001. Within two months the IMO Assembly, meeting at its 22nd session in November 2001, adopted resolution A.924(22) calling for a review of existing measures to prevent and suppress acts of terrorism against ships and in ports, and it set a Diplomatic Conference for December 2002. That Conference, of SOLAS Contracting Governments, met from 9 to 13 December 2002 and adopted both the new security chapter and the Code in a single sitting on 12 December 2002. The compression matters: the maritime world went from a Code adopted on 12 December 2002 to one in force and certificated on 1 July 2004 in about 19 months, an unusually fast turnaround that left the early implementation rough and the Part B guidance to do heavy lifting.

The legal instrument that makes the Code bite is SOLAS Chapter XI-2, headed “Special measures to enhance maritime security.” A code, on its own, is just text; it becomes binding because SOLAS regulation XI-2/4 requires ships and companies to comply with the relevant requirements of Part A of the ISPS Code, and XI-2/10 does the same for port facilities. The chapter is short but load-bearing. Regulation XI-2/3 puts the duty on Contracting Governments to set security levels and to make sure ships flying their flag and port facilities in their territory act on those levels. Regulation XI-2/6 mandates the ship security alert system. Regulation XI-2/8 preserves the master’s professional judgment: the master may not be constrained by the company, the charterer, or anyone else from taking any decision that the master judges necessary for the safety and security of the ship, and that includes denying access or refusing to load cargo. Regulation XI-2/9 gives port States control and compliance measures over visiting ships, the enforcement teeth.

Why a separate chapter and not an amendment to ISM

The drafters could have hung security off the existing International Safety Management (ISM) Code in SOLAS Chapter IX, since both are management systems with plans, designated persons, and audits. They kept them separate on purpose. Safety, under ISM, manages the risks the ship creates or meets in normal operation: fire, flooding, machinery failure, human error. Security, under ISPS, manages a hostile intelligent adversary who adapts to the measures put in place. The two disciplines share machinery but not mindset, and a fire drill does not prepare a crew for a boarding. The separation also let the security regime carry its own certificate, the International Ship Security Certificate, distinct from the ISM Safety Management Certificate, so that a port-state control officer can verify each independently. The relationship to the wider safety-management system still matters, and the cyber dimension of it now sits with the maritime cyber security cluster, because IMO resolution MSC.428(98) later folded cyber-risk management into the ISM system rather than the ISPS one.

Part A and Part B: mandatory text and recommendatory guidance

The ISPS Code is one document in two parts, and the split decides what a flag State can enforce. Part A is mandatory. It states, in numbered functional requirements, what Contracting Governments, companies, ships, and port facilities must do: conduct security assessments, draw up security plans, appoint security officers, control access, monitor restricted areas, and respond to changes in security level. Part B is recommendatory guidance on how to do what Part A requires, paragraph by paragraph, with the detail an operator needs to write a real plan rather than a one-line statement of intent.

The clean line between the two blurs in three places worth knowing. First, several Part A requirements explicitly incorporate Part B paragraphs by reference, making those paragraphs mandatory through the back door. Second, the ship security assessment that Part A section 8 of the ISPS Code requires must take into account the guidance in Part B section 8, so the recommendatory text shapes the mandatory output. SOLAS regulation XI-2/4 is what makes Part A binding in the first place; it is not regulation XI-2/8, which preserves the master’s overriding authority. Third, and most consequential in practice, many flag Administrations and port States simply require full Part B compliance as a condition of issuing or accepting the International Ship Security Certificate. The United States took this route under its Maritime Transportation Security Act, treating much of Part B as a baseline rather than a menu. The working rule for an operator is to read Part B as binding, because the State that certificates or inspects the ship usually treats it that way.

What Part A actually requires of a company

Part A turns on a short list of obligations that a shipping company has to discharge before its ship can trade internationally. The company must designate a Company Security Officer and ensure a Ship Security Assessment is carried out for each ship. It must develop, submit for approval, and implement a Ship Security Plan based on that assessment. It must designate a Ship Security Officer for each ship and ensure the master and crew are trained and drilled. It must make sure the ship security alert system is fitted and tested. None of this is optional, and a ship that cannot produce an approved plan and a valid certificate can be detained or refused entry under regulation XI-2/9. The IMO ISPS Code compliance check walks the same Part A obligations item by item, from the CSO designation through to the ship security alert system, so an operator can see which of the mandatory elements is still open. The same architecture applies on the shore side: the Contracting Government, through its Designated Authority, requires a Port Facility Security Assessment and an approved Port Facility Security Plan for every port facility that serves ships on international voyages.

The three security levels

The ISPS Code runs on three security levels, and the level is the dial that turns measures up and down as the threat changes. The definitions are tight, and they come straight from SOLAS XI-2 and Part A of the Code. Security level 1 is normal: the level at which ships and port facilities operate day to day, with the minimum appropriate protective measures maintained at all times. Security level 2 is heightened: additional protective measures maintained for as long as there is a heightened risk of a security incident. Security level 3 is exceptional: further specific protective measures maintained for the limited period when a security incident is probable or imminent, even if it is not possible to identify the specific target.

The setting of the level is a government act, not a shipowner’s choice. The Contracting Government sets the security level for ships entitled to fly its flag and for port facilities within its territory, and it communicates changes to the ships and facilities affected. A ship must always operate at the security level set by its flag State, but when it enters a port it must comply with the port facility’s level if that is higher, and a ship at a higher level than the facility triggers a Declaration of Security so the two sides agree who covers the gap. The level a ship operates at is therefore the higher of its own and the port’s, never the lower, which is the rule that stops a ship importing a relaxed posture into a tense port. The ISPS port-facility security level tool works this higher-of comparison and flags when the mismatch obliges a Declaration of Security.

The pattern in the table is the substance of the level system: each step up adds measures rather than replacing them, narrows access, and shifts more of the decision to the government. Most ships spend almost their entire working life at level 1; level 2 appears around specific intelligence or a tense region; level 3 is rare and usually means a named, credible threat against a known target. The cost and disruption rise steeply with the level, which is why governments do not set level 2 or 3 lightly. The wider risk picture that decides when a region warrants a raised posture sits in the maritime security and risk subject hub.

The ship side: SSP, SSO, and CSO

On the ship, three things carry the regime: a plan, an officer who owns it on board, and an officer who owns it for the company. The Ship Security Plan (SSP) is the document that translates the security assessment into the actual measures the ship will take at each security level. It is ship-specific, it is approved by the flag Administration or a Recognized Security Organization acting for it, and it is confidential: a port-state control officer may verify that an approved plan exists and check certain implementation, but the detailed plan is not open to general inspection, because publishing the measures would defeat them. The plan covers access control, restricted areas, cargo and stores handling, monitoring, the security duties of the crew, and the procedures for responding to a security threat and for raising the security level.

The Ship Security Officer (SSO) is the person on board accountable to the master for the security of the ship. Part A makes the SSO responsible for implementing and maintaining the SSP, for carrying out regular security inspections, for proposing modifications to the plan, for security awareness and vigilance among the crew, for reporting security incidents, and for coordinating with the Company Security Officer and the Port Facility Security Officer. The SSO is a designated role, not necessarily a dedicated job: on most ships a deck officer holds it alongside other duties, but the accountability is personal and named. The master sits above the SSO and retains the overriding authority of regulation XI-2/8: if security measures and safety conflict, the master decides, and the safety of life and the ship governs.

The Company Security Officer

The Company Security Officer (CSO) is the shore-side counterpart, the person in the company accountable for security across the fleet or the assigned ships. The CSO ensures the Ship Security Assessment is carried out, that the SSP is prepared, submitted for approval, implemented, and maintained, and that deficiencies found in audits and inspections are corrected. The CSO arranges the internal audits and reviews of the plan, ensures adequate training for shipboard personnel and for the SSO, and is the company’s point of contact for security matters with flag States, port facilities, and the SSO. One CSO can cover several ships, which is the usual arrangement, but the role has to be genuinely resourced: a CSO who is a name on a form and not a working function is the most common finding when a security regime is audited and found wanting. The relationship between the CSO, the SSO, and the master is the spine of the ship-side regime, with the CSO setting the framework, the SSO running it on board, and the master holding the final word.

The port side: PFSP and PFSO

The shore half of the regime mirrors the ship half. Every port facility that serves ships on international voyages must have a Port Facility Security Assessment carried out and an approved Port Facility Security Plan (PFSP). The assessment, done for or on behalf of the Contracting Government, identifies the assets and infrastructure it is important to protect, the threats to them, and the vulnerabilities, and it feeds the plan. The PFSP states the measures the facility will take at each security level: access control to the facility, control of restricted areas, handling of cargo and ship’s stores, monitoring, and the response procedures. Like the SSP, the PFSP is confidential and is approved by the Designated Authority of the Contracting Government in whose territory the facility lies.

The Port Facility Security Officer (PFSO) owns the plan on the shore side. Part A makes the PFSO responsible for the security of the facility: conducting the initial and regular security surveys, implementing and maintaining the PFSP, proposing modifications, raising security awareness among facility personnel, recommending and incorporating modifications, ensuring security equipment is operated and maintained, and coordinating with the SSO and CSO of ships using the facility. The PFSO is the person a ship’s SSO deals with on arrival, and the two of them are the parties who agree and sign a Declaration of Security when the interface needs one. A single PFSO may be assigned to more than one port facility, provided each facility is clearly identified and the role is properly covered, the same resourcing caveat that applies to the CSO. The money side of a port call, the dues and the disbursement account that fund the facility a PFSO protects, sits in the port dues and disbursements hub.

The ship-port interface

The point where the regime earns its keep is the ship-port interface: the activities that take place when a ship is directly and immediately affected by actions involving the movement of people or goods or the provision of port services to or from the ship. This is where the two plans have to mesh. The ship arrives operating at its security level; the facility operates at its own; cargo, stores, crew, visitors, and contractors cross the boundary; and each crossing is a point a hostile actor could exploit. The ISPS Code handles this by making both sides plan for the interface and, where the risk is higher, by requiring the Declaration of Security that pins down who covers what. A clean interface is invisible; a failed one is how a stowaway, a weapon, or a saboteur gets aboard, which is why the access-control and monitoring measures cluster around exactly this moment.

The security assessment: the analytical core

Every plan in the regime, ship and port, starts from a security assessment, and the assessment is the analytical core that the rest hangs on. The Ship Security Assessment (SSA) is an essential and integral part of developing and updating the Ship Security Plan. Part A requires it to include an on-scene security survey and, at minimum, identification of existing security measures and procedures, identification and evaluation of the key shipboard operations it is important to protect, identification of possible threats and their likelihood in order to establish and prioritize security measures, and identification of weaknesses, including human factors, in the infrastructure, policies, and procedures.

The assessment is risk-based, not checklist-based, which is the feature that makes it valuable and the feature that makes it easy to do badly. A genuine SSA names the specific vulnerabilities of the specific ship: the accommodation door that does not lock, the unmonitored stern, the stores delivery that nobody supervises, the freeboard low enough to board from a small craft. A poor SSA copies a template and produces a plan that satisfies an auditor but protects nothing. The Port Facility Security Assessment follows the same logic on the shore side, identifying and evaluating the important assets and infrastructure, the possible threats and their likelihood, and the vulnerabilities in the physical layout, the procedures, and the personnel. The quality of the assessment sets the ceiling on the quality of everything downstream, because a plan can only address the risks the assessment found.

The threats the assessment has to weigh are the ones the Code was written against. Part B lists the kinds of unlawful act the assessor considers: damage to or destruction of the ship or a port facility, by an explosive device, arson, sabotage, or vandalism; hijacking or seizure of the ship or the people on board; tampering with cargo, ship’s stores, or essential equipment; unauthorized access, including stowaways; smuggling weapons or equipment, including weapons of mass destruction; use of the ship to carry an attacker or that person’s equipment; use of the ship itself as a weapon or as a means to cause damage; blockading port entrances, locks, or approaches; and a nuclear, biological, or chemical attack. The assessor scores each against the specific ship or facility, because a passenger ferry, a chemical tanker, and a container feeder do not share the same threat profile, and a plan that treats them as if they did wastes effort on the wrong risks. The output of the assessment is a prioritized list, not a flat inventory, and the priority order is what tells the plan-writer where to spend the security budget first.

The International Ship Security Certificate

The International Ship Security Certificate (ISSC) is the document that proves a ship has been verified to comply. It is issued to a ship by its flag Administration, or by a Recognized Security Organization authorized to act on the Administration’s behalf, after verification that the ship and its Ship Security Plan meet the requirements of SOLAS Chapter XI-2 and Part A of the ISPS Code. The certificate is valid for a period not exceeding five years, subject to at least one intermediate verification between the second and third anniversary dates, the same survey rhythm the safety certificates use. An Interim ISSC, valid for a shorter period, covers a ship newly delivered, newly transferred to a flag, or newly entering service, so that a ship is not stranded uncertificated while the full verification is arranged.

The ISSC is one of the documents a port-state control officer checks first, because regulation XI-2/9 lets a port State verify that a visiting ship holds a valid certificate and is operating at the required security level, and an invalid or missing certificate is grounds for control measures up to and including denial of entry. The verification behind the certificate is not a paperwork formality: it tests whether the approved plan is actually implemented, whether the SSO knows the plan, whether the crew can carry out their security duties, and whether the equipment, including the alert system, works. A certificate held against a plan that exists only on paper is the failure mode the verification is designed to catch, and a ship caught operating with an approved plan it does not follow faces the same control measures as one with no certificate at all.

The Declaration of Security

The Declaration of Security (DoS) is the agreement that fills the gap between two security regimes that meet. It is a document, completed and signed by a ship and a port facility (or by two ships when they interface), that states the security measures each will implement during their interface, the security level at which each will operate, and the responsibility each takes. The point of it is to make the handover explicit when the risk is high enough that an implicit understanding will not do. Part A and the Part B guidance set out when a DoS is needed: at security level 3, whenever the ship operates at a higher level than the port facility or another interfacing ship, when a Contracting Government determines it is needed, or as set in the relevant security plans.

Either side can trigger it. A ship’s SSO can request a DoS when the ship is at a higher level than the facility, when there is no Port Facility Security Plan for the facility it is using, or when a previous incident involving that ship or facility warrants it. A PFSO can request one for the same reasons in reverse. The DoS records, in writing, that the responsibilities are agreed: which side controls access, which monitors the deck and the waterside, which supervises cargo and stores, and which handles the crew and visitor movements across the interface. It is the instrument that stops the dangerous assumption that the other party has the interface covered, and it is the paper trail that shows, after an incident, who was responsible for what.

The Ship Security Alert System

The Ship Security Alert System (SSAS) is the last line, the measure that covers the moment the ship is taken or attacked and the rest of the regime has failed. SOLAS regulation XI-2/6 requires it on all ships to which Chapter XI-2 applies: passenger ships, high-speed passenger craft, cargo ships of 500 gross tonnage and upward, and mobile offshore drilling units. When activated, the SSAS transmits a covert ship-to-shore security alert to a competent authority designated by the flag Administration, which may be the company or a shore station that then relays it, identifying the ship and its location and indicating that the security of the ship is under threat or has been compromised.

The defining feature of the SSAS is silence. It raises no alarm on board: no siren, no light, no signal that anyone on the ship can detect, so an attacker who has taken the bridge has no way to know the alert has gone out. It does not send the alert to other ships in the area, unlike a distress signal, precisely because broadcasting it would warn the attacker and could endanger the ship further. It must be capable of being activated from the navigation bridge and from at least one other location on the ship, so that a crew member who has retreated to a citadel or another part of the ship can still trigger it. The alert routes to the flag State’s designated competent authority, which assesses it and initiates the response, military or law-enforcement, that the situation calls for. The SSAS is why a hijacking now produces a shore-side response within minutes rather than only when the ship fails to arrive, and it is the technical answer to exactly the kind of unlawful act that the SUA Convention 1988 criminalizes. The hijacking threat that the alert system answers concentrates in the same contested waters the war-risk and high-risk areas work covers, where the Gulf of Aden, the Gulf of Guinea, and the southern Red Sea drive both the insurer’s additional premium and the master’s decision to transit at a raised security level.

The SUA Convention: the criminal-law foundation

The ISPS Code prevents; the SUA Convention prosecutes. The Convention for the Suppression of Unlawful Acts against the Safety of Maritime Navigation, adopted on 10 March 1988 and in force from 1 March 1992, is the criminal-law instrument that the preventive ISPS regime sits on. It came out of the Achille Lauro hijacking of October 1985, when the absence of a clear international basis to prosecute the hijackers exposed a gap: the law of piracy, confined to acts on the high seas for private ends, did not reach a politically motivated seizure in territorial waters. SUA closed that gap. It obliges States Parties to criminalize the seizure of a ship by force, acts of violence against persons on board that endanger safe navigation, the destruction of or damage to a ship or its cargo, and the placing of devices likely to destroy a ship, among other offences, and it builds in the prosecute-or-extradite duty that denies an offender a safe harbor.

The 2005 Protocols to the SUA treaties, adopted on 14 October 2005 and in force from 28 July 2010, widened the offences and added a ship-boarding regime. They criminalize using a ship to transport weapons of mass destruction or related material, and using a ship itself as a weapon, the post-9/11 concern that the 1988 text did not address. The Article 8bis boarding provisions let a State Party request the flag State’s authorization to board a ship suspected of involvement in a SUA offence, a framework for cooperative interdiction that the 1988 Convention lacked. The full treatment of the offences, the prosecute-or-extradite duty, and the 2005 boarding regime sits in the SUA Convention 1988 article, the one deep-dive leaf of this cluster. The two instruments are complementary: a State that has implemented ISPS has the measures to stop the act, and a State that has ratified SUA has the law to punish the actor who gets past them.

The US implementation: MTSA and 33 CFR

The United States implemented the ISPS Code through the Maritime Transportation Security Act of 2002 (MTSA), signed into law on 25 November 2002, slightly before the IMO adopted the Code, because the US legislation and the international instrument were developed in parallel after 11 September 2001. MTSA directs the Department of Homeland Security, through the US Coast Guard, to assess and reduce the vulnerability of US ports and vessels, and the Coast Guard’s regulations carry it out. Those regulations sit in Title 33 of the Code of Federal Regulations, Parts 101 to 106: Part 101 sets the general framework and the MARSEC levels (the US analogue of the three ISPS security levels), Part 104 covers vessel security, Part 105 covers facility security, and Part 106 covers Outer Continental Shelf facilities. The full provisions came into effect on 1 July 2004, the same day the ISPS Code entered into force internationally, so that US and international requirements lined up from day one.

The US scheme is broader than the international floor in two ways worth noting. It applies to many domestic vessels and facilities that the international ISPS regime, confined to ships on international voyages, does not reach, so a US harbor tug or a domestic ferry can fall under MTSA security requirements that ISPS alone would not impose. It also folds in the Transportation Worker Identification Credential (TWIC), a biometric identity card required for unescorted access to secure areas of MTSA-regulated vessels and facilities, an access-control layer the international Code recommends in principle but does not specify. A foreign-flag ship calling at a US port must hold a valid ISSC and operate at the MARSEC level the Coast Guard has set, and the Coast Guard exercises the port-State control of SOLAS XI-2/9 to verify it, which is why the international certificate and the US domestic regime meet at the gangway of every foreign ship in a US port.

Training, drills, and the human factor

A plan protects nothing if the crew cannot carry it out, so the ISPS Code puts weight on training, drills, and exercises. Part A requires that the SSO, the CSO, and the PFSO have knowledge and training in the security matters their role demands, and that shipboard and facility personnel with specific security duties understand those duties. The Code distinguishes the levels of training: the officers carry the full competence, the personnel with assigned security duties carry the competence for their tasks, and all other personnel carry security awareness, enough to recognize and report a threat. The STCW Convention’s 2010 Manila amendments later added mandatory security-awareness and designated-security-duty training for seafarers, so a deck rating now joins a ship already holding the relevant security certificate rather than being trained ad hoc on board.

Drills and exercises keep the competence live. The Code expects security drills at intervals appropriate to the ship and facility, frequent enough that the crew can execute the plan without hesitation, and larger security exercises at least once each calendar year with no more than 18 months between them. A drill tests one element, an access-control check or a response to a breach; an exercise tests the whole system and the coordination between the ship, the company, the facility, and the response authorities. The reason the intervals are fixed in the Code is that a security plan, unlike a safety drill, has no routine operational trigger to keep it sharp: a crew handles real fires and real machinery faults often enough to stay current, but it almost never faces a real boarding, so the drill is the only thing standing between an approved plan and a crew that has forgotten it.

How the pieces fit together

The regime is easier to hold as a single flow than as a list of acronyms. A security assessment, ship or port, finds the vulnerabilities of the specific ship or facility. A security plan, the SSP or the PFSP, converts those findings into the measures to be taken at each of the three security levels. A named officer owns each plan: the SSO on the ship, accountable to the master, supported by the CSO ashore; the PFSO at the facility, accountable to the Designated Authority. A certificate, the ISSC, proves the ship’s plan was verified and is implemented, and it is the document a port State checks. A Declaration of Security pins down responsibility at the interface when the risk is high. And the Ship Security Alert System covers the moment everything else fails, sending a silent alarm to the shore. Underneath all of it, SOLAS Chapter XI-2 makes the Code mandatory and gives port States the power to enforce it, and the SUA Convention supplies the criminal law to prosecute the offender the measures were built to keep out.

The cluster’s single deep-dive article, SUA Convention 1988, carries the legal-foundation detail. The cluster sits inside the broader maritime security and risk subject hub, alongside the maritime cyber security cluster that handles the digital dimension the 2002 drafters did not foresee and the war-risk and high-risk-area work that governs transits of dangerous regions. The commercial side of the ports the PFSO protects runs through the port dues and disbursements hub. Read together, these articles place the ISPS regime in its full context: a preventive security system, resting on a criminal-law foundation, operating inside the commercial and physical world of ports and ships.

Limitations

This article maps the ISPS and port-facility-security regime and the instruments around it; it is not a substitute for the ISPS Code text, SOLAS Chapter XI-2 as amended, the flag Administration’s security guidance, or the specific security plan of a given ship or facility. The security plans themselves are confidential by design, and the measures any real ship or facility takes at each security level are set by its approved plan and its Administration, not by the general description here. The division between the mandatory Part A and the recommendatory Part B is the international baseline, but individual flag States and port States, the United States among them, treat large parts of Part B as mandatory in practice, so the binding requirement for a specific ship is the one its certifying Administration and the port States it visits actually apply.

The certification and verification rhythm stated here, a five-year ISSC with an intermediate verification, is the standard regime, but interim certificates, additional verifications, and the consequences of a deficiency are governed by the Administration and the port-State control authority for the specific case. The US implementation summarized here, MTSA and 33 CFR Parts 101 to 106, reflects the federal scheme and its MARSEC levels and TWIC requirement, but the exact application to a vessel or facility is set by the Coast Guard regulations and any local Captain of the Port orders in force at the time. The SUA offences and the 2005 boarding regime described here are the treaty framework; whether and how they apply in a given incident depends on which States have ratified which instruments and on the domestic criminal law that implements them. For any operational or compliance decision, the controlling documents are the current Code, the regulation, the certificate, and the plan, not this overview.

See also

• SUA Convention 1988: the criminal-law foundation, the prosecute-or-extradite duty, and the 2005 boarding regime.
• Maritime security and risk: the subject hub over ISPS, cyber security, and war-risk transit.
• Maritime cyber security: the IACS UR E26 and E27 cyber-resilience requirements and the IMO resolution behind them.
• War-risk and high-risk areas: the third E1 sibling, covering the contested transits and the war-risk additional premium that the SSAS hijacking threat ties into.
• Port dues and disbursements: the charges and the disbursement account for the port a PFSO protects.
• ISPS port-facility security level: works the higher-of comparison between a ship’s level and the port’s, and flags when a Declaration of Security is owed.
• IMO ISPS Code compliance check: steps through the Part A obligations on the company and the ship to show which mandatory elements are still open.