The Pilot Records Database: What Part 135 Operators Must Report

The Pilot Records Database, established under 14 CFR Part 111, replaced a slow, paper-driven system in which a hiring operator sent written requests to a pilot's former employers and waited for responses that may or may not have arrived. PRD centralizes those records in an FAA-managed database.

The practical effect for Part 135 operators is that the obligation runs in two directions. You must report specified records about the pilots you employ, and you must review the database before you allow a newly hired pilot to begin service.

This is a recordkeeping and process obligation rather than a flight operations one, which is exactly why it tends to be under-resourced. It rarely surfaces in day-to-day operations until an inspector asks to see it.

Broadly, the reportable set covers the pilot's relationship with your company and their qualification history with you. That includes employment history such as dates of service and the position held, and records of training, qualification, and proficiency events conducted under your programs.

It also includes records concerning final disciplinary action and the circumstances of separation from employment, along with drug and alcohol testing information handled through the applicable testing program rules.

Because the specific reportable elements and the reporting deadlines have been phased and amended over time, verify the current requirements and timelines directly against Part 111 and the FAA's PRD guidance rather than relying on a summary, including this one.

The hiring side of PRD is just as binding as the reporting side. Before allowing a newly hired pilot to begin service, an operator is required to review the pilot's records in the database as part of its evaluation.

That review needs to be documented. Knowing that someone looked is not the same as being able to show, months or years later, who reviewed which records and when, and that the review happened before the pilot flew.

Operators who treat this as a checkbox at the end of onboarding tend to discover the gap during a records audit, when reconstructing the timeline is difficult.

The most common failure is not refusal to comply. It is diffusion of responsibility. PRD sits between HR, the Chief Pilot, and the training department, and when no one owns it, reporting falls behind quietly because nothing in daily operations depends on it.

The second failure is timing. Records that must be reported within a defined window after an event get batched and submitted late, or a departure is processed without the associated separation record being reported at all.

The third is reconstruction. When records live in an HR folder, a training spreadsheet, and someone's inbox, assembling a defensible history for a single pilot can take hours. Multiply that by a records review across the roster and it becomes a serious workload.

A durable PRD process has three properties. Ownership is explicit, with one named person accountable and a documented backup. Events trigger reporting automatically rather than depending on someone remembering, so a completed check, a disciplinary action, or a separation each initiate the same defined workflow.

Finally, evidence is retrievable. For any pilot and any reportable event, you should be able to produce what was reported, when, and by whom, without assembling it from scattered sources.

Navlyt keeps crew records, certificates, and medicals in one workspace alongside your compliance obligations, so the underlying record a PRD process depends on is current and retrievable rather than scattered. For the related medical currency problem, see our guide to Part 135 medical certificate tracking.