Drone Data Security Checklist for Canadian Government and Enterprise Buyers
Evaluate the entire drone data chain—from aircraft and controller to apps, cloud, contractors, integrations, privacy, incident response and secure disposal—before approving a government or enterprise deployment.
Assess
Control
Monitor
A drone program is secure only when the organization controls what is collected, where it moves, who can access it, which suppliers touch it, how long it is retained and how incidents are handled. Product certifications and encryption are evidence—not a substitute for an organization-specific risk assessment and authorization.
Map every place drone data can exist
Drone risk is broader than images stored on an SD card. A mission can create video, thermal imagery, location, timestamps, flight logs, account data, device identifiers, voice communications, annotations, AI detections, maps, API payloads and maintenance records.
Images can reveal more than the stated subject
Inspection imagery can expose facility layouts, access points, equipment condition, employee routines, critical infrastructure and nearby private property.
Routes and logs can reveal capability
Flight paths, mission times, pilot activity, emergency locations and response patterns can be sensitive even when the captured image is not.
People may be identifiable unintentionally
Faces, licence plates, home locations, voice, behaviour and device-linked records can create privacy obligations even when surveillance is not the mission.
Required output: create a data-flow diagram that identifies collection, temporary storage, transmission, processing, sharing, backup, retention and deletion for every device, app, cloud service, integration and contractor.
Do not enter production with any of these questions unanswered
Information category
The competent authority has not classified or categorized the mission data and system.
Permitted technology
Departmental, sector, client or national-security policy has not confirmed the platform is eligible.
Data-flow visibility
The buyer cannot identify every destination, subprocess, integration and support path.
Security authority
No senior authority has accepted the residual risk or authorized the system.
Privacy assessment
Personal-information collection has not been reviewed by privacy or ATIP specialists.
Supplier evidence
The vendor will not provide current assurance evidence or architecture answers.
Identity security
Shared accounts are required or MFA and role separation cannot be implemented.
Data location
Cloud region, backup location or subcontractor processing locations are unknown.
Incident terms
The contract lacks notification, evidence preservation and remediation obligations.
Patch and end-of-life
The support period, update process or end-of-life plan is unknown.
Secure disposal
No verified erasure process exists for all devices, cloud data and backups.
Operational separation
The system must connect directly to sensitive production networks without segmentation.
A high checklist score cannot override a failed critical gate. National-security, classified, law-enforcement, defence, intelligence and critical-infrastructure deployments can have mandatory restrictions that apply regardless of product features.
Cloud, on-premises or offline operation?
Choose the deployment model after data categorization and mission analysis. Each option changes collaboration, remote operations, data location, patching, integration and the controls your organization must operate.
On tablets and phones, swipe the table left.
| Architecture | Advantages | Main risks | Best fit | Required buyer controls |
|---|---|---|---|---|
| Public cloud | Remote operations, collaboration, scaling and managed availability | Cross-border processing, shared responsibility, account exposure and vendor dependence | Approved distributed enterprise operations | Cloud assessment, authorization, identity, logging, retention and vendor evidence |
| Private on-premises | Greater control of data location, integration and isolated-network operation | Internal patching, backup, capacity, administrator and disaster-recovery burden | Sensitive environments with funded infrastructure teams | Hardened hosting, monitoring, backup, privileged access and lifecycle ownership |
| Offline / Local Data Mode | Reduces or removes internet connectivity during flight operations | Reduced cloud collaboration, map, sync, support and remote-operation functions | Standalone sensitive missions | Offline update, removable-media, local archive and secure transfer controls |
| Third-party platform / SDK | Custom workflow and integration control | Additional supplier, code, API, credential and software-supply-chain risk | Organizations with development and assurance capability | Code review, dependencies, API security, SBOM where available and support plan |
Cloud security is shared responsibility: certifications can help assess provider controls, but the buyer remains responsible for categorization, configuration, identity, monitoring, privacy, integrations and accepting residual risk.
What DJI provides—and what buyers still need to verify
Control which data categories can be shared
DJI states that Pilot 2 users can choose security modes and grant or revoke permissions for device information, flight records, logs, approximate location and related services.
Disconnect Pilot 2 from the internet
DJI states that Local Data Mode permits offline operation without account login. Firmware and other packages can be downloaded separately and imported offline.
AES-256 and protected app-server channels
DJI states that the aircraft-to-controller radio link uses AES-256 encryption and that app-server traffic uses HTTPS or WSS over TLS.
AWS in the United States and Europe
DJI states that FlightHub 2 data for users outside mainland China is stored on AWS infrastructure in the United States or Europe.
ISO 27001 and ISO 27701
DJI states that FlightHub 2 is certified to ISO/IEC 27001 for information security and ISO/IEC 27701 for privacy information management.
Private or isolated intranet deployment
DJI offers FlightHub 2 On-Premises and an all-in-one option for organizations requiring local infrastructure and greater data control.
Review the exact scope
DJI announced a 2026 OnDefend assessment of Air 3S and Matrice 4E with no critical, high or medium findings in the tested scope. Treat this as point-in-time evidence, not assurance for every product or firmware.
Bug bounty and active lifecycle
DJI operates a security response centre and vulnerability-reporting program. Confirm that the exact product remains inside the active security-maintenance lifecycle.
Verify full erasure coverage
DJI describes clearing logs and cache, restoring devices and requesting account-data deletion. Verify coverage for each device, controller, card, cloud service and backup.
Evidence request: obtain the current FlightHub 2 Data Security Clarification FAQ, certification statements, architecture description, applicable independent assessments, subprocessors, data locations, retention behaviour and product-security support period.
Security requirements must appear in the solicitation and contract
Supply-chain risk extends across manufacturers, distributors, cloud providers, app stores, cellular carriers, installers, maintenance providers, subcontractors, APIs and software updates.
Determine whether an SRCL is required
Current CanadaBuys guidance requires an SRCL and security clauses for federal procurements with security needs. Required supplier and personnel screening must be valid before protected access.
Review the full service chain
- Manufacturer and authorized dealer
- Cloud and hosting providers
- Installers and maintenance contractors
- Software, API and analytics suppliers
- Subcontractors and foreign processing
Record source and configuration
- Serial numbers and product region
- Firmware and app source
- Controller and payload configuration
- Activation organization
- Chain of custody and receiving inspection
Confirm scope and currency
- Certificates and applicable scope
- Independent test date and products
- Vulnerability and patch process
- Material unresolved findings
- Security-support lifecycle
Control vendor and dealer support
- Named support roles
- Buyer approval before remote access
- Time-limited and logged sessions
- Data minimization for diagnostics
- Return or destruction of support copies
Reduce concentration risk
- Export routes and logs
- Maintain manual procedures
- Identify replacement lead times
- Assess lock-in and compatibility
- Define migration triggers
Complete privacy analysis before routine collection begins
Apply the Directive on Privacy Practices
The federal directive covers the personal-information lifecycle, including information held by third parties under contract. Consult privacy specialists on the required PIA, protocol, notice or related deliverable.
Identify applicable privacy law
PIPEDA or substantially similar provincial legislation may apply depending on the organization, province and activity. Public-sector and municipal rules also vary.
Collect only what the mission needs
- Define approved purpose
- Avoid unrelated homes and people
- Reduce unnecessary zoom, audio and retention
- Mask or redact where appropriate
- Prevent secondary use without approval
Make collection transparent where required
- Operational notices and signage
- Privacy contact
- Purpose and authority
- Retention and sharing
- Complaint and access process
Set schedules by data class
- Separate evidence from routine imagery
- Set cloud and local expiry
- Control backups and exports
- Place legal holds where required
- Verify deletion completion
Control links and downstream copies
- Approve recipients and purpose
- Use expiry and access control
- Record disclosures
- Limit contractor reuse
- Protect public-release workflows
Privacy is not limited to decisions about people. Consult privacy specialists when identifiable individuals, homes, vehicles, voices or location patterns may be collected.
Use a documented secure baseline for every field kit
Choose the approved network-security mode
- Document cloud, on-premises or Local Data Mode
- Disable optional sharing unless approved
- Use organization-controlled accounts
- Record account region and activation owner
- Review settings after updates
Treat the remote as a sensitive endpoint
- Asset tag and named custodian
- Strong screen lock
- Restrict unknown apps and removable media
- Disable unneeded radios
- Protect cached media and credentials
Control storage and possession
- Use approved cards
- Inspect internal storage behaviour
- Confirm secure-erasure method
- Maintain chain of custody
- Report loss immediately
Use a controlled update channel
- Approved download source
- Review release notes
- Test before broad rollout
- Keep components compatible
- Record version and approval
Encrypt downstream storage
- Approved encrypted endpoints
- Approved transfer methods
- No uncontrolled personal-device copies
- Verify model-specific onboard controls
- Do not assume feature parity
Separate normal and sensitive kits
- Dedicated controllers where warranted
- Preload offline maps and approvals
- Carry approved clean media
- Prevent casual charging/network access
- Reconcile equipment after missions
Most practical breaches begin with accounts, networks or integrations
MFA, SSO and role separation
- Use MFA where supported
- Integrate SSO where available
- No shared pilot or administrator accounts
- Separate administrator, operator, analyst and viewer
- Frequent privileged-access review
Segment drone systems
- Managed enterprise networks
- No unnecessary access to high-value systems
- Restrict inbound and outbound services
- Monitor traffic and failure where feasible
- Document field exceptions
Protect keys and downstream systems
- Approved secrets management
- Least privilege and environment separation
- Rotate credentials
- Validate event inputs
- Log exports and changes
Control live-feed access
- Approve viewers
- Time-limited or authenticated access
- Prevent public-chat sharing
- Record disclosures
- Apply evidence rules where needed
Preserve evidence and monitor changes
- Account, device, flight and integration logs
- Reliable time sync
- Protect logs from editing
- Approved retention
- Review failures and privilege changes
Design safe failure modes
- Cloud outage response
- Local emergency control
- Backup-link testing
- RTH and alternate landing behaviour
- Service-outage exercises
Security promises must be measurable and enforceable
Adapt contract language with procurement, legal, privacy and security authorities. The clauses below are requirements to consider, not model legal text.
| Contract area | Requirement to define | Evidence or remedy |
|---|---|---|
| Data ownership | Buyer ownership and permitted supplier use | No secondary use, model training or marketing without written approval |
| Data location | Primary, backup and support-processing regions | Advance notice and approval before change |
| Subprocessors | Cloud, support, analytics and integration suppliers | Notification, objection and flow-down requirements |
| Security controls | Encryption, identity, logging, isolation, backup and deletion | Control matrix and current third-party evidence |
| Incident notice | Maximum notification time and required content | Updates, evidence preservation and root-cause report |
| Vulnerabilities | Disclosure, patch priority and remediation timelines | Notice of exploitation, workaround and fix |
| Remote support | Buyer approval, named staff, access limits and logging | Time-bound sessions and access records |
| Security screening | Required organization, personnel and site clearances | Verification before access or award |
| Audit rights | Access to reports, certifications and control evidence | Remediation, suspension or termination |
| Business continuity | Backup, recovery objectives, service continuity and export | Test evidence and continuity assistance |
| Change control | Material architecture, ownership, hosting or security changes | Advance notice and reassessment |
| End of service | Data export, verified deletion and account closure | Deletion certificate and migration support |
| Product lifecycle | Security-support and end-of-life dates | Migration notice and support terms |
Federal procurement: security clauses should align with the completed SRCL, Statement of Work and Contract Security Program requirements.
Prepare before a drone, controller, account or cloud workspace is compromised
Define reportable events
- Lost aircraft, controller or media
- Unauthorized account access
- Unexpected data transmission
- Malicious or unapproved firmware
- Cloud, API or contractor exposure
Stop access without destroying evidence
- Disable accounts and tokens
- Isolate affected systems
- Pause automated missions
- Preserve logs and media
- Engage vendor and responders
Determine data and operational impact
- Data accessible or exported
- Sites and people affected
- Flight safety or evidence integrity
- Credentials still exposed
- Reporting duties
Follow applicable breach obligations
PIPEDA-covered organizations must report breaches posing a real risk of significant harm, notify affected individuals and keep records of all breaches. Federal institutions follow their Privacy Act, Treasury Board and OPC processes.
Rebuild trust and capability
- Rotate credentials and keys
- Patch or reimage devices
- Validate routes and settings
- Restore clean data only
- Obtain approval before resuming
Close control gaps
- Root-cause analysis
- Update architecture and SOPs
- Address supplier performance
- Retrain roles
- Track actions to closure
Secure decommissioning begins before the purchase order
Identify every data-bearing component
Aircraft, controllers, SD cards, mobile devices, computers, docks, network equipment, cloud workspaces, API accounts, backups and contractor copies.
Use model-specific sanitization
Clear local caches, logs and media; factory-reset where appropriate; delete cloud projects and exports; and verify backup expiry. Deleting a visible folder is not sufficient.
Revoke every identity and integration
Remove users, API keys, SSO assignments, livestream links, vendor access, cellular accounts and device bindings according to the approved exit plan.
Control resale, return and destruction
Apply asset-disposal policy, document chain of custody and confirm that transferred equipment no longer contains organizational information.
Retain what law and policy require
Preserve procurement, authorization, flight, maintenance, incident, breach and disposal evidence according to approved retention schedules.
Improve the next procurement
Record export difficulty, vendor cooperation, hidden dependencies, deletion evidence and replacement lead time.
Drone data security readiness tracker
Check an item only after evidence has been reviewed. Completion does not create legal compliance or security authorization. Critical gates must be resolved by the organization’s competent authority.
1. Governance, categorization and authorization
2. Procurement, SRCL and supply-chain risk
3. Data flows and deployment architecture
4. Privacy and records management
5. Aircraft, controller and removable media
6. Identity, network and integration controls
7. Logging, monitoring and vulnerability management
8. Contracts and supplier operations
9. Incident response and continuity
10. Decommissioning and program review
Internal decision language: use “evidence reviewed,” “control implemented,” “risk accepted” and “authorized by” rather than declaring a system “secure.”
Request an enterprise drone security and deployment assessment
SpeedyDrone Canada can help government, institutional and enterprise buyers scope DJI Enterprise aircraft, Dock 3, FlightHub 2, on-premises options, Local Data Mode workflows, training and implementation partners. Final security approval remains with the buyer’s competent authorities.
Drone data security FAQ
What is the first step in a drone data security review?
Categorize the mission and information, identify the competent security and privacy authorities, and map every data flow before selecting a product or deployment model.
Does encryption make a drone system secure?
No. Encryption protects selected data in transit or at rest, but security also depends on identity, device configuration, suppliers, cloud controls, integrations, privacy, logging, incident response and physical custody.
What is DJI Local Data Mode?
DJI states that Local Data Mode disconnects the DJI Pilot 2 application from the internet and supports offline operation.
Where does FlightHub 2 store Canadian customer data?
DJI states that FlightHub 2 data for users outside mainland China is stored on AWS servers in the United States or Europe.
Can FlightHub 2 be deployed on premises?
Yes. DJI offers FlightHub 2 On-Premises and an all-in-one option, including private deployment in an isolated intranet environment.
Is DJI FlightHub 2 ISO certified?
DJI states that FlightHub 2 holds ISO/IEC 27001 information-security and ISO/IEC 27701 privacy-information-management certifications.
Does DJI encrypt the aircraft-to-controller link?
DJI states that enterprise aircraft-to-controller transmission uses AES-256 encryption and that Pilot app-to-server communications use HTTPS or WSS over TLS.
Do federal government drone procurements require an SRCL?
Federal procurements with security requirements require the applicable Security Requirements Check List, Statement of Work and Contract Security Program process.
When is a privacy impact assessment required?
Federal institutions should apply the current Directive on Privacy Practices and consult privacy specialists. Other organizations must determine the requirements applicable to their jurisdiction and activity.
What vendor evidence should a buyer request?
Request current certifications, independent assessments, architecture, data locations, subprocessors, encryption details, vulnerability process, patch timelines, end-of-life support, incident terms and deletion procedures.
Should drone controllers be treated as managed endpoints?
Yes. Controllers can contain credentials, cached media, logs, maps, applications and network access and should be securely configured and managed.
What should a drone vendor contract say about security incidents?
Define the notification deadline, required facts, ongoing updates, evidence preservation, investigation cooperation, remediation, root-cause reporting and remedies.
What are PIPEDA breach obligations for Canadian businesses?
Organizations subject to PIPEDA must report breaches that create a real risk of significant harm, notify affected individuals and keep records of all breaches.
Can a checklist approve a drone system for government use?
No. A checklist organizes evidence and decisions. Formal approval must come through the organization’s security, privacy, procurement and operational authorization processes.
How should a drone be securely decommissioned?
Inventory all data-bearing components, erase and verify local and cloud data, revoke accounts and APIs, close cellular access, control resale or destruction, and retain required disposal evidence.
Where can Canadian buyers request an enterprise drone security discussion?
Contact SpeedyDrone Canada with the mission, data category, intended DJI aircraft, cloud or on-premises preference, sites, integrations and approval stakeholders.
- DJI Trust Center: Enterprise privacy controls and offline updates
- DJI Enterprise: Data control, Local Data Mode, encryption and deletion
- DJI Enterprise: FlightHub 2 security and on-premises options
- DJI Enterprise: FlightHub 2 Data Security Clarification FAQ
- DJI: 2026 independent security-assessment announcement
- DJI Security Response Center
- Canadian Centre for Cyber Security: Cloud assessment and authorization
- Canadian Centre for Cyber Security: ITSG-33 controls
- Canadian Centre for Cyber Security: Supply-chain risk management
- Canadian Centre for Cyber Security: MFA guidance
- Treasury Board: Directive on Privacy Practices
- CanadaBuys: Security in federal contracts
- Government of Canada: Security Requirements Check List
- Office of the Privacy Commissioner: PIPEDA breach reporting
- SpeedyDrone Canada: DJI Enterprise solutions
- SpeedyDrone Canada: DJI Dock 3
- SpeedyDrone Canada: Contact
This article is general procurement and planning information, not legal, privacy, cybersecurity, engineering, contracting or security-authorization advice. Product controls, firmware, cloud services, laws, policies and procurement rules can change.
