SORA for drones: how the Specific Operations Risk Assessment works

SORA, the Specific Operations Risk Assessment, is the method a drone operator uses to prove that a flight in the Specific category is safe enough to be approved. The Specific category sits between the low-risk Open category and the high-risk Certified category, and it covers operations that go beyond Open limits, such as flying beyond visual line of sight or over people in ways Open rules do not allow. Rather than a fixed rulebook, SORA is a structured risk assessment that an operator works through and submits to the national aviation authority to earn an operational authorisation.

This guide explains where SORA comes from and when you need it, how the assessment weighs ground risk and air risk to arrive at a single risk level, what that level then demands of the operation, and how the evidence behind it should be kept. The current version, SORA 2.5, became the reference method across the EU in late 2025, so the walkthrough follows its ten-step shape and its language around risk classes and safety objectives.

Where SORA comes from and when you need it

SORA was developed by JARUS, the Joint Authorities for Rulemaking on Unmanned Systems, as a risk assessment method that authorities worldwide could share, and versions of it are used in Canada, Australia, and beyond as well as the EU. In Europe, EASA adopted SORA as an accepted means of complying with Article 11 of Regulation (EU) 2019/947, the article that requires a risk assessment for Specific-category operations. So when an operation does not fit the Open category, SORA is the standard path to showing it can be flown safely.

You need a full SORA when your operation falls in the Specific category and no lighter route already covers it. For common operations, a Standard Scenario or a Predefined Risk Assessment lets an operator declare against a ready-made assessment instead of building one from scratch. When no such shortcut fits, the operator carries out the SORA itself, describing the operation in a concept of operations and then working through the risk to the ground and the air. The output is a package the authority reviews before granting authorisation.

How the assessment arrives at a SAIL

The core of SORA is turning a described operation into a single measure of how much assurance it demands. The method assesses the ground risk, meaning the danger to people and property if the drone comes down, and the air risk, meaning the chance of meeting a crewed aircraft. Each is scored, then reduced by mitigations the operator applies, such as limiting where and when the flight happens or containing the aircraft within a defined volume. The JARUS SORA 2.5 main body sets out each step and the tables behind the scoring.

The final ground and air risk results combine into a Specific Assurance and Integrity Level, or SAIL, graded from one to six. The SAIL is the pivot of the whole method: a higher SAIL means a higher-risk operation, which in turn demands stronger evidence that the operation is under control. A flight over a busy area near an airport lands at a high SAIL and has to show far more than the same drone flown at a remote test range below a low altitude. The SAIL is what translates risk into how much an operator must prove.

What the SAIL then demands

Once the SAIL is set, it points to a list of Operational Safety Objectives, or OSOs, that the operation has to meet, with the demanded level of assurance rising as the SAIL rises. There are 24 of these objectives in the current method, and they cover things like the reliability of the drone, the training of the remote pilot and crew, procedures for normal and emergency situations, and how the operator maintains the aircraft. A low-SAIL operation may satisfy many objectives lightly, while a high-SAIL one has to evidence each in depth.

Alongside the objectives, SORA looks hard at containment: the measures that keep a failing drone inside its intended area and out of adjacent ground and airspace, assessed at low, medium, or high levels. When every step is done, the operator submits a package to the authority that typically includes the risk assessment and its supporting evidence, an operations manual describing the procedures, and the application itself. If the authority is satisfied, it issues the operational authorisation that lets the flights go ahead.

Keeping the SORA and its evidence on file

A SORA is not a one-time form; it is a live description of how an operation stays safe, and the authorisation rests on the operation matching it in practice. The assessment names the aircraft, the pilots and crew, the procedures, the operating volume, and the mitigations, and each of those has to hold in practice. If a pilot's training lapses, a procedure drifts, or the aircraft changes, the evidence behind the SAIL weakens, and the operation may no longer sit inside the authorisation it was granted. Keeping the assessment aligned with reality is an ongoing job, not a filing task.

That is easier when the pieces the SORA depends on live in one place: the risk assessment and the SAIL it produced, the operations manual, the crew qualifications, the aircraft maintenance history, and any incident that touches the safety case. Tie each of those to the operation the authorisation covers, and an operator can show, on request, that the flight matched the assessment it was approved under. The authorisation is the permission, and the maintained record is what proves the operation still earns it.

Common mistakes with SORA

Reaching for a full SORA when a shortcut fits. Many operations are covered by a Standard Scenario or a Predefined Risk Assessment, which let you declare against a ready-made assessment. Building a full SORA when one of these applies adds weeks of work for no regulatory gain.

Treating the SAIL as the finish line. Arriving at a SAIL is the middle of the process, not the end. The SAIL points to the safety objectives and containment evidence the operation still has to meet, and skipping that step leaves an assessment that no authority will accept.

Underestimating ground risk in populated areas. Ground risk scales with how many people could be under the flight, and current SORA uses population data to set it. Assuming a route over a town scores like open country is a fast way to build an assessment the authority sends straight back.

Writing the assessment and never revisiting it. An authorisation assumes the operation keeps matching its SORA. When crew, procedures, or the aircraft change and the assessment is not updated, the operation can drift outside what was approved without anyone noticing until a check.

Submitting evidence that does not match the assessment. The safety objectives call for evidence at a level set by the SAIL, and vague or missing proof stalls the review. Authorities look for specific documentation tied to each objective, not general assurances that the operation is careful.

FAQ

When do I need a SORA instead of a simpler approval?

You need a SORA when your operation is in the Specific category and no Standard Scenario or Predefined Risk Assessment covers it. If one of those ready-made routes fits your operation, you can declare against it instead of building a full risk assessment.

What is a SAIL in SORA?

A SAIL, or Specific Assurance and Integrity Level, is the risk level SORA assigns to an operation on a scale of one to six. It reflects the combined ground and air risk and sets how much evidence the operation must provide to be approved.

Who reviews and approves a SORA?

The national aviation authority of the country where you operate reviews the SORA. You submit the risk assessment, supporting evidence, and an operations manual, and if the authority is satisfied that the operation meets its safety objectives, it issues an operational authorisation.

Is SORA only used in Europe?

No. SORA was written by JARUS for international use, and countries including Canada, Australia, and New Zealand base their Specific-category approvals on it. The EU version, adopted by EASA under Regulation (EU) 2019/947, is one widely used implementation among several.

Closing thought

SORA is the method that turns a described Specific-category operation into a single risk level, the SAIL, and then into a concrete list of safety objectives and containment measures the operation has to meet before an authority will approve it. It rewards operations that understand their own ground and air risk and can evidence how they keep it under control.

If you are building a Specific-category operation around a SORA, FlybyOps was built for the operational record problem at the center of regulated drone work. A risk register, a document vault with expiration tracking, a project and job hierarchy with map-based scoping, and an append-only audit log are all part of how the platform keeps each risk assessment, the SAIL it produced, and the evidence behind every mitigation filed together for the authority that approved it.