Scope-based Access on Policy and Control
Scope-Based Access Control is an optional, tag-driven access control layer for Policy and Control. It works alongside your existing connector/account-level access and role permissions to restrict which specific Policies, Controls, and Evaluation results a user can see and act on, based on Qualys tags assigned to that user.
Permissions define what a user can do (view, create, edit, delete). Scope defines which objects they can do it to. The two always apply together.
This is separate from, and does not change, your existing connector tagging or connector scope model. It is an additional, optional layer that applies specifically to Policy and Control visibility.
Key Concepts
| Term | Definition |
|---|---|
| Evaluation Scope Mode | A per-customer preference that determines whether tag-based scoping is applied. Set to Connector Only (legacy behavior) or Connector and Policy (tag-scoped behavior). |
| Scoped tags | Tags assigned to a Policy or Control that determine which users can see or act on it under Connector and Policy mode. |
| Global Policy Read tag (GLB_POLICY_READ) | A system tag is automatically created for every customer. A manager applies it directly to a Policy or Control (via Apply Tags) to make that object visible to sub-users without granting them edit, delete, or re-tag rights on it. |
| Scoped user (Entity Admin) | A user without global scope. Sees only Policies, Controls, and Evaluations whose tags intersect with their own tags flowing from entity/connector level, unless the object is shared read-only via the GLB_POLICY_READ tag. |
| Unscoped user (System Entity) | A user with global scope, generally an administrator with broader visibility across all tag-scoped Policies and Controls. |
How Scoping Works
Scoping behavior depends on your customer's Evaluation Scope Mode preference, set on the Preferences tab. This setting is visible to Manager users only:
| Mode | Behavior |
|---|---|
| Connector Only (default) | No change from today: visibility is governed solely by connector/account access. |
| Connector and Policy (opt-in) | A user only sees a Policy or Control if its tags intersect with the tags assigned to them. Evaluation results are additionally filtered to only the Controls scoped to the user's tags. |
If a user has no tags assigned while the customer is in Connector and Policy mode, that user sees zero Policies, Controls, or Evaluations, except for objects a manager has explicitly tagged with GLB_POLICY_READ for read-only sharing.
What's affected vs. unaffected
| Area | Scoped when Connector and Policy is on? |
|---|---|
| Policy listing | Yes |
| Control listing | Yes |
| Control evaluation results (AWS/Azure/GCP/OCI) | Yes, plus results are further narrowed to scoped Controls |
| Remediation history | No, always account-scoped only |
| Insight Evaluation | No, always account-scoped only |
Creating, Editing, and Cloning Policies and Controls
Behavior differs depending on whether the acting user is a System Entity (has global scope) or an Entity Admin (does not have global scope):
- System Entity user (global scope): Can create, edit, delete, and apply tags to Policy and Control. Defining scope on create is optional.
- Entity Admin user (no global scope): Must define scope tags when creating a Policy or Control, and cannot edit, delete, or apply tags to a Policy or Control that carries the GLB_POLICY_READ (global) tag.
- Cloning: Any user can create a copy of a Policy or Control they can view (except system-defined ones), even if they can't edit the original. The clone starts with the same field values but empty scope tags, so assign new scope tags to the copy before saving.
- Connector Only mode: Scoping isn't in effect. Defining scope on create is optional, and users can edit, delete, and tag Policies and Controls as they always have.
Sharing Read-Only Access with the GLB_POLICY_READ Tag
A Policy or Control created by a manager (or any System Entity user) can be made visible to Entity Admin users without granting them edit, delete, or re-tag rights on it. To do this:
- Open the Policy or Control and use the new Apply Tags action.
- Add the GLB_POLICY_READ tag to the object.
Entity Admin users can then see the Policy or Control in their scoped views, but cannot edit, delete, or change its tags. A System Entity user can later use the new Edit option on a System Control to remove tags that were previously added, including GLB_POLICY_READ.
The GLB_POLICY_READ tag is created automatically for every customer — existing customers and new customers alike — so it is always available without manual setup.
Permissions Reference
The Policy, Control and Exception Permissions section governs actions on these objects, independently of scope. This replaces the legacy "Manage Custom Controls" permission with 10 granular permissions.
| Object | Read | Create/Clone | Edit | Delete |
|---|---|---|---|---|
| Policy, Control & Exception (shared) | CLOUDVIEW.POLICY.CONTROL.ACCESS(Policy, Control and Exception Access) |
— | — | — |
| Control | — | CLOUDVIEW.CONTROL.CREATE(Create, Clone Control) |
CLOUDVIEW.CONTROL.EDIT(Edit Control) |
CLOUDVIEW.CONTROL.DELETE(Delete Control) |
| Policy | — | CLOUDVIEW.POLICY.CREATE(Create, Clone Policy) |
CLOUDVIEW.POLICY.EDIT(Edit Policy) |
CLOUDVIEW.POLICY.DELETE(Delete Policy) |
| Exception | — | CLOUDVIEW.EXCEPTION.CREATE(Create, Clone Exceptions) |
CLOUDVIEW.EXCEPTION.EDIT(Edit Exceptions) |
CLOUDVIEW.EXCEPTION.DELETE(Delete Exceptions |
Policy, Control and Exception Access is the master read permission. See UI Changes by Permission State below for the full, precise list of what's hidden or shown at each permission level.
Interface Changes by Permission State
Without Policy, Control and Exception Access
- Posture, Policy, and Response tabs are hidden entirely
- CSPM report option is hidden from Reports
- Controls Failed column is hidden for resources in the Inventory tab (all clouds)
- Controls Evaluated tab is hidden in resource details (all clouds)
- Inventory failed/passed columns are hidden in the multi-cloud Inventory tab
- Misconfiguration count is hidden in Attack Path
- Build Control option is hidden from the Investigate tab
- Posture-related dropdown options are hidden in the Dashboard's Create Widget flow
With Policy, Control and Exception Access, no create/edit/delete permissions
- Policy tab shows, with a view-only list for Policy, Control, and Exception
- Create, Edit, and Create Copy actions are hidden across the Policy, Control, and Exception tabs
With create/edit/delete permissions also granted
- Create, Edit, and Delete become available for whichever of Policy, Control, or Exception the granted permission covers
- Copy (clone) for Control specifically requires Create, Clone Control; Policy and Exception copy follow their own Create permission the same way
SBAC-Specific Changes
- The Preferences tab (visible to Manager users only) gets a new Scope setting: Connector Only vs. Connector and Policy
- System Entity users (users with global scope) can create, edit, delete, and apply tags to Policy and Control
- Entity Admin users (users without global scope) cannot edit, delete, or apply tags to a Policy or Control that carries the global tag
- A new Apply Tags action is added to apply the global tag to a Policy or Control
- A new step is added to the create/edit flow for Policy and Control to define access scope
- The Policy/Control view screen now displays the defined access scope
- A new Edit option is added on System Control to remove previously added tags
Roles Reference
| Role | Permissions | Typical use |
|---|---|---|
| TotalCloud User (existing) | Read-only Policy, Control and Exception Access; no CRUD | General users who need visibility but not governance rights. Learn more |
| TotalCloud Policy Admin (new) | Full CRUD on Policy, Control, and Exception | Security engineers building and tuning controls |
| TotalCloud Policy Reader (new) | Read-only on Policy, Control, and Exception | Auditors, compliance stakeholders. Learn more |
Every permission above is individually selectable, so you can build custom roles too, for example, a role that can create and edit Controls but not delete them, or edit and delete Exceptions but only view Controls. See Assign Role to Users for how to build a custom role.
Account-Level Overrides
Two overrides sit above the permission and scope model, for admins who need to bypass it entirely for a specific user:
| Override | Effect |
|---|---|
| Allow user full permissions and scope | Grants the user complete access to everything, regardless of assigned role or tag scope. Supersedes the entire permission and scoping model. |
| Allow user view access to all objects | Grants full read visibility across all objects, independent of tag scope. Create, edit, and delete rights still follow the user's assigned role and permissions as normal. |
If neither override is enabled, a user's effective access is simply their role's granted permissions, applied only within their tag-based scope.
Migrating to SBAC
Moving to tag-based scoping is optional and customer-controlled.
- If you're happy with your existing roles and permissions, no action is required. Nothing changes for you.
- To adopt SBAC, set your Evaluation Scope Mode preference to Connector and Policy and assign tags to your users and to the Policies/Controls you want scoped. Existing functionality keeps working, but scope enforcement only takes effect once tags are defined.
- The Global Policy Read (GLB_POLICY_READ) system tag is created automatically for your account. You don't need to create it yourself. Apply it directly to a Policy or Control to share it read-only with sub-users, without tagging every viewer individually.
Troubleshooting
| Symptom | Likely Cause | What to Check |
|---|---|---|
| A user sees zero Policies or Controls unexpectedly | The user has no tags assigned while the customer is in Connector and Policy mode | Confirm the user's assigned tags overlap with the object's scope tags, or that the object carries the GLB_POLICY_READ tag for read-only sharing |
| Evaluation results look stale after re-tagging a Control | Scoped-control cache hasn't refreshed yet (up to a short delay) | Wait a few minutes, or re-check after the Control's tags are confirmed saved |
| Can't edit, delete, or tag a Policy or Control you can otherwise see | It carries a read-only scope tag you don't have edit rights to | Clone it instead. The copy starts with empty scope tags you can assign yourself |