You acquire a competitor. Or you spin out a regional subsidiary. Or your single-entity business reorganizes into divisions. Whatever the trigger — your GRC program suddenly has a multi-entity problem.
Most GRC tools handle this badly. Some handle it by giving each entity its own tenant (“just spin up another instance”). Some handle it by stretching a single tenant across entities (“just add a column for which subsidiary”). Both approaches break in predictable ways. The first creates duplicate work and zero rollup. The second creates security and access-control nightmares.
The fix is architectural. Multi-entity has to be a first-class concept in the data model — not a tag, not a workaround. Talarity calls this primitive Linked Accounts.
The patterns multi-entity organizations need
Across our customers operating multi-entity programs, four patterns come up repeatedly.
Inheritance. A parent organization sets a baseline policy. Subsidiaries inherit it. Subsidiaries can extend (add stricter requirements) but not relax (loosen the parent’s). When the parent updates the baseline, the inheritance flows down automatically.
Rollup. Each subsidiary maintains its own evidence, controls, and risk register. The parent sees a consolidated view — top-level risks, framework coverage across the portfolio, vendor exposure across all entities. The rollup is computed from the underlying entity data, not maintained separately.
Local autonomy. Each entity can operate independently when needed. A regional subsidiary can run its own audits, manage its own vendors, and respond to its own regulators — without the parent’s involvement. The parent has visibility, not operational gating.
Cross-entity reuse. Evidence collected at one entity can satisfy controls at another (when the underlying control is shared). A pen test commissioned by the parent satisfies the pen-test control across all subsidiaries that share the parent’s infrastructure. No re-collection.
These four patterns together describe what mature multi-entity GRC looks like. Tools that don’t support them force teams to maintain parallel programs across entities — at multiplicative cost.
What goes wrong in single-tenant tools
When a multi-entity organization tries to operate inside a single-tenant GRC tool, three failure modes emerge.
Access control becomes brittle. Subsidiary employees should see only their entity’s data. The parent should see everything. Auditors should see only the entity they’re auditing. With “subsidiary” as a column rather than a structural concept, every query needs an explicit filter — and forgetting one filter exposes data inappropriately.
Reports require manual aggregation. “What’s our consolidated risk exposure across all subsidiaries?” becomes a query nobody can answer cleanly. The parent’s compliance team ends up exporting data from each subsidiary to a spreadsheet and aggregating manually. The result drifts from the underlying source of truth within hours.
Inheritance doesn’t work. When the parent updates a baseline policy, there’s no mechanism to push the change down. Subsidiaries either re-implement manually (slow, error-prone) or stay on the old version (compliance gap). Neither is the desired state.
These failures don’t kill the tool — they just produce a constant tax. Audit prep takes longer. Regulator questions take longer to answer. The CISO spends time on reconciliation that should be spent on actual risk reduction.
What goes wrong in multi-tenant tools
The other failure mode: spinning up a separate tenant per subsidiary. This is sometimes a deliberate choice (each subsidiary licenses the tool independently) and sometimes the only available option.
The problems with multi-tenant separation:
No rollup at all. Each tenant is an island. The parent sees nothing automatically. To produce a consolidated view, someone exports from each tenant and reconciles by hand.
Evidence can’t be shared. A pen test commissioned by the parent has to be uploaded to each subsidiary’s tenant separately. Updating the report means re-uploading N times. Nobody does this consistently.
Vendor data fragments. The same vendor (say, AWS) shows up in every tenant. Vendor risk decisions made by the parent don’t propagate. When AWS issues a new SOC 2 report, every tenant has to ingest it independently.
Licensing and operations get complex. Provisioning users across tenants. Managing SSO across tenants. Tracking spend across tenants. Each adds operational overhead that scales with subsidiary count.
The compromise organizations usually settle into is “single-tenant for related entities, separate tenants for fundamentally different businesses.” That’s a reasonable line, but it doesn’t fix the underlying architecture problem — it just chooses which set of compromises to accept.
What multi-entity actually requires
Done correctly, multi-entity GRC looks like this:
- Linked Accounts are first-class entities in the data model — not tags, not subsidiary columns, not separate tenants.
- Inheritance flows downward by default. Parent baselines apply to children unless explicitly overridden.
- Visibility flows upward by default. Children’s risk, controls, and evidence are visible to the parent’s compliance team — with fine-grained access control for sensitive subsidiaries.
- Cross-entity evidence sharing is opt-in. Mark a piece of evidence as shareable at the parent level; it’s available to satisfy controls in every linked account.
- Reports roll up automatically. Consolidated dashboards exist by default. Filtering between consolidated and per-entity views is one click.
- License inheritance is explicit. A parent can provide free access to its subsidiaries (common in M&A integration scenarios). Or it can require subsidiaries to license independently. Either is configurable; both produce clean billing.
Each of these is straightforward to describe and architecturally significant to implement. The tools that do this right have it built in from the foundation; bolt-ons rarely work.
How Talarity handles it
Talarity treats Linked Accounts as a foundational primitive, not a feature. Every object in the system — controls, evidence, risks, vendors, assessments — knows which Linked Account it belongs to. Inheritance, rollup, and cross-entity sharing are first-class capabilities, not workarounds.
In practice, this means:
- A parent organization can set a baseline ISO 27001 program; subsidiaries inherit and run it locally.
- Risk registers consolidate from each subsidiary into a parent rollup automatically.
- Vendor risk decisions made by the parent flow down to subsidiaries that use the same vendors.
- M&A scenarios work cleanly: acquire a company, attach them as a Linked Account, inherit the parent baseline within days.
- Audit-time, an auditor can be granted access to a single subsidiary, the whole portfolio, or any subset.
If your organization runs multi-entity GRC and your current tooling makes that work harder than it should be — talk to us. The architecture matters more than the feature list.