PII & Encryption

What personal information BindPilot stores, what it encrypts, and what it does not

PII & Encryption

This page describes how BindPilot handles personally identifiable information (PII). It is written to match what the software actually does today, not what it is planned to do.

Current state, in one paragraph

BindPilot does not collect or store Social Security numbers, tax IDs, bank account numbers, or routing numbers — there is no field for them anywhere in the platform, so there is nothing to encrypt. The two pieces of personal data it does store on a client record are date of birth and, for auto policies, driver's licence number; both are stored as ordinary database values, protected by the managed database provider's encryption at rest and by application-level access control, not by field-level encryption. Field-level encryption is applied today to carrier and integration credentials — the API keys and appointment credentials an agency connects — which are the highest-value secrets the platform holds.

If you need field-level encryption of client PII as a condition of using BindPilot, say so before you onboard; it is a supported direction, not a shipped feature.

What Is PII?

Personally Identifiable Information includes:

  • Social Security Number (SSN)
  • Date of Birth (DOB)
  • Driver License Number
  • Bank Account Numbers
  • Medical Records
  • Immigration Status / Visa Info

Storing PII in insurance systems requires careful handling per state regulations.

Encryption Standards

Where BindPilot applies field-level encryption, it uses Fernet from the Python cryptography library:

  • Algorithm: AES-128 in CBC mode, with HMAC-SHA256 for authentication
  • Key material: a 256-bit key, split by Fernet into a 128-bit encryption key and a 128-bit signing key
  • Guarantees: confidentiality plus tamper detection — a modified ciphertext fails to decrypt rather than decrypting to garbage
  • Key rotation: no rotation has been performed yet; the procedure is being written

Fernet is not AES-256, and it is not AES-GCM. If a security questionnaire asks for the cipher, those are the accurate answers.

In Transit (TLS 1.3)

All data sent between your browser/app and BindPilot servers:

  • Encrypted: TLS 1.3 (Transport Layer Security)
  • Certificate: Valid SSL/TLS certificate (verified by browser)
  • Transport security: TLS 1.3 on all connections

You know it's secure when you see:

  • URL starts with https:// (not http://)
  • Lock icon in browser address bar
  • No browser security warnings

At Rest (Database Encryption)

Two different protections, and it matters which one covers what:

  • Volume-level encryption at rest — provided by the managed Postgres provider, and it covers everything in the database, including client records.
  • Field-level encryption (Fernet) — applied by BindPilot itself, and it covers carrier connection credentials and third-party integration secrets only. The encryption key lives in the application environment rather than the database, so those values are not readable from a database dump alone.

Client PII — date of birth, driver's licence number — is covered by the first and not the second. A database dump would show those values.

Sensitive Field Handling

SSN (Social Security Number)

Storage: not stored. BindPilot has no SSN field. There is no column for it on any record, so no SSN is written to the database, appears in an export, or reaches a carrier through this platform.

Two related protections do exist, because an SSN can still arrive as free text in a note or a chat message:

  • Application logs are scrubbed of SSN, EIN and date-of-birth patterns before anything is written.
  • Text sent to an AI model is passed through a redactor first, so a pasted SSN does not leave the platform in a prompt.

Licence details are validated for format; the NIPR lookup is built but not yet activated, and falls back to self-attestation.

State Regulations:

  • Some states prohibit SSN collection (ask first)
  • Vermont, Massachusetts, Nevada have strict SSN rules
  • BindPilot respects state-specific restrictions

DOB (Date of Birth)

Storage: stored as a plain date on the client record — covered by the database's encryption at rest, not by field-level encryption Display: shown in the UI (medium sensitivity) Use: age-based risk assessment, rating

Driver License

Storage: stored as a plain value inside the client's driver list — covered by the database's encryption at rest, not by field-level encryption Display: shown to users with access to the client record Use: auto underwriting, identity verification

This is the one item on the PII list above that BindPilot both stores and does not encrypt at the field level. It is stated plainly here so that nobody has to infer it.

Bank Account & Routing Number

Storage: not stored. BindPilot has no field for either, and no endpoint accepts one. Your agency's own subscription is billed through Stripe, which holds that payment instrument on its own systems. The client portal's payment endpoint records an amount and a policy — it never takes a card or account number. Carrier premium collection is handled by the carrier.

Medical Records

Storage: not a structured field. Medical records can arrive as a claim document attachment (medical_records is one of the claim document types). Encryption: attachments are not encrypted by BindPilot at the file level. They are covered by transport encryption in flight and by the storage provider's encryption at rest. Retention: governed by your agency's retention settings, not by an automatic one-year delete.

CCPA & State Privacy Laws

BindPilot complies with state-by-state PII rules:

| State | Rule | BindPilot Compliance | |-------|------|----------------------| | California (CCPA) | Can't sell SSN, DOB | We don't sell any data | | Massachusetts 201 CMR 17.00 | SSN special handling | No SSN is collected or stored | | Vermont | Can't require SSN | We request only if needed | | Nevada | Can't use SSN for ID | We verify via other means | | New York | Notification if breach | 72 hours to DFS (23 NYCRR 500.17) |

Encryption in Backups

Backups are taken and encrypted at rest by the managed Postgres provider, not by BindPilot. Retention window, regional redundancy and restore access therefore follow that provider's plan settings rather than a BindPilot-specific policy — ask us for the current configuration if your compliance programme needs the exact numbers.

If you request a data export, it is delivered over TLS in a standard format. There is no separately-keyed encrypted archive option today.

Key Management

The field-encryption key protects carrier and integration credentials.

| Protection | Details | |-----------|---------| | Separation | The key lives in the application environment, not in the database | | Rotation | No rotation performed yet; procedure being written pre-launch | | Disaster Recovery | Losing the key makes the encrypted credentials unrecoverable — they would have to be re-entered | | HSM | Hardware Security Module — planned for SOC 2, not in place |

Who Can See What

Client records (including date of birth and driver's licence number) are protected by access control, not by encryption:

  • You and your team members, according to your roles
  • BindPilot's own systems, in the course of serving your requests
  • Anyone holding a database dump would see these values

Carrier and integration credentials are protected by both:

  • Decrypted only by the application, using a key held outside the database
  • A database dump alone does not reveal them

In case of a breach, treat client PII in this platform as readable to an attacker who reaches the database, and treat connected carrier credentials as protected unless the application environment was compromised too. That distinction is the honest one, and it is the one to plan your incident response around.

Checking Encryption in Your Browser

See TLS certificate details:

  1. Go to BindPilot in your browser
  2. Click the lock icon in address bar
  3. Click "Certificate" or "Details"
  4. You'll see:
    • Issued to: BindPilot
    • Issued by: Certificate Authority (Cloudflare, DigiCert, etc.)
    • Valid from/to: Expiration date
    • Cipher: TLS_AES_256_GCM_SHA384 (or similar)

This verifies secure encryption is active.

Best Practices When Using BindPilot

  1. Use HTTPS — Always; never use HTTP
  2. Lock your device — Don't leave BindPilot open unattended
  3. Strong password — at least 8 characters (the enforced minimum), unique to BindPilot. Longer is better
  4. Don't screenshot SSN — Avoid storing sensitive data locally
  5. Log out when done — Automatic after 1 hour
  6. Report issues — Email compliance@bindpilot.ai if something feels off

Next: Backup & Recovery and State Insurance Regulations.

Last updated: Recently