# Privacy notice 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](#what-is-not-settled-yet) rather than written as though it were. ## Who we are 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 . ## What Reynforce is, which decides most of what follows 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. ## What we hold ### When you ask for access 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. ### When an agent signs your company up 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. ### When a person signs in 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. ### Your register 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. ### The record of promises 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. ### Agent keys 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. ### When you pay 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. ### Email we send you The recipient's address and the message, through Resend. See [Email](#email) below. ### Technical logs **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. ## What we never hold - **The contents of your email or your CRM.** A mailbox connector asks for metadata only — the body is not requested rather than requested and discarded — and never asks for a subject line. A CRM connector asks only for the fields you have mapped. - **Your agents' messages.** We keep **the sentence a promise was made in, capped at 1,000 characters**, so that what was promised can be checked. That cap is in the record's own schema, which is what makes this sentence checkable rather than a policy. - **Card numbers.** They never reach us, by construction. ## Cookies **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'`. ## How long we keep it | | | |---|---| | 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:** - **A record of a promise nobody has closed is never deleted on age.** If somebody is still waiting on a promise made in your name, the record of it stays. This is derived from the records themselves rather than stored as a flag, because a stored flag becomes wrong the moment the promise is closed. - **Every deletion is itself recorded**, with the count read off the file before it goes — the one number a deletion cannot recover afterwards. **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. ## Where it is held, and by whom 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 | ### Encryption, stated accurately - **In transit:** everything, over TLS. - **At rest:** your register, your record and your directory sit on **encrypted storage provided by Fly.io** — that encryption is theirs, with their keys, and this notice does not claim it as ours. - **Encrypted by us, with our own keys:** the **credentials** we hold for systems you have connected, and **every backup**, before it is written anywhere. - **A backup never carries a credential.** The secret store is excluded by path, because a token in object storage outlives the revoke that was meant to end it. ## Email 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. ## Your rights Access, rectification, erasure, restriction, portability and objection, in the usual terms. Write to . **Export is built, not promised:** any signed-in member can download the whole store at any time, without asking us. ### Removing a person's name 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** — — and we would rather you wrote to us first. ## What is not settled yet **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 | ## Changes 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.