> ## Documentation Index
> Fetch the complete documentation index at: https://docs.planeconnection.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Data Privacy and Compliance
> How PlaneConnection protects personal data through multi-tenant isolation, encryption, retention policies, right-to-deletion support, and privacy by design.
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.
**Who should read this:** Administrators, accountable executives, safety managers, and anyone
responsible for data governance within their organization. For hands-on privacy management tasks,
see the [Manage Privacy and Data Compliance](/en/how-to/admin/manage-privacy) how-to guide.
## 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.
For a deeper technical discussion of multi-tenant isolation, see the [Multi-Tenancy and Data
Isolation](/en/explanation/multi-tenancy) explanation page.
## 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
PlaneConnection does not support unencrypted HTTP connections. All HTTP requests are
automatically redirected to HTTPS. API clients that attempt plaintext connections receive a 301
redirect to the HTTPS endpoint.
## 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
| Data Category | Minimum Retention | Regulatory Basis |
| ---------------------------------------- | ---------------------------------------- | ------------------------- |
| Safety reports, investigations, and CPAs | 5 years | 14 CFR 5.97 (SMS records) |
| Risk assessments and safety controls | Duration of control relevance + 3 years | AC 120-92D guidance |
| Training records | 24 months after employee departure | 14 CFR 135.63(a)(5) |
| Flight logs | 24 months | 14 CFR 135.63(a)(4) |
| Passenger manifests | 24 months | 14 CFR 135.63(c) |
| Crew duty and rest records | 90 days minimum | 14 CFR 135.63(a)(2) |
| NTSB-reportable event records | Indefinite (until investigation closure) | 49 CFR Part 830 |
| Audit trail entries | 7 years | Industry best practice |
### 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](/en/how-to/admin/manage-privacy).
### 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.
Deleting safety data prematurely can create compliance gaps. If the FAA requests SMS records
during an inspection and those records have been deleted outside the retention window, it may
constitute a violation of 14 CFR 5.97. The system's retention floor prevents this scenario.
## 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](/en/reference/permissions) 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:
| Module | PII Types | Handling |
| -------------------- | ------------------------------------------------------- | ------------------------------------------------------------------------------------ |
| **Safety** | Reporter name, email, contact info | Protected by confidentiality settings. Anonymized in trend analysis. |
| **Ops** | Crew names, certificates, medical status, contact info | Restricted to roles with crew management permissions. |
| **Ops (Passengers)** | Passenger names, contact info, travel documents | Accessible only to dispatchers and admins. Deleted per retention policy. |
| **FBO** | Customer names, contact info, payment data | Payment data tokenized through payment processor. PII subject to standard retention. |
| **Training** | Trainee names, performance records, certificate details | Restricted to training administrators and the individual trainee. |
## 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.
The determination of whether specific data constitutes SSI is the responsibility of the
certificate holder, not the platform. Contact your organization's security coordinator or the TSA
for SSI classification guidance.
## 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
Handle deletion requests, configure retention, and manage consent.
Technical details of workspace isolation architecture.
Data portability and export capabilities.
Role-based access controls across all modules.