The History of Expanso (Part 6): Data Controls are a One-Way Street

The below is a continuation of the series on the history of Expanso. Today, we're talking about the third and final unchangeable law of data: the ever-tightening web of data controls. Read the whole series starting from Part 1.

The History of Expanso (Part 6): Data Controls are a One-Way Street

Back when I was at Chef, I had an idea for a feature that would help people instantly comply with the Sarbanes-Oxley Act. Because I'm a nerd, I dove into the line items to see what we could productize into code. I remember reading through it—sure, that's a good one, oh we could do something there... and then I saw their statements on passwords. Here was a choice line: "Monitoring: Auditing processes and schedules should be developed to address the high-risk areas within the IT organization."

What the hell does that even mean? How can anyone build code against "should be developed"? If I have a post-it note that says "we've developed it," are we compliant? It was the opposite of useful.

This isn't a knock on the bill's authors. You wouldn't want legislation to be too prescriptive about technology. But it's a perfect example of how regulations create high-stakes ambiguity for the people who actually have to build things.

And It's Not Getting Better

With machine learning, the hunger for data has exploded. But as data appetites grow, the rules have gotten more complex and the penalties more severe. Take GDPR. (Standard disclaimer: I'm not a lawyer, this isn't legal advice.) The regulation is widely interpreted to mean that moving EU personal data out of the Union—even if you've anonymized it—is a non-starter. Some interpretations suggest just moving unanonymized IP addresses inside the EU is already a violation.

Are your data pipelines evaluating this risk right now? Most are not. And as governments wake up to the realities of data privacy and security, the rules will only get tighter.

Your Chief Legal Officer is Now a System Architect

This brings us to a brutal truth: the rules governing data are a one-way street. They only get stricter, more numerous, and more complex. Every year brings new regulations like GDPR, CCPA, and national data sovereignty laws. At the same time, internal security standards are rightly becoming more demanding.

These rules are no longer policies you handle with a checkbox. They are fundamental, immovable constraints on system design. Your architecture must obey them from the start.

This reality breaks the old playbook. Centralizing everything in a single region is now a massive liability. Every time you copy data across a border, you expand its attack surface and create a new compliance headache. You introduce a dozen new questions for auditors: Who has access to the copy? Is it encrypted correctly? Has its lineage been preserved? Can you prove you deleted it?

Centralization Creates a Single Point of Failure

The centralize-everything model was born in an era where moving data was cheap and unregulated. Today, that model creates a high-value target for attackers and a nightmare for compliance teams. Each copy is another potential leak. Each transfer is another point of interception.

At scale, this becomes an unmanageable risk. Your data warehouse can be a fortress, but its security is irrelevant if the vulnerability is in one of the dozens of ETL jobs that feed it, or in a poorly-secured bucket where an intermediate copy was stored. The blast radius for any mistake is enormous. Auditing this sprawling system becomes nearly impossible.

The industry has tried patching this with more complex access controls and lineage tracking. These are fixes for the symptoms, not the cause. The root problem is the assumption that you should move data to compute.

An Architecture for a Regulated World

The only way to build secure and compliant systems is to flip the model: stop moving data by default.

If patient data cannot leave the hospital network, the model must be trained inside that network. If financial data cannot leave its country of origin, the fraud detection pipeline must run in that country. The raw, sensitive data stays put, protected by the legal and security perimeters it was born in.

This architectural shift treats data sovereignty not as an afterthought, but as a primary design principle. By moving the logic, you minimize the attack surface. Only the results—the aggregates, the model weights, the alerts—are moved across boundaries. The compliance burden shrinks because you are no longer creating endless copies of sensitive information.

Building for Clarity

This frustration was a big reason we built Expanso. That feeling of staring at a vague regulation and having no clear path forward is poison for engineering teams. We needed a platform designed for a world where data has gravity and is subject to strict, sometimes confusing, laws.

Expanso gives you a single control plane to securely run your code where your data already lives, whether that's inside a specific country or behind a hospital firewall. It orchestrates the execution, ensuring logic goes to data while providing a unified audit trail. It's about replacing ambiguity with auditable certainty.

We're moving into an era where data architecture is as much about law and risk as it is about performance. What's the most painful compliance hurdle that forced your team to completely rethink a project?