The UK has adopted SORA as its methodology for commercial BVLOS drone approvals. Most operators aren’t ready for it. The reason isn’t the regulation itself. It’s the operational infrastructure behind it.
Why BVLOS Isn’t a Flying Problem
Most people assume that flying a drone beyond visual line of sight is primarily a hardware challenge. Better batteries. Longer range radios. Reliable detect-and-avoid systems. Those things matter, but they’re largely solved problems for professional operators. The part that actually stops most commercial drone businesses from conducting BVLOS flights isn’t in the air. It’s on the ground, buried in the documentation and risk assessment process required to get approval in the first place.
The UK’s Civil Aviation Authority has adopted SORA as the structured methodology operators must use to build their safety case for BVLOS permissions. It’s a significant step towards a more systematic, data-driven approval process. But the CAA is also allowing operators with existing authorisations to renew under the previous process for a 12-month transition period while the SORA methodology is further refined.
That transition window matters. It means the market is in flux, and operators who treat it as breathing room rather than preparation time are making a mistake. The gap between “framework exists” and “operations happen at scale” is a software and data problem, and it’s one the industry hasn’t fully reckoned with.
What SORA Actually Requires
SORA stands for Specific Operations Risk Assessment. Developed through JARUS and adopted by the CAA, it’s the framework operators must use to demonstrate that a proposed BVLOS operation is safe before applying for advanced permissions.
On paper, the logic is sound. You assess the risk your operation poses to people on the ground and to other airspace users. You apply mitigations. You demonstrate a specific safety level. Approval follows.
In practice, the process is demanding. A single SORA submission requires you to characterise your operational volume with precision, classify the ground risk based on population density and controlled area status, determine your Air Risk Class by cross-referencing your flight geography against airspace encounter probabilities, select appropriate Strategic and Tactical mitigations, and document everything to a standard the CAA can audit.
Every one of those steps depends on data. Real-world operational data. Airspace data. Population density data. Encounter probability models. If you’re assembling that manually, pulling from different sources, formatting it into a document, and hoping it’s consistent and defensible, you’re doing this the hard way.
That’s where most operators currently are.
The Infrastructure Gap Nobody Talks About
The drone industry spent years waiting for BVLOS frameworks to emerge. Now that SORA is here in the UK, the conversation in trade press and industry events has largely moved to hardware certification, detect-and-avoid approval, and command-and-control link requirements. Those are real issues for later-stage operators. But the more immediate bottleneck for the vast majority of commercial operators isn’t certification. It’s the operational management infrastructure needed to build a credible safety case and sustain compliance once flights are approved.
Think about what BVLOS operations at any meaningful scale actually require. You need consistent pre-flight risk assessment, not just for the initial approval but for every mission variation. You need flight logging that produces auditable records. You need to track crew competencies, aircraft maintenance status, battery cycles. When the CAA reviews your operations, the documentation has to be coherent across all of it.
Operators managing that across spreadsheets, shared drives, and email chains are building their safety case on foundations that won’t hold under scrutiny. The CAA isn’t unreasonable, but it is thorough. A single inconsistency in your records can unravel an approval process that took months.
How Software Changes the Equation
This is where purpose-built drone operations software makes a genuine difference, and it’s a different kind of difference than most operators expect.
The obvious benefit is efficiency. Replacing manual processes with structured digital workflows saves time. That’s real, but it’s not the point.
The deeper value is that good software makes the invisible visible. When your risk assessment methodology is embedded in the tool you use to plan every flight, consistency stops being something you have to remember and becomes something you get by default. When your flight logs, crew records, and equipment history are in one place, the audit trail builds itself.
For SORA specifically, software that has the methodology built in means operators don’t have to carry every technical nuance of the framework in their heads. The system guides them through the required steps, surfaces the relevant data, and produces outputs structured the way regulators expect. That’s the abstraction layer that turns an intimidating process into something a commercially focused operator can actually manage.
The Transition Period Is an Opportunity, Not a Holiday
Here’s the practical reality. The 12-month window in which operators can renew existing authorisations under the old process will close. The CAA will refine the SORA methodology and the new framework will become the only pathway. What happens then depends entirely on how well-prepared operators are.
Getting SORA-ready isn’t a one-off exercise. It requires operators to rethink how they collect, store, and present operational data. It requires documentation disciplines that don’t come naturally to businesses built around flying rather than filing.
The operators who use this period to build that infrastructure, who get their records in order, who adopt tools designed for structured risk assessment, are the ones who will hold approvals when the transition completes. The ones who wait will be starting from scratch at the worst possible time.
That’s not speculation. It’s the pattern that follows every significant regulatory shift in commercial aviation.
Founder & Director of Dronedesk
Q&A with Dorian Ellis, Founder & Director of Dronedesk
You’ve described BVLOS approval as fundamentally a data problem. What do you mean by that?
When operators come to me frustrated by the SORA process, the problem is almost never that they don’t understand the risk assessment conceptually. They get the logic. The problem is that they don’t have their operational data in a form that supports the methodology. They’re trying to answer questions SORA asks – what’s your population density classification for this operational volume, or what’s your encounter probability for this flight geography – and they don’t have structured data to draw on. So they make estimates. And estimates in a safety case are a problem.
How does Dronedesk address that specifically?
We’ve built SORA into the operational workflow rather than treating it as something that happens separately at submission time. When you’re planning a mission in Dronedesk, the risk assessment process is part of that planning. The system surfaces the relevant data, walks you through the required classifications, and produces outputs that are consistent with what the CAA expects. The complexity doesn’t disappear, but the operator doesn’t have to carry it all in their head.
The UK is currently in a transition period on BVLOS. What’s your read on where things go from here?
The 12-month renewal window under the old process is useful breathing room, but I’d caution against treating it as a signal that SORA is optional or temporary. The CAA is refining the methodology, not abandoning it. Operators who spend this period getting genuinely SORA-ready will be in a strong position when the window closes. Operators who don’t will face a difficult conversation with the CAA at renewal time.
What about the broader picture in the US and Europe?
Every major market is moving towards structured, data-driven risk assessment for BVLOS. The FAA’s proposed Part 108 in the US is heading in a similar direction, with its own framework replacing the current waiver-by-waiver approach. When that lands, the operational model won’t look that different from SORA in many respects. Operators who’ve built their processes around structured documentation and proper risk assessment will have a genuine head start, regardless of which side of the Atlantic they’re on.
What’s your advice for operators looking at BVLOS right now?
Don’t wait for the methodology to be finalised before you start preparing. Get your operational records in order. Build documentation habits now. If your records wouldn’t survive a CAA audit today, fix that before you worry about anything else. The operators who get to BVLOS first will be the ones who did the unglamorous groundwork early.
The Transition Period Is Ending. Your Preparation Should Already Be Well Underway
SORA isn’t going away. The CAA’s transition period exists to refine the methodology and give operators time to prepare, not to delay the inevitable. The commercial use cases for BVLOS – infrastructure inspection, rail corridor monitoring, energy network assessment, precision agriculture – are well-established. The technology to execute them exists. The regulatory direction is clear.
What separates operators who will capitalise on that opportunity from those who won’t isn’t going to be who has the best aircraft. It’ll be who has the operational maturity to get approved, stay compliant, and scale.
For a deeper look at how BVLOS frameworks compare across the UK, EU, and US – including how Part 108 sits relative to SORA – see our full framework comparison.
If you’re building towards BVLOS operations and want to see how purpose-built software changes the compliance picture, Dronedesk is worth a look.
Related Categories