> ## 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.
# SmartScore Data Privacy and Trust
> How SmartScore protects operator data through a physical firewall, encryption, consent controls, digital signatures, and PBC governance -- ensuring safety data is never shared with insurers.
SmartScore handles a fundamental tension: operators need to share
operational data with insurers to demonstrate safety, but they must
never share voluntary safety reports -- the backbone of just culture --
with anyone outside the organization. This page explains the technical
and governance architecture that resolves this tension.
**Who should read this:** Accountable executives, safety managers, IT administrators, legal
counsel, and anyone responsible for data governance. For the hands-on consent management workflow,
see [Generate and Share Your SmartScore](/en/how-to/sms/generate-smartscore).
## PBC Structure and Data Governance
PlaneConnection is incorporated as a **Delaware Public Benefit
Corporation (PBC)**. Unlike a standard C-corp, a PBC has a legally
binding obligation to balance shareholder interests with its stated
public benefit -- in this case, improving aviation safety.
For data governance, the PBC structure means:
* **Data stewardship is a fiduciary duty**, not a policy choice that
can be reversed by new management
* Annual benefit reports must disclose safety outcomes, equity metrics,
and data governance transparency
* Price governance in the PBC charter caps score pricing at cost with
an annual adjustment limit and a permanent free tier
* The scoring product operates through a separate PBC subsidiary to
isolate scoring-related liability from the platform
## The Data Firewall
The core privacy mechanism is a **physical separation** between two
categories of data, enforced at the database level.
### Zone A: Operational Metrics (Score-Eligible)
Zone A contains objective, operational facts -- the same information an
operator would disclose on an insurance application:
| Data Category | Examples |
| ---------------------- | ----------------------------------------------------- |
| Fleet composition | Aircraft count, types, age, hull values |
| Flight activity | Total hours, legs per month, route complexity |
| Maintenance compliance | Overdue items, AD compliance rate, MEL usage |
| Crew qualifications | ATP percentage, average hours, currency rates |
| Training completion | Recurrent training rates, simulator hours, pass rates |
| Dispatch quality | Weather briefing rate, flight following coverage |
| Duty/rest compliance | Duty time adherence, rest compliance rate |
| Certifications | IS-BAO stage, ARGUS rating, certificate status |
| Organizational info | Years in operation, employee count, fleet size |
### Zone B: Voluntary Safety Data (Never Shared)
Zone B contains safety reports and related data that must be protected
to preserve just culture:
| Data Category | Why It Is Firewalled |
| -------------------- | --------------------------------------------------- |
| Hazard reports | Reporters must never fear premium consequences |
| Investigations | Detailed findings could be used against operators |
| Corrective actions | Specifics reveal vulnerabilities |
| Near-miss details | The most valuable safety data is the most sensitive |
| NTSB notifications | Legal exposure |
| Confidential reports | Identity protection |
| Risk assessments | Internal risk analysis |
### How the Firewall Works
The firewall is **code, not policy** — it is enforced at the
infrastructure level, not through access control lists or manual
processes. The scoring engine physically cannot access Zone B data,
and automated tests continuously verify this separation. The engine
returns only aggregate metrics (counts, rates, percentages), never
individual records.
Zone B data is absent from development and staging environments entirely. Only synthetic data is
used for testing. This eliminates the risk of safety reports being exposed through non-production
systems.
## Encryption
### Zone B Application-Layer Encryption
Beyond database-level encryption at rest, Zone B data receives an
additional layer of **application-layer encryption** on content fields
before they are written to the database. Each record is encrypted with
a unique key, and Zone B encryption keys are entirely distinct from
Zone A — compromise of one does not expose the other.
### Transport Encryption
All data in transit uses TLS 1.3. The insurer API additionally requires
mutual TLS (mTLS), meaning both PlaneConnection and the insurer
authenticate each other's identity at the transport layer.
## Consent Framework
SmartScore uses a **per-insurer, per-purpose, opt-in** consent model
with four independent consent grants:
| Consent Purpose | Default | Required For |
| ---------------------------------- | ----------------- | ------------------------------ |
| Score calculation | OFF | Seeing your own score |
| Score sharing with a named insurer | OFF (per insurer) | Insurer receiving your score |
| Anonymized benchmarking | OFF | Peer group comparisons |
| Algorithm improvement | OFF | Contributing to model accuracy |
Each consent is independently toggleable. Granting score calculation
does not enable sharing. Sharing with Insurer A does not enable sharing
with Insurer B.
### Triple-Consent Flow
Sharing a score with an insurer requires three distinct steps:
1. **Education** -- an informational page explaining what will be
shared, with no consent requested
2. **Authorization** -- selecting a named insurer, choosing a sharing
tier and duration, and reviewing the disclosure
3. **Confirmation** -- reviewing a transmission summary and completing
the duty-to-disclose attestation
All sharing toggles start in the OFF position. "Share" and "Don't
Share" buttons have equal visual weight. No confirmshaming, urgency
language, or dark patterns. The entire consent flow meets WCAG 2.1 AA
accessibility requirements.
### Immutable Consent Ledger
Every consent event is stored in an append-only, hash-chained ledger
following ISO 27560 and Kantara consent receipt specifications:
* Event type (granted, modified, revoked, expired)
* Timestamp, authenticated user, disclosure version and hash
* Purposes, named recipients, scope, and duration
* Record hash linked to previous hash (chain integrity)
* 7-year retention after consent expiry or revocation
## Duty-to-Disclose Attestation
Before sharing a score, operators must attest that they have
independently satisfied their duty to disclose all material facts to
their insurer. This attestation includes a mandatory checklist:
* Disclosed all known safety issues
* Disclosed any pending FAA enforcement actions
* Disclosed any incidents/accidents in the current policy period
* Understood that the score reflects operational metrics only
This protects both the operator and PlaneConnection by making clear
that SmartScore supplements -- but does not replace -- the duty of
utmost good faith in insurance.
## Digital Signatures and Tamper-Proofing
SmartScore reports are protected by three complementary mechanisms:
| Mechanism | What It Protects | How to Verify |
| ------------------------------ | ---------------- | ---------------------------------------------------- |
| **PAdES digital signature** | PDF reports | Open in Adobe Reader; signature panel shows validity |
| **JWS signature** | API responses | Verify with PlaneConnection's published public key |
| **Online verification portal** | Any report | Scan the QR code or visit the verification URL |
PDF reports use an Adobe AATL-trusted signing certificate (DigiCert or
GlobalSign) with an RFC 3161 timestamp from a trusted timestamp
authority. Any modification to the PDF after signing invalidates the
signature.
## Score Verification Portal
Insurers can independently verify any SmartScore report's authenticity
by scanning the QR code on the PDF or visiting the verification URL.
The portal confirms:
* Whether the report is authentic (valid, tampered, or expired)
* The generation timestamp
* The current score (if the operator has an active consent grant for
that insurer)
## FCRA Positioning
SmartScore is structured to avoid classification as a consumer
reporting agency under the Fair Credit Reporting Act:
* **Operator-initiated sharing** -- the operator decides whether and
when to share; PlaneConnection does not furnish reports to insurers
independently
* **No direct insurer query access** (Phase 1) -- insurers cannot
query the system for scores without operator initiation
* **Organizational-level scoring** -- scores assess fleet/organizational
risk, not individual consumer creditworthiness
* **First-party data only** -- scores are generated from data the
operator inputs into the platform
## What Happens When You Revoke Consent
Revocation is designed to be as easy as granting -- one click plus one
confirmation:
1. The insurer's access is terminated immediately
2. A webhook notification is sent to the insurer
3. The revocation is logged in the immutable consent ledger
4. The insurer must delete score data within 30 days and certify
destruction
5. Scores already used for underwriting decisions are flagged as
"consent revoked" but may be retained by the insurer for regulatory
purposes
## Data Retention and Deletion
| Data Type | Retention Period | Basis |
| ---------------------------------- | ---------------------------------------------- | ------------------------ |
| Zone A operational metrics | Duration of platform use + 5 years | 14 CFR 5.97 |
| Zone B safety data | Configurable (minimum 5 years per 14 CFR 5.97) | Regulatory floor |
| Score history | 7 years | Audit trail requirements |
| Consent ledger | 7 years after consent expiry/revocation | ISO 27560 |
| Shared score copies (insurer-held) | 24 months maximum | Data license agreement |
Operators can export all their data in standard formats (JSON/CSV) at
any time with no fees. On account closure, Zone B data is purged after
the regulatory retention period expires. Zone A aggregate statistics may
be retained in anonymized form for benchmarking (only if the operator
consented to anonymized benchmarking).
## Related
Overview of the two-score architecture and design principles.
Step-by-step guide to the consent and sharing workflow.
Platform-wide privacy architecture beyond SmartScore.
Common questions about privacy, data sharing, and compliance.