01 / Data and privacy
Define why the data is being collected
A roof documentation project may need clear views of a client’s property. It rarely needs unrelated detail about neighboring residents, private yards or people passing nearby. A practical data plan begins with the intended subject and asks what information is actually necessary to answer the project question.
Tell the operator about sensitive features before capture. These might include a restricted work area, a private gathering, identifying signs or assets that should not appear in marketing material. A narrow purpose makes it easier to plan the view, limit unnecessary collection and decide which files belong in the final delivery. It also helps the client explain the project to others who may notice the aircraft.
02 / Data and privacy
Use established principles without overstating them
NTIA’s voluntary UAS privacy practices encourage notice where appropriate, care with identifiable information, limits on use and sharing, security and attention to evolving law. These are voluntary practices, not a substitute for determining the requirements of a particular project or jurisdiction.
Use them to structure a real conversation. Who should know capture is planned? What information is sensitive? Who needs the files? Can incidental identifying details be excluded from a public version? Who will answer a concern? These questions give privacy a place in the workflow instead of treating it as a paragraph added after the work is complete.
03 / Data and privacy
Separate evidence, working files and public selections
Original capture files preserve the starting point. Working files document processing or editing. Delivery files serve the client’s intended use. Public selections have an additional job: they must be appropriate for a wider audience. Mixing all four in one shared folder makes it easy to mistake an edited image for an original or a private observation for a portfolio selection.
A practical folder structure is less important than a clear distinction. Name the project, preserve dates and identify revisions. Avoid overwriting a source file when preparing a smaller web version. If technical analysis depends on metadata or a native format, confirm those requirements before conversion. The next reviewer should understand what they are opening and what transformations occurred.

04 / Data and privacy
Ask specific questions about the handling chain
CISA treats drone security as a before, during and after-flight issue. Its guidance includes understanding manufacturer data practices, using appropriate account protections, obtaining software from authenticated sources and considering how captured data is transferred and stored. The aircraft is one component of a larger information workflow.
For a client, ask which devices, applications and storage services will handle the project. Confirm who can access the delivery and whether a public link is appropriate. Sensitive work may need a more controlled handoff. These are choices to agree on, not claims that any particular product eliminates every risk. Avoid promising controls that have not actually been implemented and checked.
05 / Data and privacy
A useful private record is not automatically public content
An image may be excellent evidence for a client and still be unsuitable for a website. Publication review should consider the subject, people, identifying details, private information, contractual expectations and the permission needed for the intended use. A portfolio should not rely on assumptions about what a client will be comfortable sharing.
Create a reviewed public selection separately. Confirm the caption as well as the image: a generic aerial view should not be described as proof of a specific inspection result or customer endorsement. If identifying details need to be obscured, retain the original privately where the project requires it and label the public file as an edited derivative. Keep the story accurate to the actual work.
06 / Data and privacy
Agree on retention and a reusable handoff
The delivery conversation should include how long material is expected to remain available and who is responsible for keeping it. A one-time marketing selection and a recurring property record can have different needs. Avoid an indefinite retention promise by default, and do not delete required project evidence simply because a public version has been prepared.
Give the client a short explanation of the package: where the originals are, which files are intended for sharing, what software is needed and whom to contact with a correction or handling concern. These practices make the record easier to reuse and reduce confusion long after the people who commissioned it have moved to another project.
- Purpose and necessary scope of collection.
- Access, sharing and any public-use restrictions.
- Original, working, delivery and public-file distinctions.
- Retention expectations and responsibility for archiving.
- A contact and process for questions, corrections or privacy concerns.
VERIFY THE DETAILS / KEEP EXPLORING
Sources & further reading
Original explanation by Fly Maxwell. Technical and regulatory details are linked to the responsible organizations below. Product features, software plans and operating rules can change; check the current source when planning a project or a flight.
- Finding Common Ground on UAS: Voluntary Privacy Practices National Telecommunications and Information Administration · reviewed October 8, 2026
- Secure Your Drone: Privacy and Data Protection Guidance Cybersecurity and Infrastructure Security Agency · reviewed October 8, 2026
Manufacturer specifications describe the product under stated conditions. They are not a promise of project accuracy, flight duration, target detection or a particular outcome.

