User Roles, Access Control, and Organizational Structure
Organizations
Organizations sit at the top of the tenancy model. Repositories, scan zones, credentials, asset lists, dashboards, and reports all belong to an organization, and a user's role is granted per organization. One user can hold different roles in different organizations; the system-level administrator sits above all organizations. Plan organizations around business units or customers, not around scanners.
Roles
Built-in roles include Administrator, Security Manager, Security Analyst, Vulnerability Analyst, Scan Operator, Credential Manager, Auditor, and Executive. They range from full control inside an organization (Administrator) through operational roles (Scan Operator launches scans; Credential Manager only manages credentials) to read-focused roles (Auditor, Executive) that consume dashboards and reports. Choose the narrowest role that does the job.
Users, groups, and access
Users are local or authenticated through LDAP/AD, where directory groups map to SC groups that carry roles. Restrictions layer on top of roles: a user can be limited to specific asset lists, which caps everything they can see - assets, vulnerabilities, reports, and dashboards.
Traps
- An organization Administrator is not the global system administrator; questions often swap the two.
- Role and asset-list changes apply at the user's next login, so an old session can mask a fix.
- A restricted user with a valid role but no asset lists sees nothing.
- Group mapping fails silently when the directory query does not return the group.
Rule of thumb: model access as Role × Organization × Asset List. When a user cannot see data, check the asset-list restriction before the role.