ICAO Doc 9859 is guidance to design from,
not text to copy.

See the highlighted block above the contents list. The rest of this article walks through what Doc 9859 is, how it is organized around the State Safety Programme and the operator SMS, how to use it as design guidance instead of transcribing it, and why safety assurance and indicator design are the parts that decide whether your system actually works.

ICAO publishes safety management in two connected layers. Annex 19 to the Convention on International Civil Aviation carries the Standards and Recommended Practices. It defines the SMS framework of four components and twelve elements and the State Safety Programme that each contracting State runs. Doc 9859, the Safety Management Manual, is the guidance material that supports Annex 19. It adds no requirements. It explains how to meet the ones Annex 19 sets.

The distinction matters more than it looks. An operator preparing for oversight is assessed against the applicable regulation, the national rule that transposes Annex 19, not against Doc 9859. The manual is where you learn how to build the thing the regulation expects. Treating the SMM as a compliance checklist is the first mistake, and it is a common one: the manual is a design reference, and it says so about itself. You do not get points for quoting it. You get points for running a system that matches what it describes.

ICAO revises the manual as safety management practice matures, so work from the current edition and read it alongside your own authority guidance. A State can add detail on top of the ICAO baseline, or set its own acceptable level of safety performance, so the manual is the floor of good practice rather than the last word. If you are new to the framework, the fastest orientation is to see how the same four components map onto a national rule; our Annex 19 in 90 days walkthrough does exactly that.

The SMM addresses two readers, and the whole manual makes more sense once you notice which one a passage is written for. For the State, it describes the State Safety Programme (SSP): how an authority sets safety objectives, runs its own safety risk management, oversees operators, and monitors national safety performance. For the operator, it describes the safety management system (SMS): the same discipline applied inside one organisation. The two interlock. The State sets an acceptable level of safety performance, and the operator demonstrates its own performance against agreed indicators.

Both the SSP and the SMS are built on the same four components: safety policy and objectives, safety risk management, safety assurance, and safety promotion. Under those four sit the twelve elements that make them concrete, from management commitment and safety accountabilities through hazard identification, risk assessment, safety performance monitoring, management of change and continuous improvement, to training and safety communication. If you want the components broken down on their own, we cover them in the four components of an SMS.

Where the manual earns its length is measurement. Safety performance indicators (SPIs) are the metrics an operator tracks to know whether its controls are working. Safety performance targets set where those indicators should sit. The acceptable level of safety performance is the agreed bar between operator and authority. This is the machinery of safety assurance, and it is the point where the framework stops being a policy statement and starts being an early-warning system. A pre-built SPI library is one way to avoid starting that measurement plan from a blank page.

The most common failure is to treat Doc 9859 as manual text. Teams lift its wording into a company safety manual and produce a document that reads correctly and describes a system nobody runs. An auditor who reads a manual quoting the SMM back at them, then walks the floor and finds none of it happening, has found the exact gap the manual warns about: paperwork that does not match practice.

Use the SMM instead to answer design questions. What should our hazard identification process actually produce? How do we decide a risk is tolerable, and who signs that decision? What makes an indicator leading rather than lagging? The manual answers those at the level of principle. Your job is to turn each principle into a process your people follow, sized to your operation. The difference between a leading precursor and a lagging outcome is worth getting right early; we lay it out in leading vs lagging indicators.

Scale is the other thing to read correctly. Annex 19 and the SMM are explicit that an SMS is scalable. A small operation does not need a large one committee structure, it needs the same four components implemented at a proportionate weight. Reading the manual as a fixed template forces small operators into oversized process and quietly lets large ones under-build. Reading it as design guidance lets both size the system correctly, which is the whole point of the exercise.

Of the four components, safety policy is the easiest to write and the one teams over-invest in. Safety assurance is the hardest to run and the one they under-read. Assurance is the feedback loop: are the controls we put in place actually working, and how would we know? It draws on safety performance monitoring, internal audit, management of change and continuous improvement. Without it, an SMS is a risk register that never checks itself, a filing cabinet of good intentions with no mechanism to confirm any of them held.

Indicator design is where assurance lives or dies, and the manual treatment of it rewards a second reading. A good indicator is specific, owned, and tied to a control you actually care about. It has a target and a defined action when it breaches. The SMM pushes toward a balance of leading indicators (precursors, measured before harm) and lagging indicators (outcomes, measured after harm), because a dashboard of only lagging metrics reports on accidents you have already had. Assurance built on lagging data alone is a rear-view mirror.

Where many implementations fall short is turning indicators into a red, amber and green trend bar. A colour is not a signal. The manual intent, and mature safety analytics, is to know when an indicator has genuinely shifted versus when it is moving inside normal variation. That distinction, common-cause noise versus a real special-cause change, is precisely what statistical process control provides, and it is what separates measurement from decoration. We contrast the two in real SPC vs coloured trend bars.

The gap Doc 9859 cannot close for you is the one between guidance and a live operational system. The manual tells you what safety assurance should do. It cannot make your occurrences, hazards, indicators and corrective actions live in one place where the loop actually runs. That is an implementation problem, and it is where most SMS efforts stall: the manual is written, the framework is understood, and the day-to-day still happens across disconnected spreadsheets and inboxes.

eAviora is built to the shape the SMM describes. The four components are not chapters to write, they are wired into one operational graph: occurrences, hazards, investigations, corrective actions, audits, findings, documents, training, compliance and SPIs as linked records. The Safety Risk Profile is computed, eight components fused into a single four-level score aligned to ICAO Doc 9859, rather than a number someone assigns. A pre-built 610-indicator SPI library gives assurance a starting point instead of a blank measurement plan.

Assurance that checks itself is the part the manual most wants and that tooling most often fakes. In eAviora, indicators run real statistical process control using the Western Electric rules, so a breach is a detected signal rather than a colour change. Closure is gated: a record cannot close over open risk, and a degraded barrier needs a linked corrective action proven effective before the item closes. That is safety assurance as a mechanism, not a paragraph in a manual. See it in the SMS module, or talk to us to walk the framework through on your own operation.