Governance sections
Written for the people who have to sign off on a supplier: security reviewers, privacy officers, procurement, and anyone whose name goes on the risk acceptance. Every position below is applied to our own work, including this website.
Security by design
Security is a property of how a system is built, so it is a design phase with its own deliverables rather than a review before release. The controls below are applied to our own work, including this website.
Threat modelling before implementation
We model the realistic attacks against a design, decide what each one is worth defending against, and answer the findings in the architecture. Findings are not logged as future work.
Least privilege by default
Every identity, service and tool gets the narrowest access that lets it do its job. Read-only unless a write is required, scoped to specific records rather than whole datasets.
Managed secrets, never in source
Credentials live in a managed secrets store with rotation. Automated secret scanning runs in the pipeline so a mistake is caught before it merges.
Automated checks in the pipeline
Dependency vulnerability scanning, container scanning, static analysis and secret detection run on every change, not on a quarterly schedule.
Defence in depth in the browser
A strict Content Security Policy with per-request nonces, HTTP Strict Transport Security, frame denial, and a minimal permissions policy. This site is served with all of them.
Evidence produced during delivery
Threat models, control mappings, decision records and test results accumulate as the work proceeds, so an audit or a client security questionnaire draws on evidence that already exists.
Responsible AI
AI systems fail differently from conventional software: fluently, confidently, and in ways a passing test will not reveal. These principles are the ones we actually build against.
A person remains accountable
Every automated process has a named owner in your organisation who is accountable for its outcomes. An agent is a tool that someone operates, not a party that can hold responsibility.
Grounded, cited, and willing to refuse
Answers are constrained to retrieved source material and cite it. When the evidence does not support an answer, refusing is the correct behaviour — and we test for it, because a system that never refuses will eventually invent.
Proportionate to consequence
How much autonomy a system gets depends on what an error would cost. Cheap, checkable errors can be automated; consequential or irreversible ones sit behind human approval.
Measured, not assumed
Accuracy and refusal behaviour are measured against a maintained evaluation set before release and on a schedule afterwards, because model behaviour and input distributions both drift.
Transparent to the people affected
Where automated processing affects a person, they should be able to learn that it was used and how a decision was reached. We design for that disclosure rather than treating it as a later legal question.
Limitations written down
We document what a system does not do, where it is known to be weak, and what it must not be used for. Undocumented limitations become somebody else's incident.
No training on your data
Client data is not used to train external models. Where a model provider's terms matter to your obligations, we establish that during design and record it as an architecture decision.
Human-in-the-loop controls
Oversight only works if it is built into the system rather than expected of the operator. These are the mechanisms we implement, and they are decided before the build.
Approval gates on material actions
Actions with financial, legal, contractual or personal consequence require a named human approval before they execute. Which actions qualify is agreed with you and enforced in the orchestration layer.
Confidence thresholds set by the process owner
Where a step produces a confidence signal, the threshold for proceeding is configured per field and per process by the person accountable for it — not set globally by us.
Reviewer interfaces built for reviewing
The person confirming sees per-field confidence, the source the value was read from, and an override path that is as easy as approval. A reviewer who cannot disagree easily is not really reviewing.
Overrides captured as signal
When a reviewer overrides the system, the reason is recorded. Those records are the most valuable data you have about where the system is wrong.
Mandatory escalation categories
Defined sensitive categories always escalate to a person regardless of confidence. The system cannot decide it is confident enough to skip them.
Reversibility by design
Automated actions are reversible where the process allows it. Where reversal is impossible, that is identified during design and the action is placed behind approval.
Data privacy
Privacy decisions are architecture decisions. We settle them during design, record them, and build to them.
Minimisation as a design constraint
A system holds the fields the process requires and no more. Extra data is not collected because it might be useful later — that is how breaches become worse than they needed to be.
Classification before storage
Data is classified by sensitivity before it is stored, and the classification determines where it may live, who may read it and how long it is kept.
Access reflects your permission model
Identity is federated with your existing provider so access mirrors your current model and is revoked when an account is. Retrieval respects those permissions at the index, not in a prompt.
Retention decided, not defaulted
Retention periods are agreed against your records obligations and implemented as deletion, not as an intention.
Residency and processing location
Where data is processed and stored — including where model inference runs — is established during design and recorded, because it is frequently the constraint that decides the architecture.
Personal data out of logs
Logs and telemetry are designed to carry what is needed for diagnosis without duplicating personal data into a second, less-governed store.
Quality assurance
Quality is a process with outputs you can inspect. Ours runs in the pipeline, on every change, including on this website.
Tests written with the code
Unit tests for logic, integration tests for the boundaries where systems actually fail, end-to-end tests for the journeys that matter. Written alongside the change, not scheduled afterwards.
Accessibility checked automatically
Automated accessibility testing runs against every page in the pipeline, backed by keyboard and screen-reader review. Conformance is an acceptance criterion, not a later remediation project.
Definition of done includes documentation
A change is done when it is tested, documented and accessible. Anything less is unfinished work that has been merged.
Performance budgets as criteria
Page weight, interaction latency and layout stability have agreed budgets, and a change that exceeds them is treated as a defect.
Evaluation for AI components
A curated evaluation set measures accuracy, citation correctness and refusal behaviour, and runs on every change so a regression is visible immediately.
Code review on every change
No change reaches production without review, and architecture decisions are recorded with the options that were rejected.
Support and maintenance commitments
What we commit to after launch, and what we commit to if you decide to leave. Both matter, and the second one is the more revealing.
Response targets agreed in writing
Support arrangements state response and resolution targets by severity, in the agreement rather than in a conversation. We do not publish generic figures here because they should reflect your actual service, not our marketing.
Monitoring in place before go-live
Deployment is not complete until monitoring is tied to service-level objectives, alerting routes to a person, and the support path has been communicated to users.
Patching on a schedule
Dependency currency and security patching follow an agreed schedule, with security updates prioritised rather than batched into the next release.
Backups verified by restoring them
A backup that has never been restored is an assumption. Restores are tested, and the test is evidenced.
Your code, your infrastructure, from day one
Source code, infrastructure definitions and documentation live in your repository from the first commit. There is no vendor-held artefact you would need to ask us for.
A documented exit
Handover documentation is kept current throughout the engagement, so transition to your team or another supplier is available at any point rather than negotiated at the end.
Applied here
What we do on this website
The quickest way to judge whether a supplier means any of the above is to check whether they apply it to their own property.
Strict Content Security Policy
Per-request nonces with no inline script allowance, so an injected script cannot execute.
No third-party tracking
No analytics, advertising or social scripts, and no cookies beyond what the site needs to function.
Accessibility in the pipeline
Automated accessibility tests run against every page on every commit, targeting WCAG 2.2 AA.
Tested before release
Unit, integration and end-to-end suites, plus type checking and linting, gate every change.
Security headers
HSTS, frame denial, MIME-type protection, a restrictive permissions policy and cross-origin isolation.
No data collection
The site has no form, no database and no analytics — there is nothing here that collects data about you, and the privacy notice says so plainly.
Security questionnaires
Send us yours before you send us a brief
If your organisation has a supplier security assessment, we would rather complete it early than discover a blocking requirement late. Where we cannot meet a control we will say so and describe what compensating measures we would propose — and where a certification is mandatory and we do not hold it, we will tell you that instead of hoping it is not checked.
Have a governance requirement to test?
Tell us the control you have to satisfy. We will tell you whether we meet it today, what we would need to do, or that we cannot — which is sometimes the answer.
We reply to every enquiry within one business day.