A drone detection system RFP needs requirements in eight sections: mission and threat, detection performance, coverage and site conditions, fusion and operator interface, alerting and integration, records and retention, legal and compliance, and commercial terms, plus an evaluation method that tests claims rather than reading them. Most RFPs in this category fail before they are issued, because they specify sensors instead of outcomes, copy a vendor's specification sheet into the requirements, and leave out the three sections, records, compliance, and evaluation, that decide whether the system is usable after installation.
This checklist gives sample requirement language for each section, written in the form procurement teams can paste, edit, and issue. It assumes you already understand how a drone detection system works and have matched a solution composition to your mission; this is where those decisions become a document a vendor can be held to.
State what the system is for before stating what it must contain. Vendors respond to outcomes far more precisely than to component lists, and a clear mission statement disqualifies mismatched proposals on page one. Sample language: The system shall provide continuous detection, tracking, and identification of unmanned aircraft operating within the defined protected area, with the primary operational objective of [locating the operator for law enforcement response / supporting operational hold decisions / producing a documented incursion record]. The threat profile includes commercial and consumer drones, autonomous aircraft operating without an active control link, and aircraft controlled by fiber-optic tether.
Require outcomes with numbers, and require them to be demonstrated. The FEMA Counter-UAS Grant Program's published performance measures, 90 percent classification accuracy and investigation of every violation, are a defensible baseline for any buyer. Sample language: The system shall detect and track unmanned aircraft regardless of whether the aircraft emits a radio signal. The system shall classify detections as drone or non-drone with a demonstrated accuracy of not less than 90 percent and shall document its false-alarm rate at a comparable operational deployment. The system shall identify the make and model of transmitting aircraft. The system shall estimate the position of the aircraft operator for transmitting aircraft, with accuracy stated in meters at the proposed sensor geometry.
Coverage claims made without a survey are guesses. Make the survey a requirement of the proposal itself. Sample language: The vendor shall conduct a site survey prior to submitting a final proposal, and the proposal shall include a coverage map derived from that survey showing detection coverage for each sensor type at the proposed placements, identified coverage gaps, and the local radio-frequency environment assessment. Quoted ranges in open-field conditions shall not be accepted as coverage claims.
This section separates systems from sensor collections. Sample language: The system shall correlate detections from all sensor types into a single track per aircraft, presented as one target with merged attributes. The system shall not present separate alarms for the same aircraft from different sensors. The operator interface shall display aircraft position, classification, flight history, and, where available, operator position on a single map view. Multi-site deployments shall be viewable from one command interface.
Detection that reaches nobody is a log entry, and this section is where monitoring programs succeed or fail. Sample language: The system shall deliver alerts to designated personnel on mobile devices and existing communication channels, with configurable priority by geographic zone and automatic escalation when an alert is not acknowledged within a defined interval. The system shall integrate with the buyer's existing video management system and security platform via documented interfaces, and the vendor shall list all supported integrations.
The section most RFPs omit, and the one that decides whether anything the system saw can be used for prosecution, flight-restriction petitions, grant reporting, or federal oversight. Sample language: The system shall retain all detection and track data, including timestamps, sensor attribution, classification, and operator position estimates, for a period of not less than [24] months. The system shall export incident reports on demand in a standard document format suitable for law enforcement and regulatory submission. The system shall provide pattern analytics including incursion frequency, time-of-day distribution, approach corridors, and repeat aircraft identification.
Two requirements protect the buyer from acquiring a liability. First, the identification method: FEMA's legal analysis in its counter-drone grant notice treats detecting and locating drones, reading Remote ID broadcasts, and monitoring control signals as outside federal wiretap restrictions, but not capturing payload content such as video feeds, and the joint federal advisory on detection technology cautions that intercepting communications content can implicate federal surveillance statutes. Any mitigation capability is unlawful for private buyers. Second, for public agencies, eligibility under the federal rule effective July 1, 2026. Sample language: The system shall operate on a passive, receive-only basis for radio-frequency detection and shall not capture, record, or store the payload content of any drone communication, including video feeds. The system shall include no capability to interfere with, disable, or take control of an aircraft. [Public agencies: The vendor shall state whether each proposed component appears on the federal Authorized Technologies or Authorized Systems Lists and shall identify any component requiring FCC authorization to operate.]
Require a five-year figure, because installation, integration, training, licensing, and support add 30 to 60 percent to hardware and are distributed differently across every vendor's quote. Sample language: The proposal shall state a total five-year cost including hardware, installation, integration, calibration, training, software licensing, support, and maintenance, itemized by year. The proposal shall describe the support model including response-time commitments, the location of support engineers, and the update cadence for detection libraries and software. The proposal shall include two reference customers in the buyer's sector with deployments older than twelve months.
Every section above can be answered on paper. One requirement makes the answers testable. Sample language: Shortlisted vendors shall participate in an on-site evaluation at the buyer's facility using aircraft selected by the buyer, including at least one aircraft operating autonomously without an active control link. Evaluation flights shall follow a buyer-defined script, and vendors shall be scored on detections, misses, false alarms, time to first alert, operator-position error, alert delivery to a mobile device, and the quality of the exported incident report. The scoring method for those results is in our guide to comparing drone detection systems, and vendor screening before the shortlist is in our counter-UAS solutions guide.
Maximum detection range as a pass/fail figure. It rewards the vendor with the most optimistic open-field number, not the best coverage at your site.
Minimum sensor counts. Sensor count is an output of the survey, not an input to the RFP.
Named sensor brands or models. It converts an outcome procurement into a component procurement and excludes better architectures.
Any mitigation capability. For private buyers it specifies a federal violation; for agencies it belongs in a separate procurement governed by the certification framework, as our drone mitigation guide explains.
The difference between an RFP that produces a working system and one that produces a warranty dispute is whether every requirement is measurable, demonstrable, and tied to the mission in section 1. Outcomes, not components. Numbers, not adjectives. A test, not a brochure.
We answer RFPs written this way regularly, and we prefer them, because a buyer who has specified records, compliance, and evaluation has already ruled out the proposals that would have made the category look bad. AirGuard is built to meet the sample requirements above as written, and the component-level background for section 2 is in our drone detection equipment guide.
Drafting a drone detection RFP? Talk to our team and we will review your requirements against the eight sections before it goes out, no obligation.
Related reading:
How a Drone Detection System Works: Sensors, Software, and Coverage
Drone Detection Solutions: Matching the System to the Mission
What a Drone Detection System Actually Costs: Total Cost of Ownership