Knowledge base / regulation10.com product guide

Managing team members and in-app roles

To manage your team, open Team (or Members) in settings. Invite a colleague by email and assign an in-app role: Owner, Admin, Member, or Viewer. You can change a person's role or remove them at any time, and every change is written to the audit log.

The four roles map to how compliance work is actually distributed in an organisation. An Owner has full control, including billing and the ability to manage other Owners; this is the person answerable for the workspace itself, usually whoever set it up or the budget holder. An Admin manages systems, module runs, and evidence, but not billing; this fits the compliance lead or programme manager running the day-to-day work. A Member works on the systems assigned to them, answering module questions and attaching documents; this fits engineers, product owners, and data specialists who hold the facts a module asks about. A Viewer has read-only access; this fits internal audit, legal reviewers, and senior stakeholders who need to see the state of the work without the ability to alter it.

Assigning the narrowest role that lets a person do their job is worth the small effort. It follows the least-privilege principle that underlies most security standards, and it keeps your audit trail meaningful: when a record shows who changed a classification, the role model is what makes 'and they were authorised to' part of the same answer. A governance record maintained in a workspace where everyone can edit everything is weaker evidence than the same record with enforced separation.

Invitations work by email. The colleague receives a link, creates their account or signs in, and lands in your workspace with the role you set. Until they accept, the invitation is pending and grants nothing. The number of seats available depends on your subscription tier.

Role changes take effect on the person's next request. There is no delay you need to plan around, and no session where someone keeps yesterday's permissions. Removal works the same way: a removed person loses access at once, while everything they did remains in the record attributed to them. Work history is never rewritten by a departure, which is exactly what an auditor expects.

Two rules protect the workspace from lockout and privilege mistakes. Only an Owner can manage billing, so a compromised or mistaken Admin account cannot change your plan. And only an Owner can promote, demote, or remove other Owners, so control of the workspace cannot drift downward by accident.

A practical suggestion for first setup: create one Owner, make your compliance lead an Admin, add the people who hold system knowledge as Members, and add internal audit as Viewers. Review the list periodically, because access reviews are themselves a control most frameworks expect, and the audit log gives you the change history to support one.

When someone leaves the organisation, remove them the same day their access elsewhere is revoked, and reassign any AI systems they owned so each record keeps a live, answerable owner. An inventory whose owners have all moved on is a common audit finding, and it is entirely avoidable with a leaver step that takes under a minute.

Steps

1. Open Team (or Members) in settings.
2. Invite a colleague by email.
3. Assign an in-app role: Owner, Admin, Member, or Viewer.
4. Change a role or remove a member at any time; changes are written to the audit log.