Published 11 October 2026. It has not been reviewed by a solicitor yet; one will review it before Reynforce is sold to more than a handful of customers, and this notice will say so when that happens.
Every factual statement below is a statement about code in a repository rather than an intention. Where something is not yet settled it is in What is not settled yet rather than written as though it were.
Reynforce is a trading name of a business based in the United Kingdom. The controller for the purposes of UK data protection law is the owner of that business, trading as Reynforce.
Anything in this notice, including a request about your own data, goes to callum@reynforce.com.
Reynforce records what a company's software and people commit to on that company's behalf. The data it holds is the customer's own: claims the company makes about its own product, the authority it has granted its agents, and a record of what was committed and under which authority.
It is not a marketing tool and holds no prospect list of ours. There is no tracking on this website, no analytics, and no cookie that is not strictly necessary.
The company name and the email address of the person responsible. That is the whole of it — the form's own shape refuses a source address or a browser string, so neither is held.
The company name and the email address of the person it names as owner, and that address is held only until the invitation to that person is sent. After that we keep the domain, not the person — the half after the @. Nothing records which agent named whom.
An identifier, a work email address, a display name, and the groups their own identity provider says they are in. Sign-in runs through WorkOS. A role is read from your directory rather than maintained by us, so adding somebody to your own deal desk group is what grants them that authority here.
The statements your company stands behind, who owns each one, and when each was last checked. An owner is held as an identifier and a role, and as a name only where somebody typed one.
What was committed, which agent or person committed it, what it relied on, and who approved it — as their user identifier and the role they held at the time, never as a name. A record is written once and is never edited.
A one-way hash of the key, not the key, with when it was created, who created it, and when it was revoked. The key itself is shown once and never stored, so we cannot recover it and neither can anybody who reads our disks.
Nothing is sent to Stripe yet. Once payments are live, Stripe will hold a billing name, an email address and a subscription status. Card details never reach us: payment runs on Stripe's own hosted checkout, and the key this platform holds can read customers and subscriptions and nothing else.
The recipient's address and the message, through Resend. See Email below.
One deliberate line per significant event, carrying no claim, no cookie and nobody's address. The register's own request log is switched off on purpose: a request log of a register is a list of what somebody looked at.
One cookie, set when you sign in, and nothing else. It carries a signed session, is HttpOnly and SameSite=Lax, and is Secure wherever the screen is reachable over a network. There is no analytics cookie, no advertising cookie and no third-party cookie, because there is no third party on the page: this site loads nothing from anywhere — no font, no script, no pixel — and its content security policy is default-src 'none'.
| the record of promises | 24 months, then deleted — with two conditions below |
| your register and account details | while your account is active |
| a request for access that never became an account | 12 months |
| a cancelled account or an expired trial | recoverable from a snapshot, then destroyed — see below |
| technical logs | held by our hosting provider rather than by us; we write no log file |
Two conditions on the 24 months, and both are built rather than promised:
Nothing has been deleted yet, and nothing in the code can delete it. The module that answers these questions holds no deletion primitive at all and imports nothing that could delete a file. The policy and the exemption are true from the first customer; the first sweep is due in 2028.
On cancellation the record is kept for the same 24 months, and you can export everything while you can still sign in. A trial that expires is destroyed after a snapshot is taken. We aim to keep that snapshot for 30 days; until provisioning sets the period explicitly it is the provider's default, which is 5 days. That is written here as two numbers rather than one because 30 days we chose and 5 days we inherited are different facts.
Your register, your mandates and your record sit on your own deployment — one application and one volume per customer, in London. That is a decision about blast radius: secrets and networks are isolated per application, and a credential belonging to one customer is refused at the door of another.
| what they hold | where | |
| Fly.io | the deployment, and the volume your data is on | London (lhr) |
| WorkOS | sign-in, and the directory a role is read from | not yet confirmed |
| Resend | email in flight, and 30 days of logs | United States |
| Stripe | billing details and invoices, once payments are live | not yet confirmed |
| Cloudflare | this website, and backups of your store | not yet set up |
| GitHub | the code, and the workflows an operator runs | — |
| Anthropic | Claude, used to build the product | not in the data path. No customer data is sent to a model by this platform |
Sent through Resend, and four messages are the whole list — an owner claim, a trial reminder, a receipt, a cancellation. No newsletter, no marketing mail and no unsubscribe link, because there is no list to be on.
Resend stores data in the United States. Their own security page, read on 10 October 2026:
"Stored data is held in the United States. The region you select when adding a domain controls where email is sent from, not where it is stored. Transfers are covered by Standard Contractual Clauses and the EU-U.S. Data Privacy Framework."
So sending from eu-west-1 is a deliverability decision and not a residency one, and this notice says so rather than implying otherwise.
Resend keeps email and log data for 30 days, against our 24 months for the record of promises. Two numbers about two different things: the 30 days is a copy of a message in Resend's system, and the 24 months is a record of a commitment in ours.
Access, rectification, erasure, restriction, portability and objection, in the usual terms. Write to callum@reynforce.com.
Export is built, not promised: any signed-in member can download the whole store at any time, without asking us.
You can ask us to remove or replace a person's name and email address. We do that in the directory, which is where names live. The record of what was promised refers to people by an internal identifier, so removing the name from the directory leaves the record complete and stops it identifying them.
We cannot change or delete a record of a promise. It is append-only by design, which is the whole reason it is worth anything: a record somebody can edit afterwards is not evidence of what was promised. Where a record must stop identifying somebody, the directory is the place that happens.
One thing to know about leavers: when somebody leaves, their directory entry is suspended rather than deleted, because a two-year-old record that resolves to nobody is worse than one that resolves to somebody who has left. Suspension and removing a name are separate requests and we will do either.
You can complain to the Information Commissioner's Office — https://ico.org.uk — and we would rather you wrote to us first.
Named here rather than smoothed over, because a notice that reads as finished when it is not is the failure mode this section exists to prevent.
| the controller's full legal name and trading address | a notice should name them; this one names the business and the contact address. To be filled in before a customer's own privacy review relies on this page |
| the ICO registration number | registration is outstanding; the number goes here once it exists |
| whether we are a controller or a processor for a buyer's name that arrives inside your activity data | we do not collect those people's details — they arrive in data you send or connect — and which of the two we are for them is a question for a solicitor, not for us |
| the transfer safeguard each supplier relies on, for Fly.io, WorkOS and Stripe | Resend's is quoted above because they publish it. The other three are not quoted because we have not read their pages, and a safeguard recalled from memory is worse than one marked unread |
| how long technical logs live | our hosting provider's answer rather than ours; we write no log file |
| how erasure interacts with a record you are required to keep | the hardest question on this page. Our answer above is that the name leaves the directory and the record stops identifying anybody; whether that is sufficient for a particular record is not ours to settle |
This notice is dated at the top. A change that affects what we hold or how long we hold it will be emailed to the owner of each account.