A Cancer Genomics Lab Delivers Sequencing Results Into Any Client Cloud With Files.com

A cancer genomics lab finds cancer in a blood draw. Its sequencing technology detects circulating tumor DNA at minute concentrations, sensitive enough to catch minimal residual disease long before a scan could. From its CLIA-certified lab, the company runs patient blood samples through sequencers and returns results to the biopharmaceutical companies that use them as endpoints and enrollment biomarkers in clinical trials.

The deliverable of that business is data. A single sequencing file can run to hundreds of gigabytes, and the data sets behind an engagement reach tens of terabytes. And every one of those engagements ends the same way: results delivered into the client's own cloud storage, under the client's own security rules. The lab's product had to land, again and again, in storage the lab did not own.

Every Client Arrived With Its Own Cloud, on Its Own Terms

Before Files.com, delivery meant lab staff working directly inside client-owned buckets. One client kept its data in S3, another in Google Cloud Storage, another in Azure, each with its own credentials and its own restrictions. One client locked its bucket to a single whitelisted IP address while the lab's team worked from across the country. Every engagement began with a fresh round of credential setup. Data moved between clouds through bucket-to-bucket mirror transfers, and after every upload, someone on the client-services team emailed the client by hand to say the files had arrived.

The cost landed on people, not just process. The staff doing this work are lab scientists and client-services professionals, not cloud engineers, and the company wanted them working in ordinary folders rather than inside a client's cloud console. That left the company's head of IT and security with two bad options: teach the entire team cloud engineering, or personally stand between the team and every transfer. And because the work happened inside client storage, the company was on the hook for file types, sizes, and deletion rules in environments it did not control.

The diagnosis was simple: the company had outgrown per-client cloud handling. These are long-term pharma partnerships moving tens of terabytes over years, and each new one arrived with a different cloud, a different credential set, and a different set of access restrictions. Handled by hand, every new client made the problem bigger.

Storage the Lab Would Never Own or Control

The obvious fixes did not apply. The company could not consolidate the storage, because the buckets belong to the clients, and a genomics lab does not dictate a pharmaceutical company's cloud architecture. It could not relax the restrictions, because the single-IP whitelist was the client's security policy, not the company's. And building a custom integration per client would compound rather than scale: every new partner would add another credential set, another cloud's behavior, and another piece of machinery only IT understood.

What the lab needed was a layer that sat in front of any client's S3, Google Cloud, or Azure storage without moving the data. It had to present that storage as ordinary folders to people who would never touch a cloud console. It had to keep every cloud key and client API credential contained with a single owner. It had to give partner-side users a governed way to pull results over SFTP, and it had to tell clients automatically when files were ready. The company selected Files.com to be that front end.

A Folder View Over Every Client's S3, Google Cloud, and Azure

Files.com became the lab's multi-cloud gateway: the client's storage stays exactly where it is, the keys stay with the IT team, and everyone else sees folders.

Using Files.com Remote Server Mounts, the company connected client-owned S3, Google Cloud Storage, and Azure directories into its Files.com folder tree. Lab and client-services staff stage and retrieve results in what looks like an ordinary shared folder; behind it, every read and write goes straight to the client's bucket. Most data never lands on Files.com at all. The site moves far more data than it ever holds, because the files are fronted in place rather than copied. Transfers between the company's own cloud storage and partner buckets run through the same platform, replacing the old mirror scripts.

The credential problem disappeared with the buckets. Cloud keys are held by the company’s IT team alone, and client API keys never circulate. Everyone else works at the folder level.

Client users receive governed, download-only SFTP and FTP accounts, with MFA enforced for every external account. Internal users are provisioned through Okta SSO with SCIM, so accounts follow the directory and access ends when employment does. The manual emails from the client-services mailbox are gone: Files.com upload notifications now tell clients automatically when files are ready.

The company's head of IT then made the new path the only path by writing a company-wide transfer policy with exactly two options: a partner's own SFTP process, if it passes the company's security audit, or the company's Files.com site. The policy was adopted across the company.

From One Transfer to a Company-Wide Model

With the gateway in production, the company replaced hand-worked bucket access and manual notification email with one governed folder interface its whole team could use. The model spread from the founding engagement to results sharing across the company, while both the user base and the number of outbound cloud connections grew substantially.

A whole category of risk is gone. No one at the company operates inside a client's bucket, cloud keys sit with a single owner, and client API credentials stay with that owner. Nobody had to become a cloud engineer, and nobody emails clients by hand after an upload. The company also stopped carrying responsibility for file rules inside storage it does not control.

Onboarding the next pharma partner is now a mount and a set of accounts, not an integration project.

Saying Yes to Any Client's Cloud

Today, a new pharma partnership does not open with an argument about bucket credentials. Whatever cloud the client runs, and whatever restrictions it places on access, the lab mounts the storage behind Files.com, a lab scientist drops results into a folder, and the client's team gets an automatic notification that the files are ready. What once required the head of IT to stand personally between the team and every foreign bucket now requires the head of IT only to hold the keys.

That is the durable change. The lab established a repeatable way to serve every client's storage on the client's own terms: front the buckets in place, keep the credentials with one owner, and let everyone else see folders.