Team & roles
Invite teammates by email from Team and give each one a role. Roles are per workspace: the same person can be an admin in one workspace and an auditor in another.
The four roles
Section titled “The four roles”| Role | Manage the team | Edit content | Mint an API key | Read everything |
|---|---|---|---|---|
| Owner | Yes | Yes | Yes | Yes |
| Admin | Yes | Yes | Yes | Yes |
| Member | No | Yes | No | Yes |
| Auditor | No | No | No | Yes |
Owner and admin are the same permission set today. The difference is that a workspace must always keep at least one owner (see below), so the owner role is the one that cannot be emptied out.
The auditor seat is read-only by construction
Section titled “The auditor seat is read-only by construction”An auditor can see the whole workspace and change none of it. That is enforced in the application, not by convention, and it is why the seat can be handed to an external assessor without a second thought.
It is also why an auditor cannot mint an API key. A workspace API key carries the workspace identity and nothing else, so it is full write access to the API. A read-only seat that could create one would not be read-only, whatever the label said.
Members cannot mint keys either, and that one is a deliberate judgment rather than a consequence. A member can already write the same data through the app, so a key grants no new capability, but it does grant new duration and attribution. A key has no expiry, is not tied to the person who created it, and is not revoked when their membership is. Keeping key creation with the roles that manage the team keeps credential lifetime with the people who manage access.
Giving an audit firm access for an engagement
Section titled “Giving an audit firm access for an engagement”Owners and admins can add outside auditors from Auditor access instead of Team. Each grant records the auditor’s firm and the date their access ends. On that date the workspace drops out of the auditor’s list and they can no longer open it. Nobody has to remember to remove them.
The grant stays listed after it ends, so you can see who had access and extend it for the next audit. You can move the end date or remove an auditor at any time, and a removed auditor is emailed. Each grant, date change and removal is written to the activity log.
An auditor takes no paid seat. A long engagement is extended rather than granted open-ended.
Sharing with the whole firm
Section titled “Sharing with the whole firm”When a firm staffs the engagement itself, share with the firm instead of inviting each auditor. On Auditor access, enter the email of the firm’s admin and the date access ends. If the firm is new to Keel, add its name and Keel sets the firm up with that person as admin.
The firm’s admin keeps a staff roster on Audit firm and assigns staff to your workspace. Each person they assign gets the same read-only auditor seat, ending on your date. You see who they assigned, you can move the date for all of them at once, and Stop sharing removes every one of them. Assignments and removals made by the firm also go into your activity log.
Naming the frameworks in the engagement
Section titled “Naming the frameworks in the engagement”Both forms let you tick the frameworks the audit covers. An auditor with frameworks named starts from them: their audit home, the auditor request list and the information request lists open on those frameworks. This narrows where they start, not what they can read. They keep read-only access to the whole workspace and can switch to every control or every list. Leave every box clear to scope the engagement to the whole workspace.
A workspace always keeps an owner
Section titled “A workspace always keeps an owner”Demoting or removing the last owner is refused. Promote someone else first, then step down.
Without that rule a workspace could be left with nobody able to manage the team, invite a replacement, or change a role, recoverable only by support, which is a bad place for your access to live.
Changing a role
Section titled “Changing a role”Owners and admins can change any role from Team, subject to the last-owner rule. Removing a member revokes their access immediately; their authored content stays, because an audit trail that disappears when someone leaves is not an audit trail.
Next steps
Section titled “Next steps”- Access reviews: prove periodically that the right people still have the right access, and record it.
- Competence & people: the ISO 27001 Clause 7.2 side, showing the people doing security work are competent for it. Different question from access.
- Data isolation: why membership can never reach another workspace’s data.