How Should Identity and Permission Consistency Be Governed Across Multiple Veeva Vaults?

Organisations running more than one Veeva Vault, commonly a separate Vault QMS and Vault RIM, or regional Vaults reflecting a local regulatory boundary, usually design and assure the security model of each Vault individually. Navata's existing guidance on designing and assuring a Veeva Vault security model deliberately scopes to that single-Vault problem: identity, licences, security profiles, permission sets, object and document access, lifecycle state and workflow role, combined into one Vault's effective access.

That is the right scope for a single-Vault design question. It leaves a different, genuinely cross-cutting question unanswered: once a person has a domain-level identity and Vault memberships in more than one Vault, who is governing what that person's authority looks like across the set, and deciding whether it should look the same everywhere or differently on purpose.

What the platform actually controls, and what it does not

Veeva Vault's domain architecture gives a multi-Vault organisation real, useful mechanics. User accounts exist at the domain level, and Vault memberships determine access to individual Vaults. A domain can host more than one Vault, while domain-level settings such as password policy apply consistently once rather than per Vault. Identity can be federated with a corporate identity provider through SAML 2.0, OpenID Connect or OAuth2, so authentication itself is centrally controlled even where authorisation is not.

Veeva's Domain Admin setting exposes domain-level user-management capabilities. Together with the required permissions in the relevant Vaults, it supports administration across Vaults in a multi-Vault domain.

What the platform does not do is decide, on the organisation's behalf, what a given person's security profile and permission set should be in Vault B once you know what they hold in Vault A. Provisioning into a second Vault is a separate administrative act, normally performed by that Vault's own administrators, using that Vault's own security profiles, permission sets and sharing rules. Nothing in the platform mechanics requires, or even prompts, a check that the resulting combined authority is the one the organisation intended.

This is the gap this page addresses: not the mechanics of domain-level user identities and Vault memberships, which Veeva's own documentation covers directly, but how an organisation governs the authority that results once they are in use.

Decide, per role, whether cross-Vault consistency is the intended design

Some roles genuinely should carry equivalent authority across every Vault a person touches. A Quality reviewer approving deviations in Vault QMS and reviewing related regulatory commitments in Vault RIM may need broadly comparable standing in both, because the organisation's intent is one accountable person exercising one kind of judgement across a connected process.

Other roles should legitimately differ. A regional regulatory affairs specialist may need full authoring access in their own region's Vault and only read access, or no access at all, in another region's Vault, precisely because the organisation's segregation model depends on that difference. A support or platform administrator may need elevated technical access in a sandbox or configuration Vault and none in the production Vault holding live GxP records.

The governance decision that has to exist, and usually does not, is an explicit statement, role by role, of which pattern applies: consistent, or deliberately divergent with a stated reason. Without that statement, whatever a person's actual cross-Vault access turns out to be is simply whatever the sum of independent local provisioning decisions happened to produce. That is drift, not design, even when no individual Vault's access looks wrong in isolation.

A practical way to record this is a short cross-Vault role table, held alongside each Vault's own access-rule catalogue, with columns for the role, the Vaults it applies to, whether authority is intended to be equivalent or divergent across them, and the rationale.

Design joiner-mover-leaver to act on the whole footprint

The most consequential failure mode in multi-Vault identity governance is not excessive access. It is a leaver event that only removes access from the Vault where the offboarding request happened to originate, leaving standing access in a second Vault that nobody thought to check.

This happens because joiner-mover-leaver processes are frequently owned, and triggered, at the level of a single system or a single business function, while a domain-level identity's Vault memberships span Vaults that different functions administer. A robust design has to treat the domain-level user identity and its Vault memberships, not the single-Vault account, as the unit the leaver process acts on:

• the trigger for a leaver event should reach every Vault where the identity has access, sourced from the domain's Vault-membership record rather than a manually maintained list;
• removal timing should meet the same service expectation in every Vault, not only the Vault that raised the request;
• active tasks, delegations, owned records and pending workflow assignments in every Vault should be identified and reassigned, not only in the originating Vault;
• the closure record should confirm removal was verified in each Vault individually, because a domain-level deactivation does not always guarantee every Vault-level effect has been reconciled and observed.

Mover events deserve the same discipline in reverse: when a person's role changes, evaluate what that means for their access in every Vault they hold, not only the Vault where the role change was announced. A promotion that expands authority in Vault A is sometimes accompanied by an assumption, rarely stated explicitly, about what should happen to unrelated access the person still holds in Vault B. Define the transition sequence and maximum permitted overlap. New-role access may need to be established before old access is removed for operational continuity, but any temporary combination of old and new authority should be assessed for conflict, time-bounded and explicitly owned. Completion should not mean that the new Vault acted; it should mean that every affected Vault has reached the intended end state.

Recertify cross-Vault authority as one set

A Vault-by-Vault access review can look complete while still missing the combination that actually matters. A reviewer certifying a person's access in Vault QMS, looking only at that Vault's export, cannot see that the same person also holds a conflicting authority in Vault RIM, because that fact is simply not present in the data they were given.

An access recertification process for a multi-Vault environment should present, for each user, their combined access across every Vault in scope, not a series of disconnected single-Vault exports reviewed by different people with no shared view. Where full consolidation is not practical because different Vaults have different accountable business owners, the review should at minimum flag, for the reviewer's attention, any other Vault where the same identity holds material access, so the reviewer is prompted to ask whether that combination is intended.

Domain Admin access deserves separate, explicit certification, reviewed against its own justification rather than folded into an ordinary business-role review. The setting operates together with the required permissions in the relevant Vaults, so the review should cover both the domain-level setting and the Vault permissions that make its cross-Vault administration effective.

Assess segregation-of-duties across the boundary, not only within it

Segregation-of-duties analysis is usually designed to catch conflicting authority within a single system: the same person cannot both initiate and approve the same class of record. In a multi-Vault environment, the two halves of a conflicting pair of authorities can sit in different Vaults entirely. A person with authoring access to a regulatory submission record in Vault RIM and approval access over the change-control record that governs the underlying process in Vault QMS may represent exactly the kind of conflict a single-Vault segregation review would never surface, because neither Vault's own review has visibility into the other.

Building this analysis requires an explicit map of which authority combinations, across which Vaults, are considered incompatible, maintained alongside the cross-Vault role table described earlier. Where the identity provider or an identity governance tool sits above both Vaults, that combined view is the natural place to run the check. Where it does not, export or obtain the user's Vault memberships, reconcile them against the approved cross-Vault role table in a controlled review record, identify unexpected or missing access and incompatible combinations, obtain reviewer disposition, and track exceptions to closure. Set and justify the cadence according to access risk and change frequency. As a practitioner baseline, stable business-role combinations may be reviewed annually; privileged or high-change populations may warrant more frequent review, with additional checks triggered by movers, organisational changes or material access redesign.

Evidence set for a defensible multi-Vault identity model

A reviewable set normally includes: the cross-Vault role table stating intended consistency or divergence and its rationale; the joiner-mover-leaver procedure showing it acts on the full domain-level identity and Vault-membership footprint; leaver closure records confirming removal was verified in every Vault, not only the originating one; recertification evidence showing combined cross-Vault access was reviewed as a set; the cross-Vault segregation-of-duties map and its periodic review; and a justified, separately certified list of current Domain Admin holders.

None of this replaces the single-Vault access-rule catalogue and testing described for designing and assuring an individual Vault's security model. It sits alongside that evidence, addressing the specific risk that arises only once a person's authority is considered across more than one Vault at a time.

Sources

• Veeva, Managing Users Across Vaults, Veeva Vault Platform Help: domain-level user import, filtering and administration mechanics across a multi-Vault domain.
• Veeva, Cross-Domain Users & Authentication, Veeva Vault Platform Help: distinguishes a cross-domain user, whose account belongs to a different home domain, from a domain-level user with memberships in multiple Vaults within one domain.
• Veeva, Veeva Vault Domains & Domain Settings, Veeva Vault Platform Help: domain architecture, Domain Admin capability and domain-wide settings applied across a multi-Vault domain.
• European Commission, EudraLex Volume 4, Annex 11: Computerised Systems, January 2011: access-restriction, identity-recording and periodic-evaluation expectations for computerised systems, applied here to the combined multi-Vault access picture rather than a single system.

The cross-Vault role table, joiner-mover-leaver design points, recertification approach and segregation-of-duties method proposed on this page are Navata Library methods responding to a governance gap in current vendor and regulatory material, not regulatory terms in their own right.

Relevant next step

Ask whoever owns your most recent leaver from a multi-Vault domain to produce evidence that access was removed in every Vault that person could reach, not only the Vault where the offboarding request was raised. If that evidence cannot be produced quickly, the cross-Vault governance described above has not yet started.