A Telehealth Services Company Replaces Per-Client AWS S3 Buckets With a Files.com Portal for PHI Intake

A telehealth services company runs the machinery behind other organizations' telehealth. Clients bring the brand; the company supplies the clinicians, the compliance operations, and the technology to deliver virtual care programs. Its employer clients use those programs to offer telehealth to their workforces.

The employer side of that business has a fixed opening move. An employer signs on to offer telehealth to its workforce, and the first thing it sends the company is an employee roster: names and email addresses, personal data carrying HIPAA obligations, so the company can reach those employees with health program outreach. Every new employer relationship begins with sensitive data crossing into the company's hands. The company wanted a purpose-built place to receive it.

A Hand-Built S3 Bucket for Every Sensitive Exchange

The company is cloud-native and AWS-first, and before Files.com every external exchange was a per-client build. When an outside party needed to exchange files, IT built the exchange by hand: a fresh AWS S3 bucket for that one counterparty, with its own credentials and access setup, assembled per case and maintained per case.

The heavier cost landed on the client side of the exchange. The person sending a roster is an HR contact at an employer, not a cloud engineer. Raw S3 gave that person no page to log into and nothing that looked like the company they had signed with. Reaching a single file meant clicking through several different AWS services.

The gap was structural, not a matter of better bucket hygiene. Raw object storage is not a client-facing exchange surface. It has no web experience an outsider can use and no simple external-account model, and building both on top of AWS would have meant standing up and maintaining a portal layer for a workflow that repeats with every new client. The identity problem split in two on top of it: the company's staff live in Okta, and a client's HR contact never will.

While external exchange stayed rare, a per-client build was manageable. As employer clients made it routine, the company wanted a repeatable, client-facing way to receive the most sensitive files the business touches.

Employer Onboarding Starts With a File Full of PHI

As the company added employer clients, each new relationship created another secure exchange relationship. A per-case infrastructure build could not be the way each of those relationships opened.

What the fix had to do was clear before any product entered the picture. Each client needed its own space to drop files into and retrieve files from, sealed off from every other client's data. The experience had to be a simple web page an outsider could use, under the company's own name rather than a cloud vendor's console. Internal users had to come from Okta automatically, while external client accounts had to be creatable on demand without touching the directory. All of it had to hold PII and PHI under HIPAA.

The company selected Files.com to be that exchange layer.

One Fenced Folder per Client, Under the Company's Own Domain

Files.com became the company's standing front door for client data: one governed surface where every employer client has a walled space of its own.

Isolation is the foundation. Each client gets a dedicated folder to drop company-specific files into, and Files.com permission fences keep every client's data apart from every other's. A client sees its own folder and nothing else. That per-client isolation is the control the roster exchange is built on, and it runs both ways: a client drops a file in, or the company places a file there for the client to retrieve.

The surface belongs to the company. The portal runs on a custom domain with the company's branding, so the page a client contact opens carries the name of the company they signed a contract with. Sending a roster means logging into a web page and dropping a file. No AWS account, no console, no cloud knowledge required.

Identity splits cleanly down the middle. Internal users are provisioned automatically from Okta through SAML single sign-on and Files.com's SCIM provisioning: accounts are created from the directory, group memberships are pushed from Okta, and the folder permissions mapped to those groups follow along. External client contacts get local Files.com accounts with two-factor authentication instead, activated for a transfer and disabled after a set period.

The whole pattern is written down. Creating either account type is a documented runbook the help desk executes on request, which is what turns a security architecture into an onboarding process.

A New Client's First File No Longer Waits on IT

With the portal in production, the company replaced a per-client infrastructure project with a repeatable intake pattern. Onboarding the next employer client is a folder, a group, and a credential. The help desk works it from a runbook, and IT no longer builds infrastructure to receive a file.

A new client's first file no longer waits on IT. Every future client lands on a pattern that already exists, so the exchange layer absorbs the company's client growth without adding engineering work per relationship.

The Job Raw Storage Was Never Built to Do

Today, the opening move of a new employer relationship looks different at the doorstep. It used to begin with an engineer hand-assembling an S3 bucket and an HR contact clicking through unfamiliar AWS services to find one file. Now it begins with a login page carrying the company's name and a folder that belongs to that client alone, with the isolation and the account lifecycle decided before the first byte arrives.

The company is still a cloud-native, AWS-first company. What it stopped doing is asking a raw storage bucket to be a client-facing product. Files.com took that job: the governed front door where regulated data enters the business, built once and reused for every client that follows.