Skip to content

Security and governance

Written for information governance leads, data protection officers and anyone assembling a DPIA. It describes what the software does, and says plainly where an answer is a commitment rather than a property of the product.

The short version

  • No patient-identifiable data, by design and by refusal.
  • No connection to any clinical system.
  • No clinical advice, and nothing sent to a patient.
  • Every extracted item carries a citation, or it is discarded.
  • A named person approves anything the organisation relies on.
  • Review and approval history cannot be rewritten.

What we will not put on this page

Hosting jurisdiction, the data processing agreement, the subprocessor list and certification status are commercial and legal commitments. We answer them precisely, in writing, for the arrangement you would actually be on — rather than publishing a sentence that stops being true when the infrastructure changes.

Ask for them in writing

What data InBrief holds

Contracts, service specifications and approved organisational information — plus the accounts of the staff who use it. That is the whole list.

Patient-identifiable data
None. Uploads are scanned before processing and one that appears to contain patient identifiers is rejected with the reason rather than quietly accepted. Contracts and specifications do not contain patient data, so in normal use this never fires.
Clinical systems
No connection to EMIS, SystmOne, or any other clinical system, and no integration planned that would create one. InBrief cannot tell you which of your patients are outstanding on anything, because it has never seen a patient.
Personal data we do hold
Staff account records — name, work email address, role, and the record of what each person approved. This is the data a controller would expect to see in a DPIA, and it is the only personal data in the system.
Special category data
None held, and none processed.

How one organisation is kept away from another

Enforced in the database rather than in application code — so a query that forgot to filter returns nothing, instead of returning everything.

Row-level security

Every table carrying customer content is policed on the organisation it belongs to. The policies are forced, and the application connects as a role that cannot bypass them.

Per-request scoping

The tenant is set for the duration of a single transaction, so a connection reused from a pool cannot carry one customer's context into another customer's request.

Roles and rights

Eight roles, each a combination of four rights, enforced on the server rather than by hiding buttons. A receptionist can read approved answers and cannot start an extraction or approve a communication.

How data is handled

In transit
HTTPS throughout, with HSTS set in production.
At rest
Encryption at rest is provided by the managed database and object storage the deployment uses. Uploads to object storage are written with server-side encryption enabled by default, and with a customer-managed key where one is configured.
Passwords
Never stored. Each is put through scrypt at the OWASP-recommended parameters with a per-account salt, and compared in constant time.
Sessions
Cookie-based, HTTP-only, same-site, and marked secure in production, so a session cannot be read by scripts in the page or sent to another site.
Spend
A per-organisation monthly ceiling on model spend is checked before every model call and before an extraction is queued. It is a hard stop, not a warning — one customer cannot run up an unbounded bill.

Model usage

One model provider, used for four features, on documents you chose to upload.

What is sent

  • The documents you upload, when they are read.
  • The question a member of staff asks, with passages from your approved documents.
  • The text of a communication being drafted or translated.

Your documents are not used as training data by us or by the model provider.

How answers are kept honest

  • Extraction runs in two passes. The first produces citations attached by the model provider's API rather than written by the model, because a model asked to report its own sources will invent them.
  • An item the system cannot trace back to a passage in the document is discarded. The database will not store one without a source.
  • An answer must cite or refuse. A confident, ungrounded answer cannot be written — that is a constraint in the database, not a behaviour of the prompt.
  • Every model call is metered per organisation, per feature.

Audit and approval

The record of who decided what is a compliance artefact, so the software treats it as one.

Append-only
Reviews, approvals, translation reviews and the audit log cannot be updated or deleted. That is enforced by database triggers, so a bug — or a later change by someone without this context — cannot rewrite history either.
Audit records outlive their subjects
The audit log carries no foreign keys, deliberately. An audit entry blanked when an account closes is not evidence of anything.
Approval is by a named person
Nothing a patient would read reaches them without a person with the right to approve it having done so, recorded against their name and the time.
Translations
A translation must be approved before it can be used, and cannot be approved unreviewed. Independent linguistic review by a qualified translator is available as a paid service.
The one exception
Erasure and retention expiry can remove records, and doing so is itself audited. A system that could never delete anything could not honour an erasure request.

Retention, export and deletion

Retention

Configurable per organisation, seven years by default, measured from upload. The clock uses the newest version, so a reissued contract is current however old version one is. Nothing here knows when a contract actually ends, and the interface says so rather than implying a precision it does not have.

Deletion means deletion

Deleting a document removes every version, its extractions and the stored files. Erasing the index and leaving the contract on disk would not be erasure. On versioned storage that means removing every version rather than writing a delete marker.

Expiry does not delete by default

The retention sweep reports what has expired and removes nothing until an administrator turns deletion on, having read the reports. Every sweep is recorded, including the ones that deleted nothing — so both "why has this gone?" and "why is this still here?" have an answer.

Extracted items export to CSV at any time. You are not locked in to get your own contract knowledge back out.

Hosting and processors

InBrief runs on managed cloud infrastructure in Europe, with a managed PostgreSQL database and object storage, and uses a single model provider for the four AI features. The exact regions, the processors involved and the terms that bind them belong in a data processing agreement rather than on a marketing page, because they are the part a controller has to be able to rely on — and the part most likely to change.

Ask, and we will give you the current answer in writing, for the arrangement you would actually be on: region, subprocessors, retention configuration, breach notification and the DPA itself.

Regulatory position

Not a medical device

InBrief gives no clinical advice, makes no diagnosis, performs no triage, and recommends no medication or treatment. It reads contracts and drafts administrative communications for a person to approve. Those boundaries are the reason it sits outside the medical device regime, which is why they are enforced in the software rather than written as a caveat.

Not affiliated with the NHS

InBrief is an independent software product. It is not affiliated with, endorsed by, or accredited by the NHS or any of its bodies, and it carries no NHS branding. Where it describes a contractual requirement, the contract you uploaded is the authority — not InBrief.

Where the product stops

What InBrief does

  • Works only from documents your organisation has approved.
  • Shows the passage behind every answer and every extracted item.
  • Puts review and approval in front of anything a patient would read.
  • Keeps an append-only record of who approved what, and when.

What it does not do

  • Send anything to a patient. There is no send route, and no messaging gateway.
  • Give clinical advice, diagnose, or triage.
  • Hold patient-identifiable data, or connect to a clinical system.
  • Tell you which of your patients are outstanding on anything.
  • Decide anything on your behalf. A person approves what the organisation relies on.

These are boundaries, not gaps waiting to be filled.

Send us your information governance questions.

We would rather answer a hard question early than discover it in week six of a procurement.