Home / Vaults & permissions
Access architecture

Vault boundaries people can explain—and enforce.

We translate ownership, job responsibility, and sensitivity into a maintainable RDM vault and permission model.

Begin with responsibility, not folders.

A vault should have a clear purpose, defined owners, a known audience, and a lifecycle. Folder trees then support that model rather than becoming the model.

  • Map users to job functions and approved tasks
  • Prefer user groups for repeatable access administration
  • Apply inheritance deliberately at vault and folder levels
  • Record exceptions with an owner and review date
  • Separate private user items from team-operational entries

Permission design decisions

Visibility

Who needs to know an entry exists? View access through parent paths is considered before granular action rights.

Capability

Launch, edit, delete, reveal, import, export, manage templates, and administer workspaces are treated as different responsibilities.

Inheritance

Parent rules are the default. Overrides remain limited, named, and reviewable so audits do not become archaeology.

Example role matrix

RoleTypical scopeOperating intent
Workspace administratorSystem settings, users, vaultsFew named custodians
Platform engineerAssigned infrastructure foldersUse and maintain entries
Service deskApproved support targetsLaunch without broad secret exposure
External consultantTime-bound project subsetMinimum visible and usable scope

Vault FAQ

Should every department get a vault?

Not automatically. Use a separate vault when ownership, audience, lifecycle, or security requirements are materially different.

Can permissions be overridden?

RDM supports inherited and custom permission patterns in applicable advanced data sources. We keep overrides exceptional and documented.

Do we need a permissions review?

Yes—on a schedule and after material team, vendor, or infrastructure changes. The review should verify both membership and the underlying role intent.

Make one vault the pilot.

We will map owners, roles, inheritance, and exceptions before rollout.

Plan the access workshop