When this article matters
You're trying to understand how your data is actually protected, what "AES-256 encryption" means in practice, or how account deletion can be "instantaneous" when the underlying data must still exist physically in our storage. This article explains the encryption design in plain English — what's encrypted, with which key, who can decrypt what, and why crypto-shredding works.
For the broader storage architecture (where the data physically lives), see where is my data stored. For the full sub-processor list, see our sub-processors. For the account-deletion flow that triggers crypto-shredding, see delete your account and export your data.
The three-key model — Russian-nesting-doll of locks
Think of it as three nested locks:
- Master Key (one for the whole platform) — held in our managed key-management system. Used only to encrypt Account Keys. Never used to encrypt data directly.
- Account Key (one per TaxItEasy account) — encrypted by the Master Key. Used only to encrypt the File Keys for documents in that account.
- File Key (one per document) — encrypted by the Account Key. The actual document content (file bytes, OCR text, extracted fields, bank details) is encrypted with this key.
To read your data, the chain must work end-to-end: the Master Key unlocks your Account Key → your Account Key unlocks the relevant File Key → the File Key decrypts the file. Break any link in the chain and everything below it becomes inaccessible.
The technical names for this are different in different texts — sometimes it's called "envelope encryption", sometimes "key-encryption-key" (KEK) hierarchies. We call them Master / Account / File keys because that maps cleanly to the three levels.
Why three keys (not one)
A single key — "use one key to encrypt everything" — has two big problems:
- Granularity. Compromising one key would expose every user's every document. The three-key model isolates blast radius: compromising one Account Key reveals only one account's data.
- Crypto-shredding. You can't selectively destroy data encrypted with a shared key without destroying everything else. With per-account keys, destroying one Account Key destroys exactly one user's access without touching anyone else's.
The three-key design specifically enables:
- Per-account isolation. Compromising one Account Key reveals one account's data. The Master Key alone is useless — it only decrypts Account Keys, which it can't actively retrieve without your login first triggering the unlock.
- Crypto-shredding on deletion. When you delete your account (after the 30-day grace period), we destroy your Account Key. Every File Key tied to it becomes useless. Every encrypted document, OCR result, extracted field, OAuth token becomes unreadable — for us, for our backups, forever. We don't have to track down every database row to overwrite it; the data is mathematically inaccessible.
- Defence against CLOUD-Act-style requests. Our infrastructure provider (DigitalOcean) is US-incorporated. With application-layer encryption, even if compelled to hand over storage contents, they hand over ciphertext — useless without the keys, which they don't have.
The encryption algorithm
Everything uses AES-256-GCM:
- AES (Advanced Encryption Standard) — the same family of algorithms used in banking, government, NIST-certified cryptographic systems, every TLS connection on the web.
- 256-bit keys — the strongest commercial AES variant. Breaking a single AES-256 key by brute force would take longer than the age of the universe at current compute capacity. Cryptography research occasionally finds tiny weaknesses but nothing remotely practical for production.
- GCM mode (Galois/Counter Mode) — authenticated encryption. Not just confidentiality (you can't read the data without the key) but also integrity (you can detect any tampering). If a stored ciphertext is altered, the decryption fails with an explicit authentication-check error rather than silently returning garbled data.
In transit: TLS 1.2+ on every connection (TLS 1.3 negotiated where supported). All browser-to-app, app-to-database, app-to-sub-processor connections use TLS.
What's encrypted vs plaintext
Encrypted with the three-key chain:
- Document content — the actual file bytes you uploaded (PDFs, JPGs, PNGs, HEICs)
- OCR raw text + extracted structured fields (vendor, amounts, VAT, dates, line items)
- Bank-transaction details (counterparty name, reference text, IBAN, amount)
- Trading-partner records (vendor master data, addresses, VAT IDs, IBAN)
- 2FA TOTP secrets
- OAuth refresh tokens for email integrations
Encrypted with field-level encryption (extra layer on top of the three-key chain):
- Tax IDs (VAT numbers, personal tax IDs)
- Bank IBANs
- Some other sensitive secrets
The field-level layer is independent of the three-key chain — it uses a separate key set. So even if the three-key chain were somehow compromised (which would be a catastrophic incident on its own), these specific fields are still encrypted.
Not encrypted (plaintext in the database):
- Your email address — we need it for login, password reset, billing receipts, and the 30-day inactivity reminder
- Account creation date, last login time, current subscription state
- Audit-log metadata (who did what when) — required to survive deletion for legal compliance, so necessarily readable
The "what we cannot see" section on the /security page describes this in marketing-friendly terms; this article gives the engineering view.
How the keys are managed
- Master Key: managed via a key-management system (KMS) with strict access control, replication, and audit logging. The Master Key never appears in the database — only references to it.
- Account Keys: generated automatically when you create an account. Stored encrypted (by the Master Key) in our database; the encrypted form lives next to your account row. When you sign in successfully, the Master Key unlocks your Account Key for your session; on sign-out, the unlocked form is discarded from memory.
- File Keys: generated automatically when you upload a document. Stored encrypted (by your Account Key) next to the document metadata. The unlocked File Key only exists in memory for the few seconds of upload + OCR; never persisted in plaintext.
The Master Key rotates on a regular schedule (operational rotation); old encrypted Account Keys are re-encrypted with the new Master Key during the rotation. This is standard KMS hygiene.
Crypto-shredding — what makes deletion final
When you delete your account and the 30-day grace period expires, we destroy your Account Key. Concretely:
- The encrypted-form-of-Account-Key in the database is overwritten with zero bytes.
- The Account-Key cached anywhere is invalidated.
- The KMS reference to your Account Key is revoked.
From that moment on, every File Key that was encrypted with your Account Key is mathematically inaccessible. Decrypting AES-256-GCM ciphertext without the key is computationally infeasible — not "hard", literally infeasible at any realistic level of compute. The data still exists physically in our storage as ciphertext until the natural rotation cycle clears it, but it's worthless noise.
Why this is different from "delete every row in the database":
- Atomic: one key destruction, instantly affects every document. No risk of missing a row.
- Auditable: the deletion event is one log entry, not thousands.
- Backup-proof: even backups containing your ciphertext are useless without the key.
- Forward-secure: a future court order, a future security incident, or a future change of policy on our side cannot recover the data. The cryptographic problem is fundamental.
This is how we satisfy GDPR Article 17 ("right to erasure") cryptographically rather than by best-effort row deletion. See delete your account and export your data for the user-facing deletion flow.
Edge cases
What if you lose the Master Key? Catastrophic-incident-level. We use a managed KMS with replication, access control, and audit logging; loss in normal operation doesn't happen. Recovery would use standard KMS recovery procedures (HSM-backed key escrow, multi-party authorisation for unsealing). The incident-response plan covers this scenario; you'd hear about it in a public post-mortem.
Can I bring my own key (BYOK)? Not today. Enterprise BYOK is on the Phase-17+ backlog. Currently no customer has asked for it as a hard requirement; if you need it, write to [email protected] with [SALES] BYOK and we'll discuss. The technical lift is moderate (per-account-KEK substitution) but the operational lift (key-management on the customer side, rotation coordination) is substantial.
Are backups encrypted? Yes, doubly. Backups are encrypted by DigitalOcean's storage layer (AES-256 at rest) and the document content within is already encrypted by our three-key chain. Compromising a backup yields ciphertext-of-ciphertext — even the storage-layer encryption is just an additional wrapper around already-encrypted data.
Can your engineers see my data? No, by design. Engineers cannot retrieve plaintext Account Keys; the Master Key is held by the KMS not by engineering, and the unlock only happens on user-driven authentication (your sign-in triggering the Account-Key unlock). For debugging purposes we use pseudonymised, decrypted samples that you've explicitly opted into; production data is never read for development.
What about Anthropic seeing my document content during AI extraction? The document is decrypted in our backend for the few seconds of OCR, sent to Anthropic over TLS, then dropped from our memory once the structured result is written back. Anthropic sees the document content during processing. Their retention is up to 30 days under the commercial API default; a zero-retention addendum is in negotiation. See where is my data stored for the full transfer story.
Is the three-key chain the same as "envelope encryption"? Yes, that's the same idea — wrapping data keys in higher-level keys. Different texts use different terminology (KEK/DEK, master/data, parent/child); our three-tier "Master / Account / File" maps cleanly. If your security team uses different terminology, the underlying design is the standard envelope encryption pattern.
Is the platform open-source / can I audit the encryption code? Source is not open-source today. We've been audited by external security firms; the most recent internal security hardening pass is documented (with the caveat that we don't claim ISO 27001 / SOC 2 certifications because we don't have them yet). If you're an enterprise security team wanting to inspect the design under NDA, write to [email protected].
Does deleting one document trigger crypto-shredding? No — single-document deletion is best-effort row deletion (the document and its File Key reference are removed from active tables). The full crypto-shred only applies to account-level deletion via the GDPR Article 17 flow. This is a deliberate design trade-off: per-document crypto-shredding would require per-document key destruction events, which has operational overhead disproportionate to the benefit.
Related
- Where is my data stored? — the physical-storage context
- Our sub-processors at a glance — who else handles your data
- Your GDPR rights as a user — Article 17 (erasure) in detail
- Delete your account and export your data — the deletion flow that triggers crypto-shredding