ISM Code Yacht Requirements: The Records You Have to Produce, Not Just Keep

What the ISM Code actually requires of a yacht

The International Safety Management (ISM) Code is the framework that turns a company's safety intentions into a documented Safety Management System (SMS) the vessel runs on. It applies to commercially operated yachts of 500 gross tonnage and above; below that, and for private yachts, application follows the flag administration and the relevant yacht code, and many vessels adopt the same SMS framework voluntarily [1]. Where it applies, compliance is evidenced by two certificates sustained by audit: a Document of Compliance held by the company, and a Safety Management Certificate held aboard the vessel.

Four sections do most of the work an auditor checks. Section 10 requires the company to establish procedures ensuring the ship is maintained and inspected at appropriate intervals, with defects reported and corrective action taken. Section 11 requires the documents and data relevant to the SMS to be controlled — valid, available where needed, obsolete versions removed. Section 9 covers reporting and analysing non-conformities and accidents, and the corrective action that follows. Section 12 is the internal audit, run in normal practice once a year for each vessel [2].

Read together, they ask one thing repeatedly: that records exist, stay current, and can be produced.

The requirement the Code doesn't spell out

Here is the quiet gap. The Code requires that records exist. It does not require that they be searchable, connected to one another, or transferable to the next crew [1]. A maintenance log in a folder three rotations deep satisfies the letter of section 11 right up until someone has to find one specific entry while an auditor waits.

That silence is where avoidable findings live. A non-conformity is rarely written because the work wasn't done. It is written because the vessel cannot demonstrate that it was done — the record takes twenty minutes to locate, sits on a departed engineer's phone, or turns out to have been overwritten when someone corrected it in place [3]. "You didn't service the generator" and "you can't show you serviced the generator" read very differently on paper, and only the second is the auditor's to write up.

What makes a record count as evidence

If retrieval is the real test, the property that matters most is whether a record can be trusted once it is found. A maintenance entry that could have been edited after the fact — a date changed, a signature added later, an inconvenient line quietly removed — is weak evidence, because there is no way to show it wasn't tampered with. Records that can be retroactively modified cannot serve as evidence.

That is the case for an append-only record. The ledger is append-only: nothing is ever overwritten. Corrections are recorded as new entries referencing the original, and the original remains intact. Deleted rows are struck through, never purged — the trail is the trail. Every action — logging a fault, creating a work order, signing a handover — is attributed, by signed-in user and role, and timestamped: who acted, what they did, when, and which record was affected.

Open any record and read its full audit trail. For an auditor that turns a request into a retrieval — not "let me assemble the file" but "here is the entry, here is who made it, here is when." The audit trail is not a feature. It is a legal defence: the same trail that answers an internal ISM audit answers the flag-state or Port State Control inspection behind it, and the underwriter after an incident. For the deeper case on how an append-only audit trail stands up under inspection, see the companion piece.

Section 10 in practice: the record that carries its own paperwork

Section 10 is where most engineering evidence sits, and where a planned-maintenance system on its own tends to fall short. A PMS records that a task was marked complete. It rarely holds the surrounding context an auditor asks for next: which official procedure was followed, why a workaround was used because the original part is discontinued, or the class certificate for the equipment involved. The gap between a maintenance log and defensible evidence is the gap between a tick and a document.

A work order that carries its own paperwork closes that gap. The service record, the running-hours or calendar schedule, the SOP, the relevant ISM procedure, and the equipment's certificate live on the record itself — so "show me this was done to procedure" is answered without anyone leaving the page or opening a second system. On the compliance vitamins that sit alongside it, keep certificates tracked to expiry, with renewal dates and the source PDF attached, and let alerts surface as expiry approaches.

Running ISM evidence alongside the SMS you already have

None of this replaces the SMS, the DPA's procedures, or the engineer's judgement. The work, the analysis, and the sign-off stay with the people who own them. The system proposes; the engineer decides — nothing is logged or signed without a person doing it. What changes is whether the by-product of that work stays with the vessel in a form you can produce on demand — which is also what keeps operational knowledge aboard when crew turnover and knowledge loss would otherwise carry it off the gangway.

CelesteOS is built for exactly that. Records are captured as the crew works, connected to one another, searchable in plain language, and attributed when someone asks who did what and when. It runs alongside your existing planned-maintenance system — nothing to replace, nothing to migrate — and your existing PMS keeps its class society approvals. On the compliance line itself, CelesteOS is aligned with the ISM Code, sections 10 and 11; it is audit evidence, not class approval of the software. Each vessel's data is isolated, encrypted at rest and in transit. Every record it holds is independently verifiable at verifier.celeste7.ai, and you can produce verifiable, auditable maintenance records the way an auditor's question actually arrives. When the work is captured this way, audit prep becomes retrieval, not assembly — a point we walk line by line in the ISM internal audit checklist.

Frequently asked questions

Summary

• The ISM Code applies to commercially operated yachts of 500 gross tonnage and above; its SMS asks that records exist, stay current, and can be produced on demand.
• Sections 9, 10, 11 and 12 are what an audit checks — maintenance and inspection evidence, controlled documents, non-conformity and corrective-action records, and the internal audit itself.
• Most findings are retrieval failures, not work failures: the maintenance happened, but the record can't be produced, is out of date, or was overwritten.
• A record only counts as evidence if it can be trusted once found — append-only, attributed, and timestamped; one that can be retroactively modified cannot serve as evidence.
• Keeping the evidence connected, searchable, and attributable turns audit prep into retrieval, and runs alongside the SMS and PMS you already have.

CelesteOS keeps a yacht's maintenance and compliance records with the vessel — connected, searchable, attributed, and independently verifiable — so ISM evidence is a retrieval, not an assembly. Learn about the pilot.