Data Safety & Encryption

technical explainer · v1.0

Plain-English technical explainer. Reading this is optional. The Privacy & Data Policy is the binding legal document. This page explains how the encryption works for clients who want to understand.

The short version

Every client's data is encrypted with a key derived uniquely from their account. Even if our server's disk were copied, the data would be unreadable without each client's specific key derivation. We never store passwords (only Argon2id hashes). The master encryption salt is stored in AWS KMS, separate from the data.

In practical terms: ✓ Your data is unreadable on disk without active server runtime + AWS KMS access. No human at our company can read your data by browsing files.

How encryption works in the Stack

Layer 1: Per-client key derivation
Every client has a unique UUID assigned at account creation. We derive their encryption key using HKDF-SHA256 with:

A master salt (stored in AWS KMS, never in our database or file system)
The client's UUID (the "info" parameter)
A versioned context string ("skool-twin-v1")

Result: each client has a 256-bit AES key that exists only in server memory during their session.

Layer 2: File-level encryption
Every file containing client data is encrypted with AES-256-GCM (authenticated encryption). This means:

Files cannot be read without the client's key
Files cannot be modified without detection (GCM authentication)
Each file has its own random initialization vector (IV)

Files use a versioned magic header (STV1) so we can rotate the encryption scheme in the future without breaking existing data.

Layer 3: Backup encryption
Daily backups are uploaded to AWS S3 with SSE-KMS (server-side encryption with AWS KMS keys). Even if the S3 bucket were compromised, the contents would be unreadable without KMS access. Backups are retained for 90 days then automatically destroyed.

Layer 4: Password hashing
We never store your password. When you set a password, we run it through Argon2id (the modern standard recommended by OWASP) and store only the resulting hash. When you log in, we hash what you type and compare hashes. The plaintext password never touches our database.

Layer 5: Authentication

Magic links are random 32-byte tokens, hashed before storage, single-use, expire in 24 hours
Session tokens are random 64-byte tokens, HTTPS-only cookies, 30-day TTL, can be revoked by admin instantly
All traffic uses HTTPS with TLS 1.3 enforced by Caddy reverse proxy

What happens when you delete your account

When you request deletion (or withdraw consent), the following happens:

Your client registry record is marked as deleted
Your encrypted data files are removed from active storage
Your sessions are immediately invalidated
Backups containing your data are retained for 90 days for legal/regulatory protection, then permanently destroyed (S3 lifecycle rule)
Audit logs (signin events, consent records) are retained for 7 years for legal trail purposes

What we can and cannot see

We can see:

Your email address and account metadata (registered date, last sign-in, admin role flag)
Your biological sex setting
Operational logs (signin events, error logs, cost-per-event accounting)
Aggregate usage statistics (number of audits per cycle, etc.)

We cannot see (without active runtime + KMS access):

The contents of your audit photos, audit synthesis, or per-photo readings
Your genetic upload contents or structured findings
Your bloodwork values
Your Twin notes
Your Resilience Profile Reports
Your Manny AI Coach conversations
Your password (we only have a hash)

What goes to third-party AI providers

When your data is processed by AI (Claude for synthesis, OpenAI for embeddings), the relevant content is sent through their API. Anthropic and OpenAI both commit publicly that customer API data is NOT used to train their models. The data sent includes only what's needed to generate your specific output.

Example: when you generate a Resilience Profile Report, your structured genetics + bloodwork + audit + notes are sent to Claude as the user message. Your other data is not sent.

Known limitations (full transparency)

No system is perfect. Here are honest limitations:

While data is encrypted at rest, it must be decrypted in server memory to be processed. Memory contents are not encrypted (this is true of every web application that does anything with user data).
Third-party AI providers see the relevant content when you generate reports or chat with the Coach. We trust their commitments but cannot enforce them ourselves.
If you screenshot or copy your reports outside the Stack, those copies are not protected by our encryption.
The Stack is operated by a small team. We do not have a 24/7 security operations center. We monitor for issues but cannot guarantee zero downtime or zero incidents.

Security incident response

If a security incident affecting client data is detected, we commit to:

Notify affected clients within 72 hours of confirmation (the GDPR standard)
Disclose what data was affected, how, and what remediation has been taken
Provide guidance on what affected clients should do (e.g., rotate credentials)

Contact

Security questions or concerns: support@theresilienceadvantage.com