A SORA package spends money across concept definition, ground and air risk analysis, mitigations, flight and containment tests, documentation, authority dialogue, and change control. Filling a template is a small part of that value chain.
EASA’s June 2026 Easy Access Rules update integrates SORA 2.5-related AMC and GM from ED Decision 2025/018/R. The methodology supports an application in the specific category; it does not itself grant permission, set one transition deadline for every operator, or replace the competent authority’s decision.
Identify the authority, operator, and operation before the method
The operator owns the concept of operations and application. The competent authority evaluates it. EASA supplies the regulatory framework and acceptable means and guidance; manufacturers, test organizations, consultants, airspace stakeholders, and local landowners may provide inputs. Name the jurisdiction and operating context first because forms, transition practice, and required dialogue are not automatically identical across authorities.
A review record should keep competent authority, operator identity, and ConOps as separate fields. Roles matter because the method and the approval decision are owned by different parties. That separation makes a later regression visible instead of allowing a successful headline number to hide the condition that produced it.
Place SORA 2.5 inside the authorization value chain
SORA classifies ground and air risk, applies mitigations, derives assurance needs, and connects operational safety objectives to evidence. The chain includes operational description, initial and final ground-risk class, air-risk class, containment, mitigations, OSOs, robustness, test results, manuals, and authority questions. One claim changing upstream can alter several downstream documents.
For an operating team, aircraft configuration is only useful when it can be matched to payload. Log operational volume at the same time. Every risk result should link backward to assumptions and forward to evidence. The resulting record supports a go, hold, or redesign decision without borrowing certainty from an unrelated specification.
| Value-chain party | What it supplies | What it does not supply |
|---|---|---|
| EASA | Rules, AMC, GM, and SORA framework | Operation-specific approval |
| Operator | ConOps, organization, manuals, and application | Authority decision |
| Manufacturer | Aircraft and system evidence | Complete route and population case |
| Consultant or test body | Analysis, test, and traceability support | Transfer of operator responsibility |
| Competent authority | Assessment and authorization decision | Ongoing operational compliance for the operator |
The product is an evidence package for one operational context
The deliverable is not ‘SORA 2.5 compliance’ in the abstract. It is a traceable case for a named aircraft, payload, route or volume, population and airspace environment, command-and-control architecture, personnel, weather limits, maintenance, emergency response, and change state. A reused paragraph from another route has little value if its assumptions cannot be linked to local evidence.
The test should deliberately vary population while holding ground risk constant, then reverse the comparison. Add air risk as an exception case. A good package is operation-specific and change-aware. Averages alone cannot show whether failures cluster around a specific environment, operator action, or software version.
Consulting revenue does not change the approval owner
Operators may buy analysis, testing, documentation, mapping, parachute or containment evidence, and application support. Payment does not transfer legal or operational responsibility. A consultant should state assumptions, evidence owner, validity period, and change triggers. Early discussion with the competent authority, which EASA recommends as good practice, can prevent expensive analysis along an inapplicable path.
Responsibility also needs a named owner: one for containment, another for C2 link, and a final escalation path for maintenance. Consulting can improve quality without guaranteeing the authority’s outcome. If those owners cannot reconstruct the same event from their logs, the integration is not ready to scale.
Dependencies link risk claims to physical tests
Mitigations must bind to physical and procedural proof: population or ground-area controls, strategic and tactical air-risk measures, containment, aircraft reliability, command-and-control behavior, maintenance, competence, and emergency response. The outdoor robotics test guide is relevant because a mitigation written in a manual needs a repeatable test result and an owner who maintains it.
Procurement language should state the test condition for personnel competence, the acceptance range for weather limit, and the recovery deadline for mitigation owner. Paper mitigations fail when physical evidence is not maintained. This turns a product claim into a measurable obligation while preserving the supplier’s stated evidence boundary.
Watch transition, change, and certified-category boundaries
A final GRC above 7 falls outside SORA and may require a certified-category path. Existing SORA 2.0 assessments should not be declared automatically invalid or automatically accepted; review the ED Decision applicability language and the competent authority’s transition guidance. Reassess after aircraft, payload, route, population, airspace, organization, software, mitigation, or evidence changes—not simply because a document date changed.
The most informative comparison is not a polished demonstration. It is the distribution of OSO evidence, the tail cases around robustness, and the human work required after test result. Transition and scope boundaries require current authority guidance rather than blanket statements. Those three views reveal whether the system moves labor, risk, or cost rather than removing it.
- OSO evidence
- robustness
- test result
- emergency plan
- change trigger
Questions readers ask next
Which parts of a SORA 2.5 package address ground risk, air risk, containment and assurance rather than granting permission by themselves?
The market offers analysis, mapping, testing, documentation, application support, and mitigation evidence; EASA itself supplies the regulatory framework rather than a commercial approval product. The operator remains responsible for the operation-specific case and ongoing compliance.
Official source trail: