Preparing for an FAA SAS DCT Review: What Part 135 Operators Should Expect
A SAS Data Collection Tool review is not a pop quiz — it is a structured, predictable evaluation of one element of your compliance system at a time. The operators who move through it smoothly are not the ones with the thickest manuals; they are the ones who can put a finger on the exact paragraph that answers each question. This guide walks through what the inspector is actually evaluating, what to stage before the review, and the handful of mistakes that send answers back.
The short answer
What is being judged? Whether your written program satisfies the regulation (design), and whether your operation actually performs to that program (performance).
What wins? Paragraph-level citations to your current, controlled manual suite — not narrative restatements of the rule.
What to do first? Build a question-to-paragraph cross-reference before the inspector ever opens the DCT.
What a SAS DCT review actually is
The FAA’s Safety Assurance System (SAS) is the framework Flight Standards uses to certificate and then continuously oversee 14 CFR Part 135 operators. Within SAS, the Data Collection Tool (DCT) is the standardized instrument an inspector uses to evaluate a single element of your operation — one slice of the compliance system, such as training, hazardous materials, manuals and recordkeeping, airworthiness, or operational control.
Because the DCT is standardized, the review is far more predictable than operators expect. The inspector is not improvising questions; they are working a defined list, and every question traces back to a regulatory requirement. That predictability is your advantage: if you know the questions are coming, you can stage the answers in advance.
If you want the full anatomy of SAS DCTs — the element structure, the assessment types, and who completes which — start with What are SAS DCTs? Element-Design (DA) and Element-Performance (PA) Explained.
The two questions behind every DCT: design and performance
Every SAS element can be evaluated along two axes, and understanding the difference is the single most useful thing an operator can know walking into a review.
| Assessment | The question it answers | What the inspector examines |
|---|---|---|
| Element-Design (Design Assessment / DA) | Is the written program sound? | Your manuals and procedures — does a complete, clear, regulation-satisfying method of compliance exist on paper, traceable to a specific paragraph? |
| Element-Performance (Performance Assessment / PA) | Does the operation do what the program says? | Records, observations, and processes — does the line operation actually follow the documented procedure in practice? |
The trap is to prepare for one and forget the other. An operator can have an immaculate manual (strong design) and still draw findings because line crews do something different from what the manual says (weak performance). The reverse happens too: a sound operation whose manuals never quite documented the procedure. A DCT review may probe design, performance, or both — so prepare for both.
What to stage before the review
Preparation is almost entirely about having the right documents current, controlled, and indexed. Stage these before the inspector opens the DCT:
- The complete current manual suite. General Operations Manual, General Maintenance Manual, training program, hazmat program (if you are a hazmat carrier or carry will-not-carry obligations), and every other volume your OpSpecs require. Confirm each is at its live, controlled revision — not a working draft on someone’s desktop.
- Your Operations Specifications. The OpSpecs define your authorized scope. The inspector reads the DCT against what you are actually authorized to do, so the OpSpecs frame every answer. Have them current and at hand.
- A question-to-paragraph cross-reference. The highest-leverage prep there is. For each DCT question, pre-identify the exact manual paragraph (and record, if performance is in scope) that answers it. This is the difference between a smooth review and a week of follow-up emails.
- Key personnel designations and the org chart. Many elements turn on who holds operational control, who supervises maintenance, who runs the training program. Have the current designations documented.
- Referenced program documents. SMS, drug and alcohol program, CASS, MEL/MMEL authorizations, and anything your manuals cross-reference. If a manual paragraph points to another document, the inspector may want to see it.
What makes a DCT answer strong
A strong answer does three things: it points to a precise location, it matches the current revision, and it addresses the right axis (design, performance, or both). The model answer reads less like an essay and more like a citation: “This requirement is satisfied at GOM § 4.3.2, which establishes the procedure; performance is evidenced by the training records retained under GOM § 12.1.”
Notice what that answer does not do: it does not restate the regulation in narrative form, it does not gesture vaguely at “the manual,” and it does not leave the inspector to go hunting. Precision is courtesy, and courtesy moves reviews.
The five reasons answers get sent back
Across certification and surveillance, rejected DCT answers cluster into a short list of avoidable problems:
- The cited paragraph doesn’t actually contain the required content. The citation points to § 4.3, but § 4.3 covers something adjacent. Verify every citation by reading the paragraph as if you were the inspector.
- Narrative instead of citation. The answer explains how the operator complies in prose but never points to where that compliance is documented. The inspector needs the location, not a paraphrase.
- Stale revision. The answer cites a manual paragraph that moved, was renumbered, or was removed in the current revision. Always answer against the live controlled document.
- Blank or not-applicable without a rationale. “N/A” is a legitimate answer when a requirement genuinely doesn’t apply to your scope — but only with a documented reason tied to your OpSpecs and operations. An unexplained N/A reads as an evasion.
- Design answered, performance ignored. The operator documents the written procedure beautifully but never addresses whether the operation performs to it — leaving the performance half of the inspector’s question open.
Every one of these is preventable with disciplined, paragraph-level work against the current manual suite.
How long the review takes — and what controls it
Operators often ask how long a DCT review runs. The honest answer is that the number of questions matters far less than the quality of the responses. A clean response set — precise citations, current revisions, documented rationales — gives the inspector nothing to chase, and the element closes quickly. A disorganized set generates a cycle of clarification requests that can stretch a review for weeks.
In other words, preparation does not just improve the outcome of a review; it shortens the duration. The cross-reference you build up front pays for itself in review time saved.
Related reading
- What are SAS DCTs? Element-Design (DA) and Element-Performance (PA) Explained
- DCT vs. SOC: When the FAA Wants More Than Answered DCTs
- OpSpecs Explained: How Operations Specifications Scope Your Certificate and Drive DCT Answers
- DCT Completion service — what’s included, scope, deliverable format
- Pricing — flat rates for DCT, SOC, and Manual Gap Suggested Edit Report