Data handling
What we hold, and for how long.
The second question in almost every review, and the one where a vague answer costs the most later. Two categories, and conflating them is the usual mistake: your business data, which we do not keep at all, and the record of access, which we do keep and which is the point of the product.
No copy of your figures or your documents is stored here, at any point.
Reads run against your own system at the moment somebody asks, on your own credential, and the result goes to the assistant that asked. Nothing is written down on the way past, including in the audit trail, which records that a read happened and never what it returned.
The inventory
Everything in our database, named.
This is the whole list rather than a representative sample. If something you care about is not on it, the answer is that we do not hold it.
| What | Why it exists | Personal data in it |
|---|---|---|
| Organizations and projectsyour structure | Which client, which environment, and the reference to where that environment's connection secret is kept. | none |
| Peopleone row each | A verified work email address, and a display name where your administrator entered one. Nothing arrives from your directory beyond the email. | email, name |
| Grantsthe permission itself | Person, project, tools, who granted it and when, and an end date where one was set. | by reference |
| The request trailevery call | Who, when, which environment, which tool, allowed or refused, and the reason code if refused. | by reference |
| The administration trailevery change | Who changed a grant, a setting or an approval, and what it was before. The record of the people who govern, rather than of the people who ask. | by reference |
| Your written rulesknowledge | The text your own people wrote and approved, with its version history and the name of the person who approved each version. | author names |
| Connection secretsnot in the database | Held in a managed key vault, one per project, never in the control-plane database and never in configuration. See the security model. | none |
"By reference" means the row names a person and holds nothing else about them. An audit row carries the identifier of a person, not a copy of their profile, so the whole of what we know about any individual is the row in the second line of this table.
Never held
The list that matters more than the one above.
Not stored at any point
- Your figures. Read at the moment of asking, returned, not written down.
- Your documents. Read with your person's own credential and not retained.
- The content of any answer. The trail records that a tool ran, never what came back.
- Passwords, group memberships, directory roles, photos, managers. One verified email crosses from your directory and nothing else does.
Not collected at all
- No model training on anything of yours. We run no model, so there is nothing here to train. Your assistant contract with your vendor is where that question belongs, and it stays yours.
- No cookies, analytics or trackers on this website. There is no JavaScript on it at all, which you can verify by viewing the source of this page, and the privacy notice says so in the form your legal team will want it.
- No product telemetry today. Nothing is wired, so there is no usage stream leaving the service, and there is also no error reporting. That is a genuine gap on our side as much as a privacy property, and it is named on what it cannot do.
Where it runs
One region, one cloud, one sub-processor.
| Question | Answer |
|---|---|
| Cloud and region | Microsoft Azure, West Europe. Compute, the control-plane database and the key vault are all in that region, and nothing is replicated outside it. |
| Other processors | One, and it is Microsoft. The full list, including what each one could in principle see, is on sub-processors. |
| Where your data is | Wherever it already was. Because nothing is copied, the residency question about your business data is a question about your own systems rather than about ours. |
| If you need a different region | An operator gets its own instance, database and key vault rather than a row in a shared one, so a different region is a deployment rather than a redesign. It is a conversation, not a setting, and it has a cost. |
Retention
How long, and the part of this that is not switched on yet.
The design is a request trail that ages out and an administration trail that does not, because a record of who granted what is the one somebody needs years later.
| Record | Designed retention | Enforced today |
|---|---|---|
| Your business data | None, because no copy exists | yes, structurally |
| The request trail | 400 days by default, adjustable per client | not yet |
| The administration trail | Seven years, never automatically removed | yes |
| Everything, on termination | Removed or returned on your instruction | contractual |
Read the third column. The retention job is written and tested and is not on a schedule, so today nothing ages out and the request trail keeps growing. It is a job somebody has to run, and until it is scheduled the honest description of our retention is "longer than designed". That is the kind of gap a vendor normally discovers during your audit rather than publishing before it, and it is on what it cannot do as well.
When it does run, it runs as a different database principal from the web application, which holds no delete permission on those tables at all. That separation is the reason a compromised web process cannot erase what it did, and it is why the job is separate rather than a background task inside the service.
The paperwork version of this page.
Everything above is the practice. The controller and processor roles, the deletion commitment and the audit rights are in the data processing terms.