An SMS that fits one pilot
and three aircraft.

See the highlighted block above the contents list. The sections below explain why the rule reaches the smallest operators, what it means that an SMS scales by depth rather than existence, why a borrowed airline manual backfires, what a right-sized system looks like for one to three aircraft with no safety department, and how lightweight software carries the load without adding burden.

The FAA SMS final rule, published on April 26, 2024 and effective on May 28, 2024, revised 14 CFR Part 5 and extended Safety Management System requirements well beyond the Part 121 airlines. It brought in all Part 135 certificate holders, commercial air tour operators under a 91.147 letter of authorization, and certain Part 21 certificate holders. The line small operators most need to read is explicit in the revised Part 5 rule: it applies regardless of operator size, including single-aircraft and single-pilot certificate holders.

The timeline is the same one every Part 135 operator works to. Implementation plans were due to the FAA on November 28, 2024, and the SMS must be fully implemented with a declaration of compliance submitted no later than May 28, 2027. There is no threshold below which the obligation disappears, and no version of the rule that lets a one-aircraft operation opt out. The same 2027 deadline that a regional carrier plans around is the deadline a single-pilot certificate holder plans around.

This is not the FAA being heavy-handed. It follows the ICAO framework in Annex 19, where the SMS of four components and twelve elements is described as scalable to the size and complexity of the operation, and the ICAO Doc 9859 Safety Management Manual, in its current edition, spends real effort on how to right-size a system. The intent has always been that a small operator runs a small SMS, not no SMS.

The single most useful idea for a small operator is this: scalability applies to depth, not to existence. Every operator runs the same four components of an SMS. What changes with size is how much of each you run, and how often.

Consider what actually scales. A large carrier might track hundreds of open hazards, run several standing committees that meet weekly, publish dozens of safety performance indicators, and maintain a document library measured in binders. A three-aircraft operator tracks a short live hazard list, holds a single monthly safety review, watches a handful of indicators that matter to its operation, and keeps a manual of a few pages. Both are running Safety Risk Management. In one it is a committee process; in the other it is a fifteen-minute structured review before the month closes.

Now consider what does not scale away. The four components themselves are mandatory at any size. The confidential reporting channel is required whether you employ two hundred people or two. The discipline of assessing risk on what comes in, and carrying a corrective action to proven closure, is the same discipline at any scale. When an operator gets a Part 5 finding, it is almost never because their SMS was too small. It is because a component was missing entirely, most often a confidential channel that never existed or a closure step that never happened. Depth is a choice; existence is not.

The most common mistake a small operator makes under deadline pressure is to obtain a large operator's SMS manual, change the name on the cover, and submit it. It feels efficient. It is the single fastest way to earn a finding.

A borrowed airline manual describes an operation you do not run. It references a Safety Action Group and a Safety Review Board that meet on a cadence you cannot staff, post-holders you do not employ, and procedures for departments you do not have. An auditor does not grade the manual as an essay. They read what it claims, then watch what you do, and the gap between the written system and the real one is exactly where the finding lands. A thick manual full of promises you cannot keep is worse than a thin one that is true, because every unmet promise is a documented non-conformity you wrote yourself.

There is a second cost. A borrowed manual buries the few routines that genuinely matter for your operation under dozens of pages of procedure that will never happen, so the document stops being a tool your crew uses and becomes a shelf artifact. The fix is to right-size the structure of the manual to your operation: describe what you actually do, who does it, and how often. If a section describes a committee that does not exist, delete it. The manual and the operation have to match, and in a small operation the shortest honest manual is the strongest one.

So what does a right-sized system look like when the whole operation is one to three aircraft and there is no safety department? It is built around a few honest routines, and it lets roles double up wherever that does not compromise independence.

• Roles combine, one boundary holds. The accountable manager might be the owner, and the safety manager might be the chief pilot. That is acceptable at this size, as long as the one boundary you never blur is the confidential reporting channel: a report has to be able to reach the system and be de-identified without the reporter being exposed.
• Cadence matches volume. Instead of weekly committees, a single monthly safety review of what was reported, what the risk looked like, and what actions are open. Short, minuted, and real.
• The FRAT is the daily workhorse. A pre-flight flight risk assessment tool, run before every flight, is the highest-value routine a small operator has. It turns day-to-day go/no-go judgement into scored data, and a pattern of high scores is a leading signal worth reviewing.
• Confidential reporting still applies, and matters more. In a two-person operation everyone knows who flew what, which makes a genuinely de-identified reporting channel harder and more important, not optional. A real closed loop, where the reporter gets feedback without ever being named, is what makes people willing to raise the next hazard.

Notice that none of this is a smaller idea than an airline SMS. It is the same four components, sized to the operation. The work of running it, though, is where a small operator is most exposed, because there is no team to absorb it. That is a software problem.

Most small operators start in a spreadsheet, and a spreadsheet is a fine first hazard log. It becomes a liability at exactly the moment it counts. A spreadsheet cannot stop a hazard from being marked closed while its corrective action is still open. It cannot de-identify a confidential report. It leaves no linked trail from an occurrence to the risk assessment to the action that fixed it, so when a reviewer asks you to prove the loop closed, you rebuild it by hand. And it quietly corrupts the moment two people edit it at once.

The instinct is then to reach for a big platform, and the fear is that software means more work. For a small operator the opposite is true when the tool is built right, because most of the burden of a spreadsheet SMS is building and maintaining the content by hand. eAviora removes that burden at the source: the risk model comes in the box, a pre-built library of 101 bow-tie models, 804 named barriers, 210 scenarios and a 610-indicator safety performance indicator library. A one-aircraft operator does not author a hazard catalog. It is there on day one, and you scope it down to your operation.

From there, the same discipline that protects an airline protects a single-pilot operator, without adding staff. The SMS module runs occurrences, hazards, risk assessments and corrective actions on one operational graph, so the evidence trail is a byproduct of doing the work. The enforced closure gate means a record cannot close over open risk: a degraded barrier requires a linked corrective action, proven effective, before anything reads as closed. That is the closure discipline a busy owner-pilot might otherwise forget, made structural. AI helps carry the paperwork: specialist agents draft the classification and first-pass risk assessment, and every proposal is human-gated, so a person accepts, modifies or rejects it and the decision is audit-logged. Consumption is metered in plain credits with hard caps, your data never trains any model, and tenant isolation is enforced by the database, not just by app code. To see it sized to your operation, you can book a walkthrough.