Foresight Diagnostics Delivers Cancer Genomic Data Into Any Client Cloud With Files.com

Foresight Diagnostics finds cancer in a blood draw. Its sequencing technology, developed at Stanford, detects circulating tumor DNA at concentrations below one part per million, sensitive enough to catch minimal residual disease long before a scan could. From its CLIA-certified lab in Boulder, Colorado, 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 400 GB, and the data sets behind an engagement reach 50 TB. 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. Foresight's product had to land, again and again, in storage Foresight did not own.

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

Before Files.com, delivery meant Foresight 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 Foresight's team worked from across the country. Counterparty competence varied just as widely: some large pharmaceutical partners could not produce working bucket credentials at all. 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 someone without cloud training working inside a client's bucket can do real damage with one wrong delete or one mishandled path. That left JP Younis, Foresight's VP and Head of Information Technology and Security, with three bad options: teach the entire team cloud engineering, personally stand between his team and every transfer, or watch client credentials and API keys spread across the company. And because the work happened inside client storage, Foresight was on the hook for file types, sizes, and deletion rules in environments it did not control.

The diagnosis was simple: Foresight 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 level of counterparty skill. Handled by hand, every new client made the problem bigger.

Storage Foresight Would Never Own or Control

The obvious fixes did not apply. Foresight could not consolidate the storage, because the buckets belong to the clients, and a diagnostics 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 Foresight'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 Foresight 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. Foresight selected Files.com to be that front end.

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

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

Using Files.com Remote Server Mounts, Foresight 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. In a recent 30-day period the site moved roughly 4 TB of data while holding only about 50 GB of resident storage, because the files are fronted in place rather than copied. Transfers between Foresight's own cloud storage and partner buckets run through the same platform, replacing the old mirror scripts.

The credential problem disappeared with the buckets. Only one person at Foresight holds cloud keys, and client API keys never circulate. Everyone else works at the folder level.

“I don't have to teach anybody how to be an engineer. If they can just see a folder like Box and not know what goes on behind the scenes, that's ideal.”

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.

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

From One Transfer to a Company-Wide Model

With the gateway in production, Foresight 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 several times over.

“If I hadn't bought Files.com when I did, this data transfer to our client would have been a total cost of a fortune.”

A whole category of risk is gone. No one at Foresight operates inside a client's bucket, cloud keys sit with a single owner, and client API credentials no longer spread through the company. Nobody had to become a cloud engineer, and nobody emails clients by hand after an upload. Foresight 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.

“This has definitely paid for itself so far.”

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 however well the client runs it, Foresight 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 his team and every foreign bucket now requires him only to hold the keys.

That is the durable change. Foresight 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.