Drone Risk

SORA Readiness for Airfield Operations: What Operators Need to Know

If you plan to fly a drone in the specific category at or near an airfield, you will almost certainly need to work through a Specific Operations Risk Assessment (SORA). This guide explains what SORA readiness for airfield operations involves, where operators commonly run into difficulty, and how structured advisory support can help you build a submission that is coherent and complete before it reaches a national authority.

Published 10 March 2025Updated 18 June 2025

What SORA Is and Why It Applies to Airfield Environments

The Specific Operations Risk Assessment (SORA) is a methodology developed by the Joint Authorities for Rulemaking on Unmanned Systems (JARUS) to evaluate the safety of UAS operations that fall outside the open category. Under EU regulations 2019/947 and 2019/945, civil drone operations are classified into three categories: open, specific, and certified. The specific category uses a risk-based approach, and SORA is the primary acceptable means of compliance for operators seeking an operational authorisation from a national aviation authority (NAA). EASA has published SORA as an acceptable means of compliance to Article 11 of Regulation (EU) 2019/947.

Airfield environments sit at the more demanding end of the SORA spectrum. Controlled aerodromes, military airfields, and uncontrolled grass strips each present different combinations of air traffic density, obstacle environments, and ground populations. A drone operating near an active runway introduces air risk that must be assessed and mitigated in a structured way. Ignoring or underestimating that risk is one of the most common reasons an operational authorisation application is returned or delayed.

SORA version 2.5, published by JARUS in May 2024, is the current reference document. It refines earlier editions and introduces clearer guidance on how safety services can support operators in calculating ground risk class (GRC) and air risk class (ARC). Operators preparing new submissions should work from version 2.5 rather than the older 2.0 framework.

The Ten Steps of SORA and Where Airfield Operations Add Complexity

SORA is a ten-step process. It begins with a description of the intended operation, known as the Concept of Operations (ConOps), and moves through ground risk evaluation, air risk evaluation, the assignment of a Specific Assurance and Integrity Level (SAIL), the definition of Operational Safety Objectives (OSOs), and finally the preparation of a submission package for the NAA. Each step builds on the previous one, so errors or vague language early in the ConOps tend to propagate through the entire assessment.

For airfield operations, steps two and three – ground risk class and air risk class – are where most complexity arises. Ground risk class is determined by factors including the UAS characteristic dimension, the kinetic energy of the aircraft, and the population density of the area overflown. Air risk class is shaped by the type of airspace, the volume of manned traffic, and whether the operation is conducted within visual line of sight (VLOS) or beyond visual line of sight (BVLOS). At an active aerodrome, both scores can be elevated, which pushes the resulting SAIL level higher and increases the number and robustness of OSOs the operator must demonstrate.

Mitigations are divided into strategic and tactical categories. Strategic mitigations reduce the likelihood of a hazardous event through planning – for example, by restricting the operational volume to a defined area away from the runway strip. Tactical mitigations reduce the severity or probability of a collision during flight, such as the use of a detect-and-avoid capability or a ground-based observer. Each mitigation must be assigned a robustness level – low, medium, or high – and the operator must provide evidence that the claimed robustness is achievable with the equipment and procedures described in the operator manual.

  • Define the Concept of Operations with enough detail for the NAA to understand the flight environment and intended activity.
  • Determine the intrinsic and final ground risk class using UAS size, kinetic energy, population exposure, and any applicable mitigations.
  • Determine the initial and final air risk class using airspace structure, traffic density, and the planned operating method.
  • Combine the final ground and air risk outputs to derive the SAIL level.
  • Identify the applicable Operational Safety Objectives and the robustness level expected for each one.
  • Address adjacent area and airspace considerations that may affect people, aircraft, or infrastructure outside the core operational volume.
  • Compile the safety portfolio, including the operator manual, supporting evidence, and references for each mitigation and OSO.
  • Submit the application package to the NAA and prepare to answer follow-up questions or requests for clarification.

Ground Risk at Aerodromes: Key Factors Operators Overlook

Ground risk at an aerodrome is not simply a function of how many people are standing on the apron. It also includes the population of passengers in terminal buildings, ground crew on the manoeuvring area, and members of the public in adjacent car parks or access roads. Operators who scope their ground risk assessment too narrowly – focusing only on the immediate flight path – often find that the NAA requests a revised assessment that accounts for the full operational volume and its adjacent areas.

The intrinsic GRC is calculated using the UAS characteristic dimension and the expected population density of the overflown area. Mitigations such as operational procedures that restrict flight to low-density periods, or the use of a ground observer to halt the operation if unauthorised persons enter the area, can reduce the final GRC. However, each mitigation must be described precisely in the operator manual and must be realistic given the operator’s actual resources. A mitigation that relies on equipment the operator does not own, or a procedure that cannot be executed by the crew size described in the ConOps, will not be accepted.

Aerodrome operators themselves have obligations under safety management frameworks. ICAO Annex 19 requires that organisations providing services in support of aircraft operations implement a Safety Management System (SMS) that includes hazard identification and risk assessment. A UAS operator working at an aerodrome should understand how their operation interacts with the aerodrome’s existing SMS, and should be prepared to demonstrate that their procedures are compatible with the aerodrome’s published operating procedures and any relevant local instructions.

Air Risk Assessment and the Role of Airspace Classification

Air risk class reflects the probability that a UAS will encounter a manned aircraft in the operational volume. The initial ARC is determined by the class of airspace in which the operation takes place. Class A airspace, where all flights are under instrument flight rules and subject to air traffic control, carries a different baseline risk profile than Class G airspace, where visual flight rules traffic may be present without ATC separation. Airfields often sit beneath or within controlled airspace, which affects the ARC calculation directly.

Strategic mitigations for air risk include measures such as coordinating with air traffic services to define a segregated volume, restricting operations to times when manned traffic is absent or minimal, or using a Notice to Airmen (NOTAM) to alert other airspace users. Tactical mitigations include the use of a remote identification system, a detect-and-avoid capability, or a ground-based observer with radio contact to the remote pilot. The robustness of each mitigation must be matched to the SAIL level derived from the combined risk assessment.

Operators sometimes assume that obtaining a NOTAM is enough to bring air risk down on its own. A NOTAM informs airspace users about the affected area, but the operator should assess how likely relevant traffic is to receive, interpret, and act on that information in the actual operating environment, especially in airspace where participation and situational awareness can vary. The SORA framework requires operators to examine residual risk after mitigations are applied, not only to list the mitigations themselves.

Preparing the Operator Manual and Compliance Evidence

The operator manual is the document that ties the SORA together. It must describe the operation in enough detail that the NAA can verify that every OSO is addressed, every mitigation is achievable, and every crew member has the training and competency required. A manual that is vague, internally inconsistent, or that references procedures not described elsewhere in the submission is a common source of delay.

Compliance evidence is the supporting material that demonstrates each claim in the manual is credible. For a technical mitigation, this might be a manufacturer’s datasheet, a test report, or a declaration of conformity. For a procedural mitigation, it might be a training record, a checklist, or a record of a previous operation conducted under similar conditions. The NAA is not required to accept claims that are not supported by evidence, and operators should not assume that a well-written manual will substitute for missing documentation.

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

When preparing compliance evidence, it helps to map each piece of documentation to the specific OSO or mitigation it supports. A simple table that lists each OSO, the claimed robustness level, and the document reference for the supporting evidence makes it easier for the NAA to review the submission and reduces the likelihood of requests for clarification.

Common Reasons SORA Submissions Are Returned or Delayed

The gap between the number of registered drone operators and the number of operational authorisations issued is significant. According to EASA data cited in published research, there are over 1.6 million registered drone operators in EASA countries, but only around 2,200 operational authorisations have been issued. This suggests that many operators who need an authorisation have not yet obtained one, and that the process presents real barriers.

The most frequently cited reasons for delay include an incomplete or ambiguous ConOps, a ground risk assessment that does not account for the full operational volume, OSOs that are claimed at a robustness level that is not supported by the evidence provided, and an operator manual that does not match the risk assessment. Drafting the ConOps alone can take considerable time – published accounts describe the process taking up to two years in complex cases – which underlines the value of starting with a clear and detailed description of the intended operation.

Operators who have previously flown under a standard scenario or a pre-defined risk assessment (PDRA) sometimes underestimate the additional work required for a full SORA. The PDRA route is available for operations that fit a pre-approved template, but airfield operations often involve conditions – airspace class, population density, proximity to infrastructure – that take them outside the scope of any available PDRA, making a full SORA necessary.

  • Incomplete or vague Concept of Operations that does not describe the operational environment in sufficient detail.
  • Ground risk assessment scoped too narrowly, missing adjacent populations or infrastructure.
  • Mitigations claimed at a robustness level not supported by available equipment or crew resources.
  • Operator manual that is internally inconsistent or does not align with the risk assessment.
  • Missing or inadequate compliance evidence for technical or procedural mitigations.
  • Air risk assessment that treats a NOTAM as a complete mitigation without addressing residual risk.

How Advisory Support Can Help Before You Submit

Working through a SORA for the first time, particularly for an airfield environment, is a substantial undertaking. Advisory support does not replace the operator’s responsibility to prepare and submit the application, but it can help identify gaps in the ConOps, check that the risk assessment is internally consistent, and review the operator manual for clarity and completeness before the submission reaches the NAA.

A structured pre-submission review can reduce the number of rounds of clarification required by the NAA, which in turn reduces the overall time from application to decision. It can also help operators understand which mitigations are realistic given their equipment and crew, and which OSOs are likely to attract scrutiny at the SAIL level their operation generates.

Tools that support the SORA process – such as airfield risk screening, SORA readiness checks, and safe movement planning – can help operators organise their thinking before they begin drafting the formal submission. Using a structured tool early in the process tends to surface issues that are easier to address at the planning stage than after the ConOps has been written and the risk assessment has been built around it.

Check Your SORA Readiness Before You Submit

Use the NorthSky SORA readiness tool to identify gaps in your assessment, or contact us to discuss advisory support for your airfield operation.

Start SORA Readiness Check

Frequently asked questions

Do I need a full SORA for every drone operation at an airfield?

Not necessarily. If your operation fits within a published standard scenario (STS-01 or STS-02) or a pre-defined risk assessment (PDRA), you may be able to use a simpler route. However, many airfield operations involve conditions – such as proximity to active runways, controlled airspace, or elevated population density – that take them outside the scope of available PDRAs, making a full SORA the appropriate path. Check the applicable PDRA conditions carefully before assuming a simplified route is available.

What is a SAIL level and how does it affect my application?

SAIL stands for Specific Assurance and Integrity Level. It is a number from I to VI derived by combining the final ground risk class and the final air risk class after mitigations have been applied. A higher SAIL level means a larger number of Operational Safety Objectives must be addressed, and many of those OSOs must be demonstrated at a higher robustness level. SAIL levels V and VI are rare and typically require significant technical and procedural infrastructure to support.

Can I use a NOTAM as my primary air risk mitigation?

A NOTAM can be one element of an air risk mitigation strategy, but it will rarely address the full risk picture by itself. It provides aeronautical information about an affected or restricted area; the operator should assess how likely relevant airspace users are to receive, understand, and act on that information in the specific operating environment. Under SORA, the operator assesses residual risk after the selected mitigations have been applied and substantiates the suitability of the resulting risk level. Depending on the operation, additional measures may include coordination with air traffic services, restrictions on the operational volume, improved conspicuity, or airspace observation.

How long does it typically take to prepare a SORA submission for an airfield operation?

Preparation time varies considerably depending on the complexity of the operation, the operator’s familiarity with the SORA process, and the quality of information available about the operational environment. Simple operations in low-risk airspace may take weeks to document properly. Complex operations near active aerodromes, particularly those involving BVLOS flight, can take several months. Published accounts describe ConOps drafting alone taking up to two years in the most complex cases. Starting early and using structured tools to organise the assessment helps reduce overall preparation time.

Does SORA apply in the United Kingdom as well as in EU member states?

The UK Civil Aviation Authority has indicated that it intends to introduce SORA as an acceptable means of compliance for specific category operations, but the UK SORA framework was still in development as of mid-2024. Until the UK SORA is finalised, operators in the UK applying to fly in the specific category should follow the methodology and templates set out in CAP 722A. There may be differences between the UK and EASA versions of SORA to accommodate national requirements.

What is the difference between a strategic and a tactical mitigation in SORA?

Strategic mitigations are applied before the flight takes place and reduce the likelihood of a hazardous event through planning and operational design – for example, restricting the operational volume to a defined area, scheduling flights during low-traffic periods, or coordinating with air traffic services. Tactical mitigations are applied during the flight and reduce the probability or severity of a collision if a hazard is encountered – for example, using a detect-and-avoid system or a ground observer who can alert the remote pilot to conflicting traffic. Both types must be assigned a robustness level and supported by evidence in the operator manual.

Sources

  1. EASA – Specific Operations Risk Assessment (SORA)
  2. JARUS SORA v2.5 Main Body – JAR_doc_25 (May 2024)
  3. UK Civil Aviation Authority – Specific Operations Risk Assessment (SORA)
  4. ICAO – Safety Management (Annex 19)