Secure Data Sharing in the Cloud for Collaborative Genomics

Q: How do I audit who accessed the data?

Enable CloudTrail data events or the equivalent on your provider so every object-level GET, PUT, and DELETE is recorded, and review the logs on a schedule. Auditing for inappropriate data use is standard on NIH-supported platforms.

By Dr. Zubair Khalid, DVM, MS, PhD · 2026-11-11

Secure Data Sharing in the Cloud for Collaborative Genomics

By the end of this guide you will be able to design a governed sharing arrangement for human genomic data, provision a controlled-access workspace on Amazon Web Services (AWS) with real commands, verify that the controls actually hold, and decide whether your collaboration should copy data, analyze it in place, or adopt a federated model. The walkthrough uses the AWS Command Line Interface (CLI) version 2, an AWS account with administrative access, a collaborator's AWS account ID, and a dataset stored as CRAM or BAM plus index files. If your institution already uses a managed platform such as Terra, Galaxy, or Dockstore within the AnVIL ecosystem, the same governance logic applies even though the commands differ [1].

Genomic data is unusually hard to share safely. A human genome can reveal sensitive information and is potentially re-identifiable, which makes it a category of data that many privacy laws treat differently from ordinary research records [2]. At the same time, modern genomics is a team sport. Studies such as the Pan-Cancer Analysis of Whole Genomes brought together petabyte-scale datasets from centers in different countries and jurisdictions, something that is only practical when analysis happens on flexibly scalable infrastructure [3]. The central problem of secure data sharing in the cloud for collaborative genomics is reconciling those two facts: the data must be reachable by collaborators, and it must be unreachable by everyone else.

Why Genomic Data Needs More Than Standard Cloud Security

Commercial cloud service providers (CSPs) let research groups grow their IT infrastructure on demand and overcome the bottlenecks that appear when several institutions combine large datasets. That elasticity is exactly why cloud bioinformatics took over large-cohort analysis. The catch, documented across the genomics literature, is that without adequate security controls the risk of unauthorized access can be higher for data stored on the cloud, and regulators increasingly mandate specific access patterns and security protocols for genomic data [4].

Three properties make genomic data a special case:

Re-identifiability. Even "de-identified" genomes can be matched back to individuals, which is why privacy researchers have run dedicated community competitions, such as the Critical Assessment of Data Privacy and Protection series, to stress-test sharing mechanisms including beacon services, cross-institution similarity search, and data outsourcing to public clouds [2].
Scale. Massively parallel sequencing generates data volumes that overwhelm institutional storage. Early validated pipelines such as Mercury, deployed both on local hardware and on the AWS cloud through the DNAnexus platform and applied to more than 10,000 whole-genome and whole-exome samples, demonstrated why groups moved: the cloud absorbed peak compute demand and made coordinated, secure access for multiple analysts practical [5].
Legal divergence. Different legal systems understand data protection differently. Outsourcing IT to a cloud provider can place researchers in a jurisdictional gray zone because local regulations do not always map cleanly onto where the bytes physically sit [3]. In Europe, the General Data Protection Regulation (GDPR) has pushed many archives away from centralized repositories toward federated models in which each node keeps control of its own data [6].

Surveys of genomics researchers, patient advocates, and cloud providers found that adoption is gradual and gated by persistent security and cost concerns, unfamiliarity with the technology, and researchers' own legal responsibility for data stored off site [7]. Those concerns are legitimate. The response is not to avoid the cloud but to build the governance layer deliberately.

Governance Models for Secure Data Sharing in the Cloud

Technology alone does not make sharing secure. The field has converged on governance frameworks that specify who may do what, for which purpose, under which agreement. You should choose one of these frameworks before you create a single bucket.

The five-safes framework

RAPTOR, the cloud-native genomics repository built by the Genome Institute of Singapore, implements a "five-safes" framework to give data contributors and users security and governance controls while leveraging a CSP for sharing and analysis. The five safes ask five questions about a proposed data use: Is the project safe (appropriate purpose)? Is the setting safe (secure environment)? Is the data safe (appropriately de-identified or protected)? Is the access safe (right person)? Is the output safe (no re-identification or disclosure in results)? The value of the framework is that it converts vague policy language into checklist items that can each be implemented as a technical or administrative control [4].

Federated platforms that bring code to data

The NHGRI AnVIL platform inverted the traditional model of genomics data sharing. Instead of shipping data to each researcher, AnVIL brings analysis to the data. It is a federated cloud platform built on Terra, Gen3, Galaxy, RStudio/Bioconductor, Dockstore, and Jupyter, designed to eliminate routine data movement while adding security measures for active threat detection and monitoring and providing scalable shared computing resources [1]. Federated platforms more broadly are emerging as key resources for sharing without physically moving data outside its organizational or jurisdictional boundaries, which matters enormously for GDPR-covered cohorts and for improving representation of underrepresented groups [8].

Access governance as a formal process

A landscape analysis of five NIH-funded cloud platforms (the All of Us Research Hub, NHGRI AnVIL, NHLBI BioData Catalyst, NCI Genomic Data Commons, and the Kids First Data Resource Center) plus dbGaP found real convergence on the mechanics of governance. All platforms relied on a formal data ingestion process, multiple tiers of data access with varying authentication and authorization requirements, platform and user security measures, and auditing for inappropriate data use. The platforms differed mainly in how data tiers were organized and in the specifics of authentication across tiers [9]. The lesson for your own project is that the differences between well-run platforms are small at the control level. You should expect to implement ingestion review, tiered access, and auditing regardless of which infrastructure you pick.

For groups that lack the resources to run controlled access themselves, reusable middleware helps. DS-PACK, in production at ELIXIR Luxembourg, semi-automates the end-to-end controlled access process from data submission to access approval, centralizes access control management, distributes enforcement, and supports cloud-based application access, all with data protection principles built into the components [6].

Choosing an Architecture

A short decision path asking whether data can leave the institution, whether a joint analysis is needed, and whether sensitivity is high.

Four architectures cover nearly every real collaboration. The table below summarizes them.

Architecture	How it works	Data movement	Best for	Main risk
Copy-based sharing	Data owner exports files, collaborator stores them locally or in their own cloud	Full copy leaves your control	Small, fully pinned-down agreements, public data	Copies proliferate beyond the agreement
Shared workspace	Both parties compute in one cloud environment, such as a Terra workspace or a shared AWS account	No copy to the collaborator's site	Active joint analysis on controlled-access data	Shared-account misconfiguration
Model-to-data (bring code to data)	Collaborator submits an algorithm that runs where the data sits, results are reviewed and released	No data movement at all	Data that cannot leave an institution or jurisdiction [10]	Slower iteration, output leakage must be reviewed
Encrypted computation	Analysis runs on encrypted data using cryptographic methods	Data is outsourced in encrypted form	High-sensitivity outsourcing scenarios	Computational overhead, immature tooling for large pipelines

Model-to-data deserves a note. Pilots have demonstrated its utility when technical or legal constraints preclude other methods, but it should supplement rather than replace ordinary sharing, and it needs governance so that submitted models cannot leak data through their outputs [10].

Encrypted computation is advancing quickly. Community competitions hosted by the NIH-funded iDASH center have driven practical algorithms for outsourcing genome computation so that analyses run only on encrypted data [11]. Subsequent work has produced secure count queries on encrypted genomic data that handle both genotype and phenotype under privacy regulations such as HIPAA and PIPEDA in a semi-honest cloud model [12], and prefix-tree indexing schemes that support similar-patient queries with guarantees for data privacy, query privacy, and output privacy at speeds fast enough for real biomedical applications [13]. For most labs today these techniques remain complements to, rather than substitutes for, well-governed workspace sharing.

Step-by-Step: Building a Controlled-Access Sharing Workspace on AWS

This walkthrough provisions a minimal, auditable, controlled-access bucket for a human genomic dataset and grants one collaborator's compute environment read access without download rights. The pattern is the same one used, in more elaborate form, by validated AWS genomics deployments such as Mercury on DNAnexus [5]. It reflects the shared-responsibility principle: the CSP provides security tooling, but building the controls required for a compliant solution remains the customer's job, and it is not trivial [4].

Step 1. Isolate the environment

Create a dedicated AWS account for the dataset, separate from your lab's general account, and place it in AWS Organizations. Isolation means a mistake in one account cannot expose data in another, and you can hand the account's credentials to a small, named group.

aws organizations create-organization --feature-set ALL
aws organizations create-organizational-unit \
  --root-id o-xxxxxxxxxx \
  --name genomics-controlled-access

Expected output is a JSON block containing the new organizational unit ID and Amazon Resource Name (ARN). Record the ARN. If the command fails with ConstraintViolationException: The organization must have all features enabled, rerun with -feature-set ALL as shown.

Step 2. Create the bucket with encryption and public access blocked

Genomic files must be encrypted at rest with a key you control, and public access must be blocked at both the bucket and account level. Create a customer-managed KMS key first so that CloudTrail logs every decryption.

aws kms create-key \
  --description "key for controlled-access genomics bucket" \
  --key-usage ENCRYPT_DECRYPT

Note the KeyId in the JSON output. Then create the bucket and lock it down:

aws s3api create-bucket \
  --bucket mylab-genomics-controlled-2026 \
  --region us-east-1

aws s3api put-public-access-block \
  --bucket mylab-genomics-controlled-2026 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

aws s3api put-bucket-encryption \
  --bucket mylab-genomics-controlled-2026 \
  --server-side-encryption-configuration \
  '{"Rules":[{"ApplyServerSideEncryptionByDefault":{"SSEAlgorithm":"aws:kms","KMSMasterKeyID":"arn:aws:kms:us-east-1:123456789012:key/EXAMPLE-KEY-ID"},"BucketKeyEnabled":true}]}'

aws s3api put-bucket-versioning \
  --bucket mylab-genomics-controlled-2026 \
  --versioning-configuration Status=Enabled

BucketKeyEnabled reduces the volume of KMS requests for large objects, which matters because a single whole-genome CRAM can be many gigabytes and alignment-index operations issue repeated reads. Verify the configuration before uploading anything:

aws s3api get-public-access-block \
  --bucket mylab-genomics-controlled-2026

Expected output:

{
    "PublicAccessBlockConfiguration": {
        "BlockPublicAcls": true,
        "IgnorePublicAcls": true,
        "BlockPublicPolicy": true,
        "RestrictPublicBuckets": true
    }
}

If any value is false, fix it before proceeding. A common error at this stage is InvalidArgument: Requests specifying Server Side Encryption with AWS KMS keys require AWS Signature Version 4, which appears when a client uses the older signature version. Configure the AWS CLI with aws configure set default s3.signature_version s3v4.

Step 3. Turn on access logging

Auditing for inappropriate data use is a defining feature of every well-governed platform surveyed in the NIH landscape analysis [9], and active threat detection is a stated design goal of the AnVIL platform [1]. On AWS the floor is CloudTrail data events for the bucket plus server access logging.

aws cloudtrail create-trail \
  --name genomics-access-trail \
  --s3-bucket-name mylab-genomics-controlled-2026

aws cloudtrail put-event-selectors \
  --trail-name genomics-access-trail \
  --event-selectors '[{"ReadWriteType":"All","IncludeManagementEvents":true,"DataResources":[{"Type":"AWS::S3::Object","Values":["arn:aws:s3:::mylab-genomics-controlled-2026/"]}]}]'

Expected output echoes the trail ARN and the event selector. From this point every GET, PUT, and DELETE on an object under that prefix is recorded.

Step 4. Grant the collaborator a least-privilege role

The core design decision: the collaborator can compute on the data but cannot download it to arbitrary destinations. Create a role that their compute instances assume, with three conditions: requests must come from their organization, from a specified VPC endpoint, and uploads must stay encrypted.

Trust policy (collaborator-trust.json):

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": {"AWS": "arn:aws:iam::987654321098:root"},
    "Action": "sts:AssumeRole",
    "Condition": {
      "StringEquals": {"aws:PrincipalOrgID": "o-xxxxxxxxxx"}
    }
  }]
}

Permission policy (collaborator-access.json):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:ListBucket"],
      "Resource": [
        "arn:aws:s3:::mylab-genomics-controlled-2026",
        "arn:aws:s3:::mylab-genomics-controlled-2026/collab-A/*"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceVpce": "vpce-0123456789abcdef0",
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    },
    {
      "Effect": "Deny",
      "Action": ["s3:PutObject"],
      "Resource": "arn:aws:s3:::mylab-genomics-controlled-2026/*",
      "Condition": {
        "StringNotEquals": {
          "s3:x-amz-server-side-encryption": "aws:kms"
        }
      }
    }
  ]
}

Apply them:

aws iam create-role \
  --role-name collab-A-compute-reader \
  --assume-role-policy-document file://collaborator-trust.json

aws iam put-role-policy \
  --role-name collab-A-compute-reader \
  --policy-name collab-A-s3-read \
  --policy-document file://collaborator-access.json

Each parameter matters. aws:PrincipalOrgID restricts assumption to principals inside your AWS Organization, so a leaked ARN alone is useless to outsiders. aws:SourceVpce keeps traffic inside a private VPC endpoint path rather than the public internet. The s3:x-amz-server-side-encryption conditions prevent anyone from writing unencrypted objects into your bucket. The prefix restriction (collab-A/*) scopes the collaborator to their slice of the project, mirroring the tiered-access pattern seen across NIH platforms [9].

Step 5. Upload data with integrity checks

A worked calculation showing a 30 GB CRAM at 12.5 megabytes per second taking about 2,400 seconds, roughly 40 minutes.

Use checksums so both sides can verify the transfer independently.

aws s3 cp ./cohort-A/ s3://mylab-genomics-controlled-2026/collab-A/ \
  --recursive \
  --sse aws:kms \
  --checksum-algorithm SHA256

Expected output lists each file with an upload: ... line and ends with a summary such as Completed 30 objects. As a worked sizing example, a 30 GB CRAM transferred over a 100 megabit-per-second link at 12.5 megabytes per second takes roughly 2,400 seconds, about 40 minutes. Plan overnight windows for cohorts, or use AWS Snowball-style physical transport when the dataset exceeds what your uplink can move in a maintenance window. Verify after upload:

aws s3api head-object \
  --bucket mylab-genomics-controlled-2026 \
  --key collab-A/sample01.cram

The JSON response includes ChecksumSHA256, ServerSideEncryption set to aws:kms, and object size. Compare the size against the source file with ls -l.

Step 6. Let the collaborator compute in place

The collaborator launches their analysis instances in a VPC attached to the endpoint, assumes the role, and runs the workflow against the bucket without any download step. This is the same "bring the analysis to the data" inversion that underpins AnVIL and that eliminates routine data movement while adding security monitoring [1].

aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/collab-A-compute-reader \
  --role-session-name collab-A-analysis

The output contains temporary AccessKeyId, SecretAccessKey, and SessionToken credentials. The collaborator exports them as environment variables and runs their pipeline. Because the policy grants no s3:GetObject outside the VPC endpoint, a copy attempt from a laptop fails.

Step 7. Verify the controls

Never trust configuration you have not tested. Run the IAM policy simulator against the new role:

aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/collab-A-compute-reader \
  --action-names s3:GetObject s3:PutObject \
  --resource-arns arn:aws:s3:::mylab-genomics-controlled-2026/collab-A/sample01.cram

Expected output shows allowed for s3:GetObject and denied for s3:PutObject on a read-only arrangement. Then confirm from outside the VPC that access fails, and confirm that a CloudTrail lookup shows the denied attempts:

aws cloudtrail lookup-attributes \
  --lookup-attributes AttributeKey=ResourceName,AttributeValue=mylab-genomics-controlled-2026

This last command is your audit trail. Well-governed platforms treat it as evidence of responsible stewardship, the ethical and secure management of data across its lifecycle that repositories use to demonstrate trustworthiness [14].

Practical Tips for Day-to-Day Operations

These secure data sharing genomics cloud tips come from the failure modes that recurring surveys and competition reports keep identifying.

Scope every grant to a prefix. Bucket-wide permissions are the most common over-grant. NIH platform analyses found access tiering with explicit boundaries everywhere it is done well [9].
Write the agreement before the policy. The five safes start with a safe project and a safe people assessment, not with a firewall rule. Your IAM policy should encode a decision your data access committee already made.
Federate when jurisdiction matters. If data cannot lawfully leave an institution or country, a federated arrangement where the central node handles discovery and distributed nodes handle access decisions is the GDPR-aligned pattern [8], [6].
Treat encryption as one layer, not the whole answer. Insider threats, application vulnerabilities, inadequate provider-side measures, and loss of visibility are all distinct challenge categories identified in healthcare cloud cybersecurity reviews [15]. Encrypting at rest does not neutralize a compromised collaborator account.
Use standardized, containerized workflows. Dockstore-style workflow sharing inside platforms like AnVIL lets collaborators run the identical, validated pipeline rather than re-implementing it, which reduces both error and the temptation to export raw data for local reprocessing [1].
Keep open data separate. Summary statistics and annotations can often be served from an open tier, as NIAGADS does with open-access knowledge bases alongside its FISMA-moderate controlled-access sharing service that fully supports the NIH Genomic Data Sharing Policy [16]. Splitting tiers reduces the surface you must defend.
Document participant-facing commitments. Population-scale cohort projects increasingly depend on FAIR data management and participant trust, so your technical controls should map cleanly onto what participants were told [17].

Common Mistakes and Limitations

These are the secure data sharing genomics cloud common mistakes that appear again and again in real deployments.

Relying on the provider's compliance for your compliance. CSPs supply the tools, but building the controls required for a compliant solution is the customer's work and is not trivial [4]. A HIPAA-eligible service is not automatically a HIPAA-compliant deployment.
Copying data when computing in place would do. Every copy multiplies the number of environments you must secure and the jurisdictions you must reason about [3]. The AnVIL design goal of eliminating data movement exists precisely because copies are the dominant leak path [1].
Overbroad IAM policies. A wildcard s3: on arn:aws:s3::: is an incident waiting to happen. Scope by prefix, and use a Deny statement on unencrypted writes as a backstop.
Skipping the verification step. Configurations drift. Re-run get-public-access-block and the policy simulator after every change, and review CloudTrail data events weekly. Auditing for inappropriate data use is standard practice on mature platforms [9].
Ignoring use-scope drift. Analyses involving multiple institutions carry the specific risk of data being processed beyond the agreed research scope or in untrusted environments [11]. Your technical controls should make out-of-scope actions impossible, not merely prohibited.
Treating privacy as a purely technical problem. The privacy-technique competitions that benchmark beacon privacy, secure similarity search, and cloud outsourcing exist because each new sharing mechanism creates a new attack surface [2]. Re-identifyability persists even when files are encrypted in transit and at rest.
Underestimating shared-infrastructure risk. Multi-tenant cloud environments introduce challenge categories such as shared infrastructure vulnerabilities and limited visibility that you cannot fully eliminate, only monitor and mitigate [15].
Forgetting the human layer. Researchers' legal responsibility for stored data, and their unfamiliarity with cloud technology, are documented adoption barriers [7]. Budget time for training the collaborators, not just configuring the bucket.

A final limitation: this walkthrough gives you sound technical scaffolding, but every real project needs review by your institution's legal and compliance officers before human genomic data moves. Jurisdictional analysis is fact-specific [3]. Also note that infrastructure costs vary by region, usage pattern, and negotiated agreement, so no figures are quoted here.

Frequently Asked Questions

Is it safe to store human genomic data in the cloud?

Yes, when security controls and governance are deliberately built on top of the provider's platform. The risk of unauthorized access is higher only when adequate controls are missing, which is why frameworks like five-safes and formal ingestion, tiered access, and auditing processes exist [4], [9].

What is the five-safes framework?

It is a governance checklist asking whether the project, setting, data, access, and outputs are each safe. RAPTOR implements it as a cloud-native genomics repository so contributors and users share data without security breaches or regulatory missteps [4].

Should I copy data to my collaborator or keep it in place?

Keep it in place whenever you can. Federated platforms eliminate routine data movement, add threat detection, and keep data inside its jurisdiction, while copies multiply security and legal exposure [8], [1], [3].

How do I let a collaborator compute on my data without letting them download it?

Combine an IAM role scoped to a data prefix with conditions that require a VPC endpoint and organizational membership, and grant no egress-friendly permissions. The role-assumption pattern shown above enforces compute-only access and every attempt is logged.

What encryption should I use for genomic data in cloud storage?

Use server-side encryption with a customer-managed KMS key, enable bucket keys for large files, and enforce it with policy conditions so unencrypted writes are denied. Client-side or cryptographic computation methods add protection for high-sensitivity outsourcing scenarios [12], [11], [13].

How do I audit who accessed the data?

Enable CloudTrail data events (or the equivalent on your provider) so every object-level GET, PUT, and DELETE is recorded, and review logs on a schedule. Auditing for inappropriate data use is standard on NIH-supported platforms [9].

Can encrypted computation replace normal access controls?

Not yet as a full replacement. Secure queries on encrypted genomic data work for specific tasks such as count queries and similar-patient search, but full-scale pipelines still rely primarily on governed workspace sharing [12], [11], [13].

Do I need a special platform, or is plain AWS enough?

Either works. Plain cloud accounts give maximum control but demand that you build every control yourself, while platforms like AnVIL provide federated storage, shared computing, and access management out of the box [1]. Match the choice to your team's capacity and your funder's data sharing policy.