SORA risk assessment recordkeeping: the basics

SORA produces records. Both the assessment process and the ongoing operation generate documents the operator must maintain, and the records are part of the authorization, not adjacent to it. Operators that treat the assessment as a one-time submission and the records as separate paperwork end up with gaps the authority finds during compliance review.

The structure of SORA recordkeeping is straightforward in principle and frequently incomplete in practice. The methodology, developed by JARUS and adopted into the EASA Specific category framework, produces a defined set of artifacts during assessment, and the authorization that follows generates ongoing records as the operation runs. Programs that hold a Specific category authorization carry both. This article walks the basics: what records the assessment produces, what records the operation produces, how long to retain them, and how they integrate with the broader operational record. Reference material for the methodology lives at JARUS.

Records produced by the SORA assessment

The assessment generates a structured set of documents before the operation begins. These are submitted with the authorization application and retained for the life of the authorization and beyond.

The ConOps. The concept of operations describes what the operation is, where it occurs, who conducts it, what equipment it uses, and what mitigations the operator applies. This is the foundational document; everything else in the assessment ties back to it. The ConOps tends to evolve through application review, so the program should retain version history rather than only the final approved version.

The SORA assessment document. The walk through GRC and ARC determinations, the application of mitigations, the SAIL outcome, and the resulting OSO requirements. The assessment shows the authority the reasoning behind the SAIL and provides the basis for any future amendment.

OSO evidence package. For each Operational Safety Objective required by the assessed SAIL, the operator submits evidence the objective is met at the required assurance level. The evidence varies by OSO: design documentation, test results, training records, procedure manuals, qualification certifications. The package can be substantial at higher SAILs.

The operational manual. SOPs for the operation, contingency procedures, training programs, maintenance practices, and incident reporting procedures. The manual is part of the authorization submission and becomes the operating baseline once authorization is granted.

Equipment documentation. UAS specifications, performance data, payload and equipment lists, declarations of compliance for safety-critical components, and any third-party certifications relevant to the SAIL.

Personnel qualification records. The pilots, observers, ground crew, and any other roles the operation requires. Each role with qualifications, training records, and currency aligned to what the OSOs specify.

Records produced by ongoing operation

Authorization once granted produces records continuously. These are not the same as the assessment records; they are the operational evidence the authorization remains valid.

Per-flight operational records. Date, time, location, pilot, aircraft, payload configuration, weather observations, and any deviations from authorized conditions. For operations with detect-and-avoid systems, observers, or other strategic mitigations, the records of those mitigations belong here.

Maintenance and inspection records. The aircraft and any specialty equipment maintained per the operational manual and manufacturer recommendations. Some SAIL levels require inspection intervals beyond manufacturer guidance.

Personnel currency records. Pilot recurrent training, observer requalification, and any other personnel currency requirements specified in the operational manual. Currency that lapses during an authorized operation is a compliance event.

Incident and event reports. Reportable events under the authorization conditions and internal safety reports that feed the program's risk management. The reports are part of the operational record and may need to be shared with the authority on request.

Periodic compliance reports. Many authorizations require reports to the national authority on a defined cadence, typically quarterly or annually depending on the SAIL. The reports summarize operational activity, incidents, and any changes that affect the authorization.

Mitigation performance records. Where SORA mitigations depend on continuous performance (DAA systems, command and control link integrity, observer reliability), the records of that performance during operations.

Retention and storage

The methodology does not state specific retention periods, but several defaults hold up under regulatory review.

The ConOps, SORA assessment, and OSO evidence: for the duration of the authorization plus several years after expiration or termination. These records justify the authorization and may be relevant if questions arise later.

Operational records: for the duration of the authorization plus three to five years. Operations with sensitive ground risk or operations near critical infrastructure tend to warrant longer retention.

Personnel records: for the duration of the individual's involvement plus three years. The records establish that the person was qualified during the period they were active in the operation.

Maintenance records: for the operational life of the aircraft plus three years after disposal. Maintenance history is part of the airworthiness story and may be relevant to incident analysis years later.

Incident reports: indefinitely or for at least seven years. Administrative and legal exposure from incidents can extend well beyond the operational period.

Storage requirements vary by jurisdiction, but several principles apply broadly. Records should be tamper-evident, with after-the-fact modifications visible in the record itself. Records should be retrievable on demand within timeframes the national authority specifies. Records should be scoped to the people who need them. And records should survive personnel changes, system migrations, and corporate changes through deliberate continuity planning.

Integration with the broader operational record

SORA records do not stand apart from the rest of the operational record. They sit alongside it, and the integration is part of what makes them useful when questions arise.

For operators running both EASA Specific category operations and operations in other jurisdictions (US Part 107 waivers, for example), the records need to support multiple frameworks. The aircraft maintenance record for a single airframe may need to satisfy EASA documentation under one authorization and FAA documentation under another. Programs that maintain separate systems for each framework end up with duplicate records and gaps where one system has data the other does not.

For operators running multiple pathways within the Specific category (a mix of SORA-based authorizations, PDRA-based authorizations, and Standard Scenario declarations), the records still need to integrate. Different pathways may produce different documentation, but the underlying flight records, pilot records, and equipment records should be common.

For operators planning to move toward a Light UAS Operator Certificate (LUC), the SORA recordkeeping practice is a prerequisite. The LUC requires demonstration of operational maturity that includes deliberate recordkeeping. Programs that get their SORA records right end up better positioned for an LUC application than programs that improvise.

Common mistakes in SORA recordkeeping

Treating the assessment as one-time documentation. The ConOps and SORA assessment are not snapshots; they evolve with the operation. Amendments, lessons learned, and operational changes should be reflected in updated documentation, not informal addenda.

Underdocumenting the OSO evidence. The SAIL determines required OSOs, but meeting each OSO requires evidence the operator can produce. Programs that file a SAIL number without the supporting evidence package have a category but no demonstration.

Storing records in tools the team cannot retrieve from. Records that exist only in individual inboxes, personal drives, or systems the current team cannot access are functionally unavailable when an authority asks.

Mixing SORA records with general business records. SORA records have specific retention and accessibility requirements. Mixing them with general business records makes both harder to manage and increases the risk that the SORA records get deleted under general retention policies.

Failing to update records when the operation changes. Operations evolve. New pilots, new equipment, new operating areas, new mitigations. Each change should be reflected in the operational record, and significant changes may require amendment of the authorization itself.

FAQ

What is the minimum retention period for SORA assessment records? Most national competent authorities expect retention for the duration of the authorization plus at least three years. Operations near sensitive areas or with higher SAILs often retain longer because operational and legal exposure extends further.

Can SORA records be kept in any format? Records can be paper, digital, or hybrid in principle. Digital is the practical default for most operators because retrieval, search, and tamper-evidence properties are better. Whatever format the operator chooses, the records need to be accessible on demand and protected against unauthorized modification.

Who within the program should have access to SORA records? Access should be scoped to the people who need the records. Pilots typically need their own flight records and the operational manual. Compliance staff and the operations lead need broader access. Read-only access for external review (auditors, the authority, insurance) should be available without exposing the rest of the workspace.

How do SORA records interact with the operator's broader safety management? SORA records feed the safety management process. Incident reports filed under the SORA-authorized operation contribute to the program's risk register. Compliance reports surface trends. The two systems should be connected, not parallel.

Closing thought

SORA recordkeeping basics are the records that make the authorization defensible and the operation evidentiary. The assessment produces a specific set of artifacts; the operation produces continuous evidence the authorization remains valid; the retention and storage decisions determine whether the records are useful when questions arise. Programs that build the recordkeeping practice deliberately end up with a record that supports the authorization through its life and any incident or audit along the way.

If you are running a drone operation under the EASA Specific category or any other SORA-based framework, FlybyOps was built for the operational record problem at the center of regulated drone work. A document vault for ConOps, SORA assessments, and OSO evidence; an equipment registry that captures system characteristics relevant to maintenance and authorization; a pilot registry with training and currency records aligned to OSO requirements; and an append-only audit log are all part of how the platform supports the recordkeeping a SORA-based authorization expects.