A Cancer Diagnostics Lab Answers CAP, CLIA, and ISO 13485 Audits From Files.com

A clinical cancer diagnostics laboratory runs a test that detects circulating tumor DNA at extremely low concentrations. That sensitivity has put its minimal residual disease data into clinical practice and into prospective trials that inform treatment decisions for patients. Dozens of biopharma and academic partners use the lab's CLIA-certified facility to run MRD testing as an endpoint in their clinical programs.

That business model has a consequence: the lab's product is data that leaves the building. Patient blood samples arrive by courier, get accessioned, and go into the sequencers. Somewhere in that workflow, the data becomes protected health information. The results then travel back out to the drug developer running the trial. A lab regulated under CLIA and CAP, with ISO 13485 in partner-audit scope, is accountable for every system that data touches on its way out, and that includes the transfer layer itself.

Results Measured in Terabytes, Delivered Across a Trust Boundary

The deliveries are large. Single files run to hundreds of gigabytes and aggregate data sets to tens of terabytes, drawn from petabytes of data in the lab's Google Cloud storage. Before standardizing, that data reached partners several different ways, from direct work inside client-owned cloud buckets to mirror jobs copying data from bucket to bucket, each followed by a manual notification to the client.

The lab wanted one governed path for those deliveries, with retention, access control, and logging built into the path itself. A lab whose partners audit against CAP, CLIA, and ISO 13485 at once has to answer for how results reach a partner, what is retained, and for how long, and the lab wanted those answers to come from the transfer layer.

The data itself was not going to move. Petabytes of sequencing output live in object storage, and every partner exchange crosses a trust boundary to a company the lab does not control. What the lab needed was a properly constituted, highly secured SFTP service sitting over the object storage that already held client data: a sanctioned path out of the lab. The lab deployed Files.com as that layer. When a partner audit later spanned CAP, CLIA, and ISO 13485, an administrator who had not built the deployment pulled its backup, retention, and lifecycle documentation directly from the platform.

An SFTP Service Over the Buckets the Lab Already Ran

Using Files.com Remote Server Mounts, the lab fronted its Amazon S3 and Google Cloud storage with governed folders. The sequencing data stays in the buckets the lab already pays for, and everyone works against a folder view over SFTP and the web. Partner and client accounts get download-only access to the results staged for them. Internal users are provisioned from Okta through SCIM and sign in with SSO, while every external account carries enforced MFA. When results land, Files.com sends each partner a customized upload notification automatically. Nobody sends a manual notification after an upload anymore. An executed Business Associate Agreement covers the workflow in which results return to a pharma partner as PHI.

Two Sanctioned Ways to Move a File, by Written Policy

The lab then made the path exclusive. A written, company-wide policy states that transfers happen exactly two ways: over a partner's own SFTP process if it passes the lab's security audit, and over the lab's Files.com site otherwise. The policy is globally accepted across the company.

The same discipline covers the evidence. Retention and deleted-file lifecycle settings are configured in Files.com and documented for auditors. Every login, download, and permission change streams through the Files.com SIEM connector into Rapid7, so the security team reviews transfer activity in the same pane as the rest of its logs instead of in one more console.

A Three-Framework Audit, Answered by an Administrator Who Didn't Build It

With Files.com in production, the lab had replaced several delivery paths with one governed path that generates its own evidence. In October 2025, that evidence got tested. A partner audit spanning CAP, CLIA, and ISO 13485 reviewed the lab's systems, and Files.com stood in scope as one of the named key systems.

The person answering the auditors was an administrator who had not designed the deployment. The backup, retention, and lifecycle documentation came directly from the platform.

Producing that evidence on demand is the sharpest proof, and it sits on top of a broader set of changes:

• Audit evidence comes off the platform: retention, lifecycle, and backup documentation pulled on demand by an administrator who had not built the system.
• The manual notification step is gone: partners learn the moment their results are staged, automatically, with the delivery itself on the record.
• Reviewing the transfer layer requires no extra console: every Files.com event lands in Rapid7 alongside the rest of the security team's log estate.
• The scale runs through the layer without living on it: Files.com moves terabytes a month while the data itself stays in the lab's own cloud storage, fronted in place.

The policy compounds from there. Every new partner engagement lands on one of the two sanctioned paths, so each one inherits the same retention rules, the same logs, and the same trail. The next audit cycle starts with its evidence already accumulating.

Evidence as a By-Product, Not a Project

Today, when an auditor asks the lab how results reach a partner, what is retained, and for how long, the answer is a written policy and documentation pulled from Files.com. The evidence was never prepared for the audit, because it is a by-product of the platform the transfers already run on, and that is why it survived a change of hands: producing it required knowing Files.com, not knowing the history. For a regulated lab, the transfer layer does not have to be the thing you explain to auditors. At the lab, it became the system of record they audit against.