Operational Safety Objectives in SORA: the OSO list explained

The operational safety objectives sora applicants work through are the twenty four items that turn a risk classification into a list of things you must demonstrate. They arrive late in the process, after ground risk and air risk have been assessed and combined into a Specific Assurance and Integrity Level, and they are where most of the real effort lands. Everything before the OSOs is analysis. The OSOs are where an operator has to show that procedures exist, that people are trained, that the aircraft is built well enough, and that somebody checked.

The list itself is fixed. What changes from one application to the next is how convincingly each objective has to be met, because the required level of assurance rises with the SAIL. That single mechanism explains most of what confuses newcomers: two operators can face the same twenty four objectives and have wildly different workloads. This article covers where the OSOs sit in the sequence, how the SAIL sets the bar, what the objectives cover, and why the evidence behind them is a records problem rather than a writing exercise.

Where the OSOs sit in the sequence

SORA is a ten step process that starts with a description of the operation and works outward. Ground risk considers what the aircraft could strike, driven by population density, whether the flight is within visual line of sight, the size of the aircraft, and the mitigations applied. Air risk considers the chance of encountering manned traffic in the airspace, again adjusted for mitigations. Combining the residual ground and air risk produces the SAIL, which expresses the intrinsic risk of the whole operation on a scale from I to VI.

Only then do the OSOs enter. They are not a separate methodology or an optional annex. They are the compliance half of the assessment, applied once the risk half has produced a number. A final step follows them, assessing the risk in the area adjacent to the operation and requiring containment so that an aircraft losing control does not become somebody else's problem. Applicants who write the OSO evidence before settling the SAIL usually write too much in some places and not enough in others.

How the SAIL sets the bar

The graduation is the point. As EASA describes the SORA methodology, once the SAIL is determined the applicant works through the twenty four operational safety objectives and shows compliance at a level of assurance that increases with the SAIL, so a higher risk operation faces more demanding standards and more evidence put in front of the national aviation authority. A low SAIL operation may satisfy an objective with a written procedure. The same objective at a high SAIL may require independent verification that the procedure works.

Design related objectives show the ladder most clearly, because the route to compliance changes level by level. At SAIL I and II, the operator may declare compliance against the applicable design related OSOs. At SAIL III there is a published means of compliance to work to. At SAIL IV the aircraft needs a design verification report issued by EASA. At SAIL V and VI the aircraft needs a type certificate under the airworthiness regulation, which is a manned aviation level of effort. A technical mitigation applied at a high level of assurance also pulls a design verification report into the picture.

What the objectives cover

The twenty four objectives group loosely around four sources of trouble. The first is technical failure of the aircraft system itself, covering how it was designed, who built it, how it is maintained, and how faults are detected. The second is deterioration of external services the operation depends on, such as position data or a command and control link, where the objective is that the operator understands the performance it needs and knows when it no longer has it. Neither group is satisfied by owning good equipment. Both ask what you do about it.

The third group is human error, which reaches remote pilot competence, crew procedures, workload, and the training behind all of it. The fourth is adverse operating conditions, meaning environmental limits, contingency and emergency procedures, and the discipline of not flying outside declared conditions. Read together, the list is a description of a functioning operation rather than a paperwork obstacle, which is why programs with real procedures find the OSOs tedious and programs without them find the OSOs impossible.

Turning objectives into evidence that survives

An OSO response is a claim about how an operation behaves, and an authority reads it as a claim to be substantiated. When the application says that maintenance is performed on a defined schedule by competent personnel, the substantiation is a maintenance record showing that happening. When it says remote pilots are trained and current, the substantiation is a training record with dates and outcomes against named individuals. The submission to the authority is an application form, the risk assessment with its compliance evidence, and the operator manual, and the second of those is only as strong as the operation underneath it.

That is the part applicants underestimate. An authorization is granted against an operation as described, and the description keeps being true only if the records keep being kept. Pilots change, aircraft are replaced, procedures get revised after an incident, and the evidence supporting objective eleven quietly stops matching reality. Programs that hold OSO evidence as living records rather than as an application archive can answer an audit years later. Programs that treat the submission as the deliverable find themselves rewriting it for a renewal from an operation that has moved on.

Common mistakes in SORA operational safety objectives

Writing OSO responses before the SAIL is settled. The required level of assurance depends on the SAIL. Drafting evidence first means either wasted effort or a rewrite once the number lands.

Reading the OSO list as a checklist to tick. Each objective asks for demonstrated capability at a defined level of rigor. A one line assertion satisfies the form and not the assessor.

Assuming a certified aircraft answers the design objectives. Design related OSOs have different routes by SAIL, from declaration through published means of compliance to a design verification report or type certificate.

Forgetting the containment step. The assessment does not end at the OSOs. The adjacent area and the aircraft's containment in a loss of control are a separate requirement with their own evidence.

Filing the evidence and walking away. An authorization describes an operation as it was. Personnel, aircraft, and procedures drift, and the records have to move with them or the evidence stops being true.

FAQ

How many operational safety objectives are there in SORA?

Twenty four. The list is fixed regardless of the operation, but the level of assurance required for each one rises with the SAIL, so the work involved varies enormously between a low and a high risk application.

Do all twenty four OSOs apply to every operation?

The list is applied against the SAIL, and objectives carry different required levels at different SAILs, with some effectively optional at the lowest levels. The assessment tables define which apply and how strongly.

Is SORA required for every Specific category operation?

No. Operations that fit a published standard scenario or a pre defined risk assessment use those lighter routes instead. SORA is the method for operations that no published scenario covers.

What does an operator submit to the authority?

The application form for the operational authorization, a copy of the risk assessment together with the compliance evidence supporting it, and a copy of the operator manual describing how the operation runs.

Closing thought

The OSO list looks like the hardest part of SORA and is mostly the most honest part. It asks whether the operation you described on paper is the operation you run day to day, then asks for proof scaled to how much damage getting it wrong would do. Operators who already keep maintenance, training, and flight records find that most of the answers exist. Operators who do not find that the application is asking them to build a program.

If you are building the evidence pack a national authority will read line by line, FlybyOps was built for the operational record problem at the center of regulated drone work. A risk register with severity and likelihood scoring plus mitigation owners and review dates, a pilot registry tracking training and currency, an equipment registry with per airframe history, and an append-only audit log are all part of how the platform keeps each safety objective tied to the procedure, training record, or maintenance entry that satisfies it.