The Part 5 Declaration of Compliance: An Evidence Checklist

A declaration of compliance is a short, high-stakes document. In it, the operator tells the FAA that its safety management system satisfies the revised 14 CFR Part 5 and is functioning. It is the last milestone in the timeline the 2024 SMS final rule set out. That rule was published 2024-04-26 and took effect 2024-05-28, extending SMS beyond the Part 121 airlines to all Part 135 certificate holders, to 91.147 commercial air tour operators flying under a letter of authorization, and to certain Part 21 certificate holders. The Part 5 final rule is the source document for all of it.

For Part 135 and 91.147 operators, the sequence is fixed. Implementation plans were due 2024-11-28. The SMS has to be fully implemented, and the declaration submitted, no later than 2027-05-28, and that date holds regardless of size, down to single-aircraft and single-pilot certificate holders. Certain Part 21 certificate holders that held their certificate on the effective date share the 2027-05-28 implementation date. Part 121 carriers that already ran an FAA-accepted SMS had a shorter runway: they had to conform to the revised Part 5 by 2025-05-28. Operators that took part in the FAA's earlier Safety Management System Voluntary Program (SMSVP) transition into the new Part 5 requirements, and Part 135 SMSVP letter holders also work to the 2027-05-28 deadline.

Two things about the declaration are easy to underestimate. First, the signer. The accountable executive signs it, and the rule means one identifiable person: whoever controls the resources the SMS depends on and holds final responsibility for it. It is not the safety manager's signature, and it is not a committee's. Second, the word functioning. Attesting that a system is implemented is a claim about existence. Attesting that it is functioning is a claim about behaviour, that the system has been used and has produced results. The 2024 revisions also require a confidential employee reporting system, and the declaration presumes that system is not only stood up but actually receiving reports.

The cleanest way to prepare the declaration is to build the evidence one component at a time. Part 5 is organised into four components, the same four that ICAO Annex 19 defines: Safety Policy, Safety Risk Management, Safety Assurance, and Safety Promotion. Here is what defensible evidence looks like under each.

Safety Policy. The governance spine:

• A safety policy signed by the accountable executive, current and communicated.
• The accountable executive designation and defined safety accountabilities across management.
• The confidential employee reporting system, with its policy and evidence it is in use.
• Emergency response coordination and the controlled SMS documentation itself.

Safety Risk Management. Where hazards become decisions:

• A documented hazard identification process, and a hazard log that is actually populated.
• A risk assessment method, typically a risk matrix, applied consistently.
• Records of hazards analysed, risk accepted or mitigated, with the rationale kept.

Safety Assurance. The feedback loop that proves the system works:

• Safety performance monitoring and measurement through defined indicators.
• Internal audits and evaluations, with findings raised and tracked.
• A management of change process, applied to real changes.
• Investigation of reports and corrective actions tracked to verified closure.

Safety Promotion. How safety competence and information move:

• Training and competency records for the people in safety-critical roles.
• Safety communication: bulletins, lessons learned, and evidence they reached people.

Read the four lists back and a pattern jumps out. Almost every line is a record with a date, an owner, and an outcome, not a document that sits still. That is the real test the declaration has to pass, and it is worth being honest about before you sign. Managing all four components in one place, rather than four disconnected trackers, is what keeps the evidence coherent when the auditor pulls a thread.

There is a failure mode that catches well-run operators off guard: a fully documented SMS that is not yet a functioning one. The binders are immaculate. The policy is signed, the procedures are written, the risk matrix is drawn, the training deck exists. And almost none of it has moved.

A binder proves you wrote a procedure. A record proves someone followed it. The FAA, and any competent auditor, asks for the second kind. Show me the hazard reports from the last quarter and how each was dispositioned. Show me the risk assessments, with scores and who accepted the residual risk. Show me the corrective actions you opened, and the evidence each one actually worked before you closed it. Show me that when a safety indicator drifted, someone noticed and did something. Those are the records that turn functioning from an adjective into a fact.

This is where the shape of your tooling starts to matter. If your SMS lives as documents, functioning evidence is something you assemble by hand, screenshot by screenshot, the month before submission, and it goes stale the moment you finish. If your SMS lives as connected operating data, the evidence is a by-product of running the operation. A hazard is a record. Its assessment is a record linked to it. The corrective action is a record linked to that, and it cannot be marked closed until its effectiveness is shown. Those enforced closure gates mean the trail exists because the work happened, not because someone built the trail for the audit.

The distinction is not cosmetic. An SMS that only produces binders can pass a documentation review and still fail the question the declaration actually answers, which is whether the system does anything. Records are what separate a written SMS from a working one, and the declaration is a statement about the working one.

Before you sign, run every requirement through a simple three-state test: is it neither documented nor implemented, documented but not implemented, or documented and functioning. Most operators discover their real position is more mixed than the binder suggests.

The trap is the middle state, where documented quietly masquerades as done. A few concrete examples that show up again and again:

• A hazard-reporting procedure that reads well and has produced zero reports in six months. Documented. Not functioning.
• A risk matrix in the manual with no completed assessments on file. Documented. Not functioning.
• A management of change policy that no actual change has ever been run through. Documented. Not functioning.
• A training module everyone was assigned and a third completed. Partly functioning, and you need the completion records to know which third.

Scoring each requirement honestly across those three states is exactly what a gap analysis does, and it is the right first move once you commit to the deadline. A structured Part 5 gap analysis produces a prioritised list: the neither items that need building, the documented-only items that need to be put into real use, and the functioning items that only need their evidence tidied for export. Sequencing that work by risk, rather than by the order requirements appear in the manual, is what turns a two-to-three week analysis into a credible declaration rather than a scramble.

The three-column test also protects the signer. When the accountable executive signs, the honest question is not whether the SMS is written but whether it is working. A component-by-component, requirement-by-requirement view of documented versus functioning is the evidence that lets that person sign with confidence instead of hope.