An Insurance Software Provider Runs Client PHI Intake Through Expiring Logins on a Branded Files.com Portal

A health insurance software provider builds the underwriting platform that carriers, MGUs, brokers, and third-party administrators run on. Its clients are healthcare payers.

That business model has a consequence built into it. Onboarding a client means taking in that client's data: database backups, onboarding materials, and files dense with protected health information. And the clients sending that data are healthcare payers who audit their vendors, arriving with security and risk questionnaires that ask exactly how a file gets from their systems into the company's. The company's business guaranteed that regulated data would flow inbound, and guaranteed that its clients would demand proof the path was secure.

Intake That Had to Scale Across More Than a Hundred Payer Clients

The company wanted one governed path for that data, carrying its own name. Secure-email links did not scale to that: to open a link, the company's customer solutions team had to receive a password sent through some other channel, and each link stood on its own, with no per-client structure around it.

Across more than a hundred payer clients, that pattern did not hold up. The company wanted an intake path it could show a client's security team: one platform, one consolidated log, and a credential the platform itself controls.

Access for the Engagement, Not for Good

The obvious fix, a standing file account for every client, was the wrong one. The company did not want clients holding open-ended access to its environment. A client needed a way in while an engagement was live, and no way in afterward. But issuing and revoking credentials by hand does not scale across more than a hundred client organizations, and revocation by hand is exactly the step that gets forgotten.

So the requirements were specific before any product entered the picture. The intake point had to carry the company's own name, because a payer sending a database backup is judging the vendor by what it sees. Every client had to be walled off from every other client, with no shared space to wander into. Logins had to expire on their own, on a window an account manager could set without opening a ticket. Large database backups needed a protocol path, not a browser upload. And every upload and download had to land in an audit trail, on a platform that could sign a HIPAA business associate agreement and show SOC 2. The company selected Files.com to be that client intake layer.

A Branded Portal Where Logins Expire on Their Own

The company stood up a client portal on its own secure subdomain, pointed at Files.com through a DNS CNAME and carrying the company's logo and colors. A client uploading a backup sees the vendor it hired, not a third-party tool.

Behind the domain, the company prepared a folder for each organization across its client base, with Files.com folder permissions blocking any cross-visibility. A client's login reaches that client's folder and nothing else. The exchange runs in both directions: the customer success team collects database backups, documents, and onboarding materials from new clients, and sensitive deliverables for statement-of-work engagements go back out through the same per-client folders. The largest transfers, client database backups during new-client setup, run over SFTP.

The mechanism that changed the model is the access expiration date Files.com puts on a user account. An account manager enables a client's login for the window an engagement is live, down to a matter of hours. The working pattern is handing the customer success team a payer's login that is good for the next few hours. When the window closes, the platform closes the access; nobody has to remember to. Accounts carry two-factor authentication, and every upload and download is written to the Files.com audit log.

What Changed for Client Intake

With the portal in production, the company replaced an intake process built on secure-email links and out-of-band passwords with a governed exchange it can put its own name on.

• Client PHI intake runs through the branded portal. Clients upload to their own folder with a login the platform issues, and no password travels through a second channel.
• Client access is time-boxed by the platform. A login exists for the hours an engagement runs and expires on its own, so there is no standing account waiting for someone to disable it.
• Enabling a client is an account manager's action, not an IT project. The person who owns the engagement grants the access, scoped to that client's folder and window.
• Every upload and download is on the record. When a payer's security questionnaire asks how files move and who touched them, the answer is a log, not a reconstruction.

The compounding result sits underneath those. Bringing the next client onto the portal is a folder and a credential with an expiration date, so the intake model holds across a hundred-plus clients the same way it holds at one.

Credentials as Engagement Artifacts

The deeper change is in what a client credential is. The company treats client access as an engagement artifact, never as a standing account: issued for the hours the work is live, expired by Files.com, and defensible to clients who audit vendors for a living.