Every compliance conversation starts with the wrong question. The right one — where does the data physically live during operation? — has gotten harder to dodge as DORA, the EU AI Act, and a decade of residency laws redrew the map.
Most compliance meetings start with the wrong question.
The wrong question is “Is the vendor SOC 2 Type II certified?” — or the equivalent for whichever regime the procurement team is closest to. It’s not a bad question. It was the right question for a long time. But it’s been answering a sub-problem that the bigger structural question — where does the data physically live during operation, and whose audit boundary contains that location? — was supposed to feed into. And in 2026, that sequencing has reversed. The architecture is upstream of the certifications, not the other way around.
This post is about why that reversal happened, what it means for the procurement conversations happening over the next eighteen months, and why the choice between a SaaS architecture and a self-hosted architecture has become the load-bearing compliance decision rather than a separable one.
For roughly a decade — call it 2014 to 2022 — the SaaS compliance bet worked. The shape of the bet was clean: the vendor stored your data, the vendor’s environment held your data, and the vendor’s certifications were the assurance that the environment was operated correctly.
You evaluated a vendor’s SOC 2 Type II report, you read the bridge letters, you checked their CAIQ, you signed a DPA under GDPR Article 28, you signed a BAA under HIPAA §164.314 if your industry needed one, and you accepted the architecture-shaped reality that the vendor was in your data path. That acceptance came with real benefits — fast deployment, no infrastructure to run, predictable subscription cost, someone else’s on-call rotation handling the 3 a.m. database issue.
The assumption underneath was that the regulatory surface was relatively static, that transfer mechanisms like Privacy Shield were holding, and that the vendor’s posture was a meaningful shorthand for the buyer’s coverage. All three assumptions were defensible. Each held, mostly, for the decade in which the SaaS model became the default architectural choice.
What happened next is that each of those three assumptions broke.
Schrems II (July 2020) kicked off the slow collapse of the cleanest version of the assumption. Data Protection Commissioner v. Facebook Ireland invalidated the EU-US Privacy Shield framework, recharacterised the legal standard for cross-border transfers, and put US-parented vendors back into a posture where each transfer needed individualised Transfer Impact Assessments. Five years later, the EU-US Data Privacy Framework (Privacy Shield’s successor) is in force, but the underlying scrutiny didn’t recede — it just got channelled into the TIA workflow. The CLOUD Act remained intact; US-parented vendors remained compellable by US government process regardless of where data physically lived.
DORA (in force 17 January 2025) reshaped how regulated financial entities in the EU evaluate critical ICT third parties. Article 28 of DORA imposes a substantial third-party ICT register obligation — a register that documents every critical ICT provider, their substitutability, their concentration risk, and the entity’s exit strategy. For a SaaS vendor that’s in the operational data path, that register entry is heavy. For a self-hosted vendor that ships software the entity runs inside its own boundary, the entry is dramatically lighter, because the entity retains end-to-end ICT control.
The EU AI Act, with high-risk-system obligations applying from 2 August 2026, adds Article 12 record-keeping and Article 13 transparency requirements for AI systems that fall in scope. For a SaaS vendor mediating AI calls on the buyer’s behalf, those records have to be reachable through the vendor. For a buyer running AI through their own ops platform with their own model-provider credentials, the records are inside the buyer’s environment, on data the buyer owns, with no vendor-mediated AI gateway in the path.
The residency-law spread is the third front. China’s PIPL (2021), India’s DPDP (2023), Saudi Arabia’s PDPL (2023), UAE Federal DPL (2021), Quebec’s Law 25 (2024), Brazil’s LGPD (2020), and roughly a dozen sectoral or sub-national equivalents have all hardened the requirement that certain categories of personal or operational data remain inside the relevant national border. Each one is a separate regime, and each one requires that the buyer be able to demonstrate where the data physically lives — not where the vendor says it lives in its compliance documentation.
Pile the four together and the assumption that “the vendor’s posture is shorthand for ours” stops working. The vendor’s posture is theirs; ours has to be derived from where the data actually is.
All four of those forces — different in form, different in jurisdiction, different in scope — reduce to the same underlying question:
Where does the data physically reside during normal operation, and whose audit boundary contains that location?
If the answer is “the vendor’s infrastructure, in a region they nominate”, then the buyer’s compliance posture is downstream of the vendor’s. The buyer’s SOC 2 controls describe the buyer’s environment; the vendor’s SOC 2 controls describe the vendor’s environment; the question of whether they compose is its own engineering and assessment exercise. DPAs flow, BAAs flow, TIAs flow, sub-processor lists have to be maintained, the residency story is the vendor’s residency story until proven otherwise.
If the answer is “the buyer’s infrastructure, inside the buyer’s accredited environment”, then the compliance posture is the buyer’s own. The vendor isn’t a data processor under GDPR Article 28 because there’s no processing on the vendor’s behalf. The vendor isn’t a Business Associate under HIPAA §164.314 because no ePHI flows to them. The vendor isn’t a third party in scope for DORA’s Article 28 register in the same way because they aren’t operating data on the entity’s behalf. The vendor’s own certifications — present or absent — don’t compose with the buyer’s because the vendor isn’t in the buyer’s boundary.
This isn’t a clever framing. It’s the architectural primitive that the certifications and the regulations are describing. The certifications matter because they’re load-bearing for the vendor’s posture; the buyer’s posture is determined by the buyer’s environment, which is determined by where the data lives.
The order has been “evaluate the certifications, decide the architecture” because, for a decade, SaaS was the default architecture and the question of where the data lived was already answered before procurement started asking. The reversal isn’t an argument that certifications are unimportant — it’s an argument that they’re derivative of an architectural choice that buyers used to skip past and now can’t.
The pattern repeats with small variations across the regimes. The detailed framework-by-framework reference for the architecture below lives at ekso.app/compliance; the summary view follows.
GDPR / UK GDPR. When the vendor doesn’t receive personal data, the vendor isn’t a processor under Article 28. No DPA is required for the operational data. Subject-rights workflows (access, rectification, erasure, portability) execute inside the buyer’s environment. Transfer mechanisms (SCCs, UK IDTA, adequacy) are not required because no transfer to the vendor occurs.
HIPAA. When ePHI never reaches the vendor, the vendor isn’t a Business Associate. No BAA is required. The §164.308 / 164.310 / 164.312 controls the buyer has already implemented for its accredited environment apply to the software running inside that environment, unchanged.
DORA. When the vendor isn’t in the operational data path, the third-party ICT register obligation under Article 28 of DORA is dramatically reduced. The buyer retains end-to-end ICT control over the deployed software. Source escrow and continuity arrangements live in the contract, not the operational pipeline.
EU AI Act (Article 12 / 13 obligations from 2 August 2026). When the AI provider relationship is direct between buyer and provider (BYO keys), the Article 12 record-keeping happens inside the buyer’s environment, on logs the buyer owns. There’s no vendor-mediated AI gateway in scope. The transparency obligations under Article 13 attach to the buyer’s deployment, which is what the buyer can actually evidence.
CLOUD Act / Schrems II. When the vendor never receives the operational data, US-government process directed at the vendor for that data has nothing to compel — there is literally nothing to produce. The TIA collapses to a single conclusion. (Vendor-jurisdiction matters too: a non-US-parented vendor isn’t reachable by US compulsion for any of its own holdings either, but the structural point is upstream — the vendor doesn’t have the data to compel.)
Data-residency regimes. When the buyer deploys into the country, region, or facility the regime requires, the residency requirement is satisfied by construction. There’s no cross-border-transfer-approval list the vendor needs to be on, because the vendor isn’t a recipient.
The pattern under all six: the vendor’s certifications stop being load-bearing because the architecture has already pre-empted the question those certifications were answering. It’s not that SOC 2 stops mattering in some absolute sense — it’s that it stops mattering for the buyer’s audit in this architecture, because what SOC 2 attests to (the vendor’s environment) isn’t where the buyer’s data is.
This isn’t a one-sided argument. The SaaS architecture earned its decade by being genuinely good at things the self-hosted architecture is genuinely bad at, and that hasn’t reversed.
SaaS is faster to deploy. A team that wants something working by Friday will get there faster with a managed service than with self-host, even with the best installer. SaaS is operationally simpler — someone else handles patches, backups, regional failover, on-call. The cost is more predictable on a per-seat or per-month line item than the lumpier costs of running infrastructure. The capacity to upgrade in lock-step with the vendor’s roadmap is real. For teams that don’t have an IT or platform engineering function — or where compliance posture is already inherited from a broader managed-service strategy — SaaS continues to be the cleaner answer.
Self-hosted is harder. It requires running infrastructure, applying upgrades on the buyer’s timeline, owning the on-call rotation, designing the backup and DR strategy. The buyer pays the operational cost of being inside the audit boundary in exchange for owning the audit boundary.
The trade is real. It’s also exactly the trade that the regulatory shifts of 2024–2026 have moved the optimum on. As the residency, third-party-register, and AI-Act obligations have piled in, the value of owning the audit boundary has gone up; the convenience of renting it has gone down. Neither has gone to zero.
The two architectures are different bets, made under different assumptions about how the regulatory surface evolves. The point of this post isn’t that SaaS is wrong. The point is that the 2018 assumptions under which the SaaS bet looked structurally better than the self-host bet are no longer the assumptions that hold in 2026 — and procurement decisions are starting to reflect that.
If the architectural question really is upstream of the certifications question, then the order in which procurement teams ask their vendors needs to invert.
The current default — “Are you SOC 2 Type II? Send us your CAIQ. Where’s your DPA?” — assumes the vendor is in the data path and the certifications are how the buyer evaluates whether the vendor is doing the right things in that path. The reversed order starts elsewhere: “In normal operation, where will our data physically be? Whose audit boundary contains that location? What certifications are load-bearing for our coverage, and which ones are downstream of the vendor’s posture and therefore irrelevant to us?”
For a SaaS architecture, the first question’s answer is “the vendor’s environment, region X”, and the rest of the conversation flows from there — DPAs, BAAs, TIAs, sub-processor lists, cert reviews. For a self-hosted architecture, the first question’s answer is “our environment, region we choose”, and the conversation collapses considerably — there’s still a DPA for any limited PII the vendor handles for the licensing relationship, but the heavy operational-data obligations don’t attach to the vendor at all.
That’s the reframing. It doesn’t make the certification questions disappear. It puts them in the right slot in the sequence — derived from the architecture, not driving the architecture.
Architecture is the assurance.
That’s the load-bearing line on the compliance page, and it’s the line that the regulatory shifts of the last five years have made structural rather than rhetorical. The certifications a vendor holds describe the vendor’s environment. The buyer’s compliance posture is determined by the buyer’s environment. The two compose, or fail to compose, on the basis of the architectural choice that decides where the buyer’s data physically lives during operation.
For a long time, that choice was made by default and the certifications were where the compliance work happened. The choice is now the work, and the certifications are downstream.
The teams making the buying decisions in 2026 are increasingly recognising this. The forcing functions — DORA in force, EU AI Act high-risk obligations from August 2026, the residency-law spread that isn’t going to slow down — make the architectural question hard to dodge. The procurement conversations that start with “where will the data live during operation?” land differently than the ones that start with “are you SOC 2 Type II?”. The first conversation is shaped by the architecture; the second is shaped by the vendor.
We bet on the first conversation. That’s the bet underneath running on your infrastructure, shipping a self-hostable build, keeping the AI provider relationship direct (bring-your-own keys), and writing a compliance page that’s deliberately about the architecture and not about the certifications we do or don’t hold. The architecture is the assurance. The certifications are downstream.
If the regulatory surface keeps moving the way it has for the last five years, that ordering will keep being right.
The framework-by-framework reference — GDPR, HIPAA, PCI DSS, SOC 2, DORA, EU AI Act, FISMA, CLOUD Act / Schrems II, residency regimes, NIST CSF — lives at ekso.app/compliance. The architectural argument it’s grounded in is the headless-first / data-stays-home thesis. Procurement and vendor-questionnaire contact: security@ekso.app.
One workspace for tasks, tickets, time, and money. Start free. Cloud, on-premise, or your own infrastructure.
