Drone-based surveying has gone from novelty to mainstream practice across the GIS profession. A decade ago, putting a quadcopter over a quarry, a powerline corridor, or a road right-of-way was experimental. Today it is a billable line item on most survey project quotes, and clients increasingly expect drone-derived deliverables as a default rather than an option.
The deliverables side of this transformation has been well-served by software. Photogrammetry suites, point cloud processors, and orthomosaic tools have matured into serious professional platforms. GIS teams routinely produce centimeter-grade outputs that would have been hard to imagine fifteen years ago.
The operational side of drone surveying has lagged badly behind. Most teams running drone-based GIS work still manage the underlying operations with the same tools they used in 2018: a shared spreadsheet for flight logs, a folder of PDFs for client permits and insurance evidence, a separate folder for pilot certifications, and a group chat for incident reports. When a client asks for proof of who flew what, when, where, with which aircraft, and under which authorization, the answer is usually a scramble.
A growing number of GIS survey operations are catching up by adopting purpose-built systems for the operational record itself. Platforms like FlybyOps treat the underlying drone operation as the system of record, unifying flights, projects, equipment, risks, and incidents under a single audited workspace. The shift is being driven by external pressure that survey teams cannot ignore much longer, and that pressure is arriving from several directions at once.
What Is Driving the Shift
Client expectations are the most visible driver. Survey firms working with utilities, energy operators, transportation agencies, and increasingly even municipal clients now field RFPs that explicitly ask for evidence of compliance frameworks, pilot certification tracking, flight log retention policies, and incident response protocols. A response that boils down to “we have spreadsheets” is becoming a deal-breaker for serious work.
Regulator scrutiny is the second force. The FAA continues to refine its expectations around commercial UAS operations under Part 107, and ramp-check style inquiries have become more common, especially for firms operating waivers, conducting BVLOS work, or flying over people. Survey teams running 91.113 waivers for mapping over active sites are finding that records need to be ready on demand rather than reconstructable after the fact.
Insurance carriers are the third force, and probably the quietest one. Underwriters writing commercial UAS coverage have grown sharper about what they consider acceptable evidence of risk management. A team that cannot produce a coherent risk register, a maintenance log tied to specific airframes, and an incident reporting trail will find renewal conversations getting noticeably harder.
The fourth force is internal. Survey firms running drone work across multiple sites and multiple clients have a confidentiality problem they did not have when one pilot ran one project at a time. A pilot working on a confidential pipeline inspection should not be able to browse the project folder of a different client’s mining site. Spreadsheets do not enforce that. Neither do generic project management tools.
The Operational Records GIS Survey Teams Should Actually Be Keeping
Most survey teams know they should be keeping more than they currently are. The list below covers what regulators, clients, and insurers tend to look for, in roughly the order they ask for it.
Flight records that go beyond the basics. Date, time, location, pilot, aircraft, and duration are the minimum. Useful records also capture takeoff and landing coordinates, distance flown, ground crew on scene, payload carried, weather conditions at flight time, and the project or job the flight was conducted under. Hours roll up against both the pilot and the specific airframe, which matters for maintenance forecasting and for proving compliance with currency requirements.
Equipment and maintenance records. Every aircraft, every controller, every battery, every charger, and every prop set in active service should be in a registry. Maintenance events, firmware updates, battery cycle counts, and inspection records belong against the specific serial-numbered item. When an aircraft hits its manufacturer-recommended service interval, or when a battery passes its cycle-count threshold, the system should flag it before the next mission, not after.
Risk assessments tied to specific operations. Generic safety statements stapled to the front of an operations manual are not what regulators want to see. Project-by-project or job-by-job risk assessments with concrete mitigation actions, assigned owners, and review dates are what they ask for. The 5×5 severity-by-likelihood matrix borrowed from the EASA SORA framework has become a common reference point even among US operators who are not flying under EASA at all, simply because it is widely understood and easy to defend.
Incident reports filed against specific flights or jobs. Near misses, equipment failures, airspace incursions, and damage events all deserve their own record. The best programs let any member of the operation file an incident, including anonymously when the situation calls for it. Anonymous reporting is not just a courtesy. For firms running multi-stakeholder sites, it is sometimes the only way to surface a problem before it becomes an enforcement action.
Document storage that is actually access-controlled. Cargo manifests, permits, insurance certificates, client NDAs, pilot certifications, and training records all need a home. They also need to be visible to the right people and invisible to the wrong ones. Storing everything in a shared drive folder violates that requirement on day one.
Pilot and crew access scoped by project or site. A pilot assigned to a wind farm survey should see the wind farm job and nothing else. A pilot rotating between three clients should see three separate workspaces, not a master list of everything the firm is doing. The technical pattern here is role-based access combined with project-level scoping, and it cannot be retrofitted on top of a flat spreadsheet.
Audit trails that cannot be quietly edited. The most consequential records are the ones that prove who did what and when. An audit log that records every mutation to the operational record, attributed to the actor and the time, is what separates a defensible program from a hopeful one. Append-only audit trails, where nothing can be silently rewritten after the fact, are now considered the floor rather than the ceiling.
Why Spreadsheets Stop Working
Spreadsheets are not actually bad. They work fine for a single pilot running occasional flights for a single client. They start breaking down when any of the following happens.
A second pilot joins, and the team needs to track who flew what. Sharing a single sheet quickly creates conflicting versions. Locking the sheet down to one editor creates a bottleneck that nobody respects in practice.
A second client gets added, and the firm needs to keep one client’s flight data from being visible to the other client’s pilot. Sheet permissions are coarse. Subdividing into many sheets multiplies the maintenance burden.
A client or auditor asks for documentation that is six months old, and the team realizes the sheet has been overwritten multiple times since the flight in question. There is no history. There is no provenance. There is just the current state, which may or may not reflect what actually happened.
An incident occurs, and the firm needs to demonstrate that policies and procedures were followed. The sheet shows the flight took place. It does not show the risk assessment that was completed before takeoff, the mitigation actions assigned, the pilot’s currency status, or the post-flight inspection. Those were in other sheets, or in chats, or in heads.
A staff change happens, and institutional knowledge walks out the door. The new operations lead inherits a folder structure they did not build, with files named in conventions they do not recognize, and zero context about which records are current.
What to Look for in a Purpose-Built Platform
A few capabilities matter more than the rest when survey teams evaluate dedicated operations software.
Project and job structure that maps to how the firm actually scopes work. Most drone surveying happens within a project that has multiple jobs underneath, each with its own location, timing, and crew. A platform that forces all flights into a flat list, with project context tacked on as a metadata field, will fight the firm forever. A platform that natively models projects, jobs, flights, and the relationships between them will feel like an extension of how the team already thinks.
Equipment registry tied to flight hours. Drone hours need to roll up against the specific airframe automatically. Manual entry breaks down within weeks. Pilots will not consistently update a separate equipment tab after every flight.
Role-based access with project-level scoping. The five-role model of administrator, project manager, operations lead, pilot, and ground crew is becoming standard. What matters is whether the platform enforces project and job assignments such that pilots see only what they should see, with no manual gatekeeping required.
Document storage with quotas and access control. Permits, manifests, NDAs, and insurance certificates need to live alongside the operational record, not in a separate cloud drive. Encryption at rest, access logging, and presigned URLs are the technical floor.
A real audit log. Not a change history. Not a recent-edits panel. An append-only record at the database level, written in the same transaction as the underlying business event, that cannot be tampered with or rolled back without forensic evidence.
A Note on Implementation
The most common mistake firms make when moving off spreadsheets is treating the transition as a software project rather than an operational discipline shift. The platform is the easy part. The hard part is getting pilots to actually log every flight, getting project managers to maintain risk registers in real time, and getting the operations lead to treat the document vault as the canonical source of truth rather than as a backup of the shared drive.
Firms that succeed tend to do three things. They start with one client engagement as a pilot deployment rather than rolling everything out at once. They appoint a single internal owner who is accountable for the operational record across all jobs, even when project responsibility is distributed. And they treat the first ninety days as a period of process redesign, not just data migration.
FAQ
How long do drone flight records need to be kept?
FAA guidance generally treats Part 107 flight records as records that should be retained for at least two years, though some categories of records (maintenance, airworthiness, incident-related) should be kept for the life of the aircraft or until all related claims are closed. Many enterprise programs default to a five-year retention as a margin for state-level or insurance-related queries.
Do we really need a separate platform if our deliverables tool already includes flight logs?
Photogrammetry and mapping platforms often capture flight metadata as a byproduct of processing, but they are not designed to be the operational record. They typically lack risk registers, incident reporting, equipment registries, document vaults, and the audit trail features that regulators and insurers expect. Treating the deliverables platform as the operational record tends to break down once a firm starts working across multiple clients.
What is the difference between a flight log and an audit log?
A flight log records what happened during operations: who flew, where, when, in what aircraft, for how long. An audit log records what happened in the system itself: who created, modified, accessed, or deleted any record, and when. Both matter. A flight log answers questions about the operation. An audit log answers questions about the integrity of the record.
Can pilots share access to project data across client engagements?
They should not, in most cases. Site-specific NDAs and client confidentiality terms typically require that a pilot assigned to one project cannot see data from another. Spreadsheet-based systems make compliance with these terms difficult to enforce. Dedicated platforms enforce project scoping at the access control layer, so pilots see only the jobs they are assigned to.
How do small survey teams start the transition without disrupting active projects?
The usual pattern is to run the new platform alongside existing spreadsheets for one client engagement, ideally a project that is just starting. After one full project cycle, the team has a clear sense of which existing processes can be retired. A typical small team takes ninety days to fully transition, and the operational improvements compound after that.
Where This Is Going
The maturation of drone surveying as a professional practice is forcing operational standards to catch up with technical capability. The same firms that invested heavily in photogrammetry software, RTK base stations, and post-processing capability in the 2018 to 2022 window are now investing in operational software in the 2025 to 2027 window. The pattern is recognizable. A new technology arrives, the deliverables side gets professionalized first, the operational side follows two or three years later, and eventually the operational side becomes part of how clients evaluate vendors.
Survey teams that get ahead of this curve are not gaining a permanent advantage. They are simply meeting the standard their clients are about to require by default. The teams that lag will spend the next two years building the recordkeeping discipline their faster competitors already have.