Skip to main content

Tenant Access Audit

The Tenant Access Audit answers a question every Tenant eventually needs to answer for a customer, an auditor, or itself: who can access this Tenant, and what can they do? It lists everyone with access — from the Tenant itself and from any parent Tenant above it — along with their role and where that access comes from.

What this shows​

The report lists every person who can reach the Tenant:

  • Direct members — people added to this Tenant directly.
  • Inherited administrators — people who hold Administrator level or higher on a parent Tenant. In Breeze, administrator-level access flows down the Tenant hierarchy, so an administrator of a parent Tenant can also reach every Tenant below it. The audit surfaces exactly who that applies to.

For each person, the report shows:

  • Their role and task roles
  • The Tenant their access comes from, and how many levels up that Tenant sits
  • Their account status

Below the list, a Machine access summary counts non-human access: active OAuth clients, active AMR integrations (including ones inherited from a parent Tenant), members with API access enabled, and connected external data sources.

The first two counts in that summary are worth reading together. Active OAuth clients are the supported way for an external system to reach the Breeze API. API-enabled members counts people whose account still carries the older API-key permission, which lets an integration act on their behalf. That older route is being retired, so anything counted here is usually something to move over to an OAuth client rather than something to keep.

Who can run it​

Required Roles

Required roles: System Administrator (or higher) on the Tenant being audited, and Access Auditor

To perform the following steps, you need to have the roles listed above.

The Access Auditor role is assigned like any other task role, from a user's profile in User Administration — but only to someone who already holds System Administrator level. The role-editing drawer won't offer it for a Tenant administrator, so a Tenant administrator can neither grant it nor be given it. If you're a Tenant administrator and need an audit, ask your Sotera or partner system administrator to run it; the pseudonymized Excel export below is built for them to share the results with you directly.

Where to find it​

Open the Tenant you want to audit, go to Tenant Settings → Security, and click Open in the Tenant access audit section. The report opens with the audit for that Tenant already run — there's nothing to configure to see the first report.

The section only appears for users who can actually run the audit — System Administrator level or higher on the Tenant, plus the Access Auditor role. If you hold both and still don't see it, check that you opened the settings of the Tenant you mean to audit.

Understanding pseudonyms​

If the Tenant sits below other Tenants in the hierarchy, some of the people it inherits access from may be outside what you're normally allowed to see — for example, an administrator of a parent organization you don't otherwise have visibility into. The audit still needs to tell you they exist, so instead of hiding them, it shows a placeholder identity such as User-3F9A2B7C1D4E in place of a name or email.

These placeholders have two useful properties:

  • They're stable. Run the audit again next month, and the same person gets the same placeholder — so you can compare two audits and tell whether it's still the same person or someone new took over that access.
  • They don't carry across Tenants. The same person shows up under a different placeholder in a different Tenant's audit, so placeholders can't be used to track one person across multiple Tenants.

Sotera can resolve a placeholder back to a real person on legitimate request — for example, if you have a specific concern about who holds an inherited administrator role. Contact your Sotera account contact to request this.

Exporting to Excel​

Click Export to Excel to download the report as a spreadsheet, with the access list and the machine-access summary on separate sheets.

Before the download starts, a dialog offers one choice:

  • Pseudonymize inherited rows (checked by default) — every row that comes from a parent Tenant is shown as a placeholder in the file, regardless of what you personally can see on screen. This is the version meant to be handed to the Tenant directly: it shows the Tenant's own view of who can reach it, without exposing the identities of people from parent organizations.
  • Unchecked — the export matches exactly what you see on screen. Anyone whose Tenant you already have visibility into appears with their name and email; only people genuinely outside your visibility stay pseudonymized.

Every time the audit runs or is exported, that action is recorded in the Tenant's audit history.

Who can see our data?​

Running or exporting an audit only ever shows access — role assignments and account status — never Credential data, personal data collections, or anything else stored in the Tenant. People outside your normal visibility are pseudonymized rather than named, by default even in the file you might hand to someone else. Only Sotera can resolve a pseudonym to a real person, and only on legitimate request. Every audit run and every export is itself logged, so there's a record of who looked and when.

Learn more​