Platform
Multi-Organisation Governance
HQs, subsidiaries, branches, facilities, foreign entities. Each one is its own organisation on Novantra, with its own database, keys, residency, and audit stream. Cross-organisation work flows through signed packages, not shared infrastructure. The legal entity boundary IS the data boundary, by structure.
The legacy answer was row-level filtering. Regulators stopped accepting it.
For most of the cloud-platform era, multi-tenancy and multi-organisation 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. That model works while regulators stop at the customer relationship. It stops working when regulators start asking, per legal entity, where the data is and who can reach it.
GDPR has no doctrine of group treatment for data protection. ISO 27001 multi-site rules forbid shared certification across organisations that "merely share ownership". SOC 2 treats a parent providing infrastructure to subsidiaries as a subservice organisation regardless of common ownership. NIS2 scopes each entity individually. FINMA removed the intra-group outsourcing exemption. ADHICS files per facility. SAMA supervises per branch. Every framework now expects the legal entity boundary, the audit boundary, and the technical boundary to be the same line. Novantra makes that line structural.
Six commitments behind multi-organisation governance
Each commitment is a structural property of the platform: there is no setting that disables them, and no tier that downgrades them. Where the regulatory case is covered by a deep-dive article, the link is included.
01
Novantra's database-per-organisation isolation
Every organisation gets its own database. Not a schema. Not a row-level filter. A physically separate database, in its own region, under its own keys, with its own audit stream. Cross-organisation access is a structural impossibility, not a policy claim that depends on the application behaving.
Why regulators care: ISO 27001 IAF MD 1:2023 multi-site rules, GDPR controller-per-entity logic, SOC 2 subservice scoping under CC9.2, NIS2 Article 21(2)(d) supply chain, FINMA Circular 2018/3, ADHICS V2 per-facility AAMEN, and SAMA per-branch supervision all treat the legal entity boundary as the data boundary.
02
Novantra's HQ-Branch governance model
Legitimate cross-organisation work (a parent pushing a baseline policy to subsidiaries, a branch submitting an incident notification to group risk, HQ rolling up evidence from operating entities for board reporting) flows through a signed package exchange. The receiving organisation accepts, rejects, or scopes what crosses its boundary. The sending organisation gets a record of what it shared and on what basis. Neither side gets silent access to the other's database.
Why regulators care: GDPR Article 26 joint controllership requires a documented arrangement, not ambient query access. ISO 27001 A.5.19 and SOC 2 CC9.2 require supplier-like contracts where a group entity provides services to a sibling. The signed-package exchange is the artefact that maps to those legal arrangements.
03
Per-organisation residency and jurisdiction
The German subsidiary's database lives in Germany. The Abu Dhabi facility's database lives in the UAE. The Riyadh branch's database lives in-Kingdom. Each organisation is pinned to its own region at provisioning time, and cross-region movement requires explicit authorisation. Backups, telemetry, support sessions, and failover all bind to the per-organisation residency setting.
Why regulators care: GDPR Chapter V transfer rules apply per controller. ADHICS V2 requires per-facility UAE residency for protected health information. FINMA Circular 2018/3 requires Swiss-supervised data to be accessible in Switzerland. SAMA mandates in-Kingdom hosting per supervised entity. None of these survive a single shared database in one region.
04
Per-organisation keys
Each organisation's data is wrapped under that organisation's own keyring, with the master key in a provider the organisation controls. One organisation's keys cannot decrypt another organisation's data. Key rotation, retirement, and rewrap are per-organisation governed operations. A regulator inspecting one subsidiary's key custody can verify it without touching any sibling's keys.
Why regulators care: GDPR Article 32 supplementary measures, the HIPAA NPRM encryption mandate, and ADHICS V2 HSM-backed key governance all expect cryptographic separation between regulated entities to be a storage-layer fact, not a code-path assumption.
05
Signed cross-organisation packages
Every cross-organisation exchange (policy push, framework distribution, evidence template, incident handoff, rollup request) is a signed package with a versioned manifest, a timestamped acceptance on the receiving side, and a record on both sides. The audit trail records what was shared, by whom, to whom, on what basis, and what was accepted versus what was scoped out.
Why regulators care: EDPB Opinion 22/2024 requires controllers to verify Article 28 flows down to every sub-processor. ISO 27001 A.5.22 expects monitoring, review, and change management of supplier services. The signed-package exchange produces the artefact each of those expectations is asking for.
06
Cross-organisation rollup without raw data exposure
HQs need consolidated reporting across operating entities. They do not need (and most cannot legally have) raw query access to the operating entities' databases. Novantra's rollup model gives HQ scoped, signed, aggregate evidence from each branch's audit stream, with the branch retaining control over what aggregation level is exposed. The board report exists; the controller boundary is preserved.
Why regulators care: FINMA consolidated supervision expects the parent to oversee operational risk across the group without breaking the supervised-entity boundaries. SAMA group-level oversight has the same shape. The legacy answer (HQ reads everything because it's all one database) fails both.
How multi-organisation lands per tier
Multi-organisation governance is part of the platform foundation; the tiers differ in the cap on how many organisations you can run and where the platform itself runs.
| Capability | Free | Managed Cloud | Sovereign |
|---|---|---|---|
Organisations included | 1 | Up to plan cap | Unlimited |
Database-per-organisation isolation | |||
Per-organisation residency | Customer-chosen DC | ||
Per-organisation customer-controlled keys | Native | ||
HQ-Branch package exchange | |||
Signed cross-organisation evidence rollup | |||
Per-organisation audit stream | |||
Mixed-jurisdiction deployment (e.g. EU + UAE + KSA) |
Free allows evaluation against a single organisation. Managed Cloud is capped to keep small groups within scope; large groups, regulated banking, healthcare, and any in-Kingdom or in-jurisdiction mandate land naturally on Sovereign.
Verify the boundaries without our cooperation
An organisation boundary that only exists in the application layer is unauditable. Each claim below is something a regulator can verify on their own, per organisation, in front of you.
Inspect each organisation's database location directly
Each organisation has its own database resource in its own region. Pull the resource ARN, the region attribute, and the access policy yourself. The same regulator can verify, per subsidiary, that their data is where their licence requires it.
Re-derive every cross-organisation package
Every signed package crossing an organisation boundary leaves a record on both sides with a verifiable signature, a versioned manifest, and a timestamped acceptance. The receiving organisation can reproduce exactly what entered its boundary; the sending side can reproduce exactly what left.
Audit per-record access at organisation granularity
For any record in any organisation, the audit stream answers: which user from which organisation read it, with which authority, at what time. Cross-organisation access (where it happens through a signed package) is recorded as a distinct event class.
Revoke one organisation's access without affecting siblings
Revoke the wrapping key, the storage credential, or the platform role for one organisation. Sibling organisations under the same HQ are untouched. The blast radius of a revocation is bounded by the organisation boundary, by design.
The articles behind the commitments
Multi-organisation governance touches every architectural surface. Each article below covers one facet from the regulator's perspective and links back to the same platform commitments.
Multi-entity compliance: governing HQ and branches
Data residency as a deployment decision
Customer-controlled encryption keys
When your vendor's compliance becomes your audit finding
The right-to-audit clause your vendor is hoping you do not read
Audit-grade evidence is a continuous output
Tamper-proof audit trails
Breach-reporting windows are shrinking
The boundary you sign on is the boundary that runs.
If your regulator inspects one subsidiary, that subsidiary's database, keys, residency, and audit stream are the artefacts they read. They are not derived from a shared store; they are the store. Talk to us about how Novantra's multi-organisation model fits your group structure, or start on the free tier and see how the boundary works.