How do we decide what is critical?

One test, from the Coast Guard's own assessment guidance: could compromise of this system contribute to a transportation security incident? Yes or maybe means designate it critical. Write down the reasoning either way — the reasoning is what a reviewer evaluates.

Do we need a network map if we have six boats and one office?

Yes, and it will be short. The value is not complexity; it is that the boundary between your office systems and your operational systems is drawn somewhere explicit rather than assumed.

What if a system cannot be patched?

Document a compensating control and the accepted risk. The rule anticipates this — unpatchable operational technology is normal. What is not acceptable is silence.

Section 6 of 14§101.630(c)(6)

Systems, equipment, maintenance

Cybersecurity systems and equipment, with associated maintenance

What you own, what is critical, how it connects, and how it gets patched.

Section 6 is the largest technical section and the one that carries the most weight, because everything else depends on knowing what you actually have. The rule wants an inventory with critical IT and OT designated, a network map, operational technology configuration documentation, and an approved hardware, firmware and software list — all producible on request.

It also carries routine maintenance: known-exploited vulnerabilities patched without delay or compensating controls documented, a channel to receive vulnerability reports, and no operational technology exposed to the public internet without documented justification.

Also governed by§101.650(b)§101.650(e)

What the rule requires

What §101.630(c)(6) hard-wires into this section

A full asset inventory: Every IT and OT system, with the critical ones flagged. Criticality follows one test: could compromise of this system contribute to a transportation security incident? If the honest answer is yes or maybe, designate it critical.
A network map: How things connect, including the paths between the office network and anything on a vessel or in a terminal's operational environment.
OT configuration documentation: What the operational systems are set to, so a change is detectable and a rebuild is possible.
An approved hardware, firmware and software list: What is allowed to be installed and connected. This is what makes the wheelhouse USB question answerable.
Executable code disabled by default on critical systems: A configuration standard, stated in the plan and verifiable on the equipment.
KEV patching without delay: Known exploited vulnerabilities get patched without delay, or a compensating control gets documented. The compensating-control path is legitimate and requires writing.
No OT on the public internet without justification: Where an operational system is internet-reachable, the plan must document why and what protects it.

The standard

What a reviewer expects to see

An inventory that a stranger could use to walk the boat and find every device
Criticality decisions with the reasoning attached, not just a flag — the reasoning is what survives a challenge
A network map that shows the boundary between IT and OT explicitly, since Section 7 and Section 8 depend on it
A patch cadence with a named source for vulnerability intelligence and a stated maximum time to act
Compensating controls written where patching is genuinely impossible, with the risk accepted in writing
The satellite link and the crew wifi shown on the map, because that is where the flat-network problem hides

An illustration

How a criticality determination reads when it is defensible

Not a template to copy. This is the shape and specificity a section reads with when it has been written from a real operation — bracketed where your facts go.

Vessel gauging and alarm system (M/V [name], [make/model]).
Designation: CRITICAL.

Reasoning: the system reports tank levels used during transfer
operations. Manipulation or loss of this data during a transfer
could contribute to an uncontrolled discharge, which meets the
transportation security incident threshold. Manual gauging is
available as a fallback and is exercised, which lowers likelihood
but does not change the criticality designation.

Connections: local network only; no routable path to the vessel
wifi segment. Verified [date] by [name].

Evidence

What has to be producible

Asset inventory with criticality designations and last-verified dates
Network diagram, versioned
OT configuration exports or documented settings
Approved hardware and software list
KEV log: vulnerability, date identified, action taken, date closed, or compensating control
Vulnerability-report intake channel and its records
Justification memos for any internet-exposed OT

Records are kept at least two years and produced on demand §101.640, at the same vessel and facility inspections you already receive.

Failure modes

How this section gets a plan returned

An inventory of computers only: The rule reaches operational technology. Engine monitoring, gauging, chart systems, the vessel router, terminal control systems — these are the assets the rule was written about.
Criticality assigned by cost: The test is consequence, not price. An inexpensive device that could contribute to a transportation security incident is critical; an expensive one that could not, is not.
A network map that stops at the office door: The interesting risk is the path from the office to the boat and back. A map that omits the satellite link omits the finding.
No patching cadence at all: Patching without delay is the standard for known-exploited vulnerabilities. A plan silent on how you learn about them cannot claim to meet it.

Questions

What operators ask about this section

How do we decide what is critical?: One test, from the Coast Guard's own assessment guidance: could compromise of this system contribute to a transportation security incident? Yes or maybe means designate it critical. Write down the reasoning either way — the reasoning is what a reviewer evaluates.
Do we need a network map if we have six boats and one office?: Yes, and it will be short. The value is not complexity; it is that the boundary between your office systems and your operational systems is drawn somewhere explicit rather than assumed.
What if a system cannot be patched?: Document a compensating control and the accepted risk. The rule anticipates this — unpatchable operational technology is normal. What is not acceptable is silence.