Data Privacy and Compliance

PlaneConnection handles sensitive aviation data — safety reports, crew records, passenger manifests, financial transactions, and operational details — across multiple organizations on a shared platform. This page explains the privacy architecture that protects that data, the regulatory frameworks that inform design decisions, and how the platform balances privacy obligations with aviation safety record-keeping requirements.

​

Why Data Privacy Matters in Aviation

Aviation operations generate data that is simultaneously subject to multiple regulatory regimes. A single pilot’s record may involve personal data protected by GDPR (if the pilot is an EU resident) or CCPA (if a California resident), safety data required to be retained under 14 CFR Part 5 for SMS compliance, medical information subject to privacy protections, and Sensitive Security Information (SSI) governed by 49 CFR Part 1520. These overlapping obligations create tension. A data subject may request deletion of their records, but aviation regulators may require those same records to be preserved. PlaneConnection’s privacy architecture is designed to navigate this tension transparently and consistently.

​

Multi-Tenant Data Isolation

Privacy begins with isolation. Every organization on PlaneConnection operates within a dedicated workspace. Data isolation ensures that Organization A’s records are invisible to Organization B at every layer of the system.

​

How Isolation Works

PlaneConnection implements isolation through a defense-in-depth strategy spanning four layers. At the database layer, every record includes a workspace identifier and all queries filter on this value, so a query in one workspace’s context can never return another workspace’s data. At the authentication layer, user sessions are bound to a workspace, and any attempt to access data outside the authenticated workspace is rejected before a query executes. At the URL layer, every workspace-scoped route validates the workspace slug against the user’s session, providing a routing-level defense independent of the database filter. At the API layer, middleware extracts and validates the workspace context on every request before business logic runs. The reason for this layered approach is that a failure at any single layer does not expose data across organizational boundaries — each layer operates independently of the others.

​

Encryption

PlaneConnection encrypts data at two levels:

​

At Rest

All data stored in the platform’s database is encrypted at rest using AES-256 encryption managed by the infrastructure provider. File uploads (documents, attachments, images) are similarly encrypted at rest. Encryption keys are managed by the infrastructure provider and are not accessible to PlaneConnection application code.

​

In Transit

All communication between users and the platform uses TLS 1.3. This includes:

• Browser-to-server connections (HTTPS)
• API requests from integrations
• Internal service-to-service communication
• Webhook deliveries to external systems

​

Data Retention Policies

Retention policies define how long data is kept. In aviation, retention is driven by regulation as much as by business need.

​

Regulatory Retention Requirements

​

Configurable Retention

Administrators can extend retention periods beyond regulatory minimums but cannot reduce them below the required floor. The system enforces these minimums regardless of administrator configuration, preventing accidental non-compliance. When a record reaches the end of its retention period, the system flags it for review rather than deleting it automatically. An administrator must explicitly approve archival or deletion.

​

Right to Deletion

PlaneConnection supports the right to deletion under GDPR Article 17 (“right to erasure”) and CCPA section 1798.105. However, aviation regulatory requirements create legitimate exemptions.

​

How Deletion Requests Work

When a data subject requests deletion, PlaneConnection follows a structured workflow designed to balance privacy rights with regulatory obligations. The system first identifies all records associated with the data subject across all modules, then categorizes each record as either deletable or held based on regulatory retention requirements. The administrator reviews this categorization, approves the request, and executes the deletion. A deletion certificate is generated that documents what was deleted, what was retained (with the regulatory justification for each held record), and the execution timestamp. For hands-on guidance on processing deletion requests, see Manage Privacy and Data Compliance.

​

Regulatory Exemptions

Certain records cannot be deleted even when a valid deletion request is received. Safety reports that are part of an active investigation or linked to an NTSB-reportable event, training records within the 14 CFR 135.63 retention window, flight logs within their mandatory retention period, and audit trail entries that document regulatory compliance actions are all subject to regulatory holds. In these cases, the system retains the records but documents the exemption. The data subject is notified of any records that cannot be deleted and the regulatory basis for retention.

​

Privacy by Design

PlaneConnection incorporates privacy by design principles throughout the development process:

​

Data Minimization

The platform collects only data necessary for the stated purpose. For example, safety report forms collect incident details and contributing factors but do not require personally identifying information about uninvolved parties.

​

Purpose Limitation

Data collected for one purpose is not repurposed without explicit consent or regulatory authorization. Safety report data is used for safety analysis and compliance — it is not shared with marketing systems, sold to third parties, or used for employee performance evaluation (consistent with the non-punitive reporting requirements of 14 CFR 5.21).

​

Pseudonymization

Where possible, the platform separates identifying information from operational data. Safety trend analysis and SPI calculations operate on anonymized or aggregated data. Individual reporter identities are accessible only to personnel with the appropriate role (Safety Manager or Admin).

​

Access Controls

Role-based access control ensures that users see only the data their role requires. A line pilot can submit and view their own safety reports but cannot access investigation findings or other reporters’ submissions. The Permissions Matrix documents exactly which roles can access which data categories.

​

Audit Logging

Every data access and modification is logged in an immutable audit trail that captures five dimensions: who performed the action (user ID and role), what was accessed or changed (record type and ID), when the action occurred (timestamp), where the action originated (IP address and device), and why (action type: view, create, update, delete, or export). The audit trail itself is protected by retention policies and cannot be modified or deleted by workspace users. It serves dual purposes: regulatory compliance evidence (14 CFR Part 5 Subpart F) and privacy accountability (GDPR Article 30).

​

Handling PII Across Modules

Personal Identifiable Information (PII) exists in different forms across PlaneConnection’s modules:

​

Sensitive Security Information (SSI)

Some data within PlaneConnection may qualify as Sensitive Security Information under 49 CFR Part 1520. SSI includes security programs, vulnerability assessments, and certain threat information. PlaneConnection handles potential SSI by restricting access to SSI-designated records to users with explicit SSI access authorization, preventing SSI-flagged records from appearing in bulk data exports unless the exporting user has SSI clearance, logging all access to SSI-designated records with enhanced audit detail, and excluding SSI from AI analysis pipelines.

​

Summary

PlaneConnection’s privacy architecture balances three competing demands: user privacy rights, aviation regulatory retention requirements, and operational data needs. The platform achieves this through workspace isolation, encryption at every layer, configurable retention with regulatory floors, transparent deletion workflows, and comprehensive audit logging. Every privacy action is documented, and every regulatory exemption is justified and traceable.

​

Related