The drone risk register: how to build one your regulator will accept

A drone risk register is a structured, maintained record of the operational risks in a drone program: what could go wrong, how likely it is, how severe the consequences would be, what is being done to reduce the likelihood or severity, who owns the mitigation, and when the assessment was last reviewed. It is one of the artifacts a regulator, an insurer, or a sophisticated client is likely to ask for when evaluating a program's safety posture.

Many programs treat the risk register as a one-time document produced for an initial compliance exercise and then filed. Programs that get serious scrutiny treat it as a living record that gets updated when conditions change, reviewed on a defined cadence, and used as an actual input to operational decisions. The second kind is the kind regulators accept. This piece is about how to build the second kind.

What a risk register actually contains

A drone risk register is a structured list of identified risks. For each risk, the register captures:

A description of the hazard or risk event in operational terms specific enough to be actionable. "Bad weather" is not a useful entry. "Operations in winds exceeding manufacturer-rated limits during seasonal storm windows" is.

The severity of the consequences if the risk materializes, on a defined scale from minor (operational disruption, no injury) through major (significant damage, possible injury) to catastrophic (fatality, major property damage, regulatory action).

The likelihood of occurrence, on a defined scale from rare (unlikely in the lifetime of the program) through possible (could happen in a given year) to almost certain (expected during ongoing operations).

The risk score, derived from severity and likelihood. A 5x5 severity-by-likelihood matrix, a common framework in aviation risk management, has become a widely understood scoring approach for drone risk registers.

The mitigation actions, both existing controls that reduce the risk today and additional controls planned to reduce it further.

The owner of each mitigation, named by role or person, with responsibility for keeping the mitigation in place and reporting on its effectiveness.

The residual risk after mitigation, which acknowledges that controls reduce risk rather than eliminate it.

The review date, the date by which this risk should be reassessed even if no triggering event occurs.

A register containing all of these for each identified risk supports the operational program. A register containing only descriptions and scores is an artifact, not a program.

The structure regulators expect

Regulators do not usually mandate a specific format for drone risk registers, but they do look for certain characteristics in what they review.

The risks identified should be specific to the operation, not generic. A register listing "weather," "equipment failure," and "operator error" without further specification suggests the program has not thought carefully about its own operations. A register naming the specific weather conditions relevant to the operating area, the specific equipment failure modes the program has experienced or anticipates, and the specific operator errors the training program addresses suggests a program that has engaged with its risks.

Mitigation actions should be real and traceable. Listing "follow SOP" as a mitigation is weak. "Pre-flight checklist requires confirmation of weather conditions against manufacturer limits; supervisor approval required if conditions are within 10% of limits; flight postponed if outside limits" is operational.

The review cadence should be visible and adhered to. A register with review dates in the past, all bunched at the same time of year, all checked off without evidence of substantive review, looks like an artifact maintained for compliance rather than for safety. A register with staggered review dates and evidence of substantive updates over time looks like an active record.

Integration with the rest of the program should be evident. Risks identified in the register should connect to the SOPs, the training program, the equipment registry, and the incident reporting system. Risks that float free of the rest of the program tend to suggest the register is decorative.

Severity and likelihood scoring

The 5x5 matrix has become widely used in drone risk registers, partly because it is intuitive and partly because it produces a clean visual artifact. Severity is rated 1 through 5 from negligible to catastrophic. Likelihood is rated 1 through 5 from rare to almost certain. The score is the product, ranging from 1 to 25. Score categories typically map to action thresholds: low scores are tolerable with existing controls, mid-range scores require active management, high scores require additional mitigation, executive awareness, or in some cases suspension of the operation.

A few practices separate registers that use the 5x5 well from registers that use it as a marketing object.

Calibrate severity and likelihood against actual experience. Programs that score every risk as "5 severity, 1 likelihood" or "3 severity, 3 likelihood" are not calibrating; they are pattern-matching. Real calibration involves looking at the program's incident history, the industry's experience, and the specific operating conditions to produce a score that means something.

Document the reasoning for non-obvious scores. A score an outside reviewer might question should have a brief rationale attached. "Severity 4 because operation is over populated area during daylight; likelihood 2 because operator has 200+ flight hours on this airframe with no comparable incident" is a defensible entry. The numbers alone are not.

Distinguish inherent risk from residual risk. The score before mitigation and the score after mitigation are different. Both belong in the register, so that the mitigation's effectiveness is visible. Re-score when conditions change: new aircraft, new operating environments, new operator experience, new incident data should all trigger re-scoring.

Mitigation owners and evidence

The hardest part of a risk register to maintain is the discipline around mitigation tracking and review. Each mitigation should have a named owner (a role for some risks, an individual for others), with succession noted when roles change. Each mitigation should have a defined evidence trail: the training that mitigates operator error should produce attendance records; the maintenance program that mitigates equipment failure should produce equipment registry entries and flight-hour rollups; the SOP that mitigates a specific hazard should be referenced in the register. When a regulator asks "show me the evidence this mitigation is in place," the register should point to where that evidence lives.

Common mistakes

Treating the register as a deliverable for a one-time exercise. A register produced for an initial compliance exercise and not updated decays in usefulness within months and in defensibility within a year.

Generic entries. "Pilot error," "weather," "equipment failure" without operational specificity does not survive a sophisticated regulator's questions.

Mitigation without evidence. Listing controls in the register without being able to point to where the evidence of those controls lives makes the mitigation appear theoretical.

Crediting the 5x5 matrix to SORA or to a specific regulatory framework that did not originate it. The 5x5 severity-by-likelihood matrix is a general aviation risk-management approach widely adopted in drone programs. SORA, the Specific Operations Risk Assessment methodology, uses a different structure (Ground Risk Class, Air Risk Class, and the resulting SAIL designation). Programs operating under SORA should follow the SORA methodology; programs using the 5x5 should describe it as the aviation industry practice it is.

Treating residual risk as zero. Effective mitigation reduces risk; it does not eliminate it. Registers scoring every risk as low after mitigation suggest a program that has not honestly assessed the limits of its controls.

FAQ

What is the difference between a drone risk register and a drone safety case?

A risk register is the operational record of identified risks, their scoring, and their mitigations. A safety case is a broader document that argues, with evidence, that the program is acceptably safe to operate. The risk register is usually a component of the safety case, alongside SOPs, training records, the equipment program, and other supporting evidence. Smaller programs may not produce a formal safety case but should still maintain a risk register.

Does a drone risk register satisfy SORA requirements?

SORA, the Specific Operations Risk Assessment methodology developed by JARUS and adopted by EASA, has its own structured approach using Ground Risk Class, Air Risk Class, and the resulting Specific Assurance and Integrity Level (SAIL). Operations under SORA follow the SORA methodology specifically. A general drone risk register supports broader risk management but does not replace a SORA assessment where SORA applies.

How often should a drone risk register be reviewed?

Quarterly review of the full register is a useful cadence, with individual risks reviewed when triggering events occur (incidents, changes in operating conditions, new aircraft, new certifications, regulatory changes). Review dates should live in the register and be adhered to. A register reviewed once a year with no triggering-event updates is not actively used.

Who should own the drone risk register in an enterprise program?

The chief pilot or drone program lead typically owns the register. Individual risks may have different mitigation owners across operations, maintenance, training, and safety. One person should be accountable for the register as a whole, with named owners for each mitigation.

Should the risk register include risks from third-party contractors?

Yes, when the contractor's operations create risk to the program. Contractor-specific risks (currency lapses, inadequate insurance, work outside contracted scope) belong in the register alongside internal operational risks. The register reflects the program's overall risk posture, not just the operator's own activity.

The register is a piece of the program

The drone risk register is one of several artifacts that, together, demonstrate a program operates with discipline. It connects to the SOPs, the training program, the equipment registry, the incident reporting system, the audit trail. A register that sits separately, maintained for compliance purposes only, is the kind regulators have learned to distrust. A register integrated with the rest of the program is the kind that holds up.

If you are building a drone risk register that supports a regulated program, FlybyOps was built for the operational record problem at the center of regulated drone operations. A risk register with severity and likelihood scoring, mitigation tracking, defined owners and review dates, integration with the equipment registry and pilot records, and an append-only audit log capturing every change are all part of how the platform supports the safety posture of an enterprise drone program.