Drone Data Security: How to Protect Aerial and Reality Capture Data
By Kush Agarwal, President and CEO, YelloSKYE. Published .
Executive Summary
- The Question: How do you keep drone imagery, maps, scans and inspection findings from reaching people who should not have them?
- The Answer: Treat capture data as sensitive by default, because it shows layouts, weak points and commercial progress. Protect it at every stage, from the aircraft and app to upload, storage, sharing and deletion, with clear residency, role-based access, encryption, managed devices and site-specific rules. Then ask vendors for independent evidence rather than assurances.
- The YelloSKYE Angle: Inspection data from Inspect IQ and every other capture sits in the DEX platform with role-based access, so each party sees the part of the record it needs. The questions in this guide are the ones to ask any provider, us included.
Drone data security means protecting aerial images, maps, 3D models, scans and inspection findings at every stage of their life: on the aircraft and controller, in transit, during processing, in storage, when shared and when deleted. It matters because this data is unusually revealing. A single orthomosaic can show a site's layout, access points and security perimeter; an inspection model of a substation or tank farm is, in effect, a list of its weak points.
For owners of critical assets, inspection is where the stakes are highest, which is why this guide sits alongside Inspect IQ, our asset inspection solution. It sets out what capture data reveals, where it is exposed, and the controls that matter: data residency, access control, encryption, device and app security, the vendor evidence worth asking for, and policies for sensitive sites.
What capture data can reveal
Most security policies were written for documents and email. Reality capture data needs its own thinking because of what can be read from it.
| Data | What it can reveal | Who might want it |
|---|---|---|
| Orthomosaics and site maps | Layout, fences, gates, camera positions, storage areas | Thieves, trespassers, anyone planning disruption |
| Inspection imagery and defect reports | Corrosion, cracks, thermal faults and failing components on live assets | Anyone seeking to exploit weaknesses in critical infrastructure |
| 3D models and point clouds | Exact geometry of plant, structures and interiors | Competitors, or anyone needing a detailed model of a secure site |
| Progress records and quantities | How far behind a project is, what has been paid for | Counterparties in claims, rival bidders |
| Image metadata and flight logs | GPS positions, times, routes, take-off points | Anyone mapping routines and access patterns |
| Incidental imagery | Neighbouring property, vehicles, people | Privacy regulators and the people captured |
The last row is easy to overlook. Even when the site is not sensitive, images of neighbouring gardens, number plates or people can fall under privacy law in many countries.
Where the data is exposed
Data is at risk wherever it rests or moves. Mapping that journey is the quickest way to find gaps.
| Stage | Typical risk | Control |
|---|---|---|
| Aircraft and memory card | Lost or stolen card, aircraft recovered by someone else after a crash | Encrypted storage where supported, prompt upload and wipe, card custody rules |
| Controller and flight app | App syncing data to servers you did not choose, outdated firmware | Approved app list, local or offline modes, managed updates |
| Upload | Interception on public or shared networks | Encrypted transfer, trusted networks, no consumer file-sharing tools |
| Processing | Data copied to third-party compute in an unknown location | Known processing region, named sub-processors, contract terms |
| Storage | Over-broad access, forgotten copies, weak backups | Role-based access, single source of record, backup location agreed |
| Sharing | Open links forwarded beyond the intended audience | Expiring links, named-user access, watermarking where needed |
| Retention and deletion | Data kept long after the contract ends | Retention schedule, deletion on request, certificate of deletion |
For how processing works and how desktop, cloud and managed set-ups differ, see drone image processing. Here the question is simply where each copy of the data lives and who can reach it.
Data residency: where the data lives
Data residency is the location where data is stored and processed. It matters for two reasons. Legally, the jurisdiction holding the data can affect who may compel access to it and which privacy rules apply, for example the GDPR in the European Union. Contractually, many utilities, government bodies and owners of sensitive sites require their data to stay within a named country or region.
When you assess a provider, ask:
- In which regions is data stored, including backups and disaster recovery copies?
- Where is processing carried out, and does it ever move to another region at busy times?
- Which sub-processors handle the data, and where are they based?
- From which countries can support staff access customer data, and under what approval?
- Can residency be fixed in the contract, and what happens if it changes?
A clear answer to all five, written into the agreement, is worth more than a general statement that data is "stored securely in the cloud".
Access control: who sees what
Most data leaks on projects are not hacks. They are a link forwarded once too often, a former subcontractor whose account was never closed, or a shared folder anyone with the address can open. Access control deals with these.
Principles that work on projects
- Role-based access. Grant access by role, such as site engineer, consultant, client or operator, not person by person.
- Least privilege. Give each role only the sites, dates and layers it needs. A roofing contractor does not need the security perimeter.
- Single sign-on and multi-factor authentication for staff, so leavers lose access when their company account is closed.
- Time-limited access for outsiders. Insurers, adjusters and auditors often need a view for weeks, not years.
- Audit trails. A record of who viewed, downloaded or shared what, and when.
- Regular reviews. Check access lists at each project milestone and at handover.
DEX is built around role-based access. When an industrial park in our warehouse handover use case was completed, its operator was granted a role that opened the facility's visual history from earthworks to commissioning, and nothing more.
Encryption
Encryption protects data if it is intercepted or a storage device goes missing. Three points to cover:
- In transit. Uploads, downloads and app traffic should travel over encrypted connections.
- At rest. Stored data, including backups, should be encrypted, with keys managed separately from the data.
- On devices. Laptops, tablets and controllers holding capture data should use full-disk encryption, and removable cards should be treated as sensitive media.
Ask how encryption keys are managed and who can use them. Encryption is only as strong as control over the keys.
Device and app security
The aircraft and its controller are computers with radios, cameras and an internet connection. Treat them like any other managed device.
- Approve the hardware and apps that may be used, and keep firmware and apps current through a controlled update process.
- Check app data settings. Some flight apps upload logs, images or maps to the manufacturer by default. Use local or offline modes where the site requires it.
- Separate devices used for sensitive work from personal phones and tablets.
- Use device management to enforce passcodes, encryption and remote wipe.
- Plan for loss. A written procedure for a lost controller, a crashed aircraft or a missing card, including who to tell and how to revoke access.
- Check client restrictions. Some owners and public bodies limit which aircraft, components or apps may operate on their sites. Find out before mobilising.
Docked drones that launch and upload on their own add a permanent network connection on site, which brings its own controls; see drone-in-a-box systems for how docked operations run.
Vendor evidence: what to ask for
A security questionnaire tells you what a vendor says. Independent evidence tells you what was checked. The most common forms:
| Evidence | What it shows | What to check |
|---|---|---|
| ISO/IEC 27001 certificate | An information security management system has been certified against the international standard | Certificate scope, issuing body, expiry date |
| SOC 2 Type 1 report | An independent auditor has assessed whether controls are suitably designed at a point in time | Which services and trust criteria are covered |
| SOC 2 Type 2 report | An auditor has tested whether controls operated effectively over a period | The period covered, and any exceptions noted |
| Penetration test summary | An outside firm tried to break in and the findings were fixed | Date, scope, and how serious findings were closed |
| Government frameworks | Assessment against a public-sector standard, such as FedRAMP in the US | Whether it is an authorisation or only alignment |
| Data processing agreement | Contract terms for personal data, sub-processors and breach notice | Notice periods, sub-processor list, residency terms |
Reports such as SOC 2 are normally shared under a non-disclosure agreement. Read the scope carefully: a certificate that covers a company's head office systems may not cover the product you are buying. And check the date, because evidence more than a year old says little about today.
Policies for sensitive sites
Not every site needs the same rules. A simple three-tier classification, agreed with the owner before the first flight, keeps controls proportionate.
| Tier | Typical sites | Extra controls |
|---|---|---|
| Standard | Most commercial and residential projects | Approved apps, role-based access, retention schedule |
| Sensitive | Data centres, hospitals, utilities, large logistics hubs | Named and vetted pilots, no-capture zones, restricted sharing, fixed data residency |
| Critical | Energy, defence-adjacent, transport and water infrastructure | Offline capture modes, client-approved storage, redaction before sharing, deletion at contract end with confirmation |
For sensitive and critical sites, also agree in writing:
- What may and may not be captured, including no-capture zones and whether security systems must be masked.
- Who may fly, and any vetting the owner requires.
- Where processing and storage happen, and whether data may leave the country.
- How findings are shared. Defect reports for critical assets often go only to named people.
- What happens at the end: handover of all copies, deletion and a written confirmation.
For energy assets such as the arrays in our solar farm thermal inspection work, a defect map pinned to exact GPS positions is exactly the kind of output these rules exist to protect.
Building security into a capture programme
Security works best as part of how the programme runs, not as a review after something goes wrong. Write the device rules, upload routine, access roles and retention schedule into the programme's procedures, and include data terms in capture contracts with providers and subcontractors. Our guide to setting up a construction drone programme covers the procedures this sits within, and owners setting requirements across many projects can fold these points into their reality capture standards.
On YelloSKYE projects, inspection findings from automated asset inspections and all other capture are held on DEX rather than passed around as attachments, and reports can be exported to PDF, Excel and BIM-linked formats so the owner keeps a copy under its own control. We would rather clients ask us the questions above than assume the answers.
Drone data security checklist
- Classify each site as standard, sensitive or critical before capture starts.
- List every place a copy of the data will exist, from memory card to backup.
- Confirm storage, backup and processing regions, and put them in the contract.
- Set role-based access, single sign-on and multi-factor authentication; review access at each milestone.
- Use expiring, named-user sharing instead of open links.
- Require encryption in transit, at rest and on devices.
- Approve aircraft, apps and settings; manage updates and plan for lost devices.
- Ask vendors for current, in-scope independent evidence and read the exceptions.
- Agree a retention period and how deletion will be confirmed at contract end.
Frequently asked questions
Is drone data secure?
It can be, but security depends on the whole chain, not just the software. Data passes through the aircraft, the controller app, an upload, processing, storage and sharing, and each step has its own risks. Ask how each step is protected, who can reach the data at each point, and what evidence the vendor can show.
What is data residency and why does it matter for drone data?
Data residency is the country or region where data is physically stored and processed. It matters because the law of that place can apply to the data, and many owners, utilities and public bodies require their site data to stay in a particular jurisdiction. Check where primary storage, backups and processing happen, and where support staff can access it from.
What security certifications should a drone software vendor have?
Common evidence includes ISO/IEC 27001 certification of an information security management system and a SOC 2 report from an independent auditor. Some public-sector buyers also require government frameworks such as FedRAMP in the US. Always check what the certificate or report covers, when it was issued and whether the service you will use is in scope.
What is the difference between SOC 2 Type 1 and Type 2?
Both are independent audit reports on a service organisation's controls, set out under rules from the AICPA. Type 1 assesses whether controls are designed properly at one point in time. Type 2 tests whether those controls actually worked over a period, usually several months, so it is the stronger evidence.
Can a drone manufacturer see my flight data?
It depends on the aircraft, the app and its settings. Some flight apps sync logs, images or maps to the maker's servers unless that is switched off, while others offer local or offline modes. Read the app's data settings and privacy terms, and set a company policy on which apps and modes may be used on sensitive sites.