Security

The four promises, and what makes each one true

We make these claims on the front of the website. Here is the machinery behind each, so you can check rather than trust.

One firm cannot reach another firm's records

Every table in Wrenbook is attached to a funeral home by the same convention, and that convention is what grants access. The boundary lives in the database, not in the application: a query that asks for another firm's cases does not get filtered, it gets nothing, whatever the application happened to ask for.

That is worth more than it sounds. A rule the application enforces is a rule somebody can forget to write on the next screen. A rule the database enforces applies to a screen nobody has built yet.

Two different questions, deliberately kept apart

Most software has one ladder: junior, senior, administrator. Funeral service has two, and collapsing them breaks something real.

• What your role allows — owner or member. This is permission: who can invite a colleague, who can change the firm's details.
• Whether you hold a license — a personal qualification, issued by a state, recorded with the state that issued it. It does not come from your employer and it does not travel: a director licensed in Georgia does not sign in Texas.

Treating a license as a permission level would put the person who actually runs the firm into "administrative staff" if she is not licensed, and make a director hired last week an administrator on day one. Both are wrong. So they are two separate facts, and it is the second — not seniority, not ownership — that opens a Social Security number.

Social Security numbers are held apart from everything else

The product holds two kinds: the number of the person who died, which the SSA-721 and the death certificate worksheet both require, and — because the SSA-721 asks for them — the numbers of a surviving spouse and of minor or disabled adult children. Those last ones belong to living people, some of them children. It is the most sensitive thing here, and it is not protected by care. It is protected by there being no other route.

• Encrypted in their own column, with a key in the database vault, generated separately per environment. A production copy restored elsewhere does not open.
• Removed from the data surface, not merely hidden. The interface the application talks to holds no read permission on that column. An ordinary query returns nothing — not the number, not even the ciphertext. Encrypted data that still circulates is data you can decrypt the day the key leaks.
• One door, and it checks a license. Opening a number requires membership of the firm and a licensed director, because it is the licensed director who signs the SSA-721 and files the certificate.
• The record is written before the value is returned. That order is the whole point: if the record cannot be written, the number is not returned. There is no path that reveals one of these numbers and leaves nothing behind.
• Excluded from the audit trail, on purpose. Every other field's before-and-after is recorded. Not this one — a log that stored the value would become a second copy of the secret, in the one place designed never to be erased.
• Out of exports unless a licensed director asks. The checkbox appears only for someone who can use it and is unchecked every single time. That request is recorded too, naming the records opened, and the archive states on its first page whether it contains numbers. Where one is sealed rather than missing, the export says so — "held under seal" and "never given to us" must not read alike.

What this encryption does not protect, and no vendor's does. It protects against a leaked database dump and against a stolen disk backup: the key lives in the server's configuration and is not in either. It does not protect against someone who already holds administrator rights on the live database. Nothing done inside a database can — the alternative is encrypting on your machine before it ever reaches us, which would mean we could no longer produce your documents. That is the trade, stated rather than glossed.

Every change is written down, and the log cannot be edited

A record is written for every change to every table: who made it, under what role, whether it arrived through the application or straight through the database, which record, the values before and after, and which fields actually moved. It is the database that writes it, so no route avoids it.

• Append-only, enforced in SQL. Updating a log line fails. Deleting one fails. Emptying the table fails — that third one is not redundant, because emptying a table does not fire the triggers that guard the first two.
• Closed. Neither signed-in users nor anonymous ones have any read access to it.
• An unknown actor is recorded as unknown, never guessed. A log that attributes a maintenance operation to one of your directors is worse than a log that admits it does not know.
• A test guards the guard. It is not enough to check that "the list of unaudited tables is empty" — that would also pass if the check silently stopped looking. So the test creates a table on purpose and requires that it be caught, and named.

Its limit, stated. Someone holding the database's own administrator role can disable triggers. This stops accidents and it stops tampering through the application; it does not stop somebody who already owns the database. The service key we use day to day does not grant that role.

A document signed on screen carries its own proof

Signing produces a completion certificate, filed with the case as a document of its own — never a link to somebody else's website. It records the signer and their standing to sign, the exact moment, a SHA-256 fingerprint of the document as issued and of the signed copy, the version of the electronic-signature disclosure that was accepted, and the network address and browser of the device that signed. All of it is taken server-side: a value the screen declares is worth exactly what the sender is worth, which is nothing in a piece of evidence.

A certificate is produced only for an electronic signature. On paper, the attestation is the licensed director's, and manufacturing a certificate would imply an audit trail that does not exist.

Your data leaves whenever you want, without asking us

Any member of a firm can export everything in one click: every case, every person, every note and payment, every price list, and every document exactly as it was filed. One file, opening with a double-click — plain web pages to read, spreadsheets to import, and a lossless copy for whoever migrates you next.

Two details that matter more than they look. The archive contains no outgoing requests at all — a test checks that nothing in it points at a web address — so it still opens in ten years, on a machine with no internet and no Wrenbook. And what it may contain is checked by the compiler: a new table added to the database fails the build until somebody has said whether it is exported or deliberately left out. The failure mode of an export is silence, and silence is what a firm that already left discovers too late.

Erasing a firm entirely

One irreversible operation exists, and it takes a whole funeral home: members, locations, invitations and every stored file. It is confirmed by typing the firm's name — not by a checkbox, which can be ticked from a script or a copied test, whereas typing the name requires knowing which firm you are destroying.

Two guards sit around it. The database refuses to purge while a single file remains, so no document with a family's name on it is ever orphaned. And a check walks the graph of relationships from the firm outward and denounces any table that would survive the purge — it runs with the test suite, so it will still be right at the twentieth table, when nobody remembers to ask.

Who else touches your data

These are the companies that run parts of the service for us, and there are no others:

The application itself loads no third-party code. No analytics, no crash reporter, no advertising tag, nothing. The marketing site you are reading does run Google's advertising tag; the application does not, and nothing from a case file has anywhere else to go. The full detail is in the Privacy Policy.

What we do not have

This section is here because a page that only lists strengths tells you nothing about the ones it left out.

• No SOC 2, no ISO 27001, no independent penetration test. We have not been audited by anyone. If a certificate is a requirement for your firm, we do not meet it today, and we would rather you learned that here than three weeks into a migration.
• We do not claim to be HIPAA compliant and we do not hold ourselves out as anybody's business associate. What we can tell you is the design fact underneath: the case file holds no cause of death and no medical record. A physician or a coroner certifies that, and it never enters Wrenbook — the product records who certifies and how far along it is, and nothing else.
• No first-call recording, and no artificial intelligence anywhere in the product today. The application records no audio and asks for no microphone. Nothing is sent to a language model or a transcription service, because there is no such provider in the product. When that changes, it will be named in the Privacy Policy before it processes anything.
• No self-service deletion. Erasing a firm is a request that a person carries out; deleting one individual's account is not built yet. We would rather say so than describe a button that does not exist.
• No published retention period. How many years a case file must be kept is set by law and by your firm, and we do not know Georgia's number well enough to print it. So nothing is deleted on our initiative, which is the safe side of that error.

If you find a hole

Write to hello@wrenbook.com. Telling us about something you found is welcome and we will answer you ourselves. Walking through it is not. There is no bug bounty and we will not pretend there is one.

Your security questionnaire

Send it. We fill them in, we answer the awkward questions in the same words as this page, and where the honest answer is "not yet", that is what the form will say.