Security Whitepaper
Last updated: May 2026
This document describes the engineering controls and operational practices GA Flight uses to protect partner and operator data. It is written for technical reviewers conducting partner due diligence. Claims here reflect what is implemented and verifiable — not aspirational roadmap items or certifications GA Flight does not hold.
Identity and Access Control
Operators authenticate via short-lived JWTs; partner integrations use scoped, hashed API keys with per-key revocation.
Operator sessions are issued as short-lived JSON Web Tokens (JWTs) signed with a server-held key. Token expiry is enforced server-side; refresh tokens are rotated on use and invalidated on logout. Partner API keys follow a prefix-plus-hash scheme: the raw key (prefixed gaf_pk_) is shown exactly once at creation time; only a SHA-256 hash is stored in the database. Each key carries a declared scope list (e.g. public.flights:read, public.training:read) enforced on every request. Keys can be revoked individually without affecting other keys in the same organization. Multi-factor authentication (MFA) is available for all operator accounts. Single Sign-On via OpenID Connect (OIDC) and SAML 2.0 is supported for organizations that manage identity through an external provider. Role-Based Access Control (RBAC) governs which operators may act on which resources within an organization. All credential-issuing actions are written to the audit log.
Transport Security
All traffic is encrypted in transit with TLS 1.2 or higher; webhook payloads are signed with HMAC-SHA256 so receivers can verify authenticity before processing.
The GA Flight API and web properties enforce TLS 1.2 as the minimum protocol version. TLS 1.3 is preferred and negotiated when the client supports it. HTTP Strict Transport Security (HSTS) is sent on all responses; there is no plaintext HTTP fallback for authenticated surfaces. Outbound webhook deliveries are signed using HMAC-SHA256 computed over the raw request body. The signing secret (prefixed whsec_) is generated at endpoint creation and shared once. Every delivery carries three headers: X-GA-Webhook-Delivery (unique UUID), X-GA-Webhook-Timestamp (ISO 8601 timestamp), and X-GA-Webhook-Signature (sha256=<hex digest>). Receivers should verify the signature before trusting the payload and reject deliveries where the timestamp is more than five minutes old. Failed deliveries are retried up to five times with exponential backoff.
Data Residency
Customer data for EU-based organizations is stored in EU-hosted infrastructure; per-request residency policy enforcement prevents cross-region data writes.
GA Flight enforces data residency at the application layer via a policy evaluated on every write request. The enforceDataResidencyPolicy middleware validates that the target data region for a given organization matches the allowed set for that customer's residency configuration before any database write proceeds. EU-based customers are routed to EU-hosted database nodes. Primary storage is hosted in France (a European Union member state). No operational data for EU organizations is written to non-EU storage by default. This implementation is in production and verifiable by reviewing request handling. It has not yet been audited or certified by an independent third party. GA Flight does not claim ISO 27001, SOC 2, or any other framework certification at this time. The residency controls described here are engineering measures, not compliance certifications.
Audit Logging
Every significant operator action is written to a per-organization audit log; training signoff records form a cryptographically chained sequence for chain-of-custody integrity.
GA Flight maintains an audit_log table scoped per organization. Every credential-issuing action, access-control change, data export, and administrative operation is recorded with the acting user identity, timestamp, affected resource, and action type. Logs are append-only from the application layer. Training program signoff records are organized into an audit_chain structure. Each signoff record references the hash of the previous record in the chain, creating a tamper-evident sequence. This chain-of-custody design means that inserting or altering a historical signoff record would break the chain at the point of modification, making tampering detectable without requiring a central audit authority. Audit log entries are accessible to organization administrators inside the GA Flight console. Bulk export is available for compliance reviews. The cryptographic chain covers training signoffs specifically; general audit log entries use database-level append controls.
Rate Limiting
The public API applies 13 named rate-limit buckets with per-organization and per-tenant ceilings, providing baseline denial-of-service resistance by default.
GA Flight's public API applies rate limiting through a layered bucket system. Thirteen named buckets cover distinct resource families — for example, flight reads, training record queries, webhook replay, and authentication endpoints each have independent counters. This prevents a high-volume consumer of one resource type from exhausting limits on unrelated endpoints. Ceilings are enforced at two levels: per API key (limiting a single partner integration) and per organization (capping the aggregate load any single organization can generate regardless of how many keys it issues). Responses include standard rate-limit headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset) so integrators can implement client-side backoff without guessing. Rate limit counters are stored in a low-latency data store so enforcement adds minimal overhead to request processing. Burst allowances are granted for short traffic spikes within defined bounds.
GDPR Posture
GA Flight honors data subject rights including export and deletion, makes a Data Processing Agreement available on request, uses EU-primary storage, and does not embed analytics beacons by default.
GA Flight acts as a data processor on behalf of operator organizations (the data controllers) for operational data, and as a data controller for its own platform account data. A Data Processing Agreement (DPA) is available to all paying organizations on request at security@gaflight.io. Data subject rights are honored: any data subject may request a full export of their personal data or request deletion. Deletion requests are processed within 30 days and cascade through all associated records subject to retention obligations. Operators can initiate export and deletion workflows via the console or by contacting support. GA Flight's marketing site does not embed third-party analytics beacons by default. First-party analytics use only session-scoped, cookieless measurement. Primary data storage is EU-hosted (France). For sub-processor details and international transfer safeguards, see the Sub-Processors section of this document and the Privacy Policy.
Sub-Processors
GA Flight uses a small, auditable list of third-party processors. Operators may request the current list via DPA.
The following third-party sub-processors handle personal data on behalf of GA Flight: Stripe, Inc. — payment processing and billing. Stripe processes payment card data under its own PCI DSS compliance program. GA Flight does not store raw card numbers. [Operator to confirm before publishing: email delivery provider — confirm provider name, data location, and DPA status before making this document public.] [Operator to confirm before publishing: file and document storage provider — confirm provider name, data location, and DPA status before making this document public.] Sentry (Functional Software, Inc.) — error monitoring and crash reporting. Error payloads may include stack traces and request metadata; personally identifiable data is scrubbed where possible via Sentry's data scrubbing rules. GA Flight reviews sub-processor agreements annually and notifies customers of material changes to this list with at least 30 days notice, as required under the DPA terms.
Incident Response
GA Flight commits to notifying affected customers within 24 hours of a confirmed material security incident and to publishing a post-incident review.
GA Flight maintains an internal incident response procedure covering detection, containment, eradication, and recovery phases. On-call responsibilities are assigned to named engineers with defined escalation paths. For incidents classified as material — those involving unauthorized access to personal data, significant service disruption, or compromise of signing keys — GA Flight commits to notifying affected operator organizations within 24 hours of confirmation. Notification is delivered via the organization's registered administrator email address and, where applicable, in-console alert. Following resolution of a material incident, GA Flight publishes a post-incident review covering the timeline, root cause, impact scope, and remediation steps taken. This review is shared with affected customers and retained for future reference. GA Flight does not guarantee zero-incident operations. The commitment here is to transparent, timely communication and documented remediation when incidents occur.
Vulnerability Disclosure
GA Flight accepts vulnerability reports at security@gaflight.io under a 90-day coordinated disclosure window. Valid reports receive public acknowledgment.
Security researchers who identify a vulnerability in GA Flight's platform are invited to report it to security@gaflight.io. GA Flight follows a coordinated disclosure model: reporters are asked to keep findings confidential for up to 90 days from the date of first contact, giving GA Flight time to investigate, develop a fix, and deploy a remediation before details are made public. GA Flight commits to: acknowledging receipt of a report within five business days; providing a status update within 14 days; and coordinating the public disclosure timeline with the reporter where possible. GA Flight does not currently operate a paid bug bounty program. Valid reports that result in a confirmed security fix are acknowledged publicly in the relevant changelog or security advisory, with the reporter's name or handle included unless anonymity is requested. Scope includes the GA Flight web application, public API, and webhook delivery infrastructure. Out of scope: social engineering, physical access, and third-party services (report those directly to the relevant vendor).
Questions about this document or security practices: security@gaflight.io
Privacy Policy →