Securing genomic data in the cloud means more than encrypting a storage bucket. Genomic data is large, identifying and impossible to reissue once exposed, so a clinical laboratory has to secure the whole workflow (sequencer, analysis tools, storage, interfaces and report delivery) and has to write down who is responsible for each safeguard. This guide explains what to ask a cloud or SaaS vendor, how SOC 2, ISO 27001, HIPAA and disaster recovery fit together, and where pharmacogenomics (PGx) reporting adds its own requirements.
TL;DR
- Genomic data cannot be changed after a breach, so security review should follow the dataflows, not just the application's feature list.
- Under HIPAA, a cloud provider that handles ePHI is a business associate even when it holds only encrypted data, so you need a BAA and a documented split of responsibilities.
- SOC 2 Type II and ISO 27001 are useful evidence of a vendor's control environment, but neither is a genomics-specific certification and neither replaces your own risk analysis.
- Ask for recovery objectives, backup testing and SLA terms in writing before you sign, and test them yourself.
- Governance (retention, secondary use, residency, deletion, reanalysis) belongs in the security conversation from the start.
Table of Contents
- Why genomic data is not ordinary SaaS data
- What HIPAA requires of a cloud provider
- SOC 2 and healthcare SaaS: what the report tells you
- ISO 27001 and genomics
- Threat-model the workflow, not the bucket
- Disaster recovery for genomic data
- Healthcare SaaS SLAs: what to negotiate
- Governance: the part technical controls cannot supply
- Our perspective
- Where SignalPGx fits
- FAQ
- Sources
Why genomic data is not ordinary SaaS data
Most cloud security checklists were written for business applications. Genomic data breaks several of their assumptions. NIST's report on the cybersecurity of genomic data describes information that is highly identifying, hard to change once exposed, unusually large, and processed across instruments, containers, algorithms, partners and clinical systems. A leaked password can be reset. A leaked genome cannot.
Size matters operationally as well. According to NIST's August 2025 draft SP 1800-43, sequencing outputs commonly range from multiple gigabytes to terabytes, and cloud security has to preserve confidentiality, integrity and availability while also managing privacy risks from immutable data that can reveal kinship, traits and health status. That last point is the one labs most often under-weight: a genotype file says something about relatives who never consented to anything.
The practical consequence is that a security review of a genomics vendor should follow the data. NIST identifies the sequencer, cluster filesystem, analysis tools, storage, interfaces and downstream systems as connected attack surfaces. Instrument maintenance links, third-party variant-calling software, containers, backups and report delivery all belong in the model, not only the cloud bucket.
There is also a confinement problem. The same NIST report notes that contractual restrictions can impose penalties after unauthorized sharing but cannot restore privacy. That is why logical perimeters, tightly restricted destinations, microsegmented sequencers and monitoring for exfiltration matter more than after-the-fact legal remedies.
For a deeper look at the lifecycle side of this problem, the guide to data privacy in healthcare is a useful general companion, and our own piece on genomic data retention before sequencing covers the decisions a lab should make early.
What HIPAA requires of a cloud provider
If your lab is a covered entity or a business associate in the United States, HIPAA shapes every cloud decision. HHS guidance on cloud computing states that when a cloud service provider creates, receives, maintains or transmits ePHI on behalf of a covered entity or business associate, it is itself a business associate. The parties must execute a HIPAA-compliant business associate agreement (BAA), and that obligation applies even if the provider stores only encrypted data and does not hold the key.
The same HHS page allows public, private or hybrid cloud configurations, provided the organization performs an appropriate risk analysis and establishes suitable safeguards and contractual responsibilities.
Shared responsibility has to be written down
The working distinction is simple. Your lab usually controls user authentication and authorization, and the provider secures the underlying infrastructure. Both parties must document their safeguards in the risk analysis and the BAA. "The cloud is encrypted" is a feature statement, not an accountability model.
A useful exercise before contract signature is a responsibility matrix with one row per control and three columns: the vendor, your lab, and evidence. Typical rows include:
- User provisioning and deprovisioning
- Multi-factor authentication and role design
- Key management and rotation
- Audit log retention and review
- Incident detection and notification
- Backup, restore and failover testing
- Subcontractor (sub-processor) oversight
Encryption is necessary, not sufficient
Encryption protects confidentiality. It does not by itself address integrity, availability, risk analysis, physical safeguards, access controls or disaster recovery, all of which HIPAA expects you to handle. Our article on encryption methods that fit a genomics pipeline covers at-rest, in-transit and field-level options in more detail.
If something does go wrong, notification clocks start quickly. See our overview of HIPAA breach notification requirements and plan the contact chain with your vendor before an incident, not during one.
SOC 2 and healthcare SaaS: what the report tells you
SOC 2 is an auditing framework from the AICPA that evaluates how a service organization handles customer data. Unlike HIPAA, which is law, SOC 2 is an attestation a vendor chooses to obtain, which is why buyers often ask for it before signing contracts, with Type II treated as the stronger form.
The difference between the two report types matters when you read one. Type I assesses whether controls are properly designed at a single point in time. Type II assesses whether those controls operated effectively over a defined period, typically six to twelve months. For a vendor holding genotype data, ask for the Type II report, the date range it covers and the list of trust services criteria in scope.
How to read a SOC 2 report
- Check the scope. Does the audited system include the product you are buying, or only a parent platform or a single data center?
- Check the period. A report that ended 14 months ago tells you less than one that ended last quarter. Ask for a bridge letter if there is a gap.
- Read the exceptions. Auditors note control failures. One exception in access reviews is a conversation, not necessarily a disqualifier.
- Read the complementary user entity controls. These are the controls the report assumes your lab performs. They are the other half of shared responsibility.
- List the subservice organizations. Cloud infrastructure providers are often carved out, so request their reports too.
SOC 2 and HIPAA overlap heavily on access controls, audit logging, risk management and vendor management, as the SOC 2 and HIPAA comparison from Software Secured lays out. Overlap is not equivalence, though. A clean SOC 2 report does not prove HIPAA compliance, and HIPAA has no certification scheme that a vendor can hand you.
ISO 27001 and genomics
ISO/IEC 27001 certifies that an organization runs an information security management system: a documented, audited process for assessing risk, choosing controls and improving them. It is common among vendors serving European and international customers, and it often sits alongside SOC 2 in procurement questionnaires.
Two cautions apply for genomics. First, the certificate's scope statement decides what it means. Confirm that the product, the hosting environment and the teams handling your data fall inside it. Second, neither ISO 27001 nor SOC 2 is specific to genomic data. NIST's genomic data project is explicit that its community profile offers a structured, risk-based approach through voluntary guidance rather than a genomics-specific certification. It names gaps in lifecycle protection, responsible sharing, monitoring of systems that process genomic data, and guidance tailored to genomic processors.
If you serve patients in the EU or UK, add the privacy layer. Genetic data is a special category under GDPR, and our guides on GDPR genetic data rules and the DPIA questions DPOs must answer show what auditors will look for.
Threat-model the workflow, not the bucket
NIST's draft threat-modeling guidance gives labs a practical method. Its process is to document architecture and dataflows, identify threats, apply controls and privacy safeguards, and iterate. It uses STRIDE for cybersecurity threats and PRAM or LINDDUN for privacy analysis. Four plain questions drive it: what are we building, what could go wrong, what controls address it, and did they work.
A GA4GH summary of NIST work and its own cloud work stream adds that cloud genomic workflows should explicitly map high-value dataflows, trust boundaries, interfaces, external partners, researcher code and sequencer connectivity.
For a PGx lab, a first pass often looks like this:
| Stage | Typical asset | Question to ask the vendor |
|---|---|---|
| Ingest | VCF or genotype file, sample metadata | How is data authenticated and encrypted on arrival, and who can read raw files? |
| Interpretation | Medication history, evidence database | Where does processing happen, and is it logged? |
| Review | Draft report, reviewer identity | Is sign-out tied to a named, authenticated reviewer with an audit trail? |
| Delivery | Report PDF, EHR message | Which interfaces carry PHI, and how are they secured? |
| Retention | Backups, archives | How long is data kept and how is deletion proven? |
Minimize movement
GA4GH's "compute to the data" model addresses the tension between collaboration and restrictions on moving data. Federated workflows can reduce transfers, but they still need strong identity, authorization, provenance, output review and local governance.
GA4GH standards also support fine-grained access. In its Beacon API release, Beacon supports open, registered and controlled access tiers. In a description of the Rakeiora platform, htsget retrieves only relevant genomic regions and Passports with AAI encode authorization. For PGx, the idea translates well: a report engine rarely needs an entire genome, so it should not receive one.
Disaster recovery for genomic data
Disaster recovery is a legal requirement, not only an engineering preference. The HIPAA Security Rule's contingency planning standard, 45 CFR 164.308(a)(7), calls for a data backup plan and a disaster recovery plan, and expects plans to be tested and assessed for effectiveness. Treat that as a continuing process rather than a one-time item.
When you evaluate a vendor, ask for these in writing:
- Recovery time objective (RTO): how quickly the reporting service returns after an outage.
- Recovery point objective (RPO): how much recent data, such as in-flight reports or review decisions, could be lost.
- Backup scope: are raw genotype files, medication histories, report versions and audit logs all included?
- Geography: where backups live, and whether that satisfies your residency commitments.
- Test evidence: the date and result of the last restore test, not just the existence of a plan.
- Integrity checks: how corrupted or tampered backups would be detected.
Also plan your side. If your reporting vendor is down, can your lab still release urgent results, and can you reconstruct which report version a clinician saw on a given date? That second question is why immutable audit trails matter. Our overview of audit trail rules under HIPAA, ONC and ASTM explains what a defensible record contains.
Healthcare SaaS SLAs: what to negotiate
An SLA is where security promises become measurable. There is no universal standard for healthcare SaaS, so read each clause against your own operations rather than accepting a headline uptime percentage. Points worth negotiating:
- Availability definition. Does uptime cover the report engine, the API and the delivery portal, or only the login page? Are scheduled maintenance windows excluded?
- Support tiers and response times. Distinguish severity levels, and confirm who answers when a clinician cannot open a report.
- Incident notification. Set a contractual timeline for telling you about a security incident that is shorter than your own regulatory deadline, so you have time to act.
- Remedies. Service credits are common, but they do not compensate for clinical disruption. Ask about termination rights for repeated failures.
- Data return and deletion. Require export in usable formats at exit and certified deletion afterward.
- Sub-processor changes. You should get notice before a new infrastructure or AI sub-processor touches your data.
- Audit rights. Define how and how often you can review evidence, and whether the vendor supports your own customer audits.
Putting these into a single procurement scorecard, with SOC 2, ISO 27001, BAA, DR evidence and SLA terms side by side, makes vendor comparison far less subjective.
Governance: the part technical controls cannot supply
A 2024 Nature Reviews Genetics perspective argues that genomic cloud governance must address transparency, security, equitable access and sustainable stewardship, not merely perimeter protection, because genomic data affects participants and potentially their biological relatives. For PGx programs, that translates into policies that define consent use, retention, secondary use, data residency, deletion, reanalysis and who communicates with patients.
Reanalysis deserves a specific mention. PGx recommendations change as guidelines evolve, so a lab that re-evaluates stored genotypes must decide, in policy, who authorizes it, how clinicians are notified and how the original report is preserved. Security and clinical governance meet at that point.
Our perspective
We build pharmacogenomics reporting infrastructure for laboratories, and the security questions we hear most are rarely about encryption algorithms. They are about accountability: who approved this report, which evidence version supported it, who could see the file, and what happens if the system fails on a Monday morning.
Our view is that a PGx platform should be judged on how it handles the whole chain. Genotype data and medication histories come in, evidence from multiple sources is reconciled, a medical director reviews and signs, and the report is delivered to a provider or patient. Each step needs authentication, an audit trail and a clear owner. That is why we keep clinicians in control of final approval and treat the audit trail as a core feature rather than an add-on.
We also think labs should resist the temptation to collect every certificate and stop there. Certifications are evidence, not outcomes. Ask vendors to show you the responsibility matrix, the last restore test and the sub-processor list. A vendor that answers those questions plainly is usually one you can work with for years.
— Tarek
Where SignalPGx fits
If your lab wants to launch its own branded PGx reporting service without building the infrastructure from scratch, our white-label PGx reporting platform is designed for that purpose. It supports HIPAA and GDPR compliance requirements, medical-director review with an audit trail, and EHR integration over HL7/FHIR, and white-label deployment typically takes 5 to 7 days. Plans are Pilot, Standard, Scale and Enterprise; pricing is provided on request.
For labs that need help with the security and integration design first, we offer project-based services through our main site: Discovery & Strategy from $7,000, System Design from $9,000 and Deployment & Integration from $15,000, each one-off per project. Before any of them, we are happy to walk through your responsibility matrix with you. For EHR connectivity specifically, start with how to map one gene-drug pair in FHIR first.
FAQ
Is SOC 2 required for a healthcare SaaS vendor?
No law requires it. HIPAA requires a BAA and safeguards, while SOC 2 is a voluntary attestation. In practice many lab and health system buyers ask for a SOC 2 Type II report before approving a vendor, so a vendor without one will face more scrutiny.
Does ISO 27001 certification make genomic data safe?
It shows that a vendor runs a managed, audited security program within a defined scope. It does not address genomic-specific risks on its own, so check the scope statement and pair it with threat modeling of your actual dataflows.
Do we need a BAA if the cloud provider only stores encrypted data?
Yes. HHS guidance says a cloud provider that maintains ePHI for you is a business associate even when it lacks the decryption key. Execute a BAA and document each party's safeguards in your risk analysis.
What should a disaster recovery plan for a genomics lab include?
HIPAA's contingency standard calls for a data backup plan and a disaster recovery plan that are tested and assessed. Add stated RTO and RPO targets, coverage of raw data, reports and audit logs, backup location, and dated restore-test results.
Sources
- Cybersecurity of Genomic Data, NIST IR 8432
- Genomic Data Threat Modeling, NIST SP 1800-43 draft
- Cybersecurity and Privacy of Genomic Data, NCCoE
- Guidance on HIPAA and Cloud Computing, HHS
- GA4GH Cloud Work Stream: compute to the data
- GA4GH and ELIXIR Beacon API v1.0
- GA4GH standards in the Rakeiora Genomics Platform
- Ethical governance for genomic data science in the cloud, Nature Reviews Genetics
- SOC 2 Type II for Healthcare SaaS, VertiComply
- SOC 2 vs HIPAA comparison, Software Secured
- HIPAA Rules on Contingency Planning, HIPAA Journal