Skip to main content

Inviting an Auditor

When you are going through a compliance assessment or an external audit, you can open up exactly the scope you choose, for a fixed period of time, read-only to an outside auditor - without creating a regular account for them inside your organization. This document covers inviting an auditor, setting their scope, what happens when access expires, and what an auditor can and cannot do.

1. Inviting an auditor (portal)​

Auditors are invited from the organization portal's Members page, and only an admin can do it. There is a dedicated "Invite auditor" card, separate from the regular member invitation form.

  1. Enter the auditor's email address.
  2. Choose the access scope - one or more connection groups (project groups), individual connections, or a mix of both. At least one must be selected; an invitation with an empty scope grants nothing and is rejected.
  3. Set the expiry date - it defaults to 30 days from today, and can be set no further than 365 days out.
  4. Click Invite auditor to send the invitation email. Once accepted, an auditor account is created together with an access grant for the scope and expiry you set.

To open additional connections or groups to an auditor who already has an account, use Grant access on the same page: pick the auditor, and set the scope, expiry, and an optional note. A note can be attached through this path, but not on the initial invitation.

An auditor's role is managed differently

An auditor's role cannot be changed from the role dropdown in the member list. What an auditor can see is entirely determined by their grants, described below, and the member list shows either an "access until" date or "no active access" next to them instead of a role selector.

2. Scope: connections and connection groups​

An auditor's scope is set as one of the following (or a combination):

  • A connection group - grants access to every connection in that project group, including ones added later. Use this to audit an entire organization project.
  • Individual connections - grants access to one or a few specific AWS account connections. Use this to audit a single account.

The grants list keeps every grant ever made, including ones that have since been revoked or expired - "what was opened, and when" is itself part of the record. Each entry shows whether it is currently active.

3. Expiry, extension and revocation​

  • Extending expiry - extending a grant marks the existing one as expired and creates a new grant with the same scope and a new expiry date, rather than quietly pushing the old date back. This keeps the history of exactly when access was open honest.
  • Immediate revocation - an admin can revoke a grant at any time. Revoking it immediately invalidates that auditor's session, so an already-issued session cannot keep working for the rest of its lifetime.
  • Natural expiry - once the expiry date passes, access ends with no extra action needed. An auditor's session is built so it cannot outlive that expiry, so logging in again or refreshing the page after that point no longer works.

An auditor can hold several grants at once; access ends at the earliest expiry among them (if the grants cover different scopes, each scope's own expiry applies).

4. What an auditor can do​

  • Read every screen for the connections (accounts) and connection groups they were granted - asset inventory, risk assessment results, IAM analysis, network and asset graphs, the read-only parts of project settings, and so on.
  • View and export reports as PDF - taking evidence away is exactly what this access is for.
  • Read the Audit Trail, within the scope they were granted.

5. What an auditor cannot do​

  • Any write action - creating, editing or deleting connections, changing settings, managing members, starting a sync/scan/IAM analysis, generating reports, and so on. Every screen renders read-only for them, and the server rejects every write request regardless.
  • Access to AWS credentials. Other read-only users can sometimes reach a credential-issuing path indirectly through a detail view, but this path is blocked for an auditor without exception. An auditor never ends up holding real AWS credentials.
  • Reading a connection or group they were not granted. This answers exactly like a project in another tenant - "not found" - so a refusal never reveals whether something exists at all.

6. Every read is recorded​

While someone is signed in as an auditor, every read request they make is written to the audit trail. A read that is already tracked as its own kind of event (viewing or exporting a report, for example) leaves that one record; everything else leaves a separate "read recorded" entry. Filtering the audit trail by actor role = auditor shows everything a given session looked at. See Audit Trail for details.

7. What happens when access expires​

Once access expires or is revoked, the auditor can no longer stay signed in, and a further attempt is refused with an "your access has ended" message. If continued access is needed, an admin has to extend it or create a new grant from the portal - an auditor has no way to extend their own access.