Specific Operations Risk Assessment: A Practical Readiness Guide

What SORA Is and Why It Exists

SORA was developed by the Joint Authorities for Rulemaking on Unmanned Systems (JARUS) and adopted by the European Union Aviation Safety Agency (EASA) as an Acceptable Means of Compliance with Article 11 of Regulation (EU) 2019/947. Its purpose is to give operators and national aviation authorities (NAAs) a shared, structured language for evaluating risk before a flight authorisation is granted.

The specific category sits between the low-risk open category, which requires no authorisation, and the certified category, which demands full aircraft and operator certification. Operations that fall into the specific category include beyond visual line of sight (BVLOS) flights, operations over people, and any mission that does not fit a predefined standard scenario. For these cases, SORA provides a ten-step process that moves from describing the intended operation all the way through to identifying the safety objectives the operator must meet.

SORA version 2.5, the current edition, was incorporated into EASA’s Easy Access Rules for Unmanned Aircraft Systems in June 2026 following the publication of ED Decision 2025/018/R. Operators preparing submissions today should work from this version rather than the earlier 2.0 release.

The Ten Steps at a Glance

The process begins with a Concept of Operations (ConOps). This document captures the technical, operational, and human factors relevant to the intended flight. A weak ConOps is a common reason an application stalls, because every later step draws directly from it.

Steps two and three establish the Ground Risk Class (GRC) and the Air Risk Class (ARC). The GRC reflects the risk of the drone striking people or property on the ground, taking into account factors such as drone size, kinetic energy, and the population density of the operational area. The ARC reflects the risk of a mid-air collision with manned aircraft or other drones, and is classified from ARC-a (low traffic, low risk) to ARC-d (high traffic, high risk).

Steps four through seven apply mitigations to reduce the initial GRC and ARC values. Mitigations are grouped into three types: M1 mitigations reduce ground risk through operational restrictions or sheltering assumptions; M2 mitigations use technical means such as containment systems; and strategic mitigations reduce air risk by restricting the airspace used. Each mitigation must be demonstrated at a level of robustness, low, medium, or high, that matches the risk being addressed.

Step eight combines the residual GRC and ARC into a Specific Assurance and Integrity Level (SAIL), which runs from I (lowest risk) to VI (highest risk). The SAIL then drives step nine, which identifies the Operational Safety Objectives (OSOs) the operator must satisfy. OSOs cover areas such as remote pilot competency, maintenance procedures, emergency response, and human factors. Step ten is submission: the operator sends the completed risk assessment, compliance evidence, and operator manual to the NAA for review.

Ground Risk: Calculating and Reducing Your GRC

The intrinsic GRC is determined by the drone’s maximum characteristic dimension and the nature of the area overflown. A small drone flying over a sparsely populated rural area will attract a low intrinsic GRC, while a larger aircraft operating over a controlled ground area in an urban setting will attract a higher one. SORA 2.5 revised the method for determining population density used in this calculation, so operators who completed assessments under version 2.0 should review whether their GRC values still hold.

Operators can reduce the GRC by applying M1 mitigations. M1A covers sheltering, recognising that people indoors are substantially protected from a falling drone. M1B covers operational restrictions such as avoiding overflying people entirely. M1C covers the use of ground observers to maintain situational awareness during the flight. Each credit claimed must be supported by documented procedures and, at higher SAIL levels, by evidence of training and testing.

M2 mitigations rely on technical containment, for example a geofencing system or a parachute recovery device that limits the area a drone can reach in the event of a failure. EASA requires that M2 mitigations with a high level of robustness be verified by a Design Verification Report (DVR) issued by EASA itself. Medium-robustness M2 mitigations can be declared by the manufacturer if appropriate means of compliance are used.

• Define the operational volume precisely, including the ground risk buffer and contingency volume.
• Identify the population density category for the overflown area using current data.
• Select M1 mitigations that are operationally realistic and can be documented.
• Confirm whether any M2 technical mitigation requires a DVR before planning your timeline.
• Review GRC values against SORA 2.5 if your ConOps was drafted under an earlier version.

Air Risk: Understanding ARC and Strategic Mitigations

The ARC reflects the density and type of manned aviation traffic in the airspace the drone will use. Uncontrolled low-level airspace in a remote area will typically attract ARC-a or ARC-b, while airspace near an aerodrome or in a busy transit corridor may attract ARC-c or ARC-d. Operators should consult the relevant airspace charts and, where necessary, engage with the air navigation service provider early in the planning process.

Strategic mitigations reduce the ARC by restricting when, where, and how the drone operates. Common examples include time-of-day restrictions, altitude caps, geographic boundaries, and coordination with ATC. Tactical mitigations, such as detect-and-avoid systems, can provide additional credit but require a higher level of technical evidence. For most operators in the specific category, strategic mitigations are the more practical route.

Operations near aerodromes require particular care. Aerodrome operators are expected to conduct their own risk assessments covering drone intrusion scenarios, and a UAS operator planning to fly in the vicinity of an aerodrome should expect the NAA to scrutinise the ARC determination and the proposed mitigations closely. Early coordination with the aerodrome operator and ATC is strongly advisable.

SAIL Levels and What They Mean for Your Documentation

The SAIL is the single most important output of the SORA process because it determines the depth of documentation and evidence the operator must produce. SAIL I and II operations require relatively straightforward documentation: a clear ConOps, basic training records, and standard operating procedures. SAIL III and IV operations require more detailed evidence of competency, maintenance regimes, and emergency procedures. SAIL V and VI operations require a level of rigour comparable to manned aviation, including potential type certification of the aircraft.

Each SAIL level maps to a set of OSOs, and each OSO must be met at a specified level of robustness. An operator who underestimates their SAIL, for example by applying mitigations that are not adequately supported, risks having their application rejected or returned for revision. Conversely, an operator who overestimates their SAIL will produce more documentation than necessary, which adds cost and time without improving safety.

NorthSky provides operational risk decision support and advisory guidance. Outputs do not constitute regulatory certification, aerodrome licensing, compliance verification, or formal authority determinations.

Practical preparation for higher SAIL levels should begin well before the submission deadline. Building the evidence base for OSOs, particularly those related to training, maintenance, and human factors, takes time, and gaps discovered late in the process are difficult to close quickly.

Common Preparation Gaps and How to Address Them

The ConOps is the foundation of the entire assessment, and vague or incomplete ConOps documents are a leading cause of delays. Operators should describe the operation in enough detail that someone who has never seen the site or the aircraft can understand exactly what will happen, where, when, and with what equipment. This includes the flight geography, the contingency volume, the crew composition, and the emergency procedures.

Mitigation claims that cannot be substantiated are another frequent problem. Stating that a drone has a parachute recovery system is not sufficient; the operator must show that the system has been tested, that it functions reliably at the relevant altitude and speed, and that the crew knows how to respond if it activates. Similarly, claiming M1A sheltering credit requires evidence that the population in the operational area is genuinely indoors during the planned flight window.

Operators sometimes underestimate the time required to obtain a DVR for M2 mitigations with high robustness. If your risk reduction strategy depends on a technical mitigation that requires EASA verification, build that timeline into your project plan from the start. Waiting until the rest of the SORA is complete before initiating the DVR process is a common and avoidable source of delay.

• Write the ConOps as if the reader has no prior knowledge of your operation or aircraft.
• Gather supporting evidence for every mitigation claim before drafting the compliance section.
• Check whether any M2 mitigation requires a DVR and initiate that process early.
• Map each OSO to specific documented procedures and training records.
• Have a colleague not involved in drafting read the full package before submission.

Submitting to the NAA and What Happens Next

When the SORA is complete, the operator submits three documents to the NAA: the application form for operational authorisation, a copy of the risk assessment with compliance evidence, and a copy of the operator manual. The NAA reviews the submission and, if satisfied, issues the operational authorisation. If the submission is incomplete or the mitigations are not adequately supported, the NAA will return it for revision.

NAAs across Europe apply the SORA framework consistently in principle, but their specific procedures, timelines, and interpretations vary. Some NAAs publish guidance notes or checklists that clarify their expectations. Reviewing any such material before submission can reduce the likelihood of a revision request.

The operational authorisation is not permanent. It is tied to the specific operation described in the ConOps. If the operator changes the aircraft, the operational area, the crew, or any other material element of the operation, a new or amended authorisation may be required. Operators should treat the authorisation as a living document and maintain the underlying evidence base so that amendments can be processed without starting from scratch.