Buying documents
What your reviewer needs, in one place
These answers describe RotorLab as of October 29, 2026 and are provided for information. They are not a warranty or part of any agreement; the Terms of Service, the Privacy Policy, the Data Processing Addendum and any Government Customer Addendum or signed agreement control. RotorLab holds no third-party attestation.
Our answers to a standard security questionnaire, the agreements that govern the service, and the list of subprocessors. Read them here, print them, or download the questionnaire as a spreadsheet.
How we protect the record, in plain words, is on the Trust Center.
Security questionnaire
Answers as of October 29, 2026. Where a question reads "Available on request," ask our sales team and we will answer it for your review. Where it reads "No," the control is not in place today.
1. Governance and company
| Number | Question | Answer |
|---|---|---|
| 1.1 | Legal name, address and security contact | RotorLab, Inc., 7709 Commerce Park, Suite 1, Dubuque, IA 52002. Security reports: security@rotorlab.app, published in /.well-known/security.txt (RFC 9116). |
| 1.2 | Is there a written information security policy, and who owns it? | Yes. The document, and who owns it, are available on request. |
| 1.3 | How many people have production access? | Available on request. The product has one platform operator seat. |
| 1.4 | Are personnel background-checked, under confidentiality terms, and trained in security? | Everyone RotorLab allows to access Records is bound to confidentiality (Data Processing Addendum, Section 3). Background checks and training: Available on request. |
| 1.5 | Do you carry cyber liability insurance? | Yes. A certificate of insurance is available on request. |
| 1.6 | Physical and environmental security of the data center | Inherited from Microsoft Azure, the hosting provider: the production server is in Central US (Iowa), and the offsite database replica and offsite backups are in East US 2 (Virginia), as the Data Processing Addendum, Section 5, names them. |
2. Access control
| Number | Question | Answer |
|---|---|---|
| 2.1 | What roles exist? | Three authority tiers: the platform operator, organization administrator and member. Below organization administrator, eight built-in roles (All areas, Member, Auditor, Pilot, Maintenance, Billing, Dispatcher and Operator-maintainer) and custom roles composed from a permission catalog, checked at every gate. The last Administrator of an organization cannot be removed. |
| 2.2 | Is customer data separated between tenants? | Every read or write by identifier takes the organization and filters on it, and the organization is taken from the signed-in session, never from the request. This is checked by automated tests. It has not been independently audited. |
| 2.3 | Is multi-factor authentication supported? Enforced? | Yes: an authenticator app (TOTP) and security keys (WebAuthn), with recovery codes. An organization can require it, with a grace period, and can require security keys only. |
| 2.4 | Is MFA required for privileged (operator) access? | Yes. The platform operator account requires two-factor authentication unless a host setting lifts it; its sessions last 8 hours with a 30-minute idle limit. |
| 2.5 | Is single sign-on supported? | Yes, OpenID Connect with PKCE: Google Workspace, Microsoft Entra and Okta. The identity token's issuer, audience, expiry, nonce and signature are verified. Only email addresses under a domain the organization proved can sign in. Just-in-time accounts and group-to-role mapping are optional and never make anyone an administrator. |
| 2.6 | Is SAML supported? Is SCIM? | SAML is not offered; single sign-on is OpenID Connect. SCIM 2.0 provisioning of users and groups is built in: the organization's directory adds members whose addresses are under a domain the organization proved (a person who already has a RotorLab sign-in is invited instead), updates them, sets their role through the same group-to-role map as single sign-on, and deactivates them, which ends their sessions and revokes their personal API keys at once and keeps the records they made. It never makes anyone an administrator, never deactivates the organization's last active administrator and never changes a member's email address. |
| 2.7 | How are passwords stored? | Never stored as entered: a per-user random salt with scrypt, with a PBKDF2-SHA256 fallback at 600,000 iterations, and constant-time comparison. |
| 2.8 | Is there brute-force protection? | Yes. A sign-in throttle with lockout holds across both web workers, and the web server rate-limits the sign-in routes to 10 requests a minute per address. |
| 2.9 | How are sessions protected? | Server-side sessions stored as hashes. The cookie is HttpOnly, SameSite=Strict and Secure in production. Default session is 14 days; an organization can set an idle limit (default 12 hours) and a lifetime. |
| 2.10 | Can your staff read customer data? | Not by routine. The operator account is kept out of organization pages. Without an open grant, support does not look at your records except under emergency access. An organization administrator can grant support access for 24 hours, 72 hours or 7 days, with a reason, and end it at any time. Emergency access needs a written reason, lasts at most a day, is logged, and every administrator of the organization is emailed at once. For a public body, emergency access is used only at its request or where the law requires it (Government Customer Addendum, Section 6). Everything support reads or changes is written to the organization's own activity log. This is a posture, not a hard boundary: whoever holds the database host can read the database. |
| 2.11 | API access | API keys are stored as hashes, scoped (status, flights, checklists, engine, builds, live, jobs) and optionally expiring. Every API route maps to a permission, checked by automated tests. |
| 2.12 | Access reviews and joiner/leaver process for your staff | Available on request. |
3. Network and application security
| Number | Question | Answer |
|---|---|---|
| 3.1 | What sits in front of the application? | Microsoft's Azure Front Door edge (Standard tier), with web application firewall custom rules, including a sign-in flood rule and a site-wide rate rule; then a load-balanced origin that admits requests only from RotorLab's own Front Door profile, reached over TLS; then a web server with per-address rate limits; then two web workers. |
| 3.2 | Security headers | Content security policy with frame-ancestors none, base-uri none and form-action self, and an allow-list of outside hosts widened only when a feature is on; X-Content-Type-Options nosniff; Referrer-Policy no-referrer; HSTS; a host allow-list. |
| 3.3 | Outbound calls | Addresses an organization enters (webhooks, alert hooks) go through a guarded opener: public addresses only, no redirects. Offline mode stops every outside call. |
| 3.4 | Container hardening | The application image runs as a non-root user; the runtime stage has no installer; no service mounts the Docker socket; every service has a memory limit and a log size cap. |
| 3.5 | Penetration test | An independent penetration test is planned for Q4 2026. None has been completed. |
| 3.6 | Vulnerability disclosure | security.txt with a contact and policy link. No bug bounty. |
4. Encryption
| Number | Question | Answer |
|---|---|---|
| 4.1 | Encryption in transit | TLS twice over: from the browser to Microsoft's Azure Front Door edge, and again from the edge to the production server. The edge decrypts the traffic to route and filter it and encrypts it again. Outbound mail uses STARTTLS by default or SSL/TLS; an administrator can also choose no encryption for a relay. The edge TLS version and cipher policy: Available on request. |
| 4.2 | Encryption at rest: what is sealed? | When the deployment's key is set: precise flight positions, stored flight log files (including files waiting to be filed), live recordings, saved missions, area outlines, authenticator secrets, and stored credentials (any setting named as a secret). Items stored before the key was set stay unsealed until they are written again or a sealing pass seals them. Other fields (names, record text) are not field-sealed. |
| 4.3 | With what algorithm? | AES-256-GCM through the cryptography library, with keys derived by HKDF-SHA256 from each key version's secret (separately for text and for each organization's files), a random 12-byte nonce per value and per file, and each value's header (format and key version) bound as associated data. Values sealed earlier with RotorLab's previous construction (authenticated encryption built from HMAC-SHA256 in counter mode with an independent MAC key and a random 16-byte nonce) are still read, and are re-sealed with AES-256-GCM by the background pass described in 4.7. It is not a FIPS 140 validated module. |
| 4.4 | Where is the key? | In the host environment (an environment variable or a mounted secret file), never in the database, with one secret per key version, so a copied database or backup carries no tracks. It does not protect against a compromised host. |
| 4.5 | Full-disk or volume encryption | Available on request. |
| 4.6 | Backup encryption | Available on request. Sealed values stay sealed inside any backup. |
| 4.7 | Key management (rotation, custody, HSM) | Keys are versioned: each value sealed with AES-256-GCM names the key version that sealed it, and values in the earlier format belong to version 1. A new version is made current from the operator console, which refuses until AES-256-GCM is on and every running application server holds that version; a background pass then re-seals values sealed under earlier versions, and earlier versions still open what they sealed. Files kept only for a day or for one analysis job are not re-sealed and expire under the version that sealed them. RotorLab holds the keys. Customer-managed keys, an HSM and a key management service are not in place today. |
5. Logging and audit
| Number | Question | Answer |
|---|---|---|
| 5.1 | Is there an audit log? | Yes. Every notable action is a row in the activity log and a line in a rotating host log. An organization administrator reads the organization's log; standard members have none; the operator sees platform events. |
| 5.2 | Is it tamper-evident? | Hash-chained: each row carries a hash over its content and the previous row, verifiable for the whole log or one organization. Once a day the newest row and the day's records are reduced to one SHA-256 hash sent to an RFC 3161 time-stamping authority and to OpenTimestamps. Rows are never deleted; the only updates are two recorded redactions. The chain shows a record has not changed since it was recorded; it does not show the record is true. |
| 5.3 | Are log writes lost under failure? | A locked write is retried; a refused row spills to a file and is written later; the backlog shows on the health check and the console. |
| 5.4 | Log retention | Activity log rows are kept, and redacted in place on organization deletion, never deleted. Container logs are capped at 100 MB per container. Host log retention: Available on request. |
| 5.5 | Do you monitor and alert? | Every five minutes each worker checks database writes, disk floor, refused log rows, analysis backlog, backups off, failing or stale, error bursts, timestamps not sent and clock jumps; by default a rule must hold on two passes four minutes apart before the operator is told by email or webhook. No SIEM. |
6. Backup and recovery
| Number | Question | Answer |
|---|---|---|
| 6.1 | How is data backed up? | Three layers. (1) A transactionally consistent database snapshot every 24 hours, keeping 7 by default, each integrity-checked and hashed with SHA-256. (2) An optional continuous replica to off-site object storage (Azure Blob Storage in East US 2, Virginia): changes copied about every 10 seconds, snapshots every 6 hours kept 30 days. (3) A host job copies the stored file stores and snapshots to off-site object storage (Azure Blob Storage in East US 2, Virginia). Which layers run in production: Available on request. |
| 6.2 | Is backup failure detected? | Yes. A failed backup is logged, counted in the daily error digest and raised as an outage alert. |
| 6.3 | RPO | Recovery point and recovery time targets are published once a restore drill proves them. Until then: Available on request. Without the off-site replica, the newest copy is the daily snapshot. If the server itself is taken over, the newest copy the server's own credentials cannot reach is the daily backup in the backup vault, so up to a day of changes can be lost in that case. |
| 6.4 | RTO | See 6.3. Available on request until a restore drill proves it. |
| 6.5 | Is restore tested? | A restore drill is documented step by step, with an integrity check and a row count. Date of the last drill: Available on request. |
| 6.6 | Do restores bring back deleted customers? | A restored copy is deleted again from a signed deletion journal, kept apart from the database, by the next scheduled check. |
| 6.7 | Business continuity and disaster recovery plan | Yes. The document is available on request. |
| 6.8 | Availability target | A 99.5 percent monthly target, measured by the service's own heartbeat and published at /status. The Terms carry no uptime warranty or service credits. |
7. Vulnerability management and supply chain
| Number | Question | Answer |
|---|---|---|
| 7.1 | Third-party dependencies | Standard library, plus Pillow and cryptography (with the packages it needs, cffi and pycparser, each locked by hash) in the application image, and torch with the packages it needs, each locked by hash, in the analysis sidecar image. |
| 7.2 | Are dependencies pinned? | Every shipping package is pinned to an exact version and every container image to a digest; the release refuses an unpinned install. |
| 7.3 | Are dependencies checked for known vulnerabilities? | Yes, at every release: each pinned version is checked against the OSV database, and a known advisory stops the build until the pin moves or the advisory is reviewed and acknowledged. |
| 7.4 | SBOM | A CycloneDX 1.6 software bill of materials ships with every release. |
| 7.5 | Container image scanning | Images are scanned on every push and weekly. The scan reports and does not block a release. |
| 7.6 | Patch timelines by severity | Available on request. |
| 7.7 | Host OS patching | Available on request. |
8. Secure development
| Number | Question | Answer |
|---|---|---|
| 8.1 | Automated tests | An automated suite run before every release, including tenant isolation, role routes, request limits, the sign-in throttle across workers, schema parity on upgrade, supply-chain pins and production settings. |
| 8.2 | Release gate | A release ships only after a passing automated run on the exact commit, including a production image build, or a full local run that records a digest of every shipped file. |
| 8.3 | Code review | Changes are checked by the automated suite and by review tooling before release. Who approves each change: Available on request. |
| 8.4 | Separation of environments | Automated tests run on a throwaway database, never on production data. Demonstration organizations used for sales demonstrations run in the production service. Their records are invented; the only real personal details in them are the sign-ins of the people invited to use them. Other environment separation: Available on request. |
| 8.5 | Secrets in source | The deployment secrets file is never committed. Secret settings are write-only in the console and never returned by the settings interface. |
9. Incident response
| Number | Question | Answer |
|---|---|---|
| 9.1 | Do you have an incident response plan? | Yes. The document is available on request. |
| 9.2 | How do you detect incidents? | Outage alert rules on the heartbeat, and security-level events in the activity log. |
| 9.3 | How are customers told? | If a personal data breach affects a customer's Records, its administrators are told without undue delay and within seventy-two hours of RotorLab confirming it (Data Processing Addendum, Section 7). Service incidents are posted on /status in plain words. |
| 9.4 | Have you had a breach? | No, not to RotorLab's knowledge. |
10. Data retention and deletion
| Number | Question | Answer |
|---|---|---|
| 10.1 | Can customers export their data? | Yes, while the plan is active or in the ninety-day read-only period: an organization export of JSON and CSV, raw flight logs, the audit binder, packages and the API, and a per-person export. |
| 10.2 | What happens when a contract ends? | 90 days read-only with export, then 12 months retained with no access, then deletion after an alert 30 days and a final notice 7 days before. Deletion is never automatic; records on legal hold are kept. |
| 10.3 | How is deletion done and evidenced? | One purge driven by a map that names a rule for every table; a table the map does not name stops the purge. A deletion certificate (name, time, actor, reason and basis, counts per table and file store, SHA-256) is kept twelve months. The former administrators are emailed that the records were deleted, with the counts. |
| 10.4 | What remains after deletion? | Activity log rows with content removed, timestamp hashes, an issued-document tombstone, billing records for the accounting period (seven years by default), and a journal line with no customer data. |
| 10.5 | Do backups outlive deletion? | Yes, for a bounded time. Snapshots expire on their schedule (7 days by default; replica snapshots 30 days). Offsite we keep 30 days of restorable history: the database replica, the copies of stored files and a daily copy in a backup vault each reach back 30 days. Backup copies are protected against early deletion, so a Record deleted from the application is gone from every one of its backup copies within 90 days of its deletion (Data Processing Addendum, Section 8). A restore deletes again from the journal. |
| 10.6 | Stored flight log retention | The organization chooses; 90 days by default, and keep forever by default for a public body. |
11. Data location
| Number | Question | Answer |
|---|---|---|
| 11.1 | Where is customer data stored and processed? | The United States, on Microsoft Azure: the production server in Central US (Iowa), and the offsite database replica and offsite backups in East US 2 (Virginia), as the Data Processing Addendum, Section 5, names them. A request may be handled first at an edge location outside the United States (see 11.3). |
| 11.2 | Can a customer keep data inside its own network? | Yes. A government or defense customer can run its own copy in offline mode, which makes no outside connection. |
| 11.3 | Transfers outside the US | A request from outside the United States, and the response to it, may be decrypted and routed at a Microsoft edge location in the visitor's region on the way between the visitor and the server in the United States; Records are stored only in the United States. Optional outside lookups send limited data to other countries when switched on: MET Norway (weather coordinates, Norway) and DJI (key identifiers, China; optional, off by default, enabled only by a customer administrator, no Records, and nothing is sent in offline mode or when left off). An organization can switch weather and lookups off for its members. Standard contractual clauses (Module Two) and the UK addendum apply for EU, UK and Swiss customers (Data Processing Addendum, Section 10). |
12. Subprocessors
| Number | Question | Answer |
|---|---|---|
| 12.1 | List your subprocessors | Microsoft Azure (hosting, backups and the Azure Front Door edge), Stripe (payments), Google Workspace (email delivery) and, only where a customer administrator switches it on, DJI (key identifiers). The full list, with what each receives, is published on RotorLab's buying documents page and in the Data Processing Addendum, Section 5. The outside services the Service calls, with what each receives, are listed in the Privacy Policy, Section 4A. |
| 12.2 | Notice of change | Thirty days' notice of a new subprocessor by email to administrators, with a right to object and to terminate the affected part with a pro-rata refund (Data Processing Addendum, Section 5). |
13. Privacy
| Number | Question | Answer |
|---|---|---|
| 13.1 | Do you sign a DPA? | Yes, the Data Processing Addendum, and a Government Customer Addendum for public bodies. |
| 13.2 | Data-subject requests | Per-person export, correction with history, deactivation, and referral to the customer within five business days. |
| 13.3 | Location privacy controls | An organization chooses what a flight keeps of where it flew: exact position, rounded area or none. It can switch outside maps, weather, lookups, autocomplete and analytics off for its members. |
| 13.4 | Analytics and cookies | Google Analytics loads only after the visitor accepts; the product's own counts are cookieless. |
| 13.5 | Do you use customer data to train models? | Only if the organization opts in; off by default and revocable. Scores are advisory and never gate anything. |
14. Accessibility
| Number | Question | Answer |
|---|---|---|
| 14.1 | Do you have an accessibility conformance report? | Yes, a self-assessed report on the VPAT 2.4 template (Section 508 and WCAG editions), available on request. It is based on automated checks and code review. No assistive-technology testing has been done yet; those criteria are marked Not Evaluated. It is not an independent audit. |
| 14.2 | Target standard | WCAG 2.1 level AA. A reported barrier is answered within thirty days. |
15. Attestations and certifications
| Number | Question | Answer |
|---|---|---|
| 15.1 | Do you hold a third-party security attestation, audit report or certification? | None held. RotorLab has no ISO 27001 certificate and no FedRAMP or GovRAMP authorization, and it has not been assessed against the CJIS Security Policy. The controls in this questionnaire are described by RotorLab, and many can be seen working in the product. |
| 15.2 | Do you plan to obtain one? | No commitment today. A formal attestation will be announced on the trust page when it exists, with its scope, not before. |
| 15.3 | Third-party assessments the customer may receive | Under the Data Processing Addendum (Section 9) the customer may ask once a year for the results of any third-party assessment RotorLab holds. None is held today. |
Agreements
These documents control. Where an answer above and an agreement differ, the agreement governs.
Terms of Service
The agreement for using RotorLab: plans, payment, your records, and what each side is responsible for.
Privacy Policy
What RotorLab collects, why, and every outside service the product calls, with what each receives (Section 4A).
Data Processing Addendum
How RotorLab processes your organization's records for you: security, subprocessors, breach notice, deletion and transfers.
Government Customer Addendum
The terms a public body adds: governing law, public records and retention, appropriations, data location and access, accessibility and payment.
Subprocessors and outside services
Who else handles data, and what each receives.
These are the subprocessors the Data Processing Addendum, Section 5, authorizes. We give your organization's administrators thirty days' notice of a new subprocessor, and you may object in writing within that period (Data Processing Addendum, Section 5). Records are stored only in the United States.
| Party | Country | What it does | What it receives |
|---|---|---|---|
| Microsoft Corporation (Microsoft Azure) | United States | For hosting: the production server in Central US (Iowa), which may run in East US 2 (Virginia) while Central US is unavailable; the offsite database replica and offsite backups in East US 2 (Virginia); and Azure Front Door, the edge network that every request to the Service and every response from it passes through, which decrypts that traffic to route and filter it and encrypts it again before passing it on. Front Door handles traffic at the Microsoft edge location nearest the user, which can be outside the United States; it caches no Records; and its request logs are stored in Central US (Iowa). RotorLab's status page runs on the same Microsoft service. | Every Record, stored in the United States, and every request and response between a browser, API client or ground station and the Service |
| Stripe, Inc. | United States | Card payments, subscriptions and invoices, and orders in RotorLab's website shop | Billing name, email, address and tax identifier, the plan, and the organization's name and identifier. Card numbers go to Stripe only. Never Records |
| Google LLC (Google Workspace), the email delivery provider configured on the Service | United States | Sends invitations, password resets, notices, replies to support requests, billing email and outage alerts | Addresses and the contents of those messages, which can include details from the Records a notice is about, and no other Records |
| SZ DJI Technology Co., Ltd. | China | Optional, off by default, enabled only by a customer administrator. Returns the keys needed to read current-format DJI flight records | Key identifiers only, no Records. A copy run in offline mode, and a customer that leaves it off, send nothing |
| The identity provider your organization connects for single sign-on | Chosen by the customer | Takes part in the OpenID Connect sign-in exchange. It is your organization's own processor | The sign-in exchange OpenID Connect defines |
RotorLab's own sales and account contacts, including the website's quote, contact and sales forms and the newsletter, are kept in GoHighLevel (HighLevel, Inc., United States), where RotorLab is the controller; it receives no Record. The outside services the Service calls, and what each receives, are listed in the Privacy Policy, Section 4A.
The agreements behind this list: the Data Processing Addendum, Section 5, and the Privacy Policy, Section 4A.
Accessibility
Our accessibility conformance report is available on request. Ask for the current one through Support and a person sends it by email.
Support
Where your organization has signed an order form, its support terms, such as hours and response targets, are set there; otherwise, a person answers by email.
Attestations
None held. RotorLab has no ISO 27001 certificate and no FedRAMP or GovRAMP authorization, and it has not been assessed against the CJIS Security Policy. The controls in this questionnaire are described by RotorLab, and many can be seen working in the product.
Need an answer marked on request?
Ask our sales team, or send your own questionnaire, and a person answers by email, usually within one business day.