What we commit to, and how to check it
Automation means a system acting on your data, in your processes, without a person in the loop for most transactions. That deserves scrutiny, so this page sets out our commitments on data handling, access, resilience and change control — and the documents we will hand over during procurement to let you verify them.
Where we cannot yet evidence something, we say so below rather than describing it as though we could.
The short version
Six things we commit to about your data
We do not train models on your data
Your documents, records and outputs are never used to train or fine-tune a model, ours or a provider's. Where a provider is in the processing path, we use their enterprise terms with training disabled, and we can show you the configuration rather than assert it.
Your data stays where you put it
Data is processed in the region and tenancy you choose. We do not move it across borders for convenience, and where a model provider is involved we either keep it in-region or route it through a regional deployment with the same residency commitments.
Access is inherited, not reimplemented
Permissions come from your identity provider, so a person or an automation only reaches what they are already entitled to see. We do not create a parallel permission model that drifts out of step with yours.
Retention is enforced, not aspirational
Every dataset has a stated retention period tied to the process it supports, and deletion runs on a schedule. Where regulation requires a longer period for audit, that is stated explicitly rather than left to accumulate.
Everything is returned and deleted on exit
At the end of an engagement you receive the outputs, the code, the configuration and the documentation. Source data, copies and derived datasets are deleted, and we can provide written confirmation of that deletion.
Sub-processors are named in advance
You get the current sub-processor list during procurement, and we notify you before adding one so you have an opportunity to object. A sub-processor added quietly is a contractual breach regardless of what it does.
How we work
The controls behind those commitments
Deployment and tenancy
You choose where the work runs, and the isolation model is a deliberate decision recorded in an architecture decision record rather than a default.
- Deployed into your cloud tenancy where residency, procurement or regulation requires it
- Separate environments for development, test and production, with no shared production runtime between clients
- Data residency honoured by region, including where a model provider is involved in the path
- Infrastructure defined as code, so environments are reproducible and drift is detectable
- No production data in non-production environments, and no exceptions without a documented risk acceptance
Access control and identity
Access is inherited from your identity provider rather than reinvented, and it is time-bound by default because standing access is where most breaches begin.
- Single sign-on through SAML or OIDC, with SCIM provisioning where your provider supports it
- Least privilege on every service account, scoped per process and reviewed on a fixed schedule
- No shared accounts, and multi-factor authentication everywhere it is available
- Engineer access to production is time-boxed, requested per task, and logged
- Access revoked at offboarding as a checklist item, not as a favour
Secure development
Security is an input to the build rather than a review at the end, which is the only version of it that holds under delivery pressure.
- Threat modelling at design time for anything handling regulated or personal data
- Mandatory peer review before merge, with protected branches and signed commits where your policy requires it
- Dependency scanning, static analysis and secret detection enforced in the pipeline rather than reported
- Software bills of materials produced for delivered systems, so your own supply-chain process can consume them
- Secrets held in a managed vault, never in code, configuration files or build logs
Vulnerability and patch management
Known-good behaviour degrades on a schedule you do not control, so remediation windows are agreed in advance rather than negotiated during an incident.
- Continuous scanning of dependencies, container images and infrastructure configuration
- Severity-based remediation targets, stated in the engagement terms: critical first, then high, then the rest
- Coordinated disclosure route for anything reported to us by a third party
- Patch and upgrade windows agreed with your operations calendar, not dictated by ours
- Model and provider version changes treated as changes, with regression checks before rollout
Logging, audit and traceability
An automated action that cannot be reconstructed is a liability in a regulated process, so logging is designed with the process rather than added to it.
- Every automated action recorded with the input, the decision, the rule or model version, and the outcome
- Immutable or append-only storage where audit requirements demand it
- Retention periods agreed per process, and enforced by policy rather than convention
- Audit logs exportable into your own SIEM or logging platform
- Model outputs traceable to the source documents or records that produced them
Incident response and continuity
The question that matters is not whether something will fail but how quickly you find out and how clearly you are told, so both are committed in writing.
- Defined severity levels with response and notification times agreed before go-live
- Backups with a tested restore procedure and a stated recovery point and recovery time objective
- Rehearsed failover and restore, because an untested backup is a belief rather than a control
- Post-incident review with a written root cause and remediation, shared with you
- A named escalation contact and a documented path for out-of-hours incidents
Change and release management
Automation in a regulated process is a controlled system, so change is tested, reversible and evidenced instead of applied directly to production.
- Every change reviewed, tested and promoted through environments by pipeline rather than by hand
- Automated rollback for each release, so recovery is a routine action rather than an improvised one
- No direct production changes outside the pipeline, and any emergency change recorded retrospectively
- Regression coverage on the critical paths before a release is allowed to proceed
- Release notes and impact assessment for anything touching a regulated or financially significant process
Governance and accountability
Someone has to own the system, the data and the risk. Naming them is part of delivery rather than a governance formality.
- A named owner on our side and a named counterpart on yours for every engagement
- A register of the AI systems and models in scope, with their risk classification
- Human oversight designed into the workflow for decisions affecting people
- Data protection impact assessments where personal data or automated decisioning requires one
- Accessible evidence: control descriptions, test results and evaluation reports, not assurances in prose
Certifications
Attestation status, stated plainly
8 of 8 statuses are unasserted
We do not publish a certification we cannot evidence. Ask us directly during procurement and you will receive the current position in writing, together with whatever evidence exists today — an audit report, a bridging letter, or the reason an audit has not yet been commissioned. A vendor who answers this question vaguely is telling you something useful.
| Attestation | What it covers | Status |
|---|---|---|
| SOC 2 Type II | Security, availability and confidentiality controls over a defined period, evidenced by an independent auditor's report. | To be confirmed |
| ISO/IEC 27001 | Information security management system certification, covering the scope of services you are procuring. | To be confirmed |
| ISO/IEC 42001 | AI management system certification — the framework that maps most directly onto governing deployed models. | To be confirmed |
| Independent penetration test | Annual third-party test of the production platform, with a summary letter available under NDA. | To be confirmed |
| Data processing agreement | GDPR and UK GDPR compliant DPA covering roles, sub-processors, international transfers and breach notification. | To be confirmed |
| Cyber Essentials Plus | UK certification of technical controls, sometimes required for public sector and supply-chain procurement. | To be confirmed |
| HIPAA business associate agreement | Required where protected health information is in scope, whether the work is in healthcare operations or not. | To be confirmed |
| EU AI Act readiness assessment | Classification of each AI system in scope against the Act's risk tiers, with the obligations mapped to controls. | To be confirmed |
Procurement
What we will hand over, on request
Master services agreement
Standard terms, with redlines accepted against your own paper where your legal team prefers it.
Data processing agreement
Executed with the current sub-processor list attached, covering transfers, retention and breach notification.
Completed security questionnaire
CAIQ, SIG or your own template. We return it as a filled document with evidence references, not a summary.
Architecture and data flow diagram
Where data enters, what it touches, where it is stored and which third parties are in the path.
Penetration test summary
Executive summary and remediation status from the most recent independent test, under NDA.
Business continuity and disaster recovery plan
Recovery objectives, backup frequency, restore procedure and the date the restore was last rehearsed.
Insurance certificates
Professional indemnity, public liability and cyber cover, with limits and expiry dates.
Retention and deletion schedule
Per-dataset retention periods, the deletion mechanism, and how deletion is confirmed to you.
Named security contact and escalation path
A person rather than a mailbox, with out-of-hours arrangements stated during procurement.
Questions we get asked
The ones that come up in every review
Will our data be used to train AI models?
Do we have to run this in our own cloud?
Who can see our data?
What happens when the engagement ends?
How do you handle a security incident?
Can you work inside our security review process?
Do you hold SOC 2 or ISO 27001?
Also relevant: how we govern the AI systems we deploy and the privacy policy.
Bring us the process you already know is costing too much
Thirty minutes with an engineer is usually enough to tell whether it is worth automating, roughly what it would save, and whether the payback is inside a window your finance team will accept. If the answer is no, we will say so on the call.