User groups

Users in CyberGuard hold no permissions directly. A user group links one domain with one role, and every member of the group receives that role’s permissions on that domain and everything beneath it. Groups are the pivot the whole access model turns on: to change what someone can do, you change which groups they are in.

Where to find it

Organization → User groups in the sidebar.

Groups are named after the pair they represent, as domain - role: Global - Administrator, Acme Manufacturing - Analyst, Payments - Reader. Reading a group name tells you exactly what it grants and where.

The roles

Eight built-in roles exist. The table is deliberately a summary — the underlying permission matrix runs to several hundred entries.

Role	Can	Cannot
Administrator	Everything, instance-wide — all business objects plus domains, users, groups, libraries, settings and backups. Approves risk acceptances.	Nothing; it is the only role that changes instance-wide configuration.
Domain manager	Everything an Analyst can, on its own domains, plus creating sub-domains and managing their groups. Reads global objects.	Approve risk acceptances. Manage users, libraries or settings.
Analyst	Create, update and delete the operational objects of its domains — audits, risk assessments, controls, assets, evidences, tasks, findings.	Touch access control. Approve risk acceptances.
Reader	Read everything in its domains, including dashboards and metrics.	Create, update or delete anything.
Approver	Read its domains, and approve or reject risk acceptances and validation steps.	Create or update business objects. Its read scope is narrower than Reader.
Respondent	Answer the requirements assigned to it — set results, attach controls and evidences, comment.	Create audits; reach the risk or administration modules.
Third-party respondent	The same, confined to the questionnaire the external contact was invited to.	See anything outside that questionnaire.
Technical tester	Run technical posture checks and manage the findings that follow.	Almost everything else; read-only on assets and frameworks.

Which groups exist

Global groups

A new instance already has five groups scoped to the root domain, granting their role across every object in the instance:

• Global - Administrator
• Global - Analyst
• Global - Reader
• Global - Approver
• Global - Respondent

Domain groups

Every domain created with Create IAM groups enabled is provisioned with its own set, scoped to that domain and its descendants. For a domain named Payments you get:

• Payments - Domain manager
• Payments - Analyst
• Payments - Reader
• Payments - Approver
• Payments - Respondent
• Payments - Technical tester

Third-party respondent groups are the exception: they are created on the third-party workspace of an entity when you invite that vendor’s contacts to answer a questionnaire — one workspace per third party per domain, so a vendor assessed repeatedly keeps the same access across rounds.

How permissions compose

Three rules cover almost every question that comes up:

1. Memberships add up. A user in several groups holds the union of their permissions. There is no “deny” that overrides a grant, so adding a group can only widen access.
2. Grants flow down the tree. A role held on a parent domain applies to its sub-domains. Granting on the root domain grants everywhere.
3. Scope beats role. Payments - Analyst is far narrower than Global - Reader despite the stronger-sounding role. Choose the domain first, then the role.

Least privilege therefore comes from picking the narrowest domain that still covers the person’s work.

Managing members

Open a group and use Add members. The picker lists users not already in the group; search by email, first name or last name, tick Include inactive to also see deactivated accounts, and confirm. Your selection is preserved while you search and page through results.

To remove people, go to the group’s users, select them and use Remove from group.

Membership is governed by the change user group permission on the group’s own domain, so a domain manager can manage their own domains’ groups without holding global user-management rights.

Caution

Two safeguards are enforced. The last member of Global - Administrator cannot be removed, and a domain manager cannot remove themselves from their own domain’s administrative group — another administrator has to do it.

Related

• Users — creating the accounts you put into groups.
• Role assignments — the flattened view of every grant in force.
• Domains — the scope each group is bound to.