Data Processing Addendum

RotorLab.app: Data Processing Addendum

Effective date: October 4, 2026

This Data Processing Addendum ("Addendum") forms part of the Terms of Service between the organization named on the account ("Customer") and RotorLab, Inc., a Delaware corporation with its headquarters in Dubuque, Iowa ("RotorLab") and applies whenever RotorLab processes personal data in the Records the Customer keeps in the Service. Where the two conflict about personal data, this Addendum controls.

1. Roles. The Customer is the controller of the Records and of the personal data in them (its members' names and contact details, pilot credentials and training, the people named on flights, maintenance records, occurrences, service records and documents, members or not, and the positions its aircraft flew), and of its activity log, which it keeps for as long as it keeps its Records. RotorLab is the processor. For the Customer's account, billing and RotorLab's own security log (a copy of sign-in and security events, kept apart from the Customer's activity log for the period the Privacy Policy states), RotorLab is the controller under the Privacy Policy. Where the Customer runs its own copy of the Service inside its own network, in offline mode (Government Customer Addendum, Section 6A), RotorLab does not hold or process the Records kept in that copy, and this Addendum covers only what RotorLab processes.

2. Instructions. RotorLab processes the Records only to provide the Service as the Terms, the documentation and the Customer's use of the Service's own controls instruct, and as the law requires (in which case RotorLab tells the Customer unless the law forbids it). RotorLab does not read, mine or disclose Records for any other purpose. Aggregate statistics that cannot identify the Customer, a person or an aircraft are not personal data.

3. Confidentiality and support access. Every person RotorLab allows to access the Records is bound by a duty of confidentiality and accesses them only to provide the Service, at the Customer's request, or under emergency access as this Section limits it. RotorLab support opens a Customer's Records in the Service only (a) while an administrator of the Customer has given support access, for a period the administrator chooses and can end at any time, which is the Customer's request; or (b) under emergency access, a narrow exception used only to respond to a security incident, to meet a legal requirement, or to prevent harm to a person or to property, where support access cannot be given in time. Emergency access needs a written reason, lasts at most a day, and every administrator of the Customer is emailed the moment it begins, with the reason, and may end it. Every read or change made under either is written to the Customer's own activity log.

4. Security. RotorLab keeps the measures the trust page states, at least: encryption in transit; server-side hashed sessions; salted password hashes; where the Service runs with its encryption key, authenticator secrets, precise flight positions, stored credentials, and stored flight log files, live recordings, saved missions, area outlines and frozen area dossiers sealed at rest with authenticated encryption as they are written (a flight log waiting in File Flights to be filed stays unsealed for up to 24 hours, until it is filed or removed; items stored before the Service held its key stay unsealed unless they are written again or a pass RotorLab runs seals them; where the Service runs without its key, all of these are stored unsealed and protected by the other measures in this Section); role gates on every read and write; a hash-chained activity log; a database snapshot on a schedule and a copy in a second location; and the deletion on termination in Section 8. The Customer's own controls include its choice of what a flight keeps of where it flew (its exact position, only a rounded area, or no position, as Section 2(e) of the Privacy Policy describes) and switches that turn off, for its members, the outside map, weather and lookup services and usage analytics. RotorLab tells the Customer of a material change to these measures thirty days before it takes effect.

5. Subprocessors. The Customer authorizes these subprocessors, and RotorLab remains responsible for them: (a) the hosting provider of the production data center in Texas and of the backup location in Iowa; (b) the object-storage provider of the offsite database replica, where it is enabled; (c) Stripe, Inc., for payment processing (Stripe receives billing details and never Records); (d) the email delivery provider configured on the installation, for invites, notices and, with consent, the newsletter (it receives addresses and message contents, never Records); (e) SZ DJI Technology Co., Ltd., only when the Customer enables decryption of current-format DJI flight records, which sends the record's key identifiers to DJI's keychain service and nothing else; (f) an identity provider the Customer itself connects for single sign-on, which is the Customer's own processor. RotorLab gives thirty days' notice of a new subprocessor by the notice channel in the Terms; the Customer may object in writing within that period, and if the objection cannot be resolved, may terminate the affected part of the Service and receive a pro-rata refund of prepaid fees. Besides these, the Service calls the outside services listed in Section 4A of the Privacy Policy, each of which receives only what that list says; the Customer can switch off, for its members, map imagery and terrain from outside services, weather, place and elevation lookups and address autocomplete.

6. Assistance. RotorLab helps the Customer answer data-subject requests, the way the Service is built to (export, an export of everything the Customer holds about one person, each person's download of their own data, correction with history, deactivation rather than deletion of a person on a record and minimizing a person who has left, voiding rather than destruction of a filed flight, legal hold), and answers a request it receives directly by referring it to the Customer within five business days. RotorLab helps the Customer with security assessments and impact assessments with the information the trust page and this Addendum give and, where more is needed, on reasonable notice.

7. Breach notice. RotorLab tells the Customer's administrators of a personal data breach affecting the Customer's Records without undue delay and in any case within seventy-two hours of confirming it, with what is known (the nature, the Records and people affected as far as known, the likely consequences, the measures taken and proposed), and updates the notice as more is known. The Customer's own notice duties to authorities and to people are the Customer's.

8. Deletion and return. During the term the Customer exports its Records at any time through the organization export, the audit binder and packages, and the public API. When the Customer's plan ends, Section 15 of the Terms applies: the Records are read-only with export for ninety days, so the Customer can take its copy; they are then retained with no access for twelve months; and after an alert thirty days and a final notice seven days before those twelve months end, RotorLab deletes the Customer's Records and every attached file in one step, from the database and the file stores, and records the deletion with counts in its activity log; a copy of that deletion certificate is available to the Customer on request for twelve months. What stays after the deletion holds no Record: the Customer's activity log rows with their content removed (each keeps its time, its kind, the organization's number and its hashes, so other records' chains still verify), the hashes of the Customer's records in RotorLab's daily timestamps, a marker for each code the Service issued saying only its kind and the day it was issued, RotorLab's own billing records of the Customer's account (amounts, tax, dates, invoice and payment references and the decisions on billing requests, with notes, subscription references and reasons removed) for RotorLab's accounting period, seven years unless RotorLab's accountant sets another, RotorLab's own security log for its period, a line in RotorLab's deletion journal (the organization's number, when it was created and a hash of its short name) so that a restored backup is deleted again, and RotorLab's own activity rows naming the organization by number and the deletion certificate by its number. Buying or restoring a plan before the deletion restores full access. RotorLab deletes sooner at the Customer's written instruction, never deletes a Record on legal hold while the hold stands, and never deletes automatically. Backups holding a copy expire on the schedule the trust page states and are not restored except to recover the Service, in which case the Records deleted are deleted again from the restored copy.

9. Audit. Once in any twelve months, and after a breach, the Customer may ask RotorLab in writing for the information reasonably needed to show compliance with this Addendum: the trust page, the current subprocessor list, a description of the measures in Section 4, the results of any third-party assessment RotorLab holds, and answers to a reasonable written questionnaire. An on-site audit needs thirty days' notice, a scope agreed in advance, ordinary business hours, and the Customer's cost.

10. International transfers. Records are processed and stored in the United States. Where the Customer is established in the EU, the UK or Switzerland, the parties enter into the standard contractual clauses (Module Two, controller to processor) and the UK addendum, which are incorporated by reference and available on request; this Addendum is the description of the processing they require, and Section 4 is the description of the technical and organizational measures.

11. Records of record. The Customer acknowledges that the Service is built so that a filed Record is kept: voided rather than deleted, corrected with history, amended rather than edited, and that a person on a Record is deactivated rather than deleted for as long as the Customer keeps the Record. An instruction to destroy a Record before the Customer's own retention period ends is given in writing, through the support contact, and RotorLab carries it out within thirty days and confirms it. For a flight, the Customer first voids it in the Service, and RotorLab carries out the instruction under the support access the Customer's administrator gives; the confirmation says what stays and why (the activity log rows that mention the flight, which are part of a hash chain, the timestamp that covered it, and documents already issued). A Record on legal hold is not destroyed while the hold stands.

12. Liability. The limitation of liability in the Terms applies to this Addendum, except that it does not limit either party's liability for a breach of Section 3 or Section 7 caused by its willful misconduct or gross negligence, or where the law does not allow it to be limited.

13. Term. This Addendum lasts as long as RotorLab processes the Customer's Records, including the periods after a plan ends and the deletion in Section 8.

14. Notices. Notices to RotorLab under this Addendum go in writing to RotorLab, Inc., Dubuque, Iowa, and by email to legal@rotorlab.app.

These documents have changed since you last accepted them. Read the ones that matter to you from the list, then confirm to continue to RotorLab.