Security

• Compute. AWS Lambda functions in the us-east-2 region behind Amazon API Gateway with WAF.
• Database. Managed PostgreSQL on Supabase. Tenant isolation is enforced through a tenant identifier (company-scoped row-level security) on business-data tables, and additional membership checks in middleware on every API request.
• Object storage. Amazon S3 buckets with public access blocked at the bucket policy, server-side encryption (AWS KMS), and versioning on the primary user-files bucket. Audit and CloudTrail buckets use S3 Object Lock in COMPLIANCE mode.
• Frontend. Next.js application hosted on Vercel's global edge network with TLS termination at the edge.
• Secrets. AWS Secrets Manager with envelope encryption by AWS KMS. Application secrets are never stored in source code, build artifacts, or environment files in the repo.
• Environment isolation. Separate AWS accounts / stacks and separate Supabase projects for development and production.

• In transit: TLS 1.2 or higher for every external connection, including API requests, the dashboard, and traffic to all subprocessors.
• At rest:
  • S3 — server-side encryption with AWS KMS (alias/aws/s3).
  • Database — encryption at rest by the managed database provider.
  • CloudTrail logs and audit-archive buckets — encrypted plus Object Lock retention.
• Application-layer encryption: Sensitive OAuth tokens (such as QuickBooks Online access and refresh tokens) are encrypted with AES-256-GCM before insertion into the database, using a master key held in AWS Secrets Manager.
• Cookies: Authentication cookies are HttpOnly, Secure, SameSite=Strict. CSRF protection uses the standard double-submit cookie pattern over an additional Secure, SameSite=Strict cookie.

• User identity. Amazon Cognito user pools manage authentication. Password policy: minimum 12 characters, mixed case, numbers, symbols, with password-history checks.
• Breached-password checks. Both client- and server-side checks against the Have I Been Pwned k-anonymity range API at signup and password change; only a 5-character SHA-1 prefix is sent over the network.
• Multi-factor authentication. MFA is required on every account. Supported factors: email OTP (default), SMS OTP (with verified phone), and TOTP authenticator apps. Account recovery requires identity verification through our support team.
• Federated identity. Optional Google OAuth and Microsoft Entra ID OIDC sign-in.
• CSRF. Double-submit cookie pattern enforced on state-changing endpoints, using a constant-time comparison.
• Tenant authorization. Every authenticated request is checked against the user's company memberships and role permissions; permission catalog is data-driven and audited.
• Personnel access. Production access is limited to authorized personnel, requires MFA on AWS and on every other administrative system, and is logged.

• Application audit log. The audit_logs table is INSERT-only at the database layer and captures security-relevant events (logins, MFA challenges, permission changes, sensitive-record reads, administrative actions, financial events, exports). Each row snapshots the actor's identity and role at the time of the event so that subsequent role changes do not rewrite history.
• Domain audit logs. Scheduling and Knowledge Base have additional domain-specific audit tables.
• AWS CloudTrail. Multi-region trail with Object Lock COMPLIANCE retention. EventBridge rule alerts on CloudTrail tampering attempts (DeleteTrail, StopLogging, UpdateTrail).
• Telemetry. Error and performance telemetry through Sentry. Customer-visible inputs are masked in session telemetry; full payment card data is never logged.
• Alerts. CloudWatch alarms on Lambda errors and on audit-write failures route to a Security SNS topic.

Training records governed by 14 CFR Part 141 retention rules are sealed (immutable) at the database level after instructor or chief-instructor sign-off. This applies to lesson reports, stage checks, endorsements, graduation certificates, and student record archives. Sealed records cannot be updated or deleted through the application or by support personnel except as required by law.

• Database. Daily automated backups managed by Supabase under their plan's backup schedule. Production runs in multi-AZ configuration.
• Object storage. S3 versioning enabled on the primary user-files bucket. Cross-region replication and AWS Backup are on our roadmap.
• Configuration as code. Infrastructure is described in CloudFormation / SAM and source code is in version control with full history.
• Restore practice. We rehearse restore from backup as part of major release readiness.

• Subprocessors are reviewed for security and data-protection posture before engagement.
• A current list of subprocessors with location and purpose is published at hangaros.com/legal/subprocessors.
• Customers may subscribe to subprocessor change notifications and may object on data-protection grounds within 14 days of notice.

• Cardholder data is collected through hosted fields served by the third-party Payment Processor we engage (as defined in Section 1.7 of the Terms of Service and identified on the Subprocessor List). The card number never reaches HangarOS servers or logs.
• HangarOS retains only payment metadata (card brand, last four digits, billing address, transaction identifiers).
• Subscription billing will be fully PCI-tokenized through the Payment Processor's hosted fields; HangarOS qualifies for SAQ A.

• Patching. Dependencies and runtimes are kept up to date. We track security advisories for AWS services, Supabase, Next.js, and other key vendors.
• Code review. All production changes go through code review and CI checks.
• Coordinated disclosure. Researchers may report vulnerabilities to security@hangaros.com. Please:
  • Provide enough detail to reproduce.
  • Give us a reasonable opportunity to remediate before public disclosure.
  • Avoid privacy violations, destruction of data, or service degradation.
  • In good-faith research consistent with this section, we will not pursue legal action.

• We maintain an internal incident response plan with documented roles, escalation paths, and decision criteria.
• Personal Data Breach notification to affected customers is committed at no later than 72 hours from confirmation, as set out in our Data Processing Agreement.
• Post-incident, we conduct a written review and update controls.

• We design controls toward SOC 2 (Trust Services Criteria CC1–CC9). A formal SOC 2 Type II report is on our roadmap.
• Underlying infrastructure providers maintain external attestations (for example, AWS SOC 2 Type II and ISO 27001).
• We are not a HIPAA covered entity. The Service is not designed for the storage of full medical records and is not subject to HIPAA Business Associate obligations.

Security is a shared responsibility. Customers are responsible for:

• protecting their account credentials and enabling MFA;
• configuring role and permission settings consistent with least privilege within their flight school;
• promptly deprovisioning Users who leave the school;
• providing required notices and consents to their own Users and data subjects;
• not uploading data beyond what is necessary for school operations (especially full medical records, payment card data, or other unnecessary sensitive data); and
• maintaining independent backups of data critical to their operations.

• Security reports / vulnerability disclosure: security@hangaros.com
• Privacy questions: privacy@hangaros.com
• General legal: legal@hangaros.com

OrangeTree Technologies LLC d/b/a HangarOS
4801 Glenwood Ave, Suite 200, Mailbox 31
Raleigh, NC 27612, United States

Last updated: May 22, 2026.