Controls we implement, stated plainly.

Separation between firms

Firm isolation is enforced by the database, not by application code that remembers to add a filter. Every tenant table carries row-level security policies keyed on the firm in scope, and the application connects as a role that can neither bypass those policies nor disable them. Tenant context is set per transaction rather than per connection, so it cannot survive into another request through a pooled connection.

The failure mode is deliberately "no rows" rather than "someone else's rows": with no firm in context, a query returns nothing.

Documents at rest

Every uploaded document and every stored print proof is encrypted with its own AES-256-GCM data key. That key is itself encrypted with a master key and stored in the database row rather than alongside the object, so possession of the storage bucket is not possession of the documents.

There are no pre-signed document URLs — not for previews, not for downloads. Every document download passes through the application, which is what makes each one attributable to a person and a time. A link to a document is not a capability to read it.

The audit history

Each firm has an append-only audit history. Entries are hash-chained: each one commits to the entry before it, so removing or altering one breaks every entry after it. The chain is written by a single database function inside the same transaction as the change it describes — an event and the state change it records commit together or not at all. No application role holds UPDATE or DELETE on it.

Verification reports the first divergent position rather than a bare pass/fail, and CSV/JSON exports carry the chain so the check can be run by someone else.

We say tamper-evident rather than immutable, and the distinction is real: a chain held by one operator cannot prove that operator never wrote a false statement when the entry was created. It can show that the sequence has not been altered since. External timestamping would strengthen that, and is not in place today.

The audit history stores identifiers, never names. Client and matter names, contact names, mailing titles and deadline labels are resolved at search time from the live records instead of being copied into the chain. That is a consequence of the chain being unerasable: anything written into it outlives the record it came from, which would make the retention promise false for everything the log happened to quote.

Signing in

Passkeys (WebAuthn with user verification required), authenticator apps (TOTP), and passwords hashed with Argon2. Roles are hierarchical and strictly ordered, so an administrator cannot act on another administrator. Failed sign-ins are throttled per account in the database, and that throttle fails closed.

A firm can require a second factor before sending — the action that spends money and reaches a real mailbox — rather than before signing in. Requiring it at sign-in would lock members out of records they need to read, including the owner who enabled it from a device with no authenticator on it.

Retention

Your firm chooses how long document contents are kept; the default is one year, and a firm can choose to keep them indefinitely. A nightly job destroys the document contents and the print proof, and destroys the wrapped encryption key first — destroying the key is what makes the deletion real, including to us.

Retention purges contents, never the record. The mailing, its timeline, the frozen recipient address, the audit history and the Mailing Record survive a purge. A purge that erased what was sent would delete the product.

Two honest qualifications. A matter on legal hold is never purged, and the job fails closed if it cannot determine the hold state. And the real window is the configured window plus backup rotation: encrypted database backups taken before a purge cannot be reached by it.

Where the mail actually goes

send.legal does not own printers. Physical mail is produced and deposited by a print-and-mail provider, which means the provider necessarily receives the document, the recipient address and the mail class. What send.legal adds is the record around that — and the record states what the provider reported rather than treating the provider's word as our own observation.

What we do not have

• No SOC 2 report, and no audit in progress that we would like to imply.
• No HIPAA BAA. We do not advertise HIPAA compliance and will not sign a BAA today.
• No independent penetration test to hand you yet.
• No external timestamping of the audit chain.

Those are the accurate answers to the four questions a security questionnaire asks first. If any of them is disqualifying for your firm, it is better learned here than in month three. Ask us anything else.