The core design decision
Patient-level data does not move. The platform's federated architecture sends models and queries to the data, inside the contributing institution's own infrastructure, and only aggregate, disclosure-controlled results return. This is the primary safeguard — everything below is defence in depth behind it.
Implemented and verifiable today
- Federated learning — training runs at participating nodes; only encrypted model weight updates are transmitted, optionally under differential privacy (DP-SGD with per-study privacy budgets).
- Statistical disclosure control — aggregate outputs pass through small-cell suppression (minimum cell count of 5) before release; the differential-privacy query console enforces per-cohort epsilon budgets.
- Tamper-evident audit trail — every governance-relevant action is written to a hash-chained audit log; any modification of a past record breaks the chain and is detectable via an integrity-verification endpoint.
- Tenant isolation — institution-scoped row-level security in the database, so one institution's users cannot read another's records even if application-layer checks were bypassed.
- Multi-factor authentication — TOTP (authenticator app) MFA on platform accounts.
- Transport and application security — TLS everywhere with HSTS, a strict Content-Security-Policy, security headers on all origins, per-client API rate limiting, and provenance/lineage tracking from dataset to study to model output.
- Tested, reviewed releases — every change passes an automated test suite and linting before deployment; deployments are reproducible from version control.
The node deployment guide documents the on-premise component's outbound-only network posture, egress allow-list, and supply-chain verification. The data protection impact assessment template and the platform's data use agreement text are available on request: hello@undosatech.com.
What federated learning does not solve by itself
Keeping data in place removes the largest risk — bulk transfer and copies — but federated learning has its own attack surface, and an honest security page names it. The residual risks, and where the platform stands on each:
- Model-update leakage and inference attacks — weight updates can, in adversarial conditions, leak information about individual training records (membership inference, gradient inversion). Mitigations in place: DP-SGD noise on updates with per-study budgets and a per-dataset lifetime epsilon ledger that hard-stops releases when exhausted, head-only fine-tuning to shrink the exposed parameter surface, and disclosure control on every aggregate output. Residual: differential privacy is configured per study rather than mandatory on all studies.
- Malicious or compromised nodes, and data poisoning — a participating node could submit crafted updates to skew or backdoor the global model. Mitigations in place: nodes run signed container images (keyless cosign signatures with a published SBOM), carry per-node identity on an audit trail, and activate only after a named institutional authoriser (PI, data custodian, or IT/security) confirms the deployment and the platform approves it — an institutional email domain alone is not sufficient. Not yet in place: byzantine-robust aggregation (update clipping and outlier rejection) — on the roadmap before multi-institution production studies.
- Aggregator compromise — the orchestrator sees individual weight updates in the clear at the application layer, so its compromise is the highest-value attack. Mitigations in place: no patient-level data exists on the orchestrator to steal, TLS everywhere, rate limiting, and a tamper-evident audit chain that makes silent manipulation detectable. Not yet in place: cryptographic secure aggregation, which would make individual updates unreadable even to the server — on the roadmap.
The honest summary: federated learning reduces privacy risk substantially — it does not eliminate it. That is why the platform layers disclosure control, differential privacy, provenance, and audit on top of the architecture rather than claiming the architecture alone is sufficient.
Regulatory positioning
The platform supports institutional compliance assessments — it does not, and cannot, make a study compliant by itself. Contributing institutions remain data controllers; their own DPIA, ethics approval, and information governance processes govern each use of their data. What the platform provides is the evidence those processes need: auto-generated governance evidence packs mapped to the UK (Five Safes, DSPT), EU (GDPR, EHDS), and US (HIPAA, Common Rule) frameworks, assembled from live platform state and independently verifiable. No software feature automatically confers GDPR, EHDS, HIPAA, or DSPT compliance, and any platform that claims otherwise should be read with suspicion.
Certifications — in process
Independent assurance is being pursued in the following order:
- Cyber Essentials, then Cyber Essentials Plus — in process, 2026.
- Independent penetration test — CREST-accredited, with a summary attestation published on this page.
- NHS Data Security and Protection Toolkit (DSPT) self-assessment.
- SATRE self-assessment — a published mapping of the platform against the Standard Architecture for Trusted Research Environments.
- ISO 27001 — on the roadmap once the organisation is at a scale where certification is meaningful.
Infrastructure and sub-processors
The platform's coordination layer runs on Netlify (this website), Vercel (platform frontend), Railway (platform API), and Supabase (authentication and platform database). Because patient-level data stays inside contributing institutions, these providers process account, metadata, and aggregate-result data — not source records. Hosting regions and transfer safeguards are documented as part of the certification work above and available on request.
Reporting a vulnerability
If you believe you have found a security issue, email security@undosatech.com. Good-faith research conducted without degrading the service or accessing others' data will not be met with legal action, and we will acknowledge reports within three working days.