A public-safety UAS request for proposal should define what data is collected, where it travels, who can access it, how integrity is preserved, how long it is kept, and what happens after a device loss, cyber incident, or contract exit. These are operational requirements, not details to leave to the airframe supplier after purchase.
Map the data flow before selecting controls
Begin with the mission record, not a generic security checklist. Follow each data type from the sensor to the authorized user and its final repository. ITU-T F.749.18 describes emergency UAS services through device, network, service, and application layers. That model is useful for procurement because a control at one layer does not automatically protect the others.
| Data stage | Typical scope | Buyer question |
|---|---|---|
| Capture | Video, imagery, telemetry, location, sensor readings, operator actions | Which data is necessary for the mission, and which data should not be collected? |
| Transmission | Control link, telemetry, payload stream, mobile network, relay, or satellite path | Where is data exposed, encrypted, buffered, retransmitted, or lost? |
| Operator access | Controller, mobile device, workstation, browser, or command console | Who can view, control, annotate, export, or delete each data class? |
| Storage | Aircraft media, removable storage, local server, supplier cloud, or agency repository | Who owns each copy, where is it hosted, and how is access recorded? |
| Use and sharing | Incident command, investigation, engineering review, training, or approved partners | What purpose, authority, redaction, and sharing rule applies? |
| Retention and disposal | Archive, legal hold, routine deletion, device return, or contract exit | What starts the retention clock, and how is deletion verified across all copies? |
Record unknown paths as open requirements. A buyer should not assume that a live video feed, removable card, controller cache, supplier cloud, and agency archive follow the same access or deletion policy.
Set requirements for data at rest and in transit
CISA's UAS cybersecurity guidance recommends evaluating the protection of command, telemetry, payload, video, and audio links, along with onboard storage and the systems used to transfer data. The procurement team should convert that guidance into requirements for the ordered configuration and operating environment.
- Identify every radio, network, cable, removable-media, API, and cloud transfer path.
- Define encryption and key-management expectations for sensitive data in transit and at rest.
- Require named users, role-based access, strong authentication, and reviewable account activity.
- Separate operational devices from unnecessary internet or enterprise-network access where the mission requires it.
- Control software, firmware, mobile applications, updates, vulnerabilities, and configuration changes.
- Plan for lost devices, compromised credentials, malicious files, failed transfers, and unavailable cloud services.
Do not turn this list into a claim that a proposed PZLON concept already meets a government security profile. The supplier must state the current implementation, evidence, exclusions, dependencies, and changes needed for the buyer's policy.
Treat retention as policy, not a storage default
The correct retention period depends on the mission, data class, jurisdiction, records policy, privacy obligations, evidentiary use, and active legal holds. A buyer should define those rules before a supplier enables automatic synchronization or indefinite cloud storage.
- Classify operational video, telemetry, annotations, logs, exports, and derived analysis.
- Name the authorized owner, custodian, users, reviewers, and external recipients.
- Define the event that starts retention and the approved period for each class.
- Specify audit history, integrity checks, redaction, legal hold, backup, recovery, and export.
- Document deletion across aircraft, controllers, removable media, local systems, cloud storage, and support copies.
The retention schedule belongs to the responsible organization. A vendor can explain system capability and limitations, but it should not silently choose the agency's legal or operational policy.
Ask for supplier evidence, not yes-or-no assurances
A security questionnaire is useful only when the answers can be checked. Request evidence that matches the proposed hardware, software, hosting, region, options, and support model.
- A current architecture and data-flow diagram for the ordered configuration
- Data locations, hosting parties, subcontractors, remote-support access, and cross-border transfers
- Identity, role, authentication, logging, encryption, key, and certificate design
- Software and firmware inventory, update process, support period, and vulnerability-handling process
- Export formats, timestamps, configuration identity, audit records, and integrity controls
- Backup, disaster recovery, incident notification, data return, account closure, and verified deletion
If an item is unavailable, record the gap and its effect on acceptance. Do not replace missing evidence with a broad statement such as “secure cloud,” “military grade,” or “compliant by design.”
Test the data workflow under representative conditions
Acceptance should confirm the workflow that the agency intends to operate. Keep the tested configuration under change control and preserve the test record with the result.
Fix the test configuration
Record the aircraft, payload, controller, radios, applications, firmware, accounts, network, cloud region, and export tools in scope.
Exercise access and transfer
Confirm approved roles, authentication, data paths, logs, encryption status, exports, and rejected access attempts without exposing live sensitive data.
Introduce degraded conditions
Check lost link, offline operation, delayed synchronization, a missing device, failed upload, revoked account, and unavailable supplier service.
Verify the incident record
Confirm timestamps, source asset, operator, configuration, annotations, original media, change history, and the agreed evidence export.
Prove recovery and exit
Restore from the approved backup, return data in a usable format, close accounts, and verify deletion for the contract-exit scenario.
Local legal, records, privacy, aviation, and cybersecurity teams should review the final requirements. This checklist supports procurement planning; it is not a substitute for jurisdiction-specific policy or legal advice.
Questions buyers often raise
What data security requirements should a public safety UAS RFQ include?
Define the data collected, each transfer path, approved storage locations, user roles, authentication, encryption, logging, retention, export, deletion, incident response, and supplier evidence. Tie each critical requirement to a document, inspection, or representative acceptance test.
How long should public safety UAS data be retained?
There is no universal retention period. The agency should set a period for each data class based on mission purpose, applicable law, records policy, evidentiary need, privacy obligations, and legal holds. The system must then support that approved policy without silent copies or indefinite default storage.
Can a supplier cloud be used as the evidence repository?
Only after the buyer verifies hosting location, access controls, encryption, audit logs, export capability, backup and recovery, subcontractors, incident notification, data return, and secure deletion. A vendor portal should not become the sole evidence record by default.
What should happen to UAS data when a contract ends?
The contract should define a usable export, a verified transfer to the authorized owner, the treatment of backups and support copies, account closure, and evidence of deletion. These exit requirements should be tested before the system becomes operationally dependent on the supplier.