What an SSAS actually does, which ships must carry one, where the alert goes when it is pressed, and why most operators discover their weak point during a test rather than an incident.
Most SSAS documentation describes a button. That is accurate and almost entirely useless, because the button is the part that works. What tends to fail is everything after it: whether the alert reaches a monitored inbox at three in the morning, whether the person who receives it knows which vessel it belongs to, and whether anyone can reconstruct what happened six months later when the flag state asks.
This guide covers the regulatory requirement, the practical workflow around it, and the questions worth asking of a provider. It is written for shipowners, managers, security officers and the shore teams who would actually handle an activation.
What an SSAS is, and what it is not
A Ship Security Alert System transmits a covert alert from a vessel to a designated authority ashore when the ship is under threat or its security has been compromised. Three characteristics define it, and each one surprises people.
It is silent. The system raises no audible or visual alarm on board and gives no indication to anyone in the vicinity that it has been activated. That is deliberate: an alert that announces itself would put the crew at greater risk during a boarding.
It does not broadcast. Unlike a distress alert, the SSAS message does not go to nearby ships or to a general rescue coordination network. It goes to a specific competent authority designated by the flag state administration, and to whoever else that administration permits.
It does not summon help. The SSAS notifies. What follows depends on the receiving authority, the company security officer and the procedures in the Ship Security Plan. An operator who assumes the alert triggers an automatic response has misunderstood the system.
Which ships must carry one
The requirement sits in SOLAS Chapter XI-2, Regulation 6, introduced alongside the ISPS Code following the 2002 amendments. It applies to passenger ships including high-speed passenger craft, cargo ships including high-speed cargo craft of 500 gross tonnage and upwards, and mobile offshore drilling units.
Installation was phased. Ships constructed on or after 1 July 2004 were required to comply on delivery. Existing ships were brought in through a schedule tied to the first radio installation survey after specified dates between 2004 and 2006, with passenger ships and certain tanker and bulk categories in the earlier tranches. In practice, any vessel in scope today should already be fitted.
Flag states may impose requirements beyond the SOLAS baseline, including which authority receives alerts, how often the system is tested and what documentation must be retained. Always work from the current flag state circular rather than a general summary, including this one.
Where the alert actually goes
This is where operators most often find a gap. SOLAS requires the Ship Security Alert System to transmit to a competent authority designated by the administration. In most cases that is the flag state, not the coastal state whose waters the vessel is in. The alert identifies the ship, gives its position, and indicates that security is under threat or has been compromised.
Many administrations also permit or require routing to the company security officer or a nominated company address. Where that is the case, the company becomes part of the alert chain, and the practical questions multiply. Is the receiving address a monitored inbox or an individual who might be on leave? Does the recipient have the vessel particulars to hand? Is there a second channel if email fails?
An alert chain that depends on one address, one channel and one person is a chain with a single point of failure, and it will fail at the least convenient moment.
When an SSAS is activated
In practical terms, the alert chain should work like this:
| Stage | What Happens |
| 1. Vessel activation | The SSAS is triggered covertly on board. |
| 2. Satellite transmission | The alert is transmitted ashore using the vessel’s communications link. |
| 3. Designated competent authority | The message is sent to the competent authority designated by the flag state administration. |
| 4. Permitted company recipients | Where the administration permits or requires it, the alert is also routed to the company security officer or other nominated company contacts. |
| 5. Verification and escalation | The receiving party identifies the vessel, confirms its position and follows the response procedure in the Ship Security Plan. |
| 6. Recorded response | The alert, notifications and follow-up actions are retained as a structured record for review, audit and investigation. |
Activation points and false alerts
SOLAS requires at least two activation points, one of them on the navigation bridge. The others are positioned so that the system can be triggered without passing through the bridge, on the assumption that the bridge may already be under the control of others.
The regulation also requires activation points to be designed so as to prevent inadvertent activation, and that is not a trivial concern. False alerts are common enough that the ISPS Code addresses them directly: Part A, section 9.4.18 requires the Ship Security Plan to include procedures and guidance on SSAS activation, deactivation, resetting and limiting false alerts.
A false activation is not merely embarrassing. It consumes the attention of a national authority, it can trigger a response the operator did not intend, and a pattern of them erodes the credibility of the next alert. If one occurs, the master should follow the procedure in the Ship Security Plan, which will normally require immediate notification of the receiving authority and the company security officer, with a record of the cause.
SSAS testing requirements, and what a test usually reveals
Testing intervals are set by the flag administration and recorded in the Ship Security Plan, along with the procedures for conducting a test. The mechanics are straightforward. The value lies in what a test exposes about everything downstream of the transmission.
A test worth running answers questions the equipment specification does not. How long did the alert take to arrive? Did it reach every nominated recipient, or only the first? Was the vessel identifiable from the alert alone, without someone cross-referencing a spreadsheet? Could the duty person see where the ship was and what was around it? Is there a durable record, or only an email that will be deleted in a mailbox clear-out?
Notify the receiving authority before conducting a test. An untested alert chain and an untested crew are different problems, and only one of them is solved by the equipment working correctly.
Compliance is the floor, not the objective
It is possible to be entirely compliant and still respond badly. A system that receives an alert and forwards it as an email satisfies the narrow requirement. It leaves the shore team assembling the picture manually at the worst possible moment: opening a tracking site to find the vessel, checking the recent track to see whether the movement was unusual, looking for other vessels nearby, trying to establish whether communications had been interrupted before the alert.
The alternative is an alert that arrives with its context attached. The vessel is identified and located on the same vessel tracking display the shore team already uses, the recent track is available, area and risk information is present, and the whole thing is recorded in a form that survives an audit. The difference is not regulatory. It is the difference between a duty officer who can act in two minutes and one who is still gathering information after twenty.
The audit trail matters more than most operators expect. Security reviews, flag inspections and post-incident investigations all ask the same question: what happened, when, and who was told? A structured record answers it. A scattered set of emails, messages and recollections does not.
Changing provider without changing equipment
The most common reason operators stay with an SSAS provider they are unhappy with is the assumption that changing means replacing hardware and taking ships out of service. Usually it does not.
Standard type-approved SSAS equipment can generally be repointed to a different service provider without physical replacement, using existing satellite communications equipment already fitted for other purposes. Whether that applies to a particular vessel depends on the equipment, the current configuration and the flag state, but it is worth establishing before assuming a hardware project. Any competent provider should be able to tell you in a short conversation whether your existing hardware can be repointed.
Questions worth asking any provider: can our existing equipment be repointed, or does this require replacement? Who manages notification to the flag state and the receiving authority during migration? How are live and test alerts distributed, and through how many channels? What does the alert record look like when an inspector asks for it? Can the alert be seen alongside the vessel’s position and recent movement, or in a separate system?
Frequently asked questions
Which ships are required to carry an SSAS?
Passenger ships including high-speed passenger craft, cargo ships including high-speed cargo craft of 500 gross tonnage and upwards, and mobile offshore drilling units, under SOLAS Chapter XI-2, Regulation 6. Flag states may apply additional requirements.
Does the SSAS alert go to nearby ships or the coastguard?
No. Unlike a distress alert, it is sent covertly to a competent authority designated by the flag state administration, and to any other recipient that administration permits. Vessels in the vicinity receive nothing.
How often must an SSAS be tested?
Testing intervals are set by the flag state administration and documented in the Ship Security Plan. Notify the receiving authority before any test so that a test alert is not treated as live.
What should happen after a false SSAS activation?
Follow the procedure in the Ship Security Plan. This normally requires immediate notification of the receiving authority and the company security officer, together with a record of the cause. The ISPS Code requires plans to include measures for limiting false alerts.
Can we change SSAS provider without replacing equipment?
In most cases yes. Standard type-approved equipment can usually be repointed to a new service provider without physical replacement, though this depends on the equipment, configuration and flag state.
How BigOceanData approaches SSAS
BigOceanData receives, records, displays and distributes Ship Security Alerts inside the same platform used for vessel tracking, geofencing and voyage history, so an alert can be viewed in the platform in line with recent movement. Alerts are distributed to nominated personnel across multiple channels and retained as a structured record supporting SOLAS Chapter XI-2 and ISPS reporting. Standard type-approved equipment can be repointed rather than replaced, and migration from an existing provider is managed for you.
Talk to us about your SSAS alert chain. We will review your current setup, equipment and migration options, and show you what an alert looks like when it arrives with its context attached. See how it all fits together on our SSAS page.
