> For the complete documentation index, see [llms.txt](https://intuitem.gitbook.io/ciso-assistant/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://intuitem.gitbook.io/ciso-assistant/concepts/foundations/iam-and-scoping.md). # IAM and scoping How IAM, the domain hierarchy, default roles, and cross-domain visibility shape what each user sees This page is the **mental model** for how access and visibility work in CISO Assistant. The full configuration-side deep-dive (SAML / OIDC / MFA / PATs / accounting) lives in [Understanding the IAM model](/ciso-assistant/configuration/organization/iam-model.md); this page focuses on the three things every user needs internalised before they can predict what they will and won't see on screen: 1. Almost everything is bound to a **domain**. 2. Permissions are inherited **down the domain tree**. 3. Some permissions are granted by a domain **default role**. The combination of these three is what produces the most common "why am I seeing items from another domain here?" moment, which the last two sections explain and resolve. ## Everything is bound to a domain The platform's primary scoping unit is the **domain** (see [Domains](/ciso-assistant/concepts/foundations/domains.md)). Almost every operational object you create carries a domain — that's what drives *who can see it* and *how it rolls up in reports*. The list is long on purpose — to make the model concrete: * **Compliance**: audits / compliance assessments, requirement assessments, evidences. * **Risk**: risk assessments, risk scenarios, quantitative risk studies, EBIOS RM studies, business impact analyses, security exceptions. * **Operations**: applied controls, policies, tasks, incidents, findings, findings binders, commitments. * **Assets**: assets, contracts, entities, solutions, representatives. * **Privacy**: processings, personal-data inventories, right requests, data breaches. * **Project management**: projects, accreditations, responsibility matrices. A small number of objects don't carry a domain because they're either system-wide (the user catalogue, the role catalogue, instance settings) or imported from a library catalogue. Everything else lives *inside* a domain. ## Inheritance — roles flow down the tree The domain hierarchy is not just for organising the UI — it actively shapes access. **A role granted on a domain applies to every domain beneath it.** Give a user the *Analyst* role on a parent domain, and they get analyst-level access to every sub-domain underneath, without re-assigning them at each level. This is why the tree shape matters as much as the names: putting "France" and "Germany" under a "EMEA" parent isn't decorative — it's the lever that lets EMEA-level managers see across both without granting them individual roles per country. Permissions only flow **downward**: a role on a sub-domain does *not* grant any access to the parent. If you need a role-holder to see across siblings, the role goes on the shared ancestor. ### The one exception: third-party workspaces A **third-party workspace** — the folder holding a vendor's questionnaire, an *enclave* internally — is the one place where the tree deliberately stops conducting. Access granted there does not reach up: a representative with view rights on their workspace sees their questionnaire and nothing the domains above it share. That containment is what makes it safe to give an external party an account on your instance at all. Each third party gets one workspace per domain. See [third-party risk](/ciso-assistant/concepts/specialised-modules/third-party-risk.md#the-third-party-workspace). The same inheritance also drives reporting: most dashboards and analytics roll up across a domain *and* its descendants, so a leadership-level view on the parent domain is automatically the consolidated view across its sub-tree. ## Domain default role — why catalogues appear across all domains Every domain has **members**: the people its own and its sub-domains' IAM groups grant roles to. A domain can carry a **default role** — and the default role is what the domain grants its members, **on the domain itself** (and only there: the grant is never recursive). For example: if the **EMEA** domain has the *Baseline reader* default role, then a user granted any role on **EMEA** or **EMEA/France** through the IAM groups is a member of EMEA, and can view EMEA's catalog objects. The grant never extends downward: EMEA's default role gives nothing on **EMEA/France** — what members see there comes from their own roles. By default, the global domain (the root) carries the **Baseline reader** default role, which grants view access to catalog objects. Everyone in the organization is a member under the root, so everyone can read the root-level catalog. Some objects exist to be **shared**. Frameworks, threats, risk matrices, reference controls, and other catalogue-style items wouldn't be useful if they were trapped in a single domain — every team needs to be able to pull from the same shared library. That's why catalog objects (usually stored in the root domain) are viewable by everyone in the organization. Who is *not* a member, and why: third parties hold their grants inside third-party workspaces, which are not the domain's groups; service accounts hold direct assignments — no group grants them anything, so they read exactly what their own assignment names. Neither ever receives anything from a default role. The default role is a dial, not a law. In the enterprise edition, each domain's default role can be **tuned**: replaced by a narrower view-only role (a custom role listing exactly the object types this domain shares), or **removed entirely** — a domain with no default role shares nothing ambiently, and its members see exactly what their own roles grant. Removing the *root* domain's default role goes all the way: the instance then runs an **explicit-grant policy**, where nothing is ambient — even the catalog is visible only to those whose roles name it. It's one field on the domain, so tightening takes effect immediately and is just as easy to revert. Configuring default roles is an **enterprise** capability. In the community edition, the default role exists only on the root domain, fixed to *Baseline reader* — it cannot be changed, and no other domain carries one. ## Why you sometimes see items from other domains Assessments routinely *compose* objects across the tree. Risk assessments reference applied controls, threats, and assets; audits reference applied controls and evidences; findings binders reference applied controls and the requirement assessments they remediate. When you're working inside one assessment, the platform's selectors and pickers don't just show you what's in the assessment's own domain — they show you **everything you have access to**. So a risk scenario authored inside the *France* domain can pull in: * A shared applied control attached to the *EMEA* parent domain (you can see it because of inheritance). * A threat from the global library (you can see it because the root domain usually has a "baseline reader" default role). * An asset attached to a sibling *Germany* domain (if your role gives you access there). This is by design — composing across the organisation is the whole point of a centralised GRC platform — but it can be disorienting on day one. The rule is consistent: you see what you have access to, regardless of which domain you started on. ## Managing the noise — focus mode (PRO) When you have access to many domains and you only want to think about one at a time, the platform exposes [**Focus mode**](/ciso-assistant/features/focus-mode.md) (PRO, default off). Focus mode scopes the entire application — every list, dashboard, count, and search — to a single domain and its sub-tree, hiding everything else for the rest of your session. It does not grant or revoke permissions; it just filters the view. Use it when: * You operate across many client domains and want to work on one at a time. * Your organisation is large enough that the "all domains" view is overwhelming for day-to-day work. * You're running a demo or an onboarding and want the rest of the workspace out of the way. When focus is engaged, all the cross-domain composition described above is suppressed — you'll only see assets, controls, and assessments from the focused sub-tree. Clearing the focus restores the full cross-domain view. ## Related * [Domains](/ciso-assistant/concepts/foundations/domains.md) — domain hierarchy, IAM groups, restructuring, moving objects. * [Actors and teams](/ciso-assistant/concepts/foundations/actors-and-teams.md) — who gets assigned what. * [Understanding the IAM model](/ciso-assistant/configuration/organization/iam-model.md) — full configuration-side deep dive (SSO, MFA, PATs, accounting). * [Focus mode](/ciso-assistant/features/focus-mode.md) — the PRO tool for scoping back the view. * [User groups](/ciso-assistant/configuration/organization/user-groups.md) — how role assignments are actually stored and managed. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://intuitem.gitbook.io/ciso-assistant/concepts/foundations/iam-and-scoping.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.