SORA Explained: The Drone Risk Assessment That Runs Your Authorisation

SORA is the document trail that turns "we'd like to fly BVLOS" into a signed authorisation. Founders hear "risk assessment" and imagine a form; it's closer to a systems-engineering argument about your operation, graded on rigour. Understanding its skeleton before you start saves months of iteration with the authority.

The logic in one diagram's worth of words

1. Describe the operation precisely (ConOps: where, when, how, with what, flown by whom).
2. Score what happens if the aircraft hits the ground → Ground Risk Class (GRC).
3. Score what it could collide with in the air → Air Risk Class (ARC).
4. Apply mitigations that provably reduce those scores.
5. Combine into a SAIL level (I–VI).
6. The SAIL selects which Operational Safety Objectives (OSOs) you must meet, and how rigorously — from "declare it" to "have it verified".

Everything you write must trace back to the ConOps — the assessor's first question about any claim is "where does the ConOps say that?"

Ground risk: population and kinetic energy

Intrinsic GRC comes from aircraft size/energy versus what's underneath: controlled area → sparsely populated → populated → assemblies. The levers engineering controls:

• Smaller/lighter aircraft — kinetic energy is a design variable (mass budget, again).
• M1 strategic mitigation — flying where people aren't: route design over water, rail corridors, industrial land. Cheapest GRC points available; buy them at mission-planning level.
• M2 impact reduction — parachute systems and similar, with evidence of effectiveness (deployment envelope, descent energy, reliability testing). Effective, but the evidence bar is real.
• Emergency Response Plan — procedural, always required, occasionally under-loved in applications and flagged.

Air risk: who else is in that sky

ARC follows airspace character: ARC-a (segregated) through ARC-d (busy controlled). Mitigation splits into strategic (operate where and when traffic isn't: altitude bands, geo-zones, time windows, coordination with the ANSP) and tactical — detect-and-avoid duties that scale from "see and be seen" (VLOS, observers) to technical DAA systems for higher-ARC BVLOS. Practical startups engineer their ARC down — low altitude, rural corridors, U-space where available — before they engineer DAA up; sensors that reliably detect a paraglider are a harder deliverable than a route that avoids paragliders.

SAIL and OSOs: where the effort curve lives

SAIL	Flavour of burden
I–II	Mostly declarations; sound manuals, trained crew, basic technical file. Reachable by a diligent small team.
III–IV	Evidence with teeth: design and reliability substantiation, structured flight-test data, possibly third-party verification of claims. The inflection point where "documentation as afterthought" startups stall.
V–VI	Approaching certified-world rigour; rare for startups, deliberate for scale-ups with matching missions.

The ~24 OSOs cover the operator (organisation, procedures, training), the aircraft (design, C3 links — your datalink architecture shows up here), and external systems. Each is graded Low/Medium/High robustness by SAIL: the same objective might need a self-declaration at SAIL II and validated evidence at SAIL IV.

Running SORA without drowning: field-tested advice

1. Decide your target SAIL first, then design the operation to hit it. SORA rewards operation-shaping: a route moved 400 m, a launch window shifted, a controlled ground area negotiated — each can drop a class and halve your evidence bill.
2. Meet the NAA before writing. A pre-application conversation about your ConOps surfaces their expectations and their pet peeves; authorities differ in both.
3. Reuse the ecosystem: PDRAs where they fit, published means-of-compliance, and (against the obvious economics) consultants for the first application — buying the template and the vocabulary, not outsourcing the understanding.
4. Version-control the whole package like source code: ConOps, OSO matrix, evidence index. Your second authorisation should be a diff, not a rewrite.
5. Write for the assessor: claims → evidence → traceability. Adjectives are not mitigations.

Frequently asked questions

What is SORA in drone regulations?

SORA (Specific Operations Risk Assessment) is the methodology EASA member states use to evaluate drone operations in the Specific category. It scores ground risk and air risk, applies mitigations, and outputs a SAIL level that determines how much evidence the operator and aircraft must provide.

What is a SAIL level?

SAIL (Specific Assurance and Integrity Level, I–VI) expresses how demanding your operation is after mitigations. SAIL II might mean declarations and basic evidence; SAIL IV and above pull in design verification and organisational requirements approaching certified-world rigour.

How long does a SORA-based authorisation take?

Realistic ranges: 2–4 months for a clean low-SAIL operation with a complete application, 6–12+ months for higher SAIL or novel operations — heavily dependent on application quality and the authority's workload. Pre-application meetings with the NAA reliably shorten the loop.