Privacy Policy

Who we are

Wrenbook is funeral home software built and operated by Kompa, a company registered in France. Everything on this page applies to the website you are reading, wrenbook.com, and to the application we open for your firm.

The product is built for funeral homes in the United States and the company behind it is French. That is worth knowing here rather than discovering it in the last section of the Terms.

Company

Kompa

Legal form

Société par actions simplifiée à associé unique (SASU), a French simplified joint-stock company

Share capital

€1,000

Registered office

11 route de la Faisanderie, 78110 Le Vésinet, France

Registration

RCS Versailles 106 806 268, registered on June 26, 2026

VAT number

FR74 106 806 268

Publication director

Benoit Roubaud, President

Contact

hello@wrenbook.com

Three kinds of people are in here

Funeral homes and their staff. You opened an account, you run cases, you produce documents. For your own account we decide what happens to that data, so this page is our promise to you.

The person who died, and the family around them. None of you signed up for anything. The details are in Wrenbook because the funeral home serving your family put them there — and it put them there because a state form demands them. For that data the funeral home decides and we act on its instructions. If you want something changed or removed, the fastest route is the funeral home. If you cannot reach them, write to hello@wrenbook.com and we will get it done.

People who visit this website. You are reading a marketing site. What it measures is at the bottom of this page, and it is not much.

What we hold, and why

Because your firm has an account

• Your email address. It is your identity: signing in means receiving a link at that address. There is no password to lose, and no password for us to hold.
• Your name, your title and your license number. The license number is not decoration — it is printed on the documents you sign, and it is what decides whether you may open a Social Security number.
• Your firm and its locations — the names, addresses, phone numbers and license numbers that print as the header of every form you file, and who is the director in charge.
• Who you invited to work alongside you, and whether they accepted.
• Which plan you are on, and whether it is paid. That is all we keep about billing; the rest lives at Stripe.

Because a funeral home opened a case that involves your family

Almost every field in a case file exists because a form demands it — Georgia's death certificate worksheet, the permit for disposition, the SSA-721 that notifies the Social Security Administration, a cremation authorization. We did not decide what to collect; the forms did, and each field in the product records which form asks for it.

• About the person who died — legal name and any other names used, date and place of birth, sex, marital status, the names of their parents, level of education, Hispanic origin, race, usual occupation and employer, whether they ever served in the armed forces, their home address, the date, time, place and county of death, how and where they are to be buried or cremated, and their Social Security number.
• About the people around them — the caller, the informant, the person authorizing the disposition and the family rank they claim, the surviving spouse, surviving children, the physician or coroner who certifies, the embalmer, whoever receives the cremated remains. For each: name, relationship, phone, email, mailing address, and a title and license number where the form asks for one. For a surviving spouse and for minor or disabled adult children, the SSA-721 also asks for a Social Security number.
• The documents filed to the case — what the family sent, what the hospital sent, and what the product generated, each kept exactly as it was filed.
• The work itself — notes, the arrangement, the itemized statement of goods and services, and payments received.
• Signatures. When a document is signed on screen, the product produces a completion certificate and files it with the case. It records who signed and their standing to sign, the exact moment, a 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. Those last two are personal data and we keep them deliberately: they are the substance of an audit trail, and a signature that cannot say how it was obtained is a signature a court can set aside. They are used for nothing else — not analytics, not profiling — and they leave with the rest of the firm's data.

What is deliberately not in a case file

• The cause and manner of death. A physician or a coroner certifies that, not a funeral director and not us. The case file records who certifies and how far along it is. It never records why someone died.
• Card numbers, anywhere. There is no card field in the application and none on this website. Card details are entered at Stripe and never reach us.
• Any recording of a first call. See the next section — this is the one people assume, and the assumption is wrong.

The first call, and what artificial intelligence does today

We market Wrenbook as turning a first call into a case file. Today that intake is typed by a person at your firm. The application records no audio, asks for no microphone, and sends nothing to any language model or transcription service. There is no such provider in this product, which is why none is named in the table further down.

When automatic transcription ships, it will be a real change in what happens to a family's worst hour, and it will not arrive quietly. We will name the provider on this page before it processes anything, say what is sent and what is kept, and tell customers rather than hope they come back and check.

Social Security numbers

This is the most sensitive thing the product holds, and it holds two kinds: the number of the person who died, and — because the SSA-721 asks for them — the numbers of a surviving spouse and of minor or disabled adult children. Those belong to living people, some of them children. They are treated differently from every other field, and not by policy but by mechanism.

• They are encrypted in their own right, in their own column, with a key held in the database's vault and generated separately for every environment. A copy of the database restored somewhere else does not open them.
• They are off the ordinary data surface entirely. The interface the application talks to has no permission to read that column at all. An ordinary query cannot return one — not in the clear, and not even encrypted. There is exactly one door, and it is the next point.
• Only a licensed funeral director can open one, one at a time, because it is the licensed director who signs the SSA-721 and files the certificate. Being an owner of the firm is not enough; being senior is not enough. The license is the key.
• Every opening is recorded before the number is handed over — who opened it, which record, and when. The order matters: if that record cannot be written, the number is not returned. There is no way to read one of these numbers and leave no trace.
• They are excluded from the change log that covers every other field, on purpose. A log that stored the value would become a second copy of the secret, in a place designed never to be erased.
• They are not in an export unless a licensed director asks. The checkbox exists only for someone who can actually use it, it is unchecked every time, that request is itself recorded and names the records opened, and the archive states on its first page whether it contains them. Where a number is sealed rather than absent, the export says so — because "held under seal" and "never given to us" must not read the same.

What that encryption does not protect, said plainly. It protects against a leaked database dump or a stolen disk backup: the key is not in either. It does not protect against someone who already holds administrator rights on the live database itself. No database-side encryption can, and claiming otherwise would be the kind of sentence that sounds reassuring right up until it matters.

Every change is written down

Every table in the application keeps an append-only record of every change: who made it, under what role, which record, the values before and after, and which fields actually moved. It is written by the database itself rather than by the application, so a change made by any route leaves the same trace. It cannot be edited or deleted, and a test refuses to let a new table exist without it.

This is a promise to the family as much as to the firm. When a name is corrected on a death certificate worksheet at two in the morning, there is a record of who corrected it and what it said before.

Who else touches it

We do not sell personal data and we do not share it for anyone's advertising. Data reaches the companies that run parts of the service for us, and no others:

And us. Wrenbook is built and run by a small team, which means a person can reach the systems your data sits on — that is what keeping software running requires, and any vendor claiming otherwise is describing a company with no engineers. Two things bound it. Nobody opens a case file without a reason to. And a change made from behind the scenes lands in the same append-only record as one made in the application, marked as having come from the database rather than from one of your directors.

We will also hand data over when the law requires it, and we would tell you unless we are forbidden from doing so. If Wrenbook is ever sold, your data goes with the service and you will be told before anything moves.

How long we keep it, and how you take it back

A case is closed, not deleted. That is not a product preference. Funeral records have to be kept, so nobody at a firm — owner included — has permission to delete case data. It is enforced by the database rather than by a rule someone has to remember.

How many years a firm must keep a case file is set by law and by the firm, not by us, and we do not invent a number here. We do not delete case records on our own initiative.

• Taking everything out: one click, any time, no need to ask us. Any member of a firm can export the lot — every case, every person, every note and payment, every price list, and every document exactly as it was filed. It arrives as one file that opens with a double-click: plain web pages to read and spreadsheet files to import, no account and no internet needed, and a machine-readable copy for whoever migrates you next. It works while you are a customer and it works the day you decide to leave. If you ever leave, your data leaves with you.
• Erasing a firm entirely: on request. We can purge a firm completely — its members, its locations, its invitations and every stored file. It is irreversible, it is confirmed by typing the firm's own name, and the database refuses to run it while a single document is still stored, so no file with a family's name on it is ever left behind. There is no self-service button for this today; you ask, and a person does it.
• Deleting one individual's account — as opposed to a whole firm — is not built yet. Write to us and we will handle it by hand until it is.

Keeping it safe

• Everything travels encrypted, and the storage underneath it is encrypted.
• One firm cannot reach another firm's records. That boundary is enforced at the database, on every table, rather than by the application remembering to check.
• Two different questions, kept separate. What your role permits — owner or member — is one thing. Whether you are a licensed director is another. Mixing them would have made a firm's administrator a director on paper, and it is the second question, not the first, that opens a Social Security number.
• The application loads no third-party tracker at all. No analytics, no crash reporter, no advertising tag. Nothing from a case file has anywhere else to go.

If a breach ever puts data at risk, we will tell the firms affected and the authorities within the deadlines the law sets, and we will tell you what we actually know rather than wait until we have a tidy story.

Each of those mechanisms is set out at length — with what it does not cover, and with what we do not have — on the Security page.

This website, and what it measures

Everything above is about the application. This website is a different thing, and it does measure visits.

• Google's tag runs on wrenbook.com. It records that someone clicked a plan after arriving from an advertisement, and it stores identifiers in your browser to do it — cookies named _ga, _ga_… and _gcl_au, and one entry in local storage. Google uses those to recognise a returning visit and to connect it to the ad that brought you. It never receives your email address, and it has no access to the application or to any case file.
• Our own count of what happens on the page — a page opened, how far it was scrolled, which button was pressed, the campaign that sent you, the referring site, a shortened description of your browser, and whether you are on a phone or a desktop. It is tied to a random identifier kept in your browser, not to a name. When you ask for a trial, the record of that submission carries the plan you chose and deliberately does not carry your email address: this count exists to tell us where the page loses people, not who they are.
• What your browser stores — our random identifier and the current session, Google's own entry, and which plan you clicked so the form remembers it. Clearing your browser data clears all of it, and nothing here follows you off this website except what Google's tag does, above.
• The trial form asks for one thing, your work email, and carries the plan you clicked. It reaches us as an email. There is no card field.

There is no cookie banner here because this site is aimed at funeral homes in the United States and is written for that audience. If you would rather the advertising tag did not run, block it in your browser or turn off ad personalization in your Google account, and if you would rather we did not count your visit at all, tell us and we will exclude you.

Your rights, whoever and wherever you are

You can ask us what we hold about you and where it came from, ask us to correct it, ask for a copy you can take elsewhere, and ask us to delete it. We give those rights to everyone who asks, whichever state you are in and whether or not a law where you live happens to require it. We will never treat you differently for asking.

We do not sell personal information, and nothing from a case file ever reaches an advertising network. The only advertising measurement we run is the tag on this marketing site, described just above.

Write to hello@wrenbook.com. If your details are in a case file rather than in an account, tell us which funeral home is handling the arrangements — that is how we find you, and it is also who we will need to tell, because they are the ones who decide what goes on the next form.

Children

Wrenbook is a professional tool and no child will ever use it. But children's data does pass through it: the SSA-721 asks for the Social Security numbers of minor children of the person who died, and a case file may carry a child's name and relationship. Those numbers are held under seal like every other one — encrypted, off the data surface, openable only by a licensed director, and logged every time. We hold nothing else about a child, and we ask for nothing else.

Changes to this page

When what we do changes, this page changes first — before the new processing starts, not after. The date at the top is the version you are reading. Two changes we already know are coming will be written here before they happen: automatic transcription of a first call, and the naming of a provider that would read it.

Reaching us

Write to hello@wrenbook.com. A person reads it, and questions about data are answered from there.