JARUS SORA Explained in Plain English

If you operate drones commercially, JARUS SORA can look like a wall of acronyms: GRC, ARC, SAIL, OSO, TMPR, ConOps. In plain English, it is much simpler than it first appears.

JARUS SORA is a structured way to answer one question: is this drone operation safe enough for the place, people, airspace and aircraft involved?

It is not a permission by itself. It is not a form you fill in once and forget. It is a risk assessment method, developed by the Joint Authorities for Rulemaking on Unmanned Systems, that many aviation authorities use or reference when assessing drone operations in the Specific category. You can find the source material through the official JARUS publications and, in Europe, SORA-based guidance appears within EASA’s Easy Access Rules for Unmanned Aircraft Systems.

This guide explains what JARUS SORA means, when it matters, how the 10-step process works, and how to think about it practically if you are a drone operator, survey company, utility team or emergency service.

What is JARUS SORA?

SORA stands for Specific Operations Risk Assessment. JARUS stands for Joint Authorities for Rulemaking on Unmanned Systems.

Put together, JARUS SORA is a methodology for assessing drone operations that are too complex or too risky to fit neatly into low-risk rules, but not necessarily so high-risk that they fall into the certified aviation category.

The method looks at two broad types of risk:

Ground risk: What could happen to uninvolved people, buildings, roads, infrastructure or property if the drone fails or falls?

Air risk: What could happen if the drone comes close to, or collides with, another aircraft?

From there, SORA works out what mitigations, procedures, technical systems, crew competence and evidence are needed to make the operation acceptable.

A useful way to think about it is this: SORA does not ask whether drones are safe in general. It asks whether this specific operation, using this aircraft, flown by this team, in this location, under these conditions, is controlled well enough.

When do drone operators need SORA?

You may encounter SORA when your planned operation does not fit the Open category or a pre-defined regulatory route such as a standard scenario or pre-defined risk assessment. The exact terminology and process depends on your aviation authority, so always check the current rules in the country where you are operating.

In broad terms, SORA becomes relevant when the regulator wants a structured safety argument for a Specific category operation.

Type of operation	What it usually means	SORA relevance
Low-risk Open category flight	The operation stays within clear limits for aircraft, distance, height, people and location	A full SORA is usually not required
Standard scenario or pre-defined assessment	The regulator has already defined the conditions and mitigations for a known type of operation	You may not need a full bespoke SORA if you comply with the scenario
Bespoke Specific category operation	The operation does not fit a standard route and needs operational authorisation	SORA is often used to build the safety case
Higher-risk operation approaching certified category	The operation may involve significant risk to people, airspace users or critical systems	SORA may not be sufficient on its own

Common examples where SORA may become relevant include beyond visual line of sight operations, flights near congested areas, operations close to critical infrastructure, complex public safety deployments, drone-in-a-box operations, higher-altitude work, or repeated operations across multiple sites.

That said, SORA is not only for advanced BVLOS projects. A visually line of sight operation can still require careful assessment if the location, population density, airspace or operational complexity demands it.

The core idea: risk on the ground plus risk in the air

The SORA process combines the seriousness of the ground risk and the air risk to determine the level of safety assurance expected from you.

If you fly a small drone over an empty rural field, the consequences of a failure are likely to be lower. If you fly a heavier aircraft near people, roads, railways, industrial sites or emergency activity, the consequences increase. Likewise, flying in airspace with little aviation activity is very different from operating near aerodromes, helicopter routes, temporary restricted areas or emergency aviation activity.

SORA turns those realities into a structured argument. You describe the operation, classify the risks, apply mitigations, then show evidence that your mitigations are real, reliable and repeatable.

Key JARUS SORA terms in plain English

Before looking at the steps, it helps to decode the main acronyms.

SORA term	Plain-English meaning
ConOps	Concept of operations. A clear description of what you plan to do, where, when, how, with which aircraft and crew
GRC	Ground Risk Class. A measure of the risk to people and property on the ground
ARC	Air Risk Class. A measure of the risk of encountering other aircraft
SAIL	Specific Assurance and Integrity Level. The level of confidence the regulator expects in your safety controls
OSO	Operational Safety Objective. A safety objective you may need to satisfy depending on the SAIL
TMPR	Tactical Mitigation Performance Requirement. The expected performance of detect-and-avoid or see-and-avoid measures during flight
Robustness	How strong and well-evidenced a mitigation must be. It considers both how effective it is and how well you can prove it
Operational volume	The three-dimensional space where the drone is intended to fly
Contingency volume	Additional space reserved for abnormal situations before the aircraft becomes uncontrolled
Adjacent area or airspace	The area around the operation that could be affected if containment fails

The most important word in that table is probably evidence. SORA is not just about saying that you have a mitigation. It is about showing why the mitigation is suitable and how you know it will work in practice.

The 10 JARUS SORA steps explained simply

The JARUS SORA methodology is often described as a 10-step process. The official documentation is technical, but the logic is straightforward.

Step	What the step does	Plain-English question
1. Describe the ConOps	Defines the operation in detail	What exactly are we going to do?
2. Determine the intrinsic ground risk	Assesses the basic risk before mitigations	If the drone fails, who or what could it hit?
3. Apply ground risk mitigations	Reduces ground risk where justified	How can we reduce the chance or consequence of harm on the ground?
4. Determine the initial air risk	Assesses the airspace and likely aircraft activity	What other aircraft could be nearby?
5. Apply strategic air mitigations	Reduces air risk before the flight starts	Can we avoid conflict through planning, coordination or timing?
6. Define tactical mitigations	Sets requirements for avoiding traffic during the flight	How will we detect and avoid other aircraft in real time?
7. Determine the SAIL	Combines ground and air risk into an assurance level	How demanding does our safety evidence need to be?
8. Meet the OSOs	Identifies safety objectives linked to the SAIL	What procedures, training, systems and checks must we prove?
9. Check adjacent areas and airspace	Looks at what happens if the drone leaves the intended area	What is the worst credible outcome if containment fails?
10. Build the safety portfolio	Pulls the argument and evidence together	Can a regulator trace every risk to a suitable control?

The process is not meant to be a box-ticking exercise. If your ConOps changes, the risk assessment may change. If you use a different aircraft, change the flight profile, move to a new location, alter the crew structure or introduce automation, you may need to revisit parts of the SORA.

A simple worked example

Imagine a utility company wants to inspect a 2 km stretch of overhead power line using a multirotor drone. The route is mostly rural, but it crosses a minor road, passes near a small group of houses and sits below airspace occasionally used by low-level helicopters.

The ConOps would describe the aircraft, operating height, route, crew roles, launch and recovery points, communications, emergency procedures, weather limits, batteries, operating volume and contingency areas. It would also explain whether the flight is visual line of sight, extended visual line of sight or beyond visual line of sight.

The ground risk assessment would consider what lies beneath and beside the route. Empty fields may be lower risk. The road crossing, houses and any public access points increase the concern. Mitigations might include selecting launch points away from people, timing the operation to avoid peak activity, using observers at access points, maintaining buffers, defining emergency landing areas and setting clear abort criteria.

The air risk assessment would look at the class of airspace, nearby aerodromes, known helicopter activity, temporary restrictions and local aviation patterns. Strategic mitigations might include coordinating with relevant stakeholders, selecting a quieter time window, publishing or checking appropriate aeronautical information where required, and avoiding known traffic hotspots. Tactical mitigations might include visual observers, defined scan sectors, radio procedures where appropriate, and immediate descent or landing actions.

The SAIL then tells the operator how rigorous the supporting evidence must be. A lower SAIL may require relatively simple procedures and records. A higher SAIL may demand stronger proof of training, technical reliability, containment, maintenance, emergency response and organisational control.

The key point is that the same aircraft can produce different SORA outcomes in different environments. A rural inspection, an urban inspection and an emergency inspection after a storm are not the same safety problem.

What a strong SORA safety case usually proves

A good SORA submission is specific, traceable and operationally realistic. It should not read like a generic safety manual copied from a previous job. The regulator or internal approver needs to see a clear line between the operation, the risk, the mitigation and the evidence.

Evidence area	What it needs to show
Operational description	The flight is clearly bounded by location, height, aircraft, crew, procedures, weather and operating limits
Ground risk controls	People and property on the ground have been identified and protected by proportionate mitigations
Air risk controls	Other airspace users have been considered and conflict risk is reduced before and during flight
Crew competence	Pilots, observers and support staff are trained, briefed and current for their roles
Aircraft suitability	The aircraft, payload, command link, failsafes and maintenance regime are appropriate for the operation
Procedures and checklists	Normal, abnormal and emergency actions are documented and usable under real conditions
Containment	The aircraft is expected to remain within the operational volume, and failures have been considered
Records	Planning, approvals, checks, logs and post-flight reviews can be retrieved and audited

This is where many operators underestimate the work. The SORA document itself is only part of the safety case. The surrounding records, such as training, maintenance, checklists, flight logs, briefings, site assessments and change control, are what make the argument credible.

How Dronedesk can support SORA preparation

Software cannot make the safety judgement for you, and it cannot guarantee an operational authorisation. But the right operational system can make it easier to organise the evidence that sits behind your SORA.

Dronedesk is an all-in-one drone operations management platform. According to the Dronedesk features page, it includes flight planning, airspace intelligence, proximity intelligence, risk assessments, configurable checklists, flight logging, fleet management, team management, client management and data reporting.

Those features align with many of the records operators need to manage around a SORA-based workflow.

SORA need	Dronedesk capability that can support the workflow
Define and plan the operation	Flight planning, airspace intelligence and proximity intelligence
Record site-specific controls	Risk assessments and configurable checklists
Show crew and asset control	Team management and fleet management
Keep an operational record	Flight logging and data reporting
Connect work to the customer or task	Client management

For organisations with multiple aircraft, pilots and operating sites, SORA evidence becomes closely linked to wider operational control. If that is becoming difficult to manage in spreadsheets, this drone fleet management guide explains what changes as drone operations scale.

Common SORA mistakes to avoid

Most weak SORA submissions fail for practical reasons, not because the operator does not understand aviation theory. The usual problem is that the safety argument is not specific enough, or the claimed mitigations are not backed by evidence.

Mistake	Why it causes problems
Starting with the risk tables before defining the ConOps	You cannot assess risk properly until the operation is clearly described
Copying a previous assessment	Similar jobs can have different ground risk, air risk, crew needs and emergency actions
Using vague mitigations	Phrases such as maintain awareness or avoid people are not enough without clear procedures
Overestimating the value of a mitigation	A mitigation only counts if it is suitable, reliable and evidenced
Forgetting adjacent areas	Regulators care about what happens if the drone leaves the planned volume
Treating VLOS as a cure-all	Visual line of sight helps, but it does not remove the need to assess airspace, workload and visibility
Failing to keep records	If you cannot show what happened, it is difficult to prove the operation was controlled

A useful test is to ask whether another competent person could read your safety case and understand exactly how the operation will be conducted. If the answer is no, the ConOps or procedures probably need more work.

Practical preparation before you start a SORA

Before diving into the methodology, gather the basics. This saves time and reduces the risk of reworking the assessment later.

• Define the operation in one sentence, including the purpose, aircraft type, location and flight profile.
• Create a map of the operational volume, contingency volume and relevant surrounding areas.
• Identify people, roads, railways, buildings, utilities, public access points and sensitive sites.
• Review airspace, aerodromes, helicopter activity, temporary restrictions and local aviation patterns.
• Gather aircraft specifications, maintenance records, failsafe details and payload information.
• Confirm pilot, observer and crew competence for the specific operation.
• Write normal, abnormal and emergency procedures in language the crew can actually use.
• Decide what evidence will prove each mitigation, not just what mitigation sounds good on paper.

The more repeatable your operation is, the more value you get from standard procedures, checklists and records. The more unusual your operation is, the more important it becomes to explain the assumptions and limitations clearly.

SORA is a safety argument, not just a calculation

It is tempting to think of JARUS SORA as a set of tables that produce an answer. The tables matter, but they are not the whole story.

A strong SORA explains the logic behind the numbers. It shows why the ground risk classification is appropriate, why the air risk classification is realistic, why the mitigations are credible, and why the organisation can deliver the operation consistently.

For survey companies, that may mean showing that repeat site work is planned and controlled consistently. For utility companies, it may mean demonstrating corridor-specific controls, emergency landing options and stakeholder coordination. For emergency services, it may mean explaining how dynamic deployments are managed without losing control of airspace, crew roles, authorisation and records.

The regulator is not looking for perfect safety. Aviation never works that way. They are looking for a proportionate, evidence-based case that the remaining risk is acceptable.

Frequently Asked Questions

Is JARUS SORA mandatory for all drone operations? No. Many low-risk operations do not need a full SORA. It becomes relevant when your aviation authority requires a structured risk assessment for a Specific category or similarly complex operation. Always check the current rules in your operating jurisdiction.

Is SORA only for BVLOS flights? No. BVLOS operations commonly need a SORA-style safety case, but complex VLOS operations can also require detailed assessment depending on the location, airspace, people on the ground and operational profile.

What does SAIL mean in SORA? SAIL means Specific Assurance and Integrity Level. It indicates how strong your safety evidence needs to be. A higher SAIL does not mean the operation is better. It means the operation requires more demanding assurance.

Can drone operations software complete a SORA automatically? Software can help organise planning, risk assessments, checklists, logs, fleet records and supporting evidence. It cannot replace competent operational judgement or guarantee regulatory approval.

Which SORA version should I use? Use the version and guidance accepted by your aviation authority. JARUS documents evolve, and regulators may adopt, adapt or reference specific versions differently.

Keep SORA evidence under control

JARUS SORA is easier to manage when your operational records are clear, consistent and accessible. If your team is planning flights, assessing risks, managing pilots and aircraft, completing checklists and logging flights across separate tools, the safety case can quickly become harder to maintain.

Dronedesk brings drone operations management into one platform, with tools for planning, risk assessments, checklists, airspace and proximity intelligence, flight logging, fleet records, team management and reporting. If SORA is becoming part of your regular operational life, centralising those records can make your safety evidence much easier to control.