An Insurance Holding Company Met a File-Level Encryption Mandate on Files.com Instead of an Emergency SFTP Upgrade

A US insurance holding company serves individuals through its life, supplemental health, and annuity carriers. Its worksite benefits arm provides benefits administration and enrollment services to employers.

Both sides of that business run on file exchange with organizations the insurer does not control. Employers send enrollment and eligibility data. Carriers and third-party administrators send and receive benefits and insurance files. Much of it is protected health information, which puts every transfer under HIPAA and puts the mechanics of how data moves into the contracts clients sign. For an insurer, the file transfer layer is not plumbing behind the product. It is part of what clients are buying.

When a client's contract required file-level encryption, the insurer needed a platform that already supported it on the client's timeline. An upgrade to the on-premises servers could not land quickly enough. The insurer served the client on a platform that already met the requirement.

Every Server Change Had to Be Scheduled With Connected Partners

The insurer's partner file exchange ran on on-premises SFTP servers, and the servers were load-bearing for outside parties: employers, carriers, and TPAs connected to them directly. Every change to the platform had to be scheduled with organizations the insurer does not control, so adding a capability to the servers was a coordination project before it was an engineering one.

That meant the platform's capabilities set the pace at which new client requirements could be met, and in regulated insurance, the security terms clients write into contracts are part of the deal.

A Contract That Required File-Level Encryption

What the new platform had to do was specific. It had to speak SFTP to partners who already worked that way. It had to keep each external party walled into its own paths. It had to encrypt files to the client's contractual standard, carry the insurer's own branding, and handle PHI under an executed Business Associate Agreement, which the insurer treats as a hard requirement of the workload rather than a preference. And it had to do all of that without adding infrastructure for the team to run.

The insurer already ran that platform. For years, its worksite benefits business had operated a branded partner transfer hub on Files.com, exchanging benefits and insurance data with external employers, carriers, and TPAs. The client requiring file-level encryption was onboarded onto the Files.com hub instead.

The insurer's other partner workloads continue on the on-premises SFTP estate, and the company plans to move them onto Files.com one at a time, running both environments in parallel until each switchover. Files.com was the established worksite-benefits hub and the immediate answer for this client.

A Partner Exchange Layer With No Operating System to Own

For the worksite benefits workloads already running there, Files.com is a governed front door for regulated partner exchange, with no underlying operating system for the infrastructure team to own.

Partners connect over SFTP to a domain carrying the insurer's brand, and each external account is provisioned into locked-down paths, so a partner reaches its own folders and nothing else. Per-user IP allow lists, two-factor authentication, and country-based login restrictions add layers of access control around that boundary.

The encryption mandate was met on Files.com rather than through an infrastructure project. Transfers are encrypted in transit and files are encrypted at rest as a matter of course, while file-level PGP/GPG encryption runs through the Files.com key manager. PHI moves under an executed Business Associate Agreement covering the workload.

The hub is also not a dead end. Every file a partner uploads is consumed by a downstream internal system, and internal teams use the same site to reach reports and work with uploaded files. The intake point and the processing handoff are one place, with nothing for the insurer's team to patch and no change window to schedule with the external clients connected to it.

The Upgrade Cycle Stopped Being the Gatekeeper

With the client running on Files.com, the insurer turned what would have been an emergency infrastructure project into an onboarding exercise.

The immediate result was one client won. The compounding result is that a security requirement a client writes into a contract now meets a platform that keeps itself current, so the answer becomes a matter of configuration rather than a question of whether an upgrade can be scheduled fast enough.