For your review
The pack, before you ask for it. Everything your reviewer will want, in one place.
Most of what a reviewer needs is already published on this site rather than held back for a qualified conversation. This page is the index, plus the parts that are sent directly because they change with dates.
Most vendors send the review pack after the demo. It is the only part of this that decides anything.
Why it is published
A review that starts with a questionnaire is a review that stalls.
The reasoning is straightforward. If the answers are public, the only thing left to discuss is whether they suit you, and that conversation can happen in week one instead of week six.
Everything in the first column below is readable right now, without an NDA, a qualification call or a form. The second column is sent directly because it carries dates.
| the usual shape | NDA, questionnaire, chase, answers |
| first real answer | week three, at best |
| this shape | read, then ask what is missing |
| first real answer | before you email us |
Published
Read these without talking to anybody.
| Document | Answers |
|---|---|
| Security model | The isolation rules, how each is enforced, and the four open items we would raise unprompted. |
| Whose permissions apply | Per connected system, whether your person's own permissions are enforced by that system or only by us. Two of four rows are us. |
| Permission gates | The four narrowing checks, and why none of them can widen access. |
| Audit trail | What is recorded, what is deliberately not recorded, who can read and export it. |
| Limits | What is structurally impossible, and what is deliberately refused because refusing is the point. |
Sent directly
These carry dates. So they are not left on a web page to go stale.
Compliance position
Where we stand per framework, in writing and with dates, answered directly for the frameworks your process actually requires rather than as a badge wall.
Sub-processor list
Who else is involved in running the service, what they do, and where. Short, because the architecture keeps it short.
Data handling and retention
What is held, what is never held, how long the audit trail lasts, and what happens to it when you leave.
Architecture diagram and data flows
Where requests go, which credential is used at each hop, and which components can reach a client database at all.
Questions we expect
The five that come up every time.
Asked
- Do you store our data?
- Can one client reach another's?
- What happens when somebody leaves?
- Can we get process isolation?
- Who can see the record of what was reached?
Answered
- No figures, no documents. Metadata, grants and audit only.
- Enforced twice – where grants are created and again where they are used.
- Their sign-in stops working, in your directory. Nothing to expire on our side.
- Yes, as a second instance with only your projects reachable. It is a deployment decision, not a redesign.
- You can, directly. The audit trail is yours to read and export, refusals included, so the record is not something you take on our description.