Knowledge Base October 14, 2026

Counter-UAS Radar RFP Checklist

A counter-UAS radar RFP checklist covering operational requirements, specifications, integration, acceptance testing, compliance, and vendor evaluation.

RFPTenderCounter-UAS RadarProcurement
Person signing a procurement document with a pen at a desk
Photo: Cytonn Photography

A request for proposal for a counter-UAS radar decides more than the purchase price. It decides what the buyer can hold the supplier to later. A vague RFP produces proposals that all look compliant while meaning different things; a precise one forces every vendor to answer the same testable questions.

This checklist is written for procurement teams, system integrators, and end users preparing a tender for drone detection radar. It follows the sequence a real evaluation needs: define the mission, specify testable performance, lock down integration and acceptance, then structure the commercial and compliance terms. For the datasheet-level detail behind each specification field, see the companion counter-UAS radar datasheet checklist.

1. Define the Operational Requirement First

The most common RFP failure is copying a vendor brochure into the requirements section. Before any specification, document what the radar must actually do:

  • Threat definition: which drone classes matter — consumer quadcopters, FPV drones, fixed-wing UAVs, larger multirotors — and the smallest radar cross section the system must handle.
  • Protected asset and site: fixed facility, temporary event, border corridor, mobile unit; site survey results including terrain, clutter sources, and available mounting points.
  • Coverage requirement: sectors or full 360 degrees, minimum and maximum engagement range, altitude band of interest.
  • Response workflow: who receives the alarm, what they do with it, and whether the radar must cue EO/IR cameras, feed a command-and-control platform, or drive an automated response.
  • Operating concept: 24/7 unattended operation, event-based deployment, or manned monitoring shifts.

Every technical requirement that follows should trace back to one of these statements. If a specification cannot be traced to an operational need, it is likely brochure language.

2. Technical Specification Requirements

Write performance requirements so that compliance can be demonstrated, not just claimed. Each item below should appear in the RFP with a required response format:

  • Detection and tracking range against a stated target RCS (for example 0.01 m²), with probability of detection and false-alarm conditions. Require vendors to separate first detection, stable track, and actionable alarm distances.
  • Coverage: azimuth field of regard, elevation coverage, and whether 360-degree coverage needs one unit or several.
  • Update rate or revisit time for the stated coverage, and track capacity under multiple simultaneous targets.
  • Accuracy: range, azimuth, and elevation accuracy sufficient for the intended cueing or handover workflow.
  • Classification: bird-versus-drone discrimination approach and expected behavior in the buyer’s actual clutter environment.
  • Environment: rain, wind, temperature, and ingress protection ratings matched to the site, not a generic laboratory condition.

Avoid specifying a single headline range with no target assumption — it invites every vendor to answer a different question.

3. Outputs and Integration

Many counter-UAS projects fail at integration, not detection. The RFP should require vendors to document:

  • track output format, message schema, and update interval;
  • network interfaces, protocols, and time synchronization;
  • EO/IR cueing support with demonstrated latency and pointing accuracy;
  • integration options for RF detection, Remote ID, C2, VMS, or PSIM platforms;
  • API or SDK availability, sample messages, and which party carries integration responsibility;
  • cybersecurity controls, user roles, logging, and behavior during network loss.

Require sample interface documentation with the proposal, not after award.

4. Site, Installation, and Acceptance Testing

The RFP should make acceptance a contractual process with evidence, not a formality. A site survey before tender issue gives vendors the same installation picture and makes their quotes comparable.

Include:

  • Installation requirements: mounting, power input and consumption, grounding, cable limits, network requirements, and any civil works the buyer must provide.
  • Factory acceptance test (FAT): the checklist the vendor will execute before shipment, including configuration and version records.
  • Site acceptance test (SAT): test target assumptions, flight profiles, pass/fail criteria for detection, tracking, alarm, and cueing, plus the deviation and retest process.
  • Evidence deliverables: sample logs, exported tracks, screenshots, and calibration records in formats the buyer can archive.

If a requirement cannot be tested at FAT or SAT, either make it testable or remove it.

5. Compliance and Export

Counter-UAS radar is a controlled product category in many jurisdictions, and longer-range systems may fall under dual-use export rules. The RFP should ask vendors to state:

  • applicable export classification and licensing responsibility;
  • expected delivery timeline including licensing lead time;
  • end-user documentation the buyer must provide;
  • any regional variants, frequency coordination, or radio licensing requirements at the deployment country.

Buyers new to this area should review the dual-use radar export compliance overview before issuing the tender, so compliance questions appear in the RFP rather than surfacing after contract signature.

6. Vendor Evaluation and Commercial Terms

Structure the proposal response so offers can be compared line by line:

  • Compliance matrix: every requirement answered as comply / partial / non-compliant with written explanation and evidence.
  • References: deployed systems of the same configuration, with contactable end users where possible.
  • Company and support footprint: local support, remote diagnostics, spare-part availability, and response-time commitments.
  • Commercial terms: price broken into hardware, software, integration, training, spares, and recurring support; warranty period and exclusions; payment milestones tied to FAT, delivery, and SAT.
  • Lifecycle costs: software update policy, calibration schedule, and expected maintenance — the total lifecycle cost of a radar routinely exceeds its purchase price over a service life.

Use weighted evaluation criteria published in the RFP itself — for example 40% technical compliance, 20% acceptance evidence, 20% lifecycle and support, 20% price — so vendors optimize for what actually matters.

7. Documentation, Training, and Support

Require with the proposal:

  • operator and maintainer training scope, duration, and language;
  • documentation set: user manual, installation guide, interface control document, maintenance schedule;
  • documentation language and revision control;
  • remote support method and on-site support options;
  • recommended inspection and maintenance plan.

Common RFP Mistakes

Watch for these patterns when drafting or reviewing the tender:

  • Copying one vendor’s datasheet into the requirements, which effectively excludes competition and hides untested claims.
  • Specifying maximum range without target RCS, altitude, probability, or false-alarm conditions.
  • Omitting update rate, coverage geometry, or track capacity.
  • Leaving integration protocols to “be determined after award.”
  • Defining no SAT pass/fail criteria, so acceptance becomes a negotiation.
  • Ignoring export licensing until after contract signature.
  • Comparing bids on purchase price alone while support and update policies differ.

Conclusion

A strong counter-UAS radar RFP reads like a test plan attached to a commercial framework: every requirement traceable to an operational need, every performance claim testable at FAT or SAT, every integration interface documented, and every vendor answering the same questions in the same format.

When the tender is built this way, evaluation becomes straightforward. Compliance matrices separate evidence from marketing, acceptance criteria protect the buyer after award, and the final choice reflects operational fit. Vendors with real, fielded systems — including the Cyrentis CR Series of pulse and FMCW counter-UAS radars spanning short to long range — generally welcome this style of RFP, because testable requirements are where verified performance wins over headline numbers.

CR-PK05B
CR-PK05B Ku-Band Medium-Range Radar Drone detection (RCS 0.01m²) ≥5km

Need Counter-Drone Radar for Your Site?

CR series low-altitude surveillance radars detect RCS 0.01 m² drones at 3–10 km and classify targets by micro-Doppler — every track outputs with target class and confidence.

View All Radars
How to Choose a Counter-UAS Radar Model: … Radar on the Move (OTM): How …