§ Security & data handling

Your matter data, in plain English.

Written for the firm IT lead or risk reviewer who needs the security posture in one read, not a sales call. Effective May 3, 2026.

TLS in transitEncryption at restSOC 2 Type I — planned 2026 Q3SOC 2 Type II — not yet
§ 01 — Encryption + transit

Everything in transit is TLS. Everything at rest is encrypted.

All traffic between the public site, application, and backend is served over TLS 1.2+ with HSTS. The application database is a managed PostgreSQL instance (post-launch) with disk-level encryption at rest using provider-managed keys (AES-256).

Generated PDFs are stored on the application host's local disk only for the lifetime of the matter and are not uploaded to third-party object storage. The PDF endpoint is gated by a per-matter capability token (32 random bytes, constant-time-compared) that is generated at intake and never logged.

§ 02 — Subprocessors

Four disclosed entities, by name.

Matter data leaves our infrastructure only when it is sent to one of the subprocessors below. We do not sell, rent, or share matter data with anyone else.

Anthropic, Inc.
Claude API (Sonnet 4.6 and Opus 4.7). Generates the narrative body of the Draft Estate Packet from the cited findings. Per Anthropic's commercial terms, content sent for completion is not used to train their models.
Vercel
Site hosting. Static and SSR rendering only. Receives no matter data — the public site does not query or accept decedent identifiers.
Railway
Application backend hosting. Hosts the FastAPI service and matter database. Provider has SOC 2 Type II.
MissingMoney.com
Public-records query target. Receives the decedent's name and the fixed state filter state=CA. No other matter data is shared. Not a subprocessor in the GDPR sense (we are the requesting party of a public-records search, not a controller delegating processing) but disclosed here for completeness.
§ 03 — Access controls

Per-matter capability tokens. No shared admin auth on the app.

Each matter receives a 32-byte URL-safe random capability token at creation. Reads of the matter, of its discoveries, and of the generated PDF require that token in the query string. Token comparison uses Python's secrets.compare_digest for constant-time equality. A wrong token returns HTTP 404 indistinguishable from an unknown matter id, so capability tokens cannot be used to enumerate valid matter ids.

There are no internal "admin reads" endpoints that bypass the capability token check. Production access to the underlying infrastructure is restricted and protected by 2FA; details available under NDA to firm risk reviewers.

Capability tokens never appear in server access logs: a logging filter rewrites token=… query values to token=REDACTED before any record is emitted.

§ 04 — Retention

Matter data: years. Contact data: until you ask.

Matter data is retained for the duration of the engagement plus a reasonable archival period required for professional-services records (typically up to seven years). On written request from the firm of record, we will delete the matter and its discoveries within thirty days of request, subject to any litigation hold or legal-process obligation.

Marketing contact data (firm name, email, demo request notes) is retained until you request deletion or for two years of inactivity, whichever is sooner. Marketing contacts are stored separately from matter data; the two systems do not share a database.

§ 05 — Incident response

If something happens, the affected firm hears from us first.

Our incident process: detect, contain, notify the affected firm or firms within 72 hours of confirmed compromise, file required regulatory disclosures (CCPA / state breach laws / 23 NYCRR 500 if applicable), and publish a post-incident write-up.

Responsible disclosure. Security issues should go to security@estatepacket.com. We acknowledge within 1 business day, do not threaten legal action against good-faith researchers, and credit the reporter on resolution unless they prefer anonymity.

§ 06 — What we don't do

The honest list.

We don't do these things, on purpose:

SOC 2 Type II
Type I planned for 2026 Q3; Type II requires twelve months of audited operating history and is not realistic for a 2026 launch.
HIPAA BAAs
Estate Packet does not collect or process Protected Health Information. We will not sign a BAA and you should not send us PHI.
Bank credentials
We never ask for and never accept executor or decedent online-banking credentials. The product is public-records-only.
SSNs
We do not collect Social Security numbers at intake. Matching is name + DOB + last addresses, by design.
Customer data training
We do not use submitted matter data to train models, build aggregate datasets we sell, or seed any advertising / lookalike audience.
§ 07 — More detail

Where to read further.

This page is the operational summary. Legal terms governing data handling are in the formal Privacy policy and Terms of service. Specific risk-review questions go to security@estatepacket.com.

§ Note for firm risk reviewersOn request from a counsel-of-record at a California T&E firm, we provide our vendor-due-diligence packet (subprocessor list, security questionnaire responses, latest penetration-test summary) under NDA. Email security@estatepacket.com with your firm's NDA template attached.