Vlad Lebediev is Founder & CEO of Triangu, an engineering-led managed cloud and DevOps firm serving regulated fintech and iGaming operators.gettyCloud computing made one promise above all others: Infrastructure could be borderless. This meant it could be elastic, spun up anywhere, scaled on demand and indifferent to geography.Financial regulation makes the opposite demand. The GDPR and regional banking rules restrict where personal and financial data can be transferred, drawing borders the cloud, by its nature, wants to erase. Meanwhile, controls must satisfy specific frameworks such as PCI-DSS and SOC 2 that often mean that auditors must be able to trace specific actions to specific people.For years, regulated companies resolved that contradiction by buying physical infrastructure in each market they operated in, because owning servers inside a licensed territory was the cleanest way to satisfy a regulator who wanted to know exactly where the data lived. It solved the core issues, but it was also slow, capital-intensive and scaled only by buying more hardware. Entering a new market meant a procurement cycle more than a deployment.However, a shift is underway. In my work leading a managed cloud firm that serves regulated fintech and gaming operators, I've seen companies that assumed physical infrastructure was non-negotiable deploy compliant environments into new jurisdictions without buying the infrastructure in each individual market. Part of the shift is that hyperscalers now offer in-country regions, contractual data-residency guarantees and the certifications regulators recognize. The deeper evolution, though, is the conceptual understanding of cloud environment compliance, as where you bought the servers now matters less than how you build and operate the system. By moving compliance from the procurement department to the engineering team, ​the same disciplines software teams already use—version control, automated testing, continuous monitoring—can be applied directly to the controls a regulator cares about. Four Pillars Of Engineering Compliance​When you treat compliance as an engineering discipline rather than a purchasing decision, four things change about how you operate:• Infrastructure becomes code. Every environment is defined in version-controlled configuration, which makes it reproducible, reviewable and identical from one deployment to the next. An auditor doesn't ask you to describe your environment; you show them the file that built it.• Evidence becomes automatic. Instead of assembling audit documentation by hand once a year, the system generates its own trail continuously: who changed what, when and with whose approval. Compliance evidence becomes a byproduct of normal operation rather than a quarterly fire drill.• Jurisdiction becomes a parameter. Entering a new regulated market turns into a configuration choice—which region, which controls, which data boundaries—rather than a capital project. You deploy into a market in weeks, not quarters.• Change becomes controlled and reversible. Every change is logged, tested and can be rolled back. That is exactly the posture a regulator wants to see, and exactly what manual processes struggle to guarantee under pressure.A handful of jurisdictions still mandate physical presence that no cloud region can satisfy, but they are now the exception, not the rule—and treating them as the rule can keep companies locked into infrastructure they no longer need.​​​How This Shift Impacts Regulated Industries​This shift isn't confined to finance. Healthcare organizations face the same tension under HIPAA and equivalent regimes—patient data bound by residency and access rules, audited against frameworks that assume traceability. In my work across regulated sectors, I've seen that while the specific framework changes, the core discipline remains the same in all regulated sectors.Consider the hardest version of the problem. Regulated online gaming operates under some of the most prescriptive infrastructure rules of any industry—per-jurisdiction licensing and regulators who audit the technical environment directly. Operators in that space have had to solve borderless-cloud-meets-bordered-regulation in its most extreme form. The lesson that emerged is the same one financial services is now learning: The constraint was never the cloud. It was the assumption that compliance is something you buy rather than something you build.​In New Jersey, for instance, online gaming may only be offered from servers physically located within Atlantic City, and operators whose servers sit outside the state are barred from the market entirely. While you can't engineer around the core requirement that servers have to sit in Atlantic City, engineering can change everything around that constraint. By treating the in-state environment as one more deployment target defined entirely in code, a jurisdiction that mandates local, audited infrastructure becomes a configuration to stand up rather than a bespoke build. The same infrastructure-as-code templates that run elsewhere should be parameterized to pin workloads to the required location, enforce the access and segregation rules the regulator expects and generate the audit trail on demand. The goal is not to avoid the requirement, but to make a heavily regulated, physically constrained market repeatable, so the operator can satisfy New Jersey's rules and Malta's and the next state's without rebuilding from scratch each time. ​​Building Cloud Compliance Based On Engineering Discipline ​By internalizing this model, companies can gain three advantages. They can enter new markets faster, because deployment replaces procurement. Their infrastructure cost can scale with revenue instead of demanding capital upfront. And, counterintuitively, their audit posture can get cleaner, because automated systems produce more consistent and more complete evidence than people assembling spreadsheets ever could.None of this is free. The model front-loads effort: Teams need real fluency in infrastructure-as-code and automated controls, which is a genuine skills shift, not a tool you switch on. Early on, encoding compliance into the pipeline is also slower than the manual process it replaces, and it demands close collaboration between engineering and compliance functions that often haven't worked that tightly before. The payoff is earned over months, not weeks—and organizations that underestimate the learning curve tend to stall halfway.More markets will open and more financial activity will move into regulated digital channels. Companies can streamline their strategies and operations by treating compliance as engineering instead of real estate. In doing so, they will learn that the obstacle wasn't the cloud but believing compliance is something you purchase when it's actually something you engineer.​​​​Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?