Six roles, and one of them cannot change anything

The six roles

Six exist, and five of them can be assigned inside an organisation. The sixth is a platform-level role that cannot be granted per-tenant at all — an attempt to do so is refused rather than quietly downgraded, which matters because the failure mode of a role system is usually a silent upgrade nobody noticed.

• Organisation admin — full administrative control of one organisation.
• Compliance admin — the same administrative surface, framed around the compliance programme. This is the role that stands in for a data protection officer today.
• Reviewer — works assessments and workflows, reviews what contributors submit.
• Contributor — answers assigned questions and works items, without administrative control.
• Auditor — read-only. See below, because this one is the whole point.
• Platform admin — global, not assignable to a tenant, used for support and provisioning.

The read-only role, and why that is the entire mechanism

Permission checks in the platform resolve to a small number of sets rather than a per-endpoint matrix. One set can view workflows, a second can edit them, a third can administer, and a fourth can sign off impact assessments.

The auditor role appears in the view set and is the only role absent from the edit set. That single exclusion is the read-only guarantee, and stating it that way is more useful than a feature bullet saying read-only access is supported — because it tells you where to look if you want to verify it, and it tells you that read-only is a property of the permission sets rather than a UI mode somebody could route around by calling the API directly.

There is a known gap worth stating. There is no first-class data protection officer role; the compliance admin role does that job. The consequence is that a DPO in your organisation holds administrative permissions they may not need, and if least privilege matters to you, that is an argument for a dedicated account rather than for adding the DPO to an existing admin login.

Membership is checked before any data is touched

Every authenticated request resolves an active organisation and then verifies a live membership record for that user in that organisation before the request reaches a handler at all. No membership, no request — the answer is a refusal rather than an empty result set, which is the right shape because an empty result is indistinguishable from a real absence of data.

Beyond that boundary, every query carries its organisation explicitly and every object lookup returns not-found rather than forbidden when the identifier belongs to somebody else. That distinction is deliberate: not-found on a mismatched identifier means an identifier cannot be used to probe for the existence of another organisation's records.

Where a parameter could widen scope — asking for the team members of a named organisation, for instance — the membership check runs again against that specific organisation, and the answer is an explicit refusal rather than a not-found, because in that case the caller already knows the organisation exists and pretending otherwise helps nobody.

Working across several organisations without several accounts

This is the consultancy, agency and managed-service case, and it is the one a single-tenant design handles badly. A person holds memberships in as many organisations as they need, each with its own roles — admin in one client, contributor in another, auditor in a third.

Listing memberships returns the organisations with a live membership and the currently active one. Switching mints a new session scoped to the chosen organisation rather than mutating the existing one, and refuses outright where there is no active membership.

Minting rather than mutating is the important detail. A session that carries an organisation identifier it was issued with cannot be pointed at a different organisation by anything the client does, because the scope is inside the signed token rather than in a header or a query parameter that travels alongside it.

Sessions, and how one is revoked before it expires

Sessions are signed tokens with an eight-hour absolute lifetime — shortened from a longer window after a security review, on the reasoning that a compliance console holding personal data should not keep a session alive for a working day and a night.

Revocation does not wait for expiry. Each user carries a token version, every session carries the version it was issued under, and any session issued under an older version is refused. Bumping the version — on a password reset, a logout, or an administrative revoke-all — invalidates every outstanding session for that person at once, without a session store to query or a denylist to maintain.

Two transports are supported. An authorisation header is primary. A cookie is a fallback used only when no header is present, and a cookie-authenticated state-changing request is additionally checked against the permitted application origins, because a cookie that travels automatically is exactly what a cross-site request forgery relies on. Multi-factor authentication is available as a time-based one-time password, and the intermediate token issued mid-authentication is explicitly rejected as a session in its own right.

Two kinds of audit log, and only one is tamper-evident

This distinction gets blurred in most marketing copy, including some of our own, so here it is drawn properly.

The general activity log records who did what to which object, with the actor, the action, the entity and structured metadata. It covers authentication events, administrative configuration changes, scanner runs and rights requests. It is append-only by construction — the service that writes it exposes only an insert and reads, with no update or delete path — but it is not cryptographically chained. Somebody with direct database access could alter a row and nothing in the data would show it. The one deliberate exception is that an actor reference is nulled when a user is hard-deleted, which is a data protection obligation rather than an audit weakness.

The evidence ledgers are a different construction entirely, and they are the ones that carry the word immutable honestly. Records-of-processing and impact-assessment events, and consent evidence, are written into per-organisation hash chains where each entry commits to the previous one, with a keyed authentication code over the same material and a separately signed head anchor. That combination detects the three attacks a bare hash chain misses — truncating the tail, wiping the chain and forging a new head — and a verification endpoint walks the chain and reports which entry broke and how.

So when a security questionnaire asks whether your audit log is immutable, the accurate answer is that the evidence trail behind consent, records of processing and impact assessments is cryptographically verifiable, and the general activity log is append-only. Both are true, they are different guarantees, and conflating them in a questionnaire response is the kind of thing that unravels badly later.

What is not modelled yet

Custom roles. The six are fixed; you cannot compose a role from individual permissions. For most organisations the sets map cleanly enough, but a large one with an unusual separation of duties will find the granularity coarse.

A dedicated data protection officer role, as above. And self-serve teammate invitation for general platform users — assessment work can be delegated and invited through its own flow, but provisioning a new tenant user is an administrative action rather than a tab in settings.

Each of those is a real limitation rather than a roadmap item being described as present, which is the distinction worth insisting on when the person reading is filling in a vendor security assessment.