The drone vendor RFP: questions and red flags

Why the RFP questions that matter are the ones vendors don't answer first

By the time a drone vendor is presenting to your procurement team, the story is polished and the flight demo is impressive. What you will not hear, unprompted, is a clear answer to: Where does your data go after it leaves the aircraft? What happens to my fleet when you stop supporting this model? Can I swap to a third-party payload without voiding the warranty? Are you on the Blue UAS cleared list?

These questions are not obscure. They determine whether a drone program remains operable, secure, and compliant over its operational life. This article gives buyers a structured framework for asking them, and a red-flags checklist for evaluating what comes back.

Domain 1: NDAA and Blue UAS compliance

The National Defense Authorization Act (NDAA) contains provisions that restrict US federal government agencies from procuring certain drone systems. Section 848 of the FY2020 NDAA prohibited DoD procurement of drones manufactured by companies on a covered list; subsequent sections extended those restrictions to other federal agencies and to systems using components from covered manufacturers. The specifics have evolved across fiscal years; the current state should be verified against the relevant NDAA section at the time of procurement.

The Blue UAS program (a DoD-administered list of drone systems that have been vetted and cleared for government use) is a practical procurement filter for organizations in or adjacent to the federal government space. Clearance on the Blue UAS list indicates the platform has passed a security review for use in government contexts; it does not automatically address all data-sovereignty concerns, but it is the nearest available shorthand for a vendor's engagement with US government security requirements.

Who needs to care:

• US federal government agencies and contractors: NDAA compliance is a legal requirement, not a preference.
• Critical infrastructure operators (utilities, water, transportation): Increasingly subject to informal guidance or internal policy requirements similar to federal restrictions.
• Commercial organizations with no government affiliation: Not legally restricted, but should be aware that a drone program built on a non-NDAA-compliant platform may need to be replaced if the organization takes government contracts in the future.

Questions to ask:

1. Is this platform currently on the DoD Blue UAS cleared list? If not, is the vendor pursuing clearance, and on what timeline?
2. Does any component of the aircraft, flight controller, or communications hardware originate from a manufacturer on the current NDAA covered-companies list?
3. If the platform is not NDAA-compliant, what is the vendor's position on the data security concerns that underlie the restriction, and how do they address them technically?

Red flags:

• Vendor is unfamiliar with the Blue UAS program or NDAA restrictions.
• Vendor claims compliance without providing documentation or current list citation.
• Vendor conflates "not banned for commercial use" with "NDAA compliant."

Currently, several Chinese-headquartered drone manufacturers — including DJI and a number of smaller platforms — are not on the Blue UAS cleared list and face restrictions in specific US government procurement contexts. Platforms with Blue UAS designation at time of writing include Parrot ANAFI Ai, Skydio X10, Autel Robotics' Alpha, and several others; verify the current list directly with DoD publication rather than relying on any static reference. The Blue UAS list changes; procurement decisions should reference the current published version.

Domain 2: Data sovereignty and routing

Where your drone data goes after it leaves the aircraft is a compliance and security question that varies substantially by platform. Drone systems with proprietary flight control apps and cloud platforms may route telemetry, imagery, or operational data through vendor-controlled infrastructure, including infrastructure outside the buyer's jurisdiction.

Questions to ask:

1. Does the aircraft or flight application transmit any data to vendor servers during or after a flight? What data specifically (telemetry, imagery, metadata, GPS tracks)?
2. Is there a documented, enforceable data processing agreement that specifies what the vendor can do with transmitted data?
3. Can the platform be operated in an air-gapped or offline configuration — with no internet connectivity — without degrading core flight functions?
4. Where are vendor cloud servers physically located? Is data routing subject to foreign jurisdiction?
5. Is there a mechanism to permanently delete flight data from vendor infrastructure upon request?

Red flags:

• Vendor cannot provide a clear description of what data is transmitted or to where.
• The flight app requires a live internet connection for basic functions (flight authorization, mission planning, log sync) with no offline mode.
• The data processing agreement is in a boilerplate terms-of-service rather than a negotiated DPA.
• The vendor is headquartered in a jurisdiction with broad government data access authority and cannot offer technical controls that limit that exposure.

Practical controls to require:

• Local data processing mode: imagery stays on the aircraft SD card and a local workstation, never uploaded to vendor cloud without operator initiation.
• A signed DPA specifying data categories, retention limits, deletion rights, and no secondary use for training or analytics without explicit consent.
• Air-gapped operation documentation — a written test procedure confirming the aircraft flies normally with all internet access blocked.

Domain 3: Payload ecosystem and lock-in

A drone aircraft is a sensor platform. Its value depends almost entirely on the payloads it can carry and the quality of those payloads. Some vendors support an open payload ecosystem with standardized interfaces; others lock buyers into proprietary payload SKUs with no interoperability to third-party sensors.

Payload lock-in is a long-term cost risk. A thermal sensor from a proprietary ecosystem may cost $8,000 when an equivalent OEM component is available for $2,000 from multiple suppliers. When the vendor discontinues the payload two product generations later, the buyer has no alternatives except a full platform replacement.

Questions to ask:

1. What is the mechanical and electrical interface standard for payload attachment? Is it proprietary or based on an open standard (e.g., Skyport, DJI Payload SDK, or a documented open interface)?
2. Does operating a third-party payload void the aircraft warranty? Under what conditions?
3. What payload options exist beyond the vendor's catalog, and does the vendor support or prohibit third-party payload integration?
4. If the vendor's preferred payload is discontinued, what is the migration path?

Red flags:

• All payloads are proprietary with no third-party integration pathway documented.
• Third-party payload use voids warranty with no recourse.
• Vendor cannot identify the payload interface standard or claims it is "custom" without technical specification.
• Software SDK for payload control is not publicly documented and requires a vendor NDA to access.

Domain 4: RTK/PPK accuracy claims

Survey and mapping applications stake their value on positional accuracy. RTK (Real-Time Kinematic) and PPK (Post-Processed Kinematic) are GPS correction techniques that reduce positional error in drone-captured data from meter-level accuracy (standard GPS) to centimeter-level accuracy. Both require a reference station or network corrections service (such as an NTRIP-connected base station or a local RTK base) in addition to the onboard GNSS receiver.

Vendors frequently publish accuracy figures (e.g., "2 cm horizontal accuracy") that apply only under ideal conditions with a co-located RTK base station, favorable satellite geometry, and correct flight parameters. Buyers who deploy the aircraft without an RTK base, in poor satellite conditions, or without understanding the GCP (ground control point, a physical marker with known GPS coordinates used to calibrate and verify photogrammetric accuracy) requirements will not achieve advertised figures.

Questions to ask:

1. Under what specific conditions were the published accuracy specifications measured? (RTK base distance, number of satellites, GCP density, flight altitude, overlap percentage)
2. What is the accuracy performance when RTK correction is unavailable (standard GNSS mode)?
3. Does the platform support PPK (post-processed kinematic, a correction method applied during data processing rather than in real time) as a fallback when an RTK correction link drops mid-flight?
4. What is the vendor's recommended GCP density for survey applications at your target GSD?
5. Is there an independent accuracy validation report (e.g., from a third-party survey firm or academic study)?

Red flags:

• Accuracy specifications are stated without specifying the test conditions.
• The vendor conflates RTK-capable (the aircraft has an RTK receiver) with RTK-ready (the aircraft can receive corrections from a base station or NTRIP service).
• No PPK fallback documented — accuracy is entirely dependent on a live RTK link.
• No independent validation data available; accuracy claims are vendor self-reported only.

Domain 5: Support, spare parts, and operational continuity

A drone program is only as reliable as its supply chain for replacement parts. Ask: What is the current domestic lead time for critical components (motors, props, battery packs, gimbal units)? What is the written SLA (service level agreement) for warranty repair turnaround? How long after a model is discontinued does the vendor commit to parts availability? Is there an authorized repair network, or must all service go through the vendor directly?

Red flags: spare parts requiring 4–8 week overseas shipping with no domestic stock; no documented repair SLA; vendor unable to answer lifecycle questions; no authorized third-party repair option.

Domain 6: SDK and API openness

Commercial drone programs increasingly depend on software integration — connecting flight logs to maintenance systems, routing inspection data to asset management platforms, triggering automated post-processing. These integrations require an SDK (Software Development Kit) or API (Application Programming Interface) — the programmatic interfaces through which third-party software communicates with the aircraft and its ground systems.

Key questions: Is the SDK publicly documented without a vendor NDA? What functions are exposed (mission planning, telemetry streaming, log export, fleet health)? Does the vendor maintain API compatibility across versions? Is SDK maintenance active — recent documentation updates, responsive developer support?

Red flags: SDK requires a signed NDA to review; core functions like log export are app-only with no API alternative; the public SDK has not been updated in over a year; the flight app has a pattern of stability regressions in recent releases.

End-of-life and vendor risk

Every hardware platform is eventually discontinued. A drone program locked into a single-vendor ecosystem is exposed when that vendor is acquired, changes strategic direction, or exits the market. Before finalizing a vendor relationship, negotiate four protections: data portability in open formats (GeoJSON, CSV, KML, raw images) without requiring vendor infrastructure; multi-platform pilot training so the team can shift platforms within 90 days if needed; clarity on whether software requires a live vendor server to activate (phone-home activation is non-functional if the vendor's servers go dark); and written confirmation on parts availability commitments post-discontinuation.

The RFP red-flags checklist

Use this as a pass/fail filter before final vendor selection.

The last question

After working through the checklist, ask the vendor one final question: "Can you provide two or three reference customers operating a program similar to ours, who are willing to take a 20-minute call?"

A vendor who hesitates, offers only written testimonials, or routes you to marketing-curated case studies is a vendor whose operational support record may not support the sales narrative. Reference checks with real operators are the most reliable signal available before commitment.

For the regulatory and operational foundation that this procurement decision will support, see A 90-day playbook to launch a compliant drone program, which covers the week-by-week steps from approved budget to first compliant operational flight.