How we plan to protect your sample and results.
Biom Atlas is not yet accepting orders or samples. Before we do, identity-linked information and lab results must live in a separate, authenticated system — never in the public marketing site. This page shows what exists today and what still has to be completed.
Clear-eyed status
The public website can collect launch-list signups and general inquiries. It is not a health-data platform, does not accept lab results, and should not be treated as a secure results portal.
- CORS, rate limits, webhook HMAC checks, and input validation around the marketing API.
- Security headers on API responses, log redaction, and removal of committed PII dump data.
- A consent-aware marketing analytics layer that stays out of health-result surfaces.
Designed to limit blast radius
Activation pseudonymizes the sample
The kit carries a specimen ID used by the lab. When a customer activates a kit, Biom Atlas links that specimen ID to the customer account in our own encrypted system. The lab should not receive the customer name, email, or marketing profile.
Lab ingest is deterministic
Raw lab results should arrive through a machine-to-machine channel such as mTLS API delivery or a PGP-signed SFTP drop. The system validates the structured payload against a schema, checks completeness, and holds early cohorts behind a QC release gate.
Email notifies, the portal delivers
Results should never be sent by email. Email can say that results are ready and link to the portal. The user authenticates before viewing any health-adjacent report content.
After validation, never during ingest
AI can help translate validated, de-identified result values into plain-language wellness guidance and score explanations. It should not decide which person receives which result, perform the identity join, or judge whether raw lab data is complete.
The model should receive specimen-level values without name or email, operate under a provider DPA with zero-retention terms, and stay inside wellness framing with no diagnosis or treatment claims. Early outputs should be human reviewed before release.
Separate storage, separate permission
Consent to receive results is not consent for future product development. Research use needs its own explicit opt-in and its own storage boundary.
Operational store
Identity-linked records, field-level encryption, KMS-backed keys, minimum viable retention, and access only for delivering results.
Research store
A de-identified dataset keyed by a research ID rather than user ID or specimen ID, retained only under separate explicit research consent.
Re-identification key
Stored separately, tightly access-controlled, and audited so long-term product research does not depend on broad access to identity-linked health data.
Controls before first real result
TLS 1.3 and mTLS where systems exchange lab files or results.
Encryption at rest with managed keys and field-level protection for identity joins.
No standing human access to identity-linked health data; break-glass only, logged.
Immutable audit logs for activation, ingest, release, and every result view.
Separate consent toggles for result delivery, research use, and marketing.
Signed BAA or DPA coverage with the lab, cloud provider, email provider, LLM provider, and other subprocessors.
CLIA-certified lab partner and a written incident-response plan before real result storage.
Separate health plane
Results should run on HIPAA-eligible cloud services, isolated from the public marketing and commerce stack.
Portal delivery
A subdomain such as results.biomatlas.com should own authentication, MFA, result rendering, and audit logs.
Legal review
Direct-to-consumer health data can trigger FTC HBNR, CPRA, and state health-privacy obligations even outside HIPAA.
How we read your microbiome
Security is one half of trust; method is the other. See exactly how we sequence and interpret your sample — and why we won’t show you a score we can’t defend.