Security and trust
Your retros contain your clients. We built for that first.
A close-out names a client, a margin and what a junior consultant really thought. This page says who can reach that material, how long it is kept, which companies see it and what is never done with it. Every claim carries the requirement or the decision record behind it, and a claim with nothing behind it is not on the page.
Who can reach what, and what is never sent
Six answers, each with the mechanism underneath it. Access, authorship and retention are decided on the server, in the function that answers the request, rather than in the interface that draws the result.
Visibility
Members see their Team. Workspace admins see the Workspace.
A Member of one Team cannot reach another Team's Retros. The Practice view, which cites several clients in one place, is open to Workspace admins alone, and every citation is checked against the reader's access on the server twice: in the query that assembles the candidate set and again in the path that returns the citations. A private Retro the reader is not named on is excluded before clustering runs, so its Cards are never cited and never influence what that reader is shown.
Anonymity
A hidden name is not the same as an absent one.
Who wrote a Card is resolved per viewer on the server, from the Retro's anonymity mode, its phase and the viewer's role. Where a viewer is not entitled to the author, the author is not in the response at all, so there is nothing to find in a browser's developer tools and nothing for a summary or a Theme narrative to leak. Votes are anonymous by voter on every mode, and vote totals stay hidden from everyone until the Facilitator reveals them, with each participant seeing only their own remaining budget until that moment.
Client participants
An internal section never reaches a client participant.
A Guest opens one Retro through a tokenised collection link, and that token reaches exactly that Retro and nothing else. Every participant in a Retro carries a stored affiliation, internal or client. A Facilitator sets it, on the link when they mint it or on a Member afterwards, and nobody sets their own. A section of a Format can be marked internal only, and on a Project Close-out the Commercials section is. The server does not send that section, or any Card written in it, to a client participant in any response, so the rule holds whether the request came from our interface or from a script. Choosing what goes into the PDF is a separate control and still belongs to the Facilitator. A Member nobody has marked counts as internal, so a client contact inside your own Workspace has to be marked before any of this applies to them. A Guest can own an Action and never appears in a billing count or in any cap.
Analysis
Theme detection reads Card text, not names.
Recurrence is computed from Card text and dates, never from authorship, and a Theme narrative obeys the same anonymity rules the Cards do. A Theme that cannot cite specific Cards in specific Retros, with Retro title and date, is not displayed at all, which is a product constraint rather than a presentation preference. The model identifiers are pinned and recorded, so the same input gives the same answer next quarter and a changed answer is traceable to a changed model.
Records
A closed Retro is frozen. An Action never is.
Cards freeze when a Retro reaches closed and cannot be edited afterwards, so a historical Retro shows what it showed on the day. Actions stay mutable forever, because chasing them is the product and a commitment that cannot be updated is a commitment nobody honours. Downgrading, cancelling and deleting a Team all archive rather than destroy. Any Retro you can read exports as CSV on every rung, including the one that needs no account.
Governance
Two roles, and a record of every destructive action.
Roles are Workspace admin and Member. There are no others to configure and no band adds one. Deleting a Team, removing a Member, reopening a Retro and cancelling a Workspace are each written to a log with the actor and the time, readable by Workspace admins. That log records what was done rather than what was read. There is no record of which Retro somebody opened.
What happens when you cancel
Cancelling starts a deletion clock of 90 days. Two emails reach the Workspace admin before anything goes: the first 30 days before deletion and the second 7 days before it. Nothing is ever deleted silently, and every deletion is preceded by at least one email.
Ninety days is shorter than you may expect, and it is deliberate. A long retention window is a long stretch during which your client's material sits on somebody else's servers after you stopped paying for it. The two warnings are what make a short window safe: a month's notice, then a week's, and the record stays exportable the whole time.
What happens when you move down a band
A downgrade removes no data at all. Every Retro stays where it is and what shrinks is how much of it you can read: the free rung opens the 3 most recent, which is exactly how a free Workspace behaves from its first day. Moving back up returns the reading.
The counter on a free Workspace is honest for the same reason. It says how many Retros and how many Cards are held, because they are genuinely still held. Nothing here is blurred, and nothing is a picture of content that has already gone.
What happens when you delete a Team
Deleting a Team archives it. No Team, Retro, Card, Group, Vote, summary, Theme or Action is destroyed by that operation. The confirmation says archive, because archive is what it does, and the interface never tells an admin that content has gone when it has not.
The Retros of an archived Team stay readable to the people who could read them before, subject to the reader's band, and they are frozen where they stand. Open Actions surface in a Workspace level view, each labelled with the Team it came from, so no commitment quietly disappears with the engagement that produced it.
Cards from an archived Team keep contributing to Workspace scoped Themes, and their citations keep naming the Team. For a consultancy the closed engagements are most of the evidence, so a Theme does not stop being true because the client relationship ended. A Workspace admin can restore an archived Team, provided the restore fits inside the band's Team allowance.
If you need something erased
An erasure request under data protection law is a different operation from archival, and it is not designed in v1. Archival deliberately destroys nothing, which is the opposite of what such a request asks for, so nobody here will tell you that archiving a Team answers one.
Saying that plainly is better than the alternative. The question is real, the answer is a piece of product design that has not been done, and a page claiming otherwise would be claiming a right you could not then exercise. Write to us and a person will take the request and tell you what is possible today.
The Retro that needs no account
You can run a Retro with no account, no email address and no payment details. It lives seven days and is then hard deleted. That is a removal of the rows rather than a flag set on them: no soft deleted remnant survives, and the absence is verifiable.
It costs nothing and asks for nothing, which makes it the honest way to see whether any of this works on your own material instead of on a demonstration Workspace. Claim it into a free Workspace inside the week and it keeps going; leave it and there is nothing left to keep.
Nothing here trains a model
No Card, Retro, summary, Theme or Action content is used to train any model, ours or a vendor's.
That covers the two AI vendors named below as well as us. It is a condition of being on the list, not a preference we mentioned to them. An embedding or generation vendor that cannot be configured to keep our content out of training is disqualified whatever else it is good at.
Every company that touches your data
Nine companies, named. Five of them see Card, Retro, summary, Theme or Action content and four never do. Each row says what it receives and why it receives it, because a category is not a name and a reader doing diligence needs the name.
This list is complete as of 3 October 2026. Adding, removing or replacing a subprocessor is a change to this page, and it ships in the same release as the change rather than after it.
What this page does not claim
No certification
Nothing here is certified or attested by anybody, and no certification is claimed. There is no report to send you and no programme to point at.
No processing agreement yet
There is no countersigned processing agreement to offer. It is an open item rather than an oversight, and it is not something copy can solve.
No response target
No response time is published here, because none has been agreed. When one is, it goes on this page with the name of the person who owns it.
Running a security review?
Send the questionnaire. We answer every question in writing, including the ones where the honest answer is not yet.
Send it to us