TRE (Trusted Research Environment) — design and SATRE compliance

Date: 2026-09-21, revised 2026-09-22 · Owner: Yahia (TRE) · Sibling document: Data Cohorts design (owner Moe) at https://cohorts-design.pages.dev · Status: design only, no code.

0. Scope and ownership

The TRE is a separate entity from the data cohorts product; there is no overlap. Yahia owns the TRE; Moe owns cohorts. This document covers: what a TRE workspace is in bionl, its lifecycle, the controls it must enforce, the SATRE specification mapped statement by statement, the audit of today's workspace VM against those controls, and the hardening track. It does not cover the catalogue, pricing, checkout, orders, allocation or cohort files — those live in the cohorts document and reach the TRE only through the contract in §3.

1. Decisions that bind the TRE (Moe, 2026-09-21, revised 2026-09-22)

2. Open questions (TRE side)

1. Post-expiry top-up: unlock with a new expiry vs new TRE (agree with cohorts).
2. The exact feature gate list for kind = tre in web/api (download, upload, export, publish, git push, URL import, workflows, sharing) — proposal in §4.2 item 1–2.
3. VM profile for TREs (machine types, GPU, egress allowlist contents, package mirror).
4. RBAC permission names for TRE entry / TRE admin.
5. Retention period for locked TREs and their materialised data; who can delete.
6. Whether the two regional TREs are ever operated as a federation (SATRE pillar 5).

3. Contract with cohorts (the only coupling)

Cohorts → TRE (S2S, idempotent):

• provision(orgId, cohortId, region, mount {bucket, prefix, label}, expiresAt, purchasedBy) → { treWorkspaceId } — creates the flagged workspace in the region, attaches the RO mount via IMS, records expiry.
• addMount(treWorkspaceId, mount) → ok — top-up; expiry untouched.
• lock(treWorkspaceId, reason) / unlock(treWorkspaceId, newExpiresAt) → ok.
• status(treWorkspaceId) → state, expiry, mounts — for the purchases page. The TRE enforces expiry itself as well (a lock is not dependent on the cohorts job running).

4. TRE workspace model (proposal)

• Workspace.kind (standard | tre), Workspace.region, Workspace.lockedAt / lockReason, TreProfile (egress allowlist, package mirror, VM tier, GPU allowed), TreMembership (user × workspace, MFA verified, terms version, training record) — or reuse WorkspaceMembers + RBAC.
• Lifecycle: provision → active (mounts added over time) → locked (expiry / incident) → unlocked (new purchase) → deleted (retention policy, with deletion record).
• Feature gates when kind = tre (web + api + runtime): download/export/upload/publish/git-push/URL-import off; egress request UI on; TRE banner; MFA + terms + training gate on entry; VM from the TRE network profile.

Source read in full 2026-09-21: satre-specification.readthedocs.io/en/stable (specification YAML = 185 statements; principles; roles; evaluation method; alignment; FAQs). Spec facts that shape our approach:

• Structure: 5 pillars → capabilities → statements. Pillars 1–4 apply to every TRE (164 statements); pillar 5 Federation (21) applies only if we federate. Counts: IG 46 (30 Mandatory + 5 Mandatory* + 5 Rec + 6 Opt), Computing 62 (25 M + 29 R + 8 O), Data Mgmt 39 (16 M + 14 R + 9 O), Supporting 17 (4 M + 13 R), Federation 21 (14 M + 1 M* + 6 R).
• Compliance rule (evaluation page): score each statement 0 / 1 / 2 / N-A. Every Mandatory statement must score ≥1 or the TRE is not SATRE-compliant. Recommended = priority after Mandatory; Optional = context-dependent. Mandatory* = mandatory unless the exemption applies (no personal data / no physical assets / public involvement). SATRE is not an accreditation; it is a self-assessment (spreadsheet template) that is expected to be published (ties to 1.7.02, 2.7.06). Recommended evaluation = score + justification + improvement per statement.
• Principles (apply across the board): Usability (don't make the TRE unusable by over-restriction; JupyterLab/browser is explicitly fine), Maintaining public trust (transparency, public involvement when holding personal data), Observability (every human/automated change produces audit data), Standardisation (reuse known patterns, don't block interoperability).
• Roles we must be able to name people for: Data Consumer/Analyst, Project Manager, Project Team; Data Steward, Database Admin, Information Asset Owner (= the cohort provider), Output Checker; Operator, Developer, Builder; IG Manager, Quality Manager, Top Management, Data Protection Manager, Auditor; Lay Panel, Data Subject.
• Key SATRE vocabulary → bionl mapping: "project" = one purchase/Order (or a Study grouping several orders); "workspace" = TRE workspace; "dataset" = cohort; "Information Asset Owner" = cohort provider (hospital); "Operator" = bionl ops; "ingress" = cohort staging + Raw drive publish; "egress" = any file/notebook/output leaving the TRE.

10.0 Posture audit of today's workspace VM (2026-09-21, code-verified) — blockers before any TRE claim

Paths: B/ = bionl monorepo, R/ = bionl-runtime. These are live security findings, not only SATRE gaps; several must be fixed platform-wide, not just for TRE workspaces.

Things that are genuinely in good shape: one VM per workspace, deleted not recycled (2.1.14 partial-HAVE); no external IP on VMs; per-PR previews + dev/prod split + tagged releases + rollback (2.2.04/05); IaC for core shape; Secret Manager + WIF, no SA keys; pino PHI redaction on api; SSRF-guarded URL import; DataSubmission review workflow as an ingress-governance precedent; IMS bucket/mount registry with drift detection; billing-grade usage metering (VmUsage, B*Usage, ledger); PostHog consent-gated.

10.1 Legend

Type: T = technical control the platform enforces · O = organisational (policy/SOP/people/contract) · T+O = both. Status today (pre-TRE, current bionl workspace + cohorts server): HAVE / PARTIAL / MISSING / ORG-MISSING / N-A. "(verify)" = pending the posture audit. Build = what the TRE work must add.

10.2 Derived TRE technical rule set (what Workspace.kind = 'tre' must enforce)

These are the concrete controls implied by the Mandatory technical statements; they become the acceptance criteria for the TRE flag in web, api, IMS and runtime:

1. No data egress by default (3.1.05, 3.1.06, 3.1.12, 2.1.01): file download, notebook export/download, signed download URLs, "publish session", git push, URL export, workflow output to non-TRE buckets are all disabled for TRE workspaces. Egress only through an explicit egress request → Output Checker approval flow (3.3.04, 3.3.05) with a machine-readable record (3.3.09 optional but cheap). Browser clipboard copy out of Jupyter cannot be technically blocked in a web app; document as a "reasonable extent" mitigation (3.1.12 guidance) plus terms of use, or run Jupyter behind a remote-desktop gateway later.
2. No ingress except governed paths (3.1.04, 3.1.12): uploads into a TRE workspace disabled by default; only cohort mounts (RO) and an approved ingress path (e.g., code from an approved git repo or a reviewed upload) are allowed.
3. Outbound internet blocked by default on the TRE VM (2.2.11), with an allowlist for required services (package mirror, IMS credential endpoint, sentinel heartbeat, Google APIs via Private Google Access). Telemetry-requiring software recorded in a risk register (2.1.09).
4. Project segregation (2.1.08, 2.1.14, 2.2.10): one VM per TRE workspace, never reused across orgs; no VM-to-VM connectivity across workspaces (firewall tags); shared services (databases, workflow engines) instanced per workspace; cross-region mixing forbidden (D5).
5. Least-privilege identity (1.5.03, 3.2.01, 3.2.03): one Firebase account per person, MFA enforced for TRE users (3.2.04), TRE membership explicit and org-scoped, access to a cohort mount only for members of the purchasing org's TRE in that region, lock on expiry (T5) and on member removal.
6. Data Controller consent gate (1.5.04): access to a cohort requires the provider's agreement, recorded per cohort (blanket licence terms accepted at purchase, or per-purchase approval when accessLevel = restricted).
7. Audit logging, tamper-resistant (2.5.03, 2.2.13–15, 3.1.11): auth events, admin actions, mount grant/revoke, file access on cohort mounts (gcsfuse/GCS data-access logs), egress requests/approvals, VM lifecycle, resource usage; shipped to Cloud Logging with a locked retention bucket; per-org/project usage records.
8. Encryption (2.8.01–02): at rest by default (GCS/Cloud SQL/PD, CMEK option via IMS StorageProfile.cmek), TLS for browser↔TRE and service↔service; in-transit inside the VPC where possible (2.8.03).
9. Configuration as code + verification (2.2.01–06, 2.4.01–05): TRE VM image, firewall, mounts and flags are declared (terraform + IMS records + runtime image), drift-checked, and a non-compliant TRE can be destroyed and recreated.
10. Lifecycle (1.4.04, 3.1.09, 3.1.10): access expiry → the TRE workspace is locked (no user of the org can enter; VM stopped; mounts remain attached but unreachable), not deleted (D10). Deletion of user outputs, materialised purchase data and VM disks happens later under a published retention policy with a deletion record (proof of deletion).
11. Transparency records (1.4.06, 1.7.02, 3.1.08): public project register (orders → "Safe Projects" register with org, cohort, purpose), data-asset register (Cohort entity with provider/contact/received date/retention), published TRE documentation.
12. Capacity and cost (2.3.01–04, 4.4.01): the purchase page states the TRE's machine types/GPU availability and compute costs; org credit/billing gates VM start (already exists) and per-project cost tracking.

10.3 Pillar 1 — Information Governance (46)

10.4 Pillar 2 — Computing Technology and Information Security (62)

10.5 Pillar 3 — Data Management (39)

10.6 Pillar 4 — Supporting Capabilities (17)

10.7 Pillar 5 — Federation (21) — N/A today, relevant if KSA and US TREs are run as a federation or if bionl joins one

5.1.01–5.1.10 (governance: scope/structure, roles + shared-responsibility model, common rules + auditable compliance status, sharing incident/audit data, SOP lifecycle, join/leave processes, common risk approach, glossary (R), common access templates (R), public representation (M*)); 5.2.01 (baseline competency, safe-people registry via API); 5.3.01–02 (Safe Projects register via API; agreed legal/ethical standards); 5.4.01–04 (encryption/keys/PKI standards, shared incident response, common identities (R), shared security logs (R)); 5.5.01 (accurate config info on federation services); 5.6.01–02 (safe-output definition; cross-member metadata catalogue (R)); 5.7.01 (transparent pricing framework (R)). Design note: keep Orders/Safe-Projects register, training records and audit logs API-exposable so the two regional TREs could later federate without redesign.

10.8 What SATRE changes in the proposed design (§5)

• New models: TreMembership (user × TRE workspace, MFA-verified, terms version, training record), UserTraining, EgressRequest (+ items, checker decision, disclosure-control JSON), AuditEvent (append-only, mirrored to locked Cloud Logging bucket), Cohort.sensitivityTier / accessLevel / agreementRef / iaoContact / retentionUntil, Order.purpose / intendedOutputs / mlPlan / projectManagerId, DeletionRecord.
• TRE network profile: dedicated subnet + firewall tag per region, no external IP, egress allowlist proxy, Private Google Access; Batch/Nextflow for TRE jobs on the same profile.
• Runtime/web feature gates for kind=tre: download/export/upload/publish/git-push/URL-import off; egress request UI on; TRE banner; MFA + terms + training gate on entry.
• Ops artefacts to write: policy repo (IG, risk, incident, change, deletion, disclosure control, training), roles RACI, supplier register, public transparency pages, SATRE self-assessment spreadsheet (initial scores from this matrix).
• Launch gate: all Mandatory statements in pillars 1–4 scored ≥1; Federation N/A.