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

Role	Manage the team	Edit controls and evidence	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 differ in two places. Only an owner can make someone an owner, change an owner’s role or remove an owner, and only an owner can delete the workspace. A workspace must also always keep at least one owner (see below).

What an auditor can and cannot change

An auditor sees the whole workspace and cannot edit controls, upload or attach evidence, or change checks. That is enforced in the application, not by convention, so the seat can be handed to an external assessor without a second thought.

The auditor’s own work does live in the workspace. An auditor can issue request lists and requests, comment on them, accept a request or send it back, accept or flag evidence, draw samples and record results, record tests, raise findings, and keep notes the client’s team does not see. Accepting and returning are auditor-only. Audit fieldwork walks through each step.

The seat is free on every plan and never counts against the seat limit, so a workspace whose paid seats are all taken can still invite its auditor.

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, which is far more than the auditor seat allows.

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

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

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 free 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.

Running the firm’s side

The firm works from Audit firm. Whoever sets the firm up becomes its admin. Admins keep the staff roster and assign staff to each client that has shared with the firm. Each person on the roster needs a Keel sign-in with the address listed there.

Assigned staff are emailed an invitation to the client’s workspace, and staff see only the clients they are assigned to. Removing someone from the roster takes them off every client they were assigned to. Once a client’s access date has passed, nobody new can be assigned until the client extends it.

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 can still read 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

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

Owners and admins can change roles from Team, subject to the last-owner rule. An admin can’t pick Owner for anyone, and can’t change or remove an existing owner; ask an owner to do it. Nobody can change their own role. Removing a member revokes their access, which can take a short while to take effect everywhere. Their authored content stays, because an audit trail that disappears when someone leaves is not an audit trail.

Handing over work when someone leaves

When you remove a member from Team, pick who takes over their work in the menu beside Remove. It starts on you. Everything they owned moves to that person in the same step:

• controls, risks and AI services they owned
• evidence and policies they owned, and their place on any responsibility matrix
• vendors where they were the business or security owner
• open checklist runs and evidence requests assigned to them

Requests an auditor has already accepted and completed checklist runs stay as they were. Pick Leave work unowned to skip the handover, and their items show as unassigned. Auditors own nothing, so removing one has no handover.

Control owners and reviews

Each control has an owner, set on the control’s page. Owners and admins can also give it a review schedule: monthly, quarterly, every six months or yearly. When a review is due within a week, or is overdue, the owner gets an email listing it. A control with no owner goes to the workspace’s owners and admins instead.

After checking a control, press Mark reviewed. That records the date and sets the next review one period out. Anyone except an auditor can mark a control reviewed.

Teams

The Teams tab on the Team page groups workspace members under a name, such as Engineering or IT. A team grants no access of its own: what each person can do still comes from their role.

Owners and admins create, rename and delete teams, and pick each team’s members from the workspace. Only current members can be picked, and removing someone from the workspace removes them from every team. Deleting a team leaves its members in the workspace. Every change is recorded in the activity log.

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.