Drone operations under EASA: documentation for the Specific category

Specific category operations under EASA Regulation (EU) 2019/947 generate substantial documentation. The authorization is supported by documentation submitted in the application; the operation itself produces documentation continuously; and the records the national competent authority can request at any time draw from both. Operators that underweight the documentation requirements at the start of a Specific category project tend to discover them later, when an authority request or an incident triggers the need to produce records the program never built.

This article walks the documentation landscape for Specific category operations: what documentation the authorization pathway requires up front, what the operation produces, what the authority can ask for, and how the records integrate across pathways and jurisdictions. The framework reference is the EASA civil drones page.

Documentation by authorization pathway

The Specific category offers several authorization pathways, and the documentation each requires varies. Understanding what each pathway demands is part of choosing the right pathway for the operation.

SORA-based authorization requires the most extensive documentation up front: a ConOps, the SORA assessment, OSO evidence at the assessed SAIL, an operational manual, personnel records, and equipment documentation. The application package can run hundreds of pages for higher-SAIL operations.

Pre-Defined Risk Assessments (PDRAs) require less documentation because the risk analysis is already complete. The operator demonstrates the operation matches the PDRA conditions and submits documentation for the operator-specific elements: operational manual, personnel records, equipment specifications.

Standard Scenarios (STS) require a declaration rather than an application, but the declaration is supported by documentation the operator must maintain even though it is not submitted: an operational manual covering the standard scenario, personnel records, and equipment documentation matching the scenario conditions.

Light UAS Operator Certificate (LUC) holders maintain documentation that supports their internal authorization process. The documentation load for an LUC is substantial because the operator effectively performs the authority's review work internally.

The pathway choice is partly a choice of where the documentation effort lives. SORA-based pathways front-load the work; STS pathways back-load it (documentation must still exist, even though the declaration is short); LUC pathways amortize the work across multiple operations.

The operational manual

The operational manual is the foundational document any Specific category operation maintains. It is part of the authorization application or the STS declaration documentation, and it is the document the authority will most often want to see when questions arise.

The manual typically covers operating procedures (pre-flight, in-flight, post-flight), contingency procedures (emergency landing, communication loss, equipment failure), training requirements for each role, currency requirements and tracking, maintenance practices and intervals, incident reporting procedures, and the operational limits the authorization specifies.

The manual is not a static document. It evolves with the operation: lessons learned from incidents, equipment changes, new operating environments, new personnel roles. The version history matters because incidents and audits often need to be reviewed against the manual version that was in effect at the time. Programs that overwrite the manual without retaining prior versions lose this traceability.

The manual is also the document new pilots and ground crew train against. Manuals that have drifted from operational reality produce trained personnel who do not match the actual procedures, which is a safety risk in its own right.

Per-flight and operational records

Each flight conducted under a Specific category authorization produces records that demonstrate the operation matched the conditions.

The flight record itself captures date, time, location, pilot in command, aircraft used, payload configuration, weather observations at the time of operation, route or operating area flown, and any deviations from authorized conditions. For operations with strategic mitigations (DAA systems, visual observers, coordinated airspace access), the records of those mitigations belong here.

The pre-flight assessment record demonstrates the operator considered the conditions before flying: airspace check, weather minimums verification, equipment status confirmation, personnel availability and currency. The level of detail scales with the SAIL and the operational risk.

Post-flight records capture any equipment anomalies, operational deviations, near-events, or follow-up actions. Post-flight records that look identical every flight tend to be records that were not actually completed.

Maintenance and inspection records for the airframe and any specialty equipment, including the date, the action taken, the person responsible, and the equipment status after the work.

Personnel currency records, updated as pilots complete recurrent training, observers requalify, and other competency requirements refresh. Currency that lapses during operations is a compliance event the program should be able to demonstrate did not happen.

Personnel and equipment documentation

Personnel documentation covers everyone with a role in the operation, not only the remote pilots. The Specific category authorization names the roles required, and each role carries documentation expectations.

For remote pilots: certification records, training history specific to the operation type, currency records, and any role-specific qualifications. For visual observers: training records on observer duties, position assignment, communication protocols. For ground crew and communications staff: training records on their roles, safety briefings, and any equipment they operate.

Equipment documentation covers the UAS itself, payloads, command and control equipment, detect-and-avoid systems, and any other equipment the authorization specifies. The documentation includes specifications, performance data, declarations of compliance, third-party certifications where relevant, and maintenance history.

The connection between personnel and equipment matters. A pilot who is qualified on one airframe may not be qualified on another; the records should show qualification per airframe, not in general. Equipment used on a specific flight should connect to the pilot record for that flight, the maintenance record for that airframe, and any waiver or amendment conditions in effect at the time.

Storage, access, and what the authority can request

The Specific category does not prescribe storage format for most documentation, but accessibility, tamper-evidence, and scoping all affect how records hold up during a request.

Accessibility on demand. The authority can request specific records related to specific operations or to the overall authorization. The operator must produce the records within the timeframe the authority specifies, usually days to weeks for routine requests.

Tamper-evidence. Records the authority might rely on should be maintained in a way that makes after-the-fact modification visible. An append-only audit log on the operational platform supports this; a freely editable spreadsheet does not.

Scoping to specific requests. Most authority requests are narrow: a specific flight, a specific date range, a specific aircraft. Producing the requested records without exposing unrelated operations protects the program's broader work from a request that started focused.

Retention beyond the authorization period. Records relevant to incidents, accidents, or regulatory reviews often need to be retained well after the authorization itself has ended. Default to retaining at least three to five years after expiration; longer for higher-SAIL operations or operations near sensitive assets.

Common mistakes in EASA Specific category documentation

Treating the operational manual as a one-time deliverable. The manual is part of the authorization, but it lives with the operation. Programs that finalize the manual at application and never update it end up with documentation that does not match the actual practice.

Underdocumenting STS declarations. Declaring under a Standard Scenario is shorter than applying for SORA-based authorization, but the documentation requirements behind the declaration still apply. Programs that take advantage of the short declaration without maintaining the supporting documentation fail their next audit.

Mixing personal and operational devices. Pilots holding flight records or operational documentation on personal devices create accessibility problems when they leave the program and create privacy concerns about what else those devices hold.

Ignoring version control on key documents. ConOps and operational manuals evolve. Without version control, the program cannot answer questions about what conditions were in effect at the time of a specific operation.

Treating multi-pathway documentation as separate. Operators running operations under multiple pathways often maintain separate documentation systems for each. The underlying records (pilots, aircraft, maintenance) should be common across pathways even if the pathway-specific documentation differs.

FAQ

Is paper documentation acceptable for Specific category operations? Yes in principle; the regulation does not specify format. Digital is the practical default for most operators because the accessibility and tamper-evidence properties are better. Hybrid approaches work for programs transitioning from legacy paper systems.

How quickly must we produce records when the authority requests them? The timeframe varies but is typically days to weeks for routine requests, with longer windows for substantial document sets. Urgent requests tied to active incident investigation can be shorter. The request itself will specify the expected timeframe.

Do we need to translate documentation into the local language? The national competent authority can accept documentation in English for most authorizations, but the local language is sometimes required for safety-critical documents like the operational manual. Confirm with the authority during the application process.

How does Specific category documentation differ from Part 107 documentation in the US? EASA's Specific category documentation is generally heavier than Part 107 documentation, particularly for higher-SAIL operations. The operational manual, OSO evidence, and ongoing compliance reporting are more substantial under EASA. Programs running both frameworks usually need a documentation approach that satisfies the heavier requirement and produces the lighter set as a subset.

Closing thought

Documentation is the connective tissue of Specific category operations. The authorization is built on documentation, the operation runs on documentation, and the records the authority can request draw from documentation produced across the full lifecycle. Programs that build the documentation practice deliberately end up with operations that hold up under any authority request. Programs that treat documentation as paperwork end up assembling records under pressure when the request arrives.

If you are operating under the EASA Specific category, FlybyOps was built for the operational record problem at the center of regulated drone work. A document vault for operational manuals, ConOps, SORA assessments, OSO evidence, and declarations; a pilot registry with training, currency, and role-specific qualification records; an equipment registry with airframe, payload, and maintenance history; and an append-only audit log are all part of how the platform supports the documentation a Specific category authorization expects.