Better Outcomes
Sign in

Information security policy

What we do, and what we have actually tested.

Last updated 12 November 2026. We do not hold a security certificate. What we have instead is a 34-check standard run against our own system on every release, and we publish what it fails. Report anything you find to security@betteroutcomes.ai.

The principle

A control that is not tested is not a control.

Most security pages are a list of adjectives. This one distinguishes three things, and keeps them apart: what we have built and test, what is policy we keep by hand, and what we have not done. The third list is the useful one, and almost nobody publishes it.

Every release runs the Agent Standard — thirty-four checks across how the system is built, who can see what, how the agents remember and learn, and whether it recovers. A check that was not run is never reported as a pass. The latest run is in our internal spec and we hand it to any client who asks, failures included.

Built and tested

These pass, on a real database, every release.

One client cannot reach another
Tested on a real database before every release.
tested
No keys or passwords in the code or the repository
Secrets live in the server environment and in the build system's secret store, entered by the owner. The check reads the code and fails the release if one appears.
tested
Agents get scoped, expiring grants — never your password
A grant names the paths and the actions, and has an expiry. A connection test gets ten minutes.
built
Sign-in is a one-time code, not a password
Emailed, works once, expires soon. There is no password for an attacker to reuse from another breach.
built
The run record holds no content
We keep the facts about a run — which agent, how long, whether it touched personal data — and never its text. Data you never store cannot leak.
built
Model hosts are told to keep nothing
Every call carries an instruction to the provider not to retain and not to train. It is the default in the code, not a setting.
built
Spend has a ceiling
A per-key limit at the provider, a limit inside each run, and a ledger of what was spent. A runaway loop cannot empty the account.
built
The service runs with the least privilege we could give it
A non-root user, no new privileges, configuration outside the code.
built
Nothing deploys until the tests pass
The deploy runs after the suite is green, and reports its own failures rather than hiding them.
built
Everything is in transit over TLS
The app, the model gateway, the payment provider, and mail over STARTTLS.
built
A person can be forgotten completely
Their facts, their history, and every lesson learned only from them. The test deliberately checks that forgetting one person does not remove another person's lesson.
tested
An agent that exceeds its limits stops itself
It stops, writes a record and tells your named person, and stays stopped until a person restarts it.
built

Policy we keep by hand

Real rules, enforced by people rather than code.

Who has access
The smallest number of people who can do the work. Access is removed when someone no longer needs it.
Keys and secrets
Entered by the owner into the server environment or the build system's secret store. Never in chat, never in a file, never in a log, never in the repository. Rotated when anyone with access leaves and after any incident.
Two-factor authentication
On every account that can reach production, the payment provider or the code.
Patching
Dependencies and the operating system kept current; anything with a known exploited vulnerability goes first.
Change control
Every change is reviewed, tested and recorded in version control before it reaches the server. There is no manual edit on a live machine.
Suppliers
Every company that touches client data is named in the subprocessor list with what it does and where it is, and the list is reviewed whenever it changes.
Our own people
Confidentiality obligations for everyone with access; a named person signs off every piece of agent work.
Reporting something
security@betteroutcomes.ai. We will not threaten anyone who reports a vulnerability in good faith, and we will tell you what we did about it.

What we have not done

The list nobody publishes.

This is current as of the last run, and it is here because a buyer who finds it out later is right to be annoyed.

We hold no security certificate
No ISO 27001, no SOC 2. We have decided which to pursue and roughly what it costs, and have not started.
not started
Deletion is not yet automatic
The keeping rules in the retention schedule are real commitments, and today they are carried out by people rather than by a job that runs on a timer. We are building that job.
manual
There is no one-click export of one person's data
We can produce it, and it takes people looking. Deleting a person, by contrast, is automatic and tested.
manual
Breach detection is not built
What exists is a limits check that stops a misbehaving agent. The breach process on the rights page is written and kept by people; the detection and the clock are being built.
manual
Restoring from a backup has never been tested end to end
The check for it reports "not run", because reporting it as a pass would be a lie.
not run
Encryption at rest is not confirmed in writing
Everything is encrypted in transit. Whether the disk under the database is encrypted is a question for our server administrator and we have not got the answer on paper, so we are not claiming it.
unconfirmed
Some of our screens use text below 14 pixels
Our own standard requires 14 pixels or more and three of our stylesheets break it. It is an accessibility failure, it is on the list, and it is not fixed.
fails
Load has not been tested
The check that a thousand incoming messages are each handled exactly once within the time budget has not been run.
not run

If you are reviewing us and this list decides it, say so and we will tell you what we would have to build and how long it would take. That is a better conversation than a questionnaire.

The commitment

What this policy obliges us to.

We keep technical and organisational measures appropriate to the risk, taking account of the state of the art and what it costs to do. That means, specifically: encryption and, where it fits, pseudonymisation; keeping the system confidential, whole, available and able to recover; being able to restore access after an incident; and regularly testing whether the measures actually work.

The regular testing is the Agent Standard, run on every release, published as a scorecard with its failures.

This policy is reviewed whenever the Standard's scorecard changes and at least once a year.