Most compliance meetings start with the wrong question.
Editorial note — September 2026: Customer-operated hosting can reduce some vendor data paths, but it does not make a deployment compliant automatically or remove contractual obligations by itself. The complete system — including hosting, identity, support access, mail, AI endpoints, telemetry, retention, and operating procedures — must be assessed for the specific use case. This article is architectural context, not legal or certification advice.
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.
The “trust the certs” era
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.
What changed
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 ICT third parties. Deployment architecture can affect the relationship and evidence available, but self-hosting does not by itself remove a software or support provider from DORA analysis. Regulated entities must determine scope with their legal and risk teams.
The EU AI Act adds record-keeping and transparency obligations for systems that fall in scope. Bring-your-own model credentials can give a customer a more direct provider relationship, but record location and responsibility still depend on the configured model endpoint, logging, contracts, and the customer’s role under the Act.
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.
The architectural question underneath
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”, the customer controls more of the technical boundary. That may reduce some transfers and vendor processing, but it does not settle whether the vendor is a processor, Business Associate, ICT third party, or other regulated party. Support arrangements, diagnostics, licensing records, identity, mail, AI providers, and other integrations can still create data paths and contractual duties.
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.
Walking the major frameworks
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. Map every flow of personal data and determine the roles of each organization. Customer-operated hosting can reduce transfers, but support, telemetry, identity, mail, and AI integrations may still require contracts and transfer safeguards.
HIPAA. Determine whether ePHI is present and which parties create, receive, maintain, or transmit it. Hosting location alone does not decide Business Associate status or satisfy the Security Rule.
DORA. Assess the software, support relationship, concentration risk, continuity plan, and contractual terms under the regulated entity’s ICT risk framework. Do not infer exclusion from a self-hosted topology.
EU AI Act. Identify the customer’s and providers’ roles, the system’s risk classification, the chosen model endpoints, and where required records are generated and retained.
CLOUD Act / Schrems II. Evaluate the jurisdictions, recipients, access mechanisms, support model, and actual transfer paths. Customer-operated hosting can reduce vendor-held operational data, but it does not replace a transfer or legal analysis.
Data-residency regimes. Deploying in a required region can be an important control. The full data-flow map must still include backups, identity, support, mail, AI, analytics, and disaster-recovery systems.
Across all six, architecture changes the evidence and obligations; it does not pre-empt the assessment.
What SaaS is still better at
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.
What this means for the procurement conversation
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.
The principle
Architecture shapes the assurance.
That is the more accurate version of the architectural argument. Certifications describe their defined scope. A buyer’s posture depends on its complete system and operating model. The two compose, or fail to compose, based on the real technical and organizational controls — not one topology label.
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 recognizing 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, and supporting direct AI-provider relationships with bring-your-own keys. The compliance page records what Ekso can support, what evidence is public today, and what remains the customer’s responsibility.
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: sales@ekso.app.