Security overview

Myelin is a transit and quality-review layer for R&D data exchanged between a pharma sponsor and its external partners. Files upload to a temporary EU staging tier, are reviewed, and on validation are delivered — checksum-verified per file — into storage the sponsor controls. Myelin is not a system of record and not long-term storage: staged copies are purged automatically seven days after verified delivery or rejection, and end users only ever consume data from sponsor infrastructure. The one exception: context documents uploaded for reviewers (protocols, sample sheets, data dictionaries) are kept in EU storage for the term of the agreement, deleted on termination, and not included in backups.

The only US-touching flow is transactional email metadata (recipient name and email address, and business metadata) — never file names, file content, or checksums.

• Multi-factor authentication, required by default. The requirement is a per-organisation setting you own — off, privileged roles only, or everyone — and a new organisation is created with it set to everyone. An account it covers must enrol a TOTP second factor before it can reach the workspace, and is challenged for it at every sign-in. Enrolment issues ten single-use recovery codes, displayed once and kept only as SHA-256 hashes; a recovery code removes the factor rather than granting a session, so the account re-enrols instead of being let through. An admin resets a member of their own organisation, which signs that member out everywhere. Challenge and recovery-code attempts are rate-limited per account, and enrolment, removal, admin reset, a spent recovery code, a failed challenge and every change to the policy are written to the audit trail.
• Three limits on that, stated rather than left to be discovered. Partner-side accounts belong to no organisation — a database constraint, not a convention — so no organisation policy can reach them: a second factor is available to a partner and recommended, never imposed by you. That is the same boundary that keeps your single sign-on enforcement off your CRO’s staff. A federated session is not challenged: the assertion is your own identity provider vouching for the person under whatever factor policy you run, and a factor enrolled against a password identity does not exist on the federated one, so a challenge there could only ask for something that cannot be present. Where you want a second factor on federated sign-in, it is a setting in your directory and it stays yours. And it does not reach the API — the Partner API, the CLI and scheduled callers authenticate with a bearer key on a plane with no human at the keyboard, where scoping, revocation and audit are the controls that apply.
• Three-layer role model (platform / bridge / project), enforced server-side only through a single authorization path that reads roles from the database and fails closed.
• Postgres Row-Level Security on every table as an independent, defense-in-depth second layer.
• Partner API keys are 238-bit random secrets stored as SHA-256 hashes, backed by least-privilege service identities the client can see, remove, and kill-switch per bridge.

Every state change — reviews, votes, transfers, configuration, access — appends to a SHA-256 hash-chained audit log. Database triggers reject UPDATE, DELETE and TRUNCATE even for the privileged role, and a persisted watermark defeats silent truncation. An automated integrity verification recomputes the full chain daily; exports ship as CSV or a 21 CFR Part 11-styled PDF, and every export is itself an audited event.

• TLS on every hop; AES-256 at rest with provider-managed keys; customer-managed keys are not in place (see below).
• No bearer token ever rides the upload path. Partners upload straight to presigned S3 URLs scoped to a single object key with a minutes-long TTL, from the browser and from the API alike. There is no session token on the transport to steal, replay, or fail to revoke.
• Staged files are reachable only through short-lived signed URLs issued after an authorization check.
• Delivery runs on a dedicated EU worker built for terabyte-scale deliveries made of many files — paired FASTQ lanes, imaging series. Files are streamed with bounded memory, never buffered whole, and progress is checkpointed between files, so an interrupted delivery resumes instead of restarting. The limits are stated up front. To a Google Cloud Storage bucket, a single file can be up to 200 GiB: an interrupted delivery resumes inside the file from what your bucket confirms it holds, and your bucket refuses the file unless it matches the MD5 the partner declared. To an Amazon S3 bucket, a single file can be up to 20 GiB. Partners send files above 20 GiB with the command-line tool or the API.
• Every first-party upload records a streaming md5 computed on the partner’s side, browser and CLI alike, and the quality engine verifies it against the partner’s own manifest. The digest is recomputed in transit and verified at the sink on delivery. One honest limit: on AWS under SSE-KMS or multipart the object ETag stops being the content md5, so verification there falls back to exact size; on Google Cloud with CMEK full digest verification is preserved.
• Every delivery drops a receipt in your bucket — manifest.json and files.csv — and the SHA-256 of both is written into that delivery’s row in the hash-chained audit trail, which refuses UPDATE and DELETE at the database to every role. A receipt altered in your own bucket therefore stops matching a record that cannot be revised. One honest limit: checking it today means reading the audit trail from us. A detached signature you can verify offline, against a published key, is designed and not built.
• Terminal transfer failures page the operator via independent monitoring.
• Hardened HTTP surface: strict transport security, a restrictive Content-Security-Policy, and automated dependency scanning across the application and the CLI.

Nightly logical backups stream to a versioned EU bucket under a write-only identity — the backup job cannot delete its own history. Independent freshness monitoring alerts if backups silently stop. Because delivered data lives in your bucket, a Myelin outage never strands validated data.

The restore evidence, stated exactly. RPO is 24 hours. RTO is one restore measured at 32 seconds on 2026-09-11 — the application and identity archives of one backup run, restored over the network into a scratch database on a Supabase-hosted cluster (restore step only; download excluded); audit chain re-verified intact, accounts and second-factor enrolments restored, every profile reattached to its login identity. That is one measurement at then-current volume, not yet at pilot volume, not a guarantee, and it scales with data size. A drill scheduled each quarter, first on 2026-10-01, restores and verifies the newest backup inside its own job, in a plain PostgreSQL rather than a Supabase project, so it does not re-measure the RTO. There is no standby instance. Signing in against a restored copy, by password or a restored second factor, is untested, so a recovery is planned on the assumption that sign-in may need hands-on work.

If Myelin stopped existing. The exposure worth assessing here is not only a breach — it is a readout stranded mid-review. So the architecture is built to leave nothing hostage: delivered data is already in your bucket and is unaffected; a delivery in flight has never left your partner’s possession and can be sent the way it was sent before Myelin; and the audit trail is exportable in full, on demand, by your own governance users — evidence you already hold, not evidence you would have to request. Continuous export into a client-controlled archive is on the roadmap; today the export is self-service and unlimited.

Some controls are not in place. Each is sequenced against a named trigger rather than left unstated:

• Independent penetration test — none commissioned by Myelin. Your security team, or a third party you appoint, may test the platform as often as you wish during a pilot and yearly after, with committed remediation windows.
• SOC 2 Type II / ISO 27001 — a certification process is undertaken when a customer requires it contractually or growth justifies it; the documentation set is maintained audit-ready in the meantime.
• SCIM provisioning — not built. Accounts are not created or deactivated automatically from your directory. Single sign-on itself is available: SAML 2.0, one connection per organisation, set up with your identity team during onboarding. Your directory decides who may authenticate; a Myelin invitation decides who may act; a person needs both. Proven against Microsoft Entra ID — other identity providers follow the same shape, but we have not run them. Single logout is not supported.
• Point-in-time recovery — not enabled. Nightly logical backups give an RPO of 24 hours, and PITR is a plan setting rather than engineering work. The trigger is written down and dated: the arrival of the first real customer data.
• Customer-managed encryption keys — not in place. The substantive answer is a mode where the transit area lives in your own cloud, under your keys: committed, not built.
• Single-founder segregation of duties — compensated by the tamper-evident audit trail.

Single sign-on, multi-factor authentication and point-in-time recovery each carry a written position stating its design, its cost and its trigger; all three are sent on request alongside the assessment pack.

GDPR: Myelin acts as processor; EU residency for all primary data; subprocessor register and Art. 28 DPA position prepared. GxP: a 21 CFR Part 11 / Annex 11 control-traceability matrix and operational SOPs are prepared; electronic signatures are declared out of POC scope with a bounded upgrade path. See also the privacy notice.