Trust

Where your data lives, who can reach it, and what we have not done yet.

Chris holds coaching conversations and feedback about the people who use it, so the questions on this page are reasonable ones to ask before anybody signs in. Every claim here was checked against the running system rather than copied from a policy document, and the last section is the things we cannot claim.

Where the data is

In Australia, on every tier. Nothing is stored or processed outside it, and each of these was read from the running configuration rather than from a policy.

Database, authentication and file storage: Supabase, ap-southeast-2, Sydney.
The application itself: Vercel, syd1, Sydney.
The voice service, which holds a call while it is running: Fly.io, Sydney.
Backups sit with the database, in the same region.

What is held, and what is not

A narrow set, and it is worth being specific rather than reassuring: Chris holds coaching material about a leader, which is more personal than a directory even though it is far less sensitive than a health record.

Name, work email, mobile number where a leader has opted into nudges, and their role and team.
Pulse responses from the people around a leader, held and reported in aggregate.
Coaching conversations, including anything a leader chooses to tell Chris.
Documents a leader uploads themselves, such as a 360 report or a psychometric profile.
Not held: payroll or financial data, health records, government identifiers, or any data about your clients’ own customers.

What reaches the AI, and what happens to it there

Chris is a coach, so it has to know who it is talking to. That means real information about a real person leaves this system on every turn, and the useful thing is to say exactly what.

Sent: the leader’s name and team name, the conversation itself, their practice and where they are in the cycle, and their own 360 analysis where they have one.
Sent for documents a leader has uploaded: a summary of each, plus up to three of the most relevant in full on any given turn.
Sent as team data: aggregate pulse scores and patterns. Never an individual team member’s response, and never their name.
Never sent: another leader’s material, payroll or financial data, health records, or government identifiers.
Anthropic’s commercial terms state that “Anthropic may not train models on Customer Content from Services”. Nothing a leader says to Chris trains a model.
We have applied to Anthropic for zero data retention. Until that is confirmed, prompts are handled under their standard commercial terms and data processing addendum. The next section sets out what that means either way.
During a voice call only, audio goes to OpenAI to be turned into text and back again. Typed conversations never touch it.
Chris does not invent coaching content. Practices come from an authored library, and the model shapes how one is said to a particular leader rather than making one up. That is enforced in the code, not asked for in a prompt.

Zero data retention at Anthropic, and where that stands

We applied for it in mid-August 2026. It has not been granted yet, so this section says what applies today and what would change, rather than describing an application as though it were the answer.

Today, under Anthropic’s standard commercial terms, they “automatically delete inputs and outputs on our backend within 30 days of receipt or generation”. That is the position anyone using Chris right now is actually in.
Under a zero data retention agreement, Anthropic “does not store their inputs or outputs except where needed to comply with law or combat misuse or harm”. A coaching conversation would exist on their infrastructure only for as long as it takes to answer it, and nowhere afterwards.
It would not put a conversation beyond safety systems. Even under such an agreement Anthropic “still retains User Safety classifier results in order to enforce our Usage Policy”, which is a score about the content rather than the content.
It would cover the Anthropic leg only. During a voice call, audio still goes to OpenAI to become text, and that is governed by its own terms rather than by this one.
It changes nothing about what WE hold. The conversation still sits in our Sydney database under the retention rules further down this page. Zero data retention is about Anthropic’s copy, not ours, and a page that blurred the two would be claiming a guarantee it does not have.
Once it is granted it shows as the data retention period on our Anthropic account, so it becomes something a reviewer can ask us to show rather than something to take on trust. We will change this section the day that happens.

Who can read a coaching conversation

Short answer: the leader. The longer answer includes what we can see ourselves, which is the part most vendors leave out.

The organisation paying for Chris can see THAT a leader is using it and when they last did. It cannot see a word of what was said.
Nothing a leader says to Chris is reported to their employer, summarised for them, or used in any performance context.
Pulse results reach an organisation as aggregates only, and a pulse with too few responses reports nothing at all rather than something identifying.
We can read a conversation in one case: where the leader has flagged a Chris reply for review, so we can see what went wrong. That is limited to our own staff and it starts with the leader pressing the button.
No other route in the product returns the contents of a conversation to anyone.

How one organisation is kept out of another

Enforced in the database and tested on every change, rather than promised in a policy. This is the part most worth checking, so here is how you would check it.

Row Level Security is enabled on every table, and a table without a policy does not ship.
Every query that bypasses RLS for administrative work is filtered by organisation, and a lint check in the build refuses queries that are not.
A cross-tenant isolation test runs in continuous integration on every change, against the committed policies, and the build fails if one organisation can read another.
Reporting to an organisation is aggregate by design. It can see whether a practice is landing. It cannot see an individual’s answers.

How people sign in

Passwordless for leaders, which removes the most common way an account is lost. Stated plainly because it is also not what an enterprise checklist expects.

Leaders sign in with a single-use link sent to their work email, or a one-time code if the link is awkward to open.
There is no password for a leader account, so there is nothing to reuse, phish or leak.
Executive accounts use a password, stored and hashed by Supabase Auth. We never see it.
Sessions are carried in signed, HTTP-only cookies, and the sign-in exchange happens server-side.

How long it is kept

One window, so there is nothing to interpret: when a contract ends, everything stays exactly where it is for thirty days so you can get it out.

Thirty days from the end of a contract to extract your data. Nothing is deleted or degraded during that window.
At the end of it the organisation’s data is deleted from live systems. Backups age out on their own cycle shortly afterwards and are not searchable in the meantime.
Where your own agreement with us sets different terms, the agreement governs. This page is the default, not an override.
While a contract is running, nothing expires. A leader’s practice history and the trend behind it are the product, and quietly ageing them out would break it.
An individual can export everything held about them at any time, from their own account settings.
An individual can request deletion, with thirty days to change their mind. That request is actioned by a person, not an automated pipeline.

If something goes wrong

What actually happens, with the timings measured from the moment we know rather than from the moment it started.

What counts: unauthorised access to leader data, loss of data, or a breach at one of the providers above that reaches your people. Not a bug and not an outage, and we will say which one it is rather than using “incident” to blur them.
How we would find out: automated checks that alert us, backup verification daily and log delivery every half hour, plus provider security notices. There is no twenty-four-hour staffed monitoring and we will not imply there is.
What happens, in order: contain, then assess scope, then tell you. Containment can mean revoking keys or taking a surface offline, and we will do that before the picture is complete rather than after.
You hear from us within seventy-two hours of us confirming a breach that involves your people: what happened, what data was involved, what we have done, and what if anything you need to do. If we are still working out the scope you get that too, rather than silence until we are sure.
A written account within fourteen days, including what changed so it cannot recur.
We follow the Notifiable Data Breaches scheme. Where a breach is likely to result in serious harm we notify the OAIC and the people affected as soon as practicable.
Your logs are yours. We preserve the relevant records and hand over what we hold for your own investigation.

Who else touches the data

Everyone in the chain, and what each one is for. Nobody outside this list processes data on our behalf.

Supabase: Database, authentication and file storage. Sydney.
Vercel: Runs the application. Sydney.
Anthropic: The model behind Chris’s coaching replies.
OpenAI: Speech to text and text to speech, during a voice call only.
Fly.io: Holds a voice call while it is running. Sydney.
Linq: SMS nudges, where a leader has opted in.
Resend: Transactional email, including sign-in links.
Inngest: Scheduled and background work.
Google Workspace: Operational alerts to our own team. These carry counts and route names, never personal data.

What we do not have yet

Written down here rather than left for you to discover. None of it is hidden behind a roadmap page.

No single sign-on or SAML. Access is by the email link described above.
No multi-factor authentication. Passwordless sign-in removes some of what MFA protects against and not all of it.
No SOC 2 or ISO 27001 certification of our own. Our infrastructure providers hold theirs; we do not claim them as ours.
No penetration test yet.

Anything not answered here, including a data processing agreement: hello@culturecrunch.io