A regulator looking at a multi-entity group in 2026 asks a question that did not show up in audits five years ago. They ask which legal entity controls each record, where each entity's data physically sits, and what would prevent one entity's staff from reading another entity's data if the access-control layer misbehaved. They ask the question of a hospital network with facilities across two emirates, a banking group with branches in Riyadh and London, a healthcare technology vendor selling to a German subsidiary of a US parent. The answers expected are not the same.

The architectural shorthand most cloud platforms reach for, one database with a tenant identifier column and a row-level security filter, was designed for a world where the legal entity boundary did not need to be inspectable. That world is closing. Regulators across multiple jurisdictions now treat each entity as its own controller, its own supervised institution, its own facility under licence. The question they are asking is structural. A logical filter is not a structural answer.

This article walks through how the major frameworks now treat multi-entity governance, why row-level isolation reads as architectural compromise under modern audit scrutiny, and what an architecture honest about the entity boundary actually looks like.

The multi-entity audit question that did not used to be asked

For most of the cloud-platform era, multi-tenancy and multi-entity were treated as the same engineering problem. A platform served customers, each customer was a tenant, and the standard answer was a WHERE tenant_id = ? filter on every query. When a single customer happened to be a group with a parent and several subsidiaries, the platform usually shrugged: either the group was one tenant with internal user roles, or each subsidiary was its own tenant with no native way to share anything between them.

That model worked while regulators were content to look at the customer relationship and stop. The auditor checked that the vendor had encryption, access controls, an incident plan, and a SOC 2 report. Whether the customer was a single entity or a group of fifteen was not their concern.

It is their concern now. The same regulatory shift that pushed vendor governance back onto the customer (covered in our piece on vendor compliance becoming the customer's audit finding) has pushed entity-level scrutiny onto multi-entity groups. The German subsidiary of a US parent is its own GDPR controller, with its own Article 26 or Article 28 obligations. The Singapore branch of a Swiss bank is its own FINMA-supervised establishment. The Dubai facility of an Abu Dhabi-headquartered hospital group submits its own ADHICS attestation. The regulator no longer accepts the "we are one group" framing as an answer to entity-level questions.

This is what makes shared-database multi-tenancy structurally awkward for multi-entity workloads. The legal boundary the regulator wants to inspect is entity-to-entity. The technical boundary the platform offers is a query filter. They are not the same shape.

What the major frameworks now expect

The pattern is consistent across jurisdictions. The vocabulary differs. The direction does not.

GDPR (European Union). GDPR has no doctrine of group treatment for data protection purposes. Each legal entity in a group is its own controller for its own processing; intra-group data sharing is a controller-to-controller transfer, governed by Articles 5 and 6 plus a lawful basis. Article 26 joint controllership applies only where two entities genuinely determine the purposes and means together, and the European Data Protection Board's Guidelines 07/2020 confirm group affiliation does not create joint controllership by default. Article 28 contracts are required between group entities where one acts as processor for another. For cross-border intra-group flows, Article 47 Binding Corporate Rules are the recognised instrument, and the EDPB's January 2026 Recommendations 1/2026 on Processor BCRs sharpened the picture further: BCR-Ps cover transfers between group members acting as processors, but the initial controller-to-processor transfer from an EEA controller still requires Standard Contractual Clauses or another Chapter V mechanism. An auditor asked to verify the lawful basis for each intra-group flow will look for entity-level records of processing, entity-specific DPAs, and a data lineage that maps cleanly onto each Article 28 contract. A tenant_id column does not map onto an Article 28 contract.

ISO 27001:2022 (international). Multi-site certification is governed by IAF MD 1:2023, in force from October 2023. The mandatory document is direct on a point that often goes unread: a certification body cannot issue one certificate to a group of organisations that "merely share ownership". The group must operate a centrally planned, controlled, and monitored management system. Most multi-entity groups do not. Where each subsidiary runs its own information security management system, each must scope, risk-assess, and demonstrate Annex A applicability separately under Clause 4.3, and the supplier controls A.5.19 through A.5.23 apply when one group entity provides shared IT services to another. There is no group-entity exemption from A.5.21 on the ICT supply chain. The audit question becomes: if the parent hosts the subsidiary's data on shared infrastructure, where is the supplier risk assessment, the contract, and the exit plan that the subsidiary must produce? Row-level isolation provides none of these artefacts because, by construction, there is no supplier boundary to govern.

SOC 2 (United States, AICPA). The AICPA's trust services criteria treat multi-entity scope through the carve-out vs inclusive method for subservice organisations. A parent that provides shared infrastructure to subsidiaries is a subservice organisation under SOC 2, regardless of common ownership. The auditor will require either an inclusive engagement (the parent's relevant controls are audited and described in the subsidiary's report) or a carve-out with Complementary Subservice Organisation Controls listed. CC6.1, CC6.6, and CC9.2 examinations are increasingly explicit about tenant isolation as a design question: when one report covers shared infrastructure across multiple entities under common ownership, the system boundary collapses every entity's access controls, incident response, and vendor management into one tested system. Service auditors in 2025 and 2026 are flagging this as a CC6.1 design weakness when the only separation between entity-controlled data is application-layer filtering, and asking for compensating controls (per-entity encryption keys, per-entity network segments, per-entity service identities) before signing the opinion.

NIS2 directive (European Union). NIS2 scopes entities individually, not at group level. Article 3 sets size-based thresholds for essential and important entities, and Article 3(2) adds an aggregation rule that pulls in subsidiaries of larger groups even when the subsidiary alone would fall below the threshold. Each in-scope entity carries its own Article 21 risk management obligations and its own Article 23 incident reporting duty. Critically, Article 21(2)(d) names supply chain security as a mandatory measure including relationships with direct suppliers and service providers; Recital 85 makes clear an entity cannot outsource its way out of these obligations. When a group has some entities in scope and others not, the in-scope entity must treat sister out-of-scope entities providing it IT services as direct suppliers, with the same contractual scrutiny, evidence requirements, and incident-notification clocks that apply to any third-party vendor. The shared-database model offers no contract to scrutinise.

FINMA (Switzerland). FINMA Circular 2018/3 on outsourcing deliberately removed the blanket intra-group exemption that existed under the prior 2008 circular. Intra-group outsourcing is now governed by the same principles as external outsourcing: the regulated institution must retain effective control, audit rights, exit capability, and data access regardless of whether the service provider is an external vendor or a sister entity. For Swiss financial groups under consolidated supervision, the parent must implement governance at consolidated level under Circular 2017/1, but the underlying legal entities remain separately licensed; foreign bank branches in Switzerland are supervised individually under the Banking Act and the Foreign Banks Ordinance. The audit question for a banking group running shared core systems is whether the Swiss-supervised entity could exit the arrangement, restore service in Switzerland, and produce its data in Switzerland without the parent's cooperation. A shared database with row-level filtering fails the exit test because there is nothing to exit to.

ADHICS V2 (United Arab Emirates). The Abu Dhabi healthcare standard applies per facility through the Department of Health's AAMEN submission platform. A hospital group with five facilities in Abu Dhabi, two in Dubai, and one in Saudi Arabia files attestations facility by facility, and the UAE data residency requirement for protected health information operates at the facility's jurisdiction. The expanded V2 scope formally authorises cloud hosting (AWS, Azure) but only in sovereign regions with controlled-transfer protocols, mandatory AES-256, MFA on PHI access, SIEM integration, and 24-hour DoH incident reporting. The audit question for a multi-facility group on shared infrastructure is whether the storage of each facility's PHI can be located in the right jurisdiction. A single shared database with a facility_id column lives in one place; the per-facility residency answer is "no", before any other control is examined.

SAMA (Saudi Arabia). The Cyber Security Framework and the Rules on Outsourcing treat Saudi banks and their foreign branches as separately supervised establishments. Material outsourcing (including operation of a bank's IT system) requires SAMA approval before contracting, and Saudi customer data must be hosted in-Kingdom unless an explicit exemption is granted. A Saudi bank with a London branch cannot satisfy in-Kingdom residency on a shared core banking platform whose underlying storage sits in one region: the inspection will ask for proof of physical data location per branch and per customer, and a logical filter does not produce that proof.

Seven frameworks, four jurisdictions. Each one expects the entity boundary, the audit boundary, and the technical boundary to align. The shared-database model with row-level filtering aligns none of them.

Why row-level isolation reads as architectural compromise

The technical literature has been catching up with the audit posture. NIST SP 800-210 distinguishes hard isolation (separation at the OS process, network, and storage layers) from soft isolation (application-layer access control); regulated workloads are expected to demonstrate the former. The OWASP Multi-Tenant Security Cheat Sheet names Broken Object Level Authorization as the primary vector for cross-tenant data leakage in row-level architectures. AWS's own SaaS Tenant Isolation Strategies whitepaper, the canonical industry reference, frames the design choice between dedicated and pooled storage as a compliance-driven question rather than a cost question.

The vulnerabilities are not hypothetical. CVE-2024-10976 in PostgreSQL allowed row-level security policies to be bypassed in subqueries when user identity changed mid-session, a known failure mode when connection pooling reuses sessions across tenants. CVE-2025-8713 exposed sampled data through query planner statistics, leaking rows that RLS was supposed to hide. CVE-2025-55241 in Microsoft Entra ID, disclosed in September 2025, allowed cross-tenant token forgery via legacy Graph APIs; an attacker could impersonate Global Admins in other tenants without leaving traces in the victim tenant's logs. The fix was issued as an emergency patch.

The point is not that PostgreSQL or Entra are insecure. Both are world-class. The point is that even at hyperscale operational maturity, application-layer tenant separation is one validation bug away from a multi-tenant breach. For a regulated multi-entity group, the audit conversation about why the German subsidiary's data was readable from the French context cannot be defended with "we patched it". The framework expectation is that the boundary was never reachable from the other side in the first place.

Common audit findings against row-level isolation in 2025 and 2026 include connection-pool context leakage (the previous tenant's session GUC persisting into the next request), prepared-statement plan caches not re-evaluating policy predicates, background jobs and webhooks running without a tenant context check, and silent policy regressions that return wrong data with no error. Each is a routine engineering risk. Each is a category of finding the auditor can now articulate by name.

The questions that distinguish governed groups from filtered groups

A short, uncomfortable checklist for any multi-entity organisation looking at its current platform or evaluating a new one.

  1. Can the platform produce, on demand, the legal entity that controls each record? Not the tenant identifier. The legal entity, mapped to the controllership arrangement under GDPR, the licensed institution under FINMA or SAMA, the accredited facility under ADHICS. If the platform answers with a tenant_id and an internal mapping table, the answer is incomplete.
  2. Is each entity's data physically separable, exportable, and exitable without the other entities' cooperation? This is the FINMA exit test and the ISO 27001 A.5.22 monitoring test in one question. Shared-storage models almost never pass it.
  3. Where does each entity's data reside, and can the platform attest to that per entity? ADHICS asks this per facility. SAMA asks it per branch. GDPR Chapter V asks it for every cross-border flow. A shared database lives in one place.
  4. What is the contract or arrangement governing data exchange between entities? GDPR Art 26 and Art 28 demand it. ISO 27001 A.5.19 and SOC 2 CC9.2 demand it. NIS2 Article 21(2)(d) demands it. The platform should have a place for that arrangement to exist as a first-class artefact, not as a tribal-knowledge assumption inside the application.
  5. How does the platform record and enforce the boundary in cross-entity workflows that are legitimately needed? Multi-entity groups have real coordination needs: consolidated reporting at HQ, shared policies pushed from parent to subsidiaries, incident escalations from a subsidiary to the group risk function. These need a governed channel between entities, not the absence of a channel between tenants.

A platform that answers each of these with an architectural artefact rather than a paragraph is governable. A platform that needs to "explain how multi-tenancy works" in answer to a structural question has the wrong shape for multi-entity work.

The architectural answer

The honest architecture for multi-entity governance puts the legal entity boundary and the technical boundary on the same line, and adds a governed mechanism for the cross-entity coordination that genuinely needs to happen.

Database-per-organisation isolation is the foundation. Each entity's data lives in its own database, in its own jurisdiction, under its own encryption keys, with its own audit log. The boundary is structural, not query-time. The audit answer to "show me the German subsidiary's data" is to point at the German subsidiary's database, in its German region, encrypted under its German key. The auditor can read the resource attributes directly. The platform is not asked to prove a filter behaved correctly across a hundred million queries; the filter does not exist as the load-bearing isolation control.

On top of that foundation, multi-entity groups need a governed coordination mechanism. The legitimate intra-group use cases (a parent pushing a baseline policy to subsidiaries, a subsidiary submitting an incident notification to group risk, HQ rolling up evidence from operating entities for board reporting) need to happen as explicit, contracted, audited cross-entity exchanges. Each exchange maps onto a legal arrangement (a joint controllership agreement, a processor contract, a group policy framework), produces an artefact (a signed package with a versioned manifest, a timestamped acceptance, a recorded incident handoff), and leaves a trail on both sides. The receiving entity gets to accept, reject, or scope what crosses its boundary. The sending entity gets a record of what it shared and on what basis. Neither entity gets silent access to the other's database.

This is what we have built into Novantra's HQ-Branch governance model. Each organisation (HQ, branch, subsidiary, facility, foreign entity) is its own first-class organisation on the platform, with its own database, its own keys, its own residency, its own audit stream. Cross-entity work flows through a package exchange: HQ packages a control framework, a policy library, or an evidence template; the branch receives the package, accepts what is in scope, and applies it inside its own boundary. Rollups go the other direction, signed and scoped, without HQ ever needing query access to the branch's raw data. The legal entity boundary stays intact. The coordination that regulated groups actually need stays possible. The companion piece on audit-grade evidence as a continuous output covers how the per-entity audit stream stays trustworthy under regulator inspection.

None of this is a feature. Each is an architectural commitment that becomes load-bearing the moment a regulator walks past the perimeter and asks the entity-level questions the frameworks now require them to ask. A platform that started with one database and a tenant_id column cannot evolve into this shape without rebuilding the storage layer. A platform that started with the entity boundary as the storage boundary has the structural answer already in place.