Security and data governance
Designed for controlled access, auditability and data minimisation.
This page describes how TrialBridge is being designed. It is a statement of architecture and intent, not a claim of certification or compliance.
Four principles shape every control.
- Least privilege by default
- Authentication proves who you are; it grants no records. Access comes from roles scoped to a trial and site.
- Least data necessary
- Pseudonymous candidate IDs; identity stays with the data owner in the first release.
- Every action attributable
- Sensitive actions write an audit event, or they don’t happen.
- People decide
- Software proposes, filters and organises. People approve criteria and decide outcomes.
Four classes of data, handled differently.
De-identification reduces privacy risk; it doesn’t remove it. De-identified data is still access-controlled, audited and deleted on schedule.
| Class | Examples | In the first release? |
|---|---|---|
| Synthetic | Generated records for demos and evaluation | Yes — demo environment only |
| De-identified | Extracts prepared under your data governance | Yes — with a data-use declaration |
| Identifiable | Names, record numbers, contact details | No — planned, gated on agreements and review |
| Clinical research records | Case report forms, consent forms, source documents | Never stored as a system of record |
What is designed for the first release, and what comes later.
“MVP scope” means designed for the first release — not yet in production. Nothing on this page has been independently verified.
Authentication and authorisation
Who can sign in, and what they can reach once they do.
| Control | Status | Applies to |
|---|---|---|
| Email and password with mandatory multi-factor authentication | MVP scope | Sign-in for every user |
| Role-based access scoped to organisation, workspace, trial and site | MVP scope | Checked on the server for every request |
| Two-person rules for criteria approval and dataset authorisation | MVP scope | No single user can do both steps |
| Single sign-on via SAML or OIDC | Planned · V2 | Use your identity provider |
| Automated user provisioning (SCIM) | Future · V3 | Joiners and leavers from your directory |
Data isolation
Keeping one organisation’s records — and one dataset’s records — apart.
| Control | Status | Applies to |
|---|---|---|
| Tenant identifier on every record, enforced again in the database | MVP scope | Two independent layers |
| Each imported dataset in its own schema with its own grants | MVP scope | Queries can only reach authorised data |
| Separate environments for production and the synthetic demo | MVP scope | The demo never holds real data |
| Dedicated single-tenant deployment | Future · V3 | For organisations that require it |
Encryption
Protection for data moving between systems and data at rest.
| Control | Status | Applies to |
|---|---|---|
| TLS for all connections, including to the database | MVP scope | In transit |
| Managed encryption keys for databases, files, exports and backups | MVP scope | At rest |
| Short-lived links for downloads (minutes, not days) | MVP scope | Exports |
| Per-organisation keys enabling cryptographic deletion | Planned · V2 | At rest |
Auditability
A complete, ordered record of research-relevant and security-relevant actions.
| Control | Status | Applies to |
|---|---|---|
| Append-only audit log: approvals, access, cohort runs, decisions, exports, role changes | MVP scope | No one can edit or delete events |
| Audit export for compliance reviewers | MVP scope | CSV / JSON |
| Streaming to your security monitoring tools | Future · V3 | SIEM export |
Data lifecycle controls
How long data is kept, and how it is removed.
| Control | Status | Applies to |
|---|---|---|
| Default retention per record type, set by your administrator | MVP scope | Retention |
| Dataset deletion with a confirmation report (records removed; counts and audit kept) | MVP scope | Deletion |
| Raw import files deleted after confirmation | MVP scope | Minimisation |
| Configurable policies per data class | Future · V3 | Retention |
Secure integrations
Bringing data in without widening access.
| Control | Status | Applies to |
|---|---|---|
| CSV import under a data-use declaration, with an identifier scan that blocks direct identifiers | MVP scope | First release |
| Integration credentials held in a secrets store, never shown after saving | MVP scope | Credentials |
| FHIR R4 and OMOP CDM connectors | Planned · V2 | Not live |
| Identifiable-data tier with field-level protection | Planned · V2 | Requires agreements and review first |
AI works on protocol text. People work on patients’ records.
The only AI-assisted task is proposing structured criteria from a protocol. It runs inside the platform’s private network, can be switched off per workspace, and its output is a draft.
No patient data in AI requests
Candidate evidence, dataset records and screening notes are never sent to a model.
Citations are verified
A proposal must quote a passage that exists in the extracted text, or it is discarded.
No confidence scores presented as certainty
We show source match and flags instead of uncalibrated model probabilities.
Human approval, recorded
Approval is by a named user, per version, with an attestation — and every screening status is set by a person.
Evaluation before release
Proposal quality will be measured against expert-annotated protocols before the feature ships. No results exist yet.
Incident response plan
A written runbook — detect, triage, contain, notify, recover, review — and a tabletop exercise before handling customer data.
Planned · V2
Backups and recovery
Point-in-time database recovery and encrypted snapshots, with restore tests on a schedule. Recovery targets will be published once tested.
MVP scope
Monitoring
Alerts on errors, failed jobs and audit-write failures; threat detection and an account-level activity trail.
MVP scope
Questions we expect from privacy and security reviewers.
If yours aren’t here, ask. We’d rather answer them early.
Contact us about securityWe don’t claim compliance with any law or standard. Compliance depends on how a system is operated, contracted and assessed, not only on its design. Before handling non-synthetic data for a customer, we’ll assess the applicable requirements for that market with qualified advisers and put the right agreements in place.
Contracting terms aren’t established yet. The first release is scoped to synthetic and de-identified data.
Not in the first release. Candidates are pseudonymous, and sites resolve identity in their own authorised systems. An identifiable-data tier is planned and gated on agreements and a security review.
The proposed architecture runs on AWS in a region chosen per customer. Region and residency options will be confirmed during contracting.
It is designed as research-operations software that leaves eligibility decisions to qualified people. Its regulatory classification has not been confirmed and will be reviewed by regulatory counsel for each market.
Formal documentation (architecture overview, data-flow diagrams, security questionnaire responses) is being prepared. Contact us and we’ll share what exists now.