Domains

A domain is the container everything else in CyberGuard lives in. It represents an organizational scope — a subsidiary, a business unit, a client, a region — and it is the platform’s primary mechanism for two things at once: access control, because roles are granted on a domain, and reporting boundaries, because dashboards and analytics aggregate per domain. Get the domain tree right early; almost every other decision follows from it.

Where to find it

Organization → Domains in the sidebar.

Key concepts

The tree

Each domain can name a Parent domain, which is how you build a hierarchy: a group-level domain on top, subsidiaries or regions beneath it, business units or programmes beneath those. Above everything sits a reserved root domain, Global, which holds cross-organization content — the built-in catalogs and libraries every domain can read.

Two things follow from a parent-child relationship:

Permissions flow downward. A role granted on a parent covers objects in its sub-domains, so you do not re-grant at every level.
Reporting rolls up. A view scoped to a parent aggregates the parent and its descendants, which is what makes leadership-level numbers work the same way the org chart does.

The hierarchy is not frozen. Editing a domain’s Parent domain moves the whole sub-tree — the domain and everything beneath it — under the new parent. Use it when a programme becomes a subsidiary, when two units merge, or to promote a sub-domain back to the top. The platform refuses moves that would create a cycle.

Create IAM groups

Not every domain needs to be an access-control boundary. The Create IAM groups checkbox decides:

On — the platform provisions one user group per role for this domain. Anyone who needs access is put in one of those groups, and the domain is a true permission scope.
Off — no groups are created. The domain still exists in the tree, can be selected in forms and can hold objects, but it carries no permission machinery of its own; access flows from whatever parent it sits under.

Turn it off for domains that are pure structure — splitting a subsidiary into “2025 audits” and “2026 audits”, for instance, where each year does not need its own set of groups. The choice is reversible: switching it on later provisions the groups, switching it off removes them.

Fields on a domain

Beyond the name and description, the list shows Content type (domain, enclave or the global root), the Parent domain, whether IAM groups were created, and any Labels you have attached. Labels are a light way to tag domains by client, region or engagement without adding levels to the tree.

Working with domains

Use the add button to create a domain, and expect to create its perimeters and user groups next. You can also bring a domain in from a file; the import offers Load missing libraries, to pull in any framework or matrix the bundle references, and Create missing asset classes, which adds the custom asset classes it uses to the global catalog.

Moving objects between domains

Nearly every operational object — audits, applied controls, evidences, risk scenarios, assets, tasks, policies, findings, incidents, entities — belongs to a domain, and that binding drives both visibility and roll-up. Reorganizations happen, so the binding is not permanent:

One object at a time — edit it and pick a different Domain. Access is re-evaluated on save, so the record leaves one domain’s views and appears in the other’s.
Several at once — select rows in a list and use the Change domain batch action.

Objects whose domain is dictated by a parent do not offer the batch action: a risk scenario always follows its risk assessment, so you move the parent instead.

Domain or perimeter?

A useful test: do these two scopes need different people seeing them? If yes, they are domains. If they need separate assessments but the same audience, they are perimeters inside one domain.

Perimeters — the finer, non-IAM scope inside a domain.
User groups — the per-domain groups that Create IAM groups provisions.
Role assignments — the explicit view of who holds what, where.
Analytics — where the roll-ups land.