Whatprocurementasksfor,andhowtogetit
A list of what exists, what is available immediately, and what needs a conversation because it is deployment-specific.
Documentset
| Document | Availability | Notes |
|---|---|---|
| Security pack | On request | Component inventory, dependency list, identity flows, key hierarchy, test evidence |
| Reference architecture | Published in outline | Full version in the security pack |
| Data processing terms | On request | Scope depends materially on deployment posture |
| Subprocessor list | On request | Maintained per deployment; change notification contractual |
| Continuity and recovery | On request | Objectives agreed per deployment rather than published |
| Incident management process | On request | Notification terms agreed in contract |
| Certification status | On request | Stated plainly, including what is in progress |
| Exit and transition terms | Contractual | Export formats documented; window agreed up front |
| Insurance and corporate | On request | Standard vendor onboarding material |
Whysomeofthisisonrequestratherthanpublished
Not because it is sensitive marketing. Two reasons. First, several of these answers are genuinely deployment-specific: recovery objectives, processing scope and subprocessor exposure differ substantially between a shared region and a disconnected on-premises installation, and a published figure would be wrong for most readers.
Second, a security pack that lists component versions and dependency inventories is operational information about a live system, and publishing it openly is not good practice for us or for the customers running on it.
Everything on the list is available to a serious evaluator under NDA, usually within a few days.
Howatypicalevaluationruns
First pass, self-service
Architecture, security, sovereignty and governance pages are written to answer a first-pass review without a call.
Pack under NDA
The document set above, usually within a few days of a mutual NDA.
Architecture review
A working session with engineers rather than a presentation, against your specific deployment.
Deployment-specific commitments
Residency, recovery objectives, notification timelines and exit terms written into contract.
Exit path walkthrough
Available before signature. We would rather you test it early.
Reference conversations
Arranged where a customer has agreed to it, with no claim made on their behalf until they have.
Questions
- Do you have SOC 2 or ISO 27001?
- We state the current position directly on request rather than implying one here, and we will not describe a framework we are working towards as one we hold. Ask, and you will also get the roadmap and the compensating controls.
- Can we run a penetration test?
- Yes, subject to scope agreement. In customer-infrastructure postures it is your environment and largely your call.
- Who are your reference customers?
- We do not publish customer names or logos without explicit permission, and we do not describe research or ecosystem relationships as commercial ones. Where a reference conversation is possible, we will arrange it.
Bring us one operational problem.
You do not need a finished brief. Bring the problem — we will work out the next step together.
Or book a call with the team