Unresolved vulnerabilities
Documentation of all identified, unresolved vulnerabilities, including those intentionally unresolved due to owner or operator risk acceptance
What is still open, and what you have decided to live with, in writing.
Section 12 contains the most misunderstood permission in the rule: you are explicitly allowed to leave a vulnerability unresolved because the owner or operator has accepted the risk. The rule says so in the section title.
That is a significant accommodation for an industry running equipment that cannot be patched and vessels that cannot come off charter for a firmware upgrade. What the rule asks in exchange is that the decision be visible, reasoned, and owned by someone with the authority to make it.
What §101.630(c)(12) hard-wires into this section
- All identified, unresolved vulnerabilities
- Open items, not only the comfortable ones. A short Section 12 in a real operation invites the question of whether the assessment was thorough.
- Intentionally unresolved items, marked as such
- Distinguish "working on it" from "decided against it." They are different states and a reviewer reads them differently.
- The risk-acceptance rationale
- Why this risk is acceptable, given the operation. Cost alone is a weak rationale; operational reality, compensating controls, and consequence bounding are strong ones.
- Compensating controls where a known-exploited vulnerability is not patched
- The rule permits compensating controls in place of immediate patching. Document them here and in Section 6.
- Renewal-cycle penetration test findings
- Whatever the five-year test surfaces that remains open lands in this section.
What a reviewer expects to see
- Risk acceptance signed by someone with authority to accept it — an owner or officer, not the CySO alone
- A review date on every accepted risk, so acceptance does not become permanent by default
- Compensating controls described specifically enough to verify
- A stated criterion for what may be accepted versus what must be fixed
- Honest inclusion of the uncomfortable items, which is the section's whole credibility
A risk acceptance that holds up
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.
V-2026-011 · Open · Intentionally unresolved (risk accepted) Vulnerability: the [system] on three vessels runs a version no longer receiving security updates. The vendor's upgrade requires a hardware replacement and a shipyard period. Compensating controls: the system is on the segmented OT network with no routable path from the business network or crew wifi; physical access is limited and logged (Section 8); configuration is documented and verified quarterly against a known-good baseline. Consequence bound: loss or manipulation would degrade [function]; manual fallback exists and is exercised in the annual drill. Accepted by [Owner/Officer], [date]. Review at the next scheduled drydocking or [date +12 months], whichever comes first.
What has to be producible
- Open findings register with dates identified and current status
- Risk-acceptance records with signature, date, rationale, and review date
- Compensating-control documentation
- Evidence that accepted risks were revisited on schedule
Records are kept at least two years and produced on demand §101.640, at the same vessel and facility inspections you already receive.
How this section gets a plan returned
- An empty Section 12
- Every real operation has open items. An empty section suggests the assessment did not look hard, which undermines Section 14.
- Risk accepted by the wrong person
- The rule frames it as owner or operator risk acceptance. A technician cannot accept enterprise risk, and a reviewer will notice who signed.
- Acceptance with no review date
- An accepted risk with no revisit becomes a permanent decision made once, under conditions that have since changed.
- Cost as the stated rationale
- It reads badly and it is the reasoning most likely to be challenged. Where cost is genuinely the driver, frame it as proportionality with the consequence bounded and compensating controls named.
What operators ask about this section
- Are we really allowed to leave something unfixed?
- Yes. The rule's own section title names intentional non-resolution due to owner or operator risk acceptance. What it requires is that the decision be documented, reasoned, and made by the owner or operator.
- Will an open Section 12 hurt our plan approval?
- An honest Section 12 with reasoned acceptances and compensating controls reads as a program that understands its own risk. An empty one raises harder questions about the assessment behind it.
- What about known-exploited vulnerabilities?
- Those must be patched without delay or have compensating controls documented. The compensating-control route is legitimate; silence is not.