How We Keep Your Data Safe

How We Keep Your Data Safe

When you trust us with your evidence, we take that seriously. The data you collect through Proof is often sensitive—personal disputes, employment issues, financial matters. It needs to be protected at every stage.

Here's exactly how we do it.

Encryption in Transit: TLS All the Way

The moment your data leaves its source - Google Drive, OneDrive, whatever it is - it's protected by TLS (Transport Layer Security). This applies to every connection: from the cloud provider to our servers, from our servers to your browser, and everywhere in between.

No one can intercept your data mid-flight. Not on public WiFi, not through compromised networks, not anywhere along the route.

Encryption at Rest: AES-256-GCM

Once your evidence reaches our servers, it's encrypted using AES-256-GCM before it touches storage.

AES-256 is the encryption standard trusted by governments and financial institutions worldwide. The "256" refers to the key size—256 bits, meaning there are more possible keys than atoms in the observable universe. Brute-forcing it isn't just difficult; it's computationally impossible with current technology.

The "GCM" (Galois/Counter Mode) part is equally important. It's an authenticated encryption mode, which means it doesn't just encrypt your data—it also verifies integrity. If even a single bit is altered, decryption fails entirely. Tampering doesn't produce corrupted files; it produces nothing at all.

Every file captured during an acquisition is encrypted individually with a randomly generated key and initialisation vector (IV). The key is 256 bits of cryptographically secure randomness. The IV is 128 bits, unique to each file. This ensures that even identical files produce completely different encrypted outputs.

Envelope Encryption with AWS KMS

Here's where our approach goes beyond standard encryption.

We use envelope encryption with AWS Key Management Service (KMS). Here's how it works:

1. For each file, we generate a random AES-256-GCM data key

2. We encrypt your file with that data key

3. We then wrap (encrypt) the data key itself using a KMS Customer Master Key (CMK)

4. The encrypted file goes to S3 storage; the wrapped key is stored separately in our database (making it even harder to access if we got breached.)

This separation is critical. The encrypted files and the keys to decrypt them never sit together. Accessing our S3 storage gives you encrypted blobs. Accessing our database gives you wrapped keys that can only be unwrapped by KMS. You'd need to compromise both systems, plus have valid AWS credentials with KMS permissions.

We maintain one CMK per user account, with automatic annual key rotation enabled. This limits exposure while keeping key management practical.

Secure Storage: S3 with Server-Side Encryption

Your encrypted evidence is stored in Amazon S3, in UK-based (eu-west-2) data centres. But we don't rely solely on our application-level encryption.

S3 itself applies an additional layer of server-side encryption. This means data is encrypted by AWS before being written to disk, and decrypted when read. It's defence in depth—even if our encryption had a flaw, AWS's encryption provides a backstop.

Access to our S3 buckets is locked down through IAM policies. There's no public access. Presigned URLs with 24-hour expiry provide temporary download access when you request your evidence. After that window closes, the URL is useless.

We also enforce a 60-day retention policy. After 60 days, acquisitions are automatically deleted—both the encrypted files in S3 and the associated keys in our database.

What We Hash and Why

Every file collected during an acquisition is hashed using three algorithms:

• SHA-256 – The primary forensic hash, used for verification and chain of custody

• SHA-512 – A longer hash providing additional verification

• MD5 – Included for compatibility with older systems and quick checks

These hashes are generated at the moment of capture, before encryption, and recorded in your chain of custody report. They're also verified when you download—we hash the decrypted file and confirm it matches the original. If anything has changed, you'll know.

Access Controls and Audit Logging

Encryption protects data at rest. Access controls protect it in use.

Your evidence is accessible only through your authenticated Clerk session (the company we use to manage your authentication). We verify JWT tokens on every API request, checking both the signature and the issuer. There's no way to access another user's acquisitions—the system validates ownership before returning any data.

Every significant action is logged:

• OAuth connections and token refreshes

• File discovery and selection

• Acquisition start, progress, and completion

• Encryption events

• S3 uploads

• Downloads (including which format and when)

• Errors and anomalies

These logs form part of your chain of custody, stored in a separate S3 bucket with their own encryption and integrity hashing.

Internally, we follow least-privilege principles. Backend services use IAM roles with minimal permissions—only what's needed to function. Sensitive configuration (database credentials, API keys, OAuth secrets) lives in AWS Secrets Manager, not in code or environment files. The Proof team don't have access to KMS and so can't access your files, only one very heavily controlled and monitored AWS account does.

Sensitive Data Handling

Our logging is configured to redact sensitive information automatically. Authorisation headers, cookies, and session tokens are replaced with [REDACTED] before being written to logs. Your OAuth tokens are stored encrypted in our database and are never exposed in API responses.

When you disconnect a cloud account, we perform a soft delete—removing the access tokens immediately while preserving the account ID and email for audit purposes. You can reconnect later without losing your acquisition history.

Security Posture

Our codebase follows OWASP Top 10 guidelines. We use Prisma ORM for database queries (eliminating SQL injection), Zod schemas for input validation (on every endpoint), and Helmet.js for security headers. Stripe webhooks are verified using signature validation before any action is taken.

We run regular dependency audits and maintain zero known vulnerabilities in our production dependencies.

The Bottom Line

Your evidence is protected by AES-256-GCM encryption with unique keys per file, wrapped using AWS KMS envelope encryption, stored in encrypted S3 buckets with strict access controls, and verified with SHA-256 hashes at every stage.

We built Proof to handle sensitive data because we understand what's at stake. When you collect evidence with us, it's cryptographically secured from the moment of capture until you decide to delete it.

Your data. Your control. Proper protection.