
Data handling
Your data stays where it is. Here is the short list of what we keep.
Your reviewer will ask what we store. Two kinds of thing pass through, and it helps to keep them apart: your business data, which we never keep, and the record of who asked what, which we keep for you.
The safest data is the data nobody kept. Most of what passes through here is never written down.
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, and the result goes straight 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. If something you care about is not on it, 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. It records the people who run access, not the people who ask. | by reference |
| Posted changeswhere writing is on | Who confirmed a change, when, which batch and how many rows. Never the values: the figures you posted live in your own system. | 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
What never stays with us.
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. No usage stream leaves the service. What your people did is in your own audit trail, yours to read and export.
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, residency for your business data is a question about your own systems. |
| If you need a different region | A separate instance gets its own database and key vault, so a different region is a deployment, not a redesign. Ask, and we will scope it with you. |
Retention
How long each record is kept.
The request trail ages out on a schedule. The administration trail is kept for years, because a record of who granted what is the one somebody needs long after the fact.
| Record | Retention |
|---|---|
| Your business data | None. No copy exists to retain. That comes from the architecture, not from a setting. |
| The request trail | 24 months, then removed by a weekly retention job. A different period can be agreed in your contract. |
| The administration trail | Seven years, never removed automatically. |
| Everything, on termination | Removed or returned on your instruction, under the data processing terms. |
The retention job runs as a different database login from the web application. The web application holds no permission to change or delete rows in the trail at all, so a compromised web process cannot erase what it did. The full list of what the design keeps out of reach is on boundaries.