Alight Meets Canadian Residency, US HIPAA, and India Performance Requirements on One Files.com Platform

Alight administers health, wealth, retirement, and leave benefits for many of the world's largest employers, including a majority of the Fortune 100. Its platforms carry benefits for more than 30 million people, and its administrative support reaches client workforces in more than 100 countries.

That work is regulated data by definition: health records, retirement accounts, and the personal information of client employees. And because Alight administers that data on its clients' behalf, the rules governing it are not Alight's to set. Every client contract brings that client's own requirements for where employee data may be stored and where it may travel. Alight has to satisfy all of them at once, on infrastructure its clients share.

Files.com gave Alight a way to hold those opposing requirements on one governed architecture: Canadian data stays in Canada and never transits the United States, US protected health information moves under a HIPAA business associate agreement (BAA), and client teams in India get accelerated access without a separate regional platform.

Clients Whose Data Rules Point in Opposite Directions

Three of the client populations exchanging files with Alight had geography requirements that no single configuration could satisfy. Canadian provincial-government clients required that their data never transit the United States: not just stored outside it, but never routed through it. US employer clients' files carry protected health information covered by HIPAA, which means any platform touching them must operate under a BAA. And client teams in India needed responsive access from the other side of the world.

A file-exchange platform with one storage region can serve the first population or the second, never both. Without per-client control over where data lives, Alight had two ways to serve its sovereignty-bound clients. It could stand up separate regional infrastructure, a second platform to deploy, patch, govern, and audit for a small set of clients. Or it could leave those clients off the modernized exchange estate entirely. For a company whose entire product is administering the client's data, a residency rule it cannot meet is a client it cannot fully serve.

The requirements also interacted. The HIPAA agreement affected whether acceleration could run on the main, US-default environment. The Canadian rule had to survive whatever that configuration turned out to be, and the India connections still needed acceleration somewhere. One global default could not hold all three at once.

As Alight consolidated external client file exchange onto one modern platform, that became the specification. Storage region had to be a property of a client's folders or site, not of the platform. Sovereignty-bound data had to stay in country, in storage and in routing. The HIPAA configuration could not break the regional overrides. And performance had to hold for teams far from wherever the data lived.

Storage Region as a Per-Client Setting

Alight built its client file exchange on Files.com, where storage region is exactly that kind of property. Each site and each folder can use Files.com storage and compute zones worldwide, and every control above the storage layer stays uniform.

For the Canadian provincial-government clients, Alight set Canada as the default storage region on the folders those clients exchange through. Every file that lands there is stored in Canada and does not pass through the United States. The folder enforces the rule, so nobody handling a transfer has to remember which clients are sovereignty-bound. Anything exchanged with those clients inherits the requirement.

The rest of the estate runs US-default storage under the HIPAA BAA, so protected health information for US employer clients moves through the same governed platform. Alight proved the two configurations together: the Canada storage override on a folder holds with the BAA in place and acceleration disabled on the main site. For client teams in India, Files.com Global Acceleration carries the connection, so users there get low-latency access without any data moving closer to them.

Where a boundary needs to be harder than a folder, Alight uses Files.com child sites. It runs three tenants under one parent, with independent compliance and acceleration configurations. Residency and compliance can differ per tenant as well as per folder, so a separation can be as hard as a jurisdiction demands.

The controls above the storage layer do not vary by geography. Sign-in runs through Alight's single sign-on with Ping Identity, the same permissions and user lifecycle rules apply everywhere, and every action lands in one audit trail, whichever region a folder stores to. Alight governs one platform. The geographies sit underneath it.

Provincial Governments on the Same Platform as Everyone Else

With the regional configuration in production, data residency at Alight is satisfied client by client instead of platform-wide. What used to be a reason to build separate infrastructure became a setting on a folder.

• Canadian provincial-government clients exchange files on the same Files.com architecture as every other Alight client. Their data is stored in Canada and does not transit the United States, and there is no second regional deployment to operate or audit.
• Protected health information for US clients moves under the HIPAA BAA on the same platform, with the Canada overrides verified to hold alongside it.
• Client teams in India connect through Global Acceleration instead of absorbing the latency of a distant storage region.
• Taking on a client in a new jurisdiction is configuration rather than construction: a storage override on that client's folders, or a child site where the boundary has to be site-wide.

Multi-region residency was not on Alight's original list of requirements for the platform. It earned its place in production: the team that runs Alight's managed file transfer now counts data residency as one of the three pillars of what Files.com does for the business, and calls it a differentiator.

Where Data Lives Is Now a Per-Client Decision

A contractual residency requirement used to mean a decision about infrastructure: build a regional deployment for one jurisdiction, or serve the client outside the modern estate. Today, the team sets the storage region on that client's folders, and Files.com enforces the rule from then on. A benefits administrator never gets to choose its own data geography. It inherits one from every client it signs, and the next client can bring a new one.