What is a Cybersecurity Assessment, and who is allowed to perform it?

The Cybersecurity Assessment is where compliance with the Coast Guard's cyber rule begins, and it is the part most often misunderstood. It is not a penetration test or a scan report. It is a documented argument about which of your systems could hurt people, the river or commerce if they were compromised — with the evidence behind the argument. The plan is written from it, a waiver request is returned without it, and it is redone every year.

What the rule requires

§101.650(e) requires a Cybersecurity Assessment, first by July 16, 2027, then at least annually, and sooner on any change of ownership. The rule defines the assessment in §101.615 as the appraisal of the risks facing an entity, its assets and its networks — identifying vulnerabilities and threats and determining how far adverse events could cause operational disruption and other harm.

Four things the rule asks of the assessment itself:

1. Analyze all networks, not only the ones you think are critical.
2. Validate the Cybersecurity Plan — check that the plan's measures actually address what was found, and feed any gaps into amendments.
3. Document recommendations and resolutions in the existing Vessel or Facility Security Assessment. The cyber assessment rides on the MTSA machinery you already have.
4. Patch or compensate every known exploited vulnerability on critical systems without delay, and document which.

The report is Sensitive Security Information. It is kept with the plan, produced to the Coast Guard on request, and never emailed.

What the assessment is not: a penetration test. The rule requires one only "in conjunction with" the five-year plan renewal (§101.650(e)(2)), not for the initial submission. A vendor insisting you need one now is selling the renewal requirement three years early.

The three stages, in plain language

The Coast Guard published its method in Policy Letter 01-26 in June 2026. The method is optional — any framework of equivalent or greater rigor is acceptable if the report names the standard used — but it is the one reviewers will recognize. It has three stages.

Stage 1: Prepare

You begin by writing down three things with the owner in the room. Risk tolerance: what is a bad day the company can live with, and what ends it. Assumptions: things everyone believes are true and nobody has checked — the policy letter's own example is "all our OT systems are segmented," and it is the one you will hear. Constraints: you cannot take a nav PC offline mid-tow, crew change is Tuesday, nobody scans the engine network.

Then you list the functions the company cannot operate without — navigation, tow makeup, dispatch, tank-barge transfer, crew change, billing — and inventory every asset with a chip in it, in the policy letter's three categories: things you control and can patch; external dependencies you subscribe to and cannot configure, like the cloud dispatch platform or payroll; and interfaces, the pathways a problem travels along — a vendor's remote link, crew wifi, a USB port, a person.

This is where "we don't really have computers on the boats" meets the inventory: two Windows PCs in the wheelhouse running the chart system, a satellite router carrying crew wifi and dispatch on one network, and an engine gateway the dealer reaches from another state. The inventory the rule requires in §101.650(b) comes out of this stage.

Stage 2: Conduct

Now you test. First, a control review: walk every measure in §101.650, from account security through physical security, and answer yes, no or partly, with evidence. Who has logins; is there MFA on email and the dispatch platform; are there default passwords on the router and the cameras; where do the logs go; have the backups ever been restored; which vendors can reach in, and is anyone watching; is crew wifi on the same network as the chart PCs; are the wheelhouse USB ports open.

Second, the threats, ranked honestly. For a towing company the list is led by email fraud that moves money, ransomware on the shoreside network, takeover of cloud email accounts, and abuse of vendor remote access — not by anything cinematic. GPS spoofing is real at sea and mostly irrelevant on a river where pilots navigate by eye and radar; it is documented as low likelihood and the assessment moves on.

Third, likelihood and impact, scored for each threat against each asset, in a simple matrix. The policy letter warns against "premature assumptions of no risk" and says the assessment "cannot be effectively completed through only a visual check or cursory review." Both a qualitative and a technical look are required.

Fourth, the decision the whole rule turns on. Systems that support a necessary function, and anything connected to them, are priority assets. A priority asset becomes critical IT or OT if substantial loss of its confidentiality, integrity or availability could result in a Transportation Security Incident — and the Coast Guard's guidance is that yes or maybe means critical. The definition in §101.615 reaches business support services and systems run by someone else, so the dealer's telematics and the MSP-managed firewall are not excused because another company holds the keys. For each designation, the reasoning is written down; it is what the plan and any waiver will stand on.

Stage 3: Communicate and document

The output is the assessment report: scope and the standard used; the inventory summary; the threat and vulnerability analysis, including scan output and the disposition of every known exploited vulnerability; the risk scores; the critical IT/OT list with the rationale per asset; a findings register with recommendations and resolutions; and a statement of whether the plan addresses what was found. Marked SSI on every page.

Each finding gets one of four honest dispositions: fixed, compensated with a documented control, risk-accepted with the owner's written rationale (the plan has a section for exactly this), or carried into a waiver or equivalency request under §101.665.

Who is allowed to perform it

The rule does not require an outside firm. It requires the method, the evidence and the documentation. The Cybersecurity Officer's first listed duty under §101.625 is to ensure the assessment is conducted, and an operator with a capable CySO and a willing MSP can do it in-house.

Two cautions. The criticality judgment against the TSI test is where inexperience shows, and it is the judgment a reviewer reads first. And the policy letter's requirement for a technical look — not a checklist interview — means someone has to read router configurations, check patch dates on the nav PCs, and scan the shoreside network. Never actively scan OT or navigation systems while a boat is underway; those are inventoried by configuration review and vendor documentation.

On independence: the rule does not require the assessor to be independent of the operation. It does require the annual audit of the plan to be performed by someone with no regular cybersecurity duties for the vessel or facility and independent of the measures being audited (§101.630(f)). Practically, that means whoever assesses and builds your program should not be the same party that audits it. A two-firm structure — one builds, one audits — satisfies the rule by design rather than by exception.

What it usually finds

On an eight-boat company, the same findings appear almost every time: training records that do not meet §101.650(d); a flat network aboard; no MFA on the dispatch platform; vendor remote access nobody monitors; backups never restore-tested; default passwords on the router and cameras; and no written incident response plan. None is exotic. All are fixable. The rest of the requirement is at /the-rule/cybersecurity-assessment.

If you would like to know what an assessment of your own boats would take, book a readiness call at /book.