SAI360 Replaces AWS Transfer Family With Files.com Without Changing Customer Endpoints

SAI360 sells governance, risk and compliance software. Its platform runs ethics, risk, compliance, and audit programs, and its learning business provides compliance training. Its customers are the organizations regulators watch hardest: hospitals, government bodies, large defense contractors, European banks. The company's stated focus is high-risk, highly regulated sectors, and compliance is not a department at SAI360. It is the product.

That puts SAI360's own file exchange under the same scrutiny its software helps customers manage. Customers move data into and out of SAI360 applications constantly: automated imports, integration feeds, extracts flowing back the other way. Roughly 90% of those customers carry data residency mandates. US data stays stateside, European data stays in Europe, Australian data stays in Australia. And every customer's data has to be kept apart from every other customer's.

“All the data has to be siloed. Customer A cannot see Customer B's data.”

A vendor built on those promises has to keep them by construction, not by care. For years, it kept them by care.

Three SFTP Endpoints, Pinned to a Cloud SAI360 Was Leaving

Customer file exchange ran on infrastructure SAI360 maintained itself: three regional AWS Transfer Family SFTP endpoints backed by S3, one each for the Americas, EMEA, and Australia, plus a separate self-run SFTP server. It met the residency requirement region by region, and it worked. That is why it survived as long as it did.

It also cost the cloud operations team steadily. Dean Heffentrager, SAI360's Director of Cloud Operations, called the estate "a pain to maintain." The sharper cost was delegation. The business divisions responsible for setting up customer access could not be handed that job safely, because there was no clean way to keep each customer's information separate while also keeping the divisions separate from each other. Isolation was administrative: something engineers enforced by hand, every time.

Two things made that arrangement untenable. First, SAI360 committed to migrating its major workloads from AWS to Google Cloud, running cutovers almost every weekend. Every customer-facing endpoint was anchored to the cloud being left, and moving an endpoint meant touching every automated customer integration behind it. Second, per-customer isolation was about to scale: 30 to 40 compliance customers across three regions each required a fully siloed environment, and Eric Fouarge, Global Head of Engineering, put the ceiling at roughly a thousand clients who could need a data exchange.

“We use AWS Transfer Family and some other God-forsaken SFTP server software. So we'll be consolidating all of that into Files.com.”

The Transfer Platform Could Not Own the Storage

The requirements described the gap precisely. Residency had to be enforced by architecture, so a US customer physically could not land data in Europe and a European customer physically could not land data anywhere else. Each customer needed its own segregated storage, per product line. The storage itself had to stay inside SAI360's own cloud projects, because a platform that held the data would fail the security requirement outright. And the whole thing had to be indifferent to which cloud sat underneath, because the storage was mid-move.

“If we are just using your front end to drop files into our controlled S3 and other buckets, that is a huge selling point for our InfoSec team.”

SAI360 selected Files.com to be that front end. It gave SAI360 a cloud-independent gateway: regional sites and per-customer mounts enforced residency and isolation in SAI360's own buckets, while customer-facing paths and endpoints stayed stable as the storage behind them moved from S3 to GCS.

Three Regional Child Sites, One Bucket per Customer

Residency is enforced by the site itself. SAI360 stood up its Americas site first, then Files.com child sites in Frankfurt for EMEA and Australia for APAC. Each child site is a fully separate environment with its own endpoint, so a customer connects in its own region and its data stays there. There is no configuration step that keeps EMEA data in Europe. The architecture does.

Isolation is enforced by the storage. Using Files.com remote server mounts, each customer-facing folder connects directly to a Google Cloud Storage or S3 bucket inside SAI360's own cloud projects, with one bucket per customer, segregated per product line. Customers connect over SFTP or the web and data flows both directions: uploads land in the customer's own bucket, and SAI360's backend services drop extracts into that bucket for the customer to collect. One customer cannot see another's data because the storage is not shared in the first place, and none of it sits on Files.com.

Provisioning is code. SAI360 runs Terraform and Ansible across its estate, and it provisions Files.com the same way, using the Files.com Terraform provider with the API covering the rest. Standing up the exchange for a new customer means creating a bucket, mounting it, and applying the configuration.

Moving the Storage Without Moving the Endpoints

The rollout ran alongside the AWS-to-GCP migration, phased by business unit with the learning division first. Where a workload still lived on AWS, Files.com mounted the S3 bucket directly. As migration windows opened, SAI360 redirected the same folder structures to GCS. The paths and endpoints customers connected to never changed, and by August 2025 nearly every workload was running in Google Cloud.

Residency by Design, Isolation by Bucket

With the regional gateway in production, SAI360 traded hand-maintained SFTP infrastructure for a structural pattern:

• Data residency is a property of the architecture for customers who mandate it. A customer connects to its own region's endpoint and its data cannot land anywhere else.
• Per-customer isolation is physical rather than procedural. Compliance customers exchange files through their own buckets in SAI360's cloud projects, so the siloing SAI360 promises its customers is enforced by the storage layout itself.
• The customer-facing endpoints are decoupled from the cloud behind them. SAI360 moved its storage from AWS to GCP under the gateway without disrupting the workflows running through it.
• Onboarding the next customer is a bucket, a mount, and a Terraform run. The same code-based pattern can be repeated as adoption expands.

“The thing that put you in the forefront was the direct to S3 and/or GCP. So that was a huge plus.”

A Front Door That Outlives the Cloud Behind It

SAI360 did not hand its customer data to a transfer vendor. It put Files.com in front of storage it already controls, which is what let a company whose product is compliance make residency and isolation properties of its architecture, and what let it change clouds without its customers ever touching an integration. Where the data lives is SAI360's decision. Where customers connect no longer depends on it.