Security & data
Your data, your controls, and what we do not claim.
Security questionnaires get answered with aspiration more often than fact. This is the fact version: how we handle your data, how we use AI models, how we deploy, how we treat personal data across borders — and, set out just as plainly, the assurances we cannot give you yet.
Nothing on this page is a marketing position. If a statement here turns out to be wrong for your engagement, that is a contractual problem for us, which is the only reason it is worth reading.
Five principles this page follows from
Your data stays in your estate
The default deployment is inside your tenant, under your identity provider, with your logging. Where that is genuinely impossible, the exception is written down and time-bound before anything moves — never assumed.
Least access, named people
Access is granted per engagement to named individuals, scoped to the systems the phase actually requires, and revoked at gate close — not at programme close, and not when someone remembers.
Your data trains nothing
We do not train, fine-tune, or benchmark general-purpose models on your data, and we work with model providers on terms that exclude submitted content from their training.
Every claim is auditable
Anything we assert about a system’s behaviour is backed by an artifact you can inspect — an evaluation run, a log, a signed threshold. Our security posture is offered to be judged the same way.
Designed for exit from day one
Including exit from us: infrastructure in your accounts, code in your repositories, evaluation suites you own, documentation written for your engineers rather than for our renewal.
Data handling
The shortest description of our data posture is that we try to need less of it than you expect.
- What we ask for
- The minimum the phase requires. A diagnosis usually runs on schemas, volumetrics, sampled records, and interviews rather than production extracts. We ask for full production data only when a specific piece of evidence cannot be produced without it, and we say which piece.
- Where it lives
- In preference order: your tenant; your cloud account operated under your controls; or, only by written exception, a dedicated environment we operate. Which one applies is a contract term agreed before the engagement starts, not a default we fall into.
- How long we hold it
- For the phase, plus whatever retention window the statement of work specifies. Working copies are destroyed at gate close and confirmed in writing. Deliverables are yours and stay yours.
- Who can see it
- The named individuals staffed on your engagement. Not “the firm”, not a bench, not a delivery centre you were never introduced to.
- What leaves the boundary
- Nothing, without a written change to the boundary. That includes screenshots in status decks, sample records in tickets, and prompts pasted into tools that were not declared.
AI model usage
Model choice is a decision made with you, in writing, before data moves — including whether a model may run outside your jurisdiction.
- Enterprise terms only
- We use commercial and enterprise API tiers whose terms exclude submitted content from provider training, and we can operate entirely on models deployed inside your own cloud tenant where you require it. Consumer tiers are not used on client work.
- Prompts and outputs are customer data
- They are logged where you require logging, redacted where you require redaction, and retained on the same schedule as any other engagement data — not on the model provider’s default.
- No shadow tooling
- The tools used on your engagement are declared to you. If someone on the team wants a new one, it goes through you first. This is the control most AI programmes are missing and most questionnaires never ask about.
- A model change is a change
- A new model version does not reach your users because it shipped. It reaches them after it clears the evaluation suite that judges the system — the same suite, the same thresholds, the same gate.
- Open weights where they fit
- Where residency, cost, or latency make a self-hosted open-weights model the better answer, we will say so, including when it reduces what we can bill for.
Deployment approaches
Three shapes, in order of preference. Each is stated with its real trade-off, because the fastest option to start is not the one that survives a security review.
- 01 · In your tenant — the default
- Your cloud, your identity provider, your logging, our engineers as named and time-boxed guests. You hold the keys and can revoke us in an afternoon. Slowest to start, and the only shape where the exit conversation is trivial.
- 02 · Your cloud, operated by us
- You own the accounts and the data; we hold scoped operational access to run the system while your team takes it over. Suitable when your platform team has no capacity in the phase window. Access scope and its expiry are named in the statement of work.
- 03 · A dedicated environment we operate
- Used only where you genuinely cannot host, and only under a written exception that names a migration date back into your estate. We will tell you what you are giving up: your logging, your key management, and a one-step revocation.
People and confidentiality
- Confidentiality before information
- We offer a mutual NDA ahead of the first scoping conversation, and one is executed before any material information is exchanged. Our default thereafter is that the engagement itself is confidential: we publish nothing about you — no logo, no case study, no anonymised story — unless you ask us to.
- Vetting your sector requires
- Where a regime mandates specific checks on the people who touch your systems — financial services, public sector, health — clearing them is a condition of staffing, agreed at contracting rather than negotiated afterwards.
- Conflicts declared before we bid
- We tell you about adjacent work before you brief us, and we decline engagements that would put us on both sides of the same question.
- Device and account posture
- Client work happens on full-disk-encrypted, screen-locked devices, with multi-factor authentication on every account used for it, and no client data in personal accounts or unmanaged storage.
Personal data, GDPR, and cross-border processing
This section exists because our own footprint raises a question a good data-protection officer will ask on the first call — so we answer it before you have to.
- Roles
- For personal data processed inside an engagement, you are the controller and we act as processor on your documented instructions. For the small amount of data this website collects, we are the controller — that is covered separately in our privacy notice.
- A DPA before processing
- We sign yours, or provide ours. Either way it is executed before any processing begins, and it names the categories of data, the purposes, the retention, and the sub-processors.
- Where our people are
- Our teams work from the United States and Egypt. Where an engagement involves personal data originating in the EEA or the UK, the transfer mechanism and the exact processing locations are named in the DPA before any transfer — and where you require processing to stay in one jurisdiction, we staff it that way or tell you we cannot.
- Sub-processors
- A named list is provided at contracting, with advance notice of any change and your right to object written into the agreement.
- Data subject requests
- We support yours within the timelines your obligations require, and we design the systems we build so that access, rectification, and erasure are operations someone can actually perform.
Responsible AI
Responsible AI is not a values statement here. It is a set of things that stop a release.
- No undocumented failure modes
- A system does not reach production until its failure taxonomy is written down: what it gets wrong, how often, how badly, and what happens next. “Accuracy 94%” is not a failure analysis — it hides whether the six per cent is embarrassing or catastrophic.
- Human decision rights are named
- For any decision with legal or material effect on a person, the system’s role is recommendation and the accountable human is named in the operating model — not implied by an org chart.
- Fairness testing where people are affected
- Where a use case touches individuals, the test set, the measures, and the thresholds for disparate performance are part of the gate, agreed before the pilot rather than examined after a complaint.
- Regulatory posture, stated honestly
- Obligations under the EU AI Act and equivalent regimes depend on the use case and on your role in the chain. We map that during Diagnose and design to it. We do not certify your compliance — that is your counsel’s call, and we put that boundary in writing rather than letting it blur.
How we build
- Security review is a gate artifact
- It is a named requirement of the Scale exit gate, not a task that slips. A system with an open security review does not advance, whatever the launch date says.
- Ordinary, unglamorous engineering discipline
- Reviewed changes, no direct pushes to main, secrets held outside source control, dependency posture checked at each gate, and infrastructure defined as code so what is running can be diffed against what was agreed.
- Every system ships with its own judgement
- The evaluation suite, the thresholds, the runbooks, and the failure taxonomy are delivered with the system. A system without its own tests is an opinion, not an asset.
This website, specifically
The smallest possible demonstration of the posture above, on the one system you can inspect right now without asking us for anything.
- It collects almost nothing
- Statically generated pages, no third-party analytics, no advertising trackers, and no cookies set by us. One key of local storage remembers your colourway choice and identifies nobody. The only personal data path is the contact form, and it never sends unless every delivery variable is configured — it degrades to a plain email address rather than pretending.
- It is served with the headers it should be
- Content-Security-Policy, HSTS with preload, frame-ancestors none, cross-origin opener and resource policies, and a permissions policy that switches off camera, microphone, geolocation, and topics. One honest qualifier, since you will see it in the header anyway: the script policy still permits inline scripts, because the framework’s bootstrap is not nonce-bound in a fully static site. It is this site’s weakest header, moving to nonces requires per-request rendering, and it is on the hardening backlog rather than quietly omitted from this list.
- Nothing is loaded from anyone else
- Fonts are self-hosted; there is no CDN script, no tag manager, and no third-party runtime request on any page. Your browser talks to this origin and nowhere else.
- Verify it rather than believe it
- All of that is visible in your browser’s network tab and response headers in about thirty seconds. We would rather you checked.
Assurance status — including what we do not hold
Most supplier pages list what they have. The useful half is what they do not, so both halves are here. If your policy requires an assurance marked “Not held”, we are not a supplier you can use today — and you should find that out on this page rather than in week three of a procurement cycle.
| Assurance | Status | What that actually means |
|---|---|---|
| ISO/IEC 27001 certification | Not held | We are a young practice and hold no certification. We will publish a target date here when one is committed, and not before — a roadmap date nobody is accountable for is exactly the kind of claim this site exists to avoid. |
| SOC 2 Type II report | Not held | Same position. If your framework treats it as mandatory rather than preferred, tell us on the first call and we will say so plainly instead of proposing a workaround. |
| Security questionnaire responses | On request | We complete yours, in your format, with named owners against each answer. We do not maintain a pre-baked answer pack, because the honest answer usually depends on the deployment shape you choose above. |
| Data processing agreement | Before processing | Executed before any personal data is processed. Yours or ours, with sub-processors and processing locations named in it. |
| Named sub-processor list | On request | Provided at contracting and kept current, with advance notice of changes and a right to object written into the agreement. |
| Professional indemnity and cyber insurance | At contracting | Levels are agreed at contracting against your requirement, and certificates are provided before work starts rather than after a claim. |
| Penetration testing of delivered systems | Per engagement | Commissioned or coordinated where the scope warrants it, as a named line in the statement of work. We do not carry it as a standing claim about work we have not done yet. |
| Right to audit | Negotiated | We accept audit and records-access terms proportionate to the engagement. We will tell you where a clause is disproportionate rather than signing and hoping it never gets exercised. |
This table, with the commercial terms, in one printable document
Reporting a vulnerability
If you find a security issue in this website, or in anything we have delivered to you, write to us and say so. We acknowledge within one working day, keep you updated until it is closed, and will not pursue or threaten researchers acting in good faith. Machine-readable contact details are published at /.well-known/security.txt.
Last reviewed July 2026.
Send us your questionnaire.
We answer it in your format, with a named owner against every line — and we will tell you before you start where the answer is going to be no.