Role-Based Access and Least Privilege
1TEN supports defined roles that enforce least privilege: Administrator (full platform access including user management), Assessor (read/write access to all compliance modules), and Contributor (read/write access to assigned modules only). Each role grants the minimum access needed for the function it supports. No role has access to capabilities it doesn't need.
The user roster with role assignments is directly accessible for assessor review. When an assessor examines AC.L2-3.1.5 (least privilege), the platform produces the evidence directly: a named list of users, their assigned roles, the access those roles grant, and the date each assignment was made. The evidence is in the system, not in a separate document that needs to be updated manually.
Provisioning Records and Access History
Every account creation, role assignment, role change, and account deactivation is recorded in the Activity Log with timestamp, acting administrator, and the change made. This creates the account management documentation that AC.L2-3.1.1 (limit system access to authorized users) and IA.L2-3.5.1 (identify system users) require. Not as a separate record kept elsewhere, but as an automatic output of the platform's operation.
The access history demonstrates that access is actively managed: accounts are deactivated when personnel depart, roles are adjusted when responsibilities change, and no accounts persist beyond their authorization period. That active management is what assessors look for when distinguishing a real access control program from a policy that describes one.
What You See Inside
- *User roster with name, role, status, and account creation date. The list assessors examine for AC.L2-3.1.1
- *Built-in roles: Administrator, Assessor, and Contributor. Each enforcing the minimum access required for that function
- *Custom role definition. Create organization-specific roles with granular module-level permissions
- *Account provisioning workflow. New accounts require administrator approval and role assignment before activation
- *Account deactivation. Immediate access removal on termination or role change, with deactivation date recorded
- *Full access history per user. Every role assignment and change with timestamp and acting administrator
- *Training module integration. Role assignments drive training course requirements automatically
- *Activity Log integration. All access changes captured in the tamper-evident audit trail
Built-In Roles and Access Levels
| Role | Access Level | Typical Assignment |
|---|---|---|
| Administrator | Full platform access including user management, system settings, and all modules | ISSO, compliance program owner, IT administrator |
| Assessor | Read/write access to all compliance modules; no user management or system settings | Compliance lead, security analyst, C3PAO pre-assessment support |
| Contributor | Read/write access to assigned modules only; no cross-module visibility beyond assignment | Domain owners, department-level contributors, IT staff assigned specific areas |
| Read-Only | View-only access to assigned modules; no creation or modification of records | Leadership review, audit support, read-only C3PAO pre-assessment access |
| Custom | Administrator-defined combination of module permissions | Organization-specific role structures not covered by standard roles |
What this replaces
- *Shared credentials for the compliance platform. Multiple people using the same login with no individual accountability
- *No access provisioning records. Accounts were created informally with no approval workflow or documentation trail
- *Former employee accounts still active in the compliance platform after departure. No deactivation record, no accountability
- *All users with administrator-level access regardless of function. No role differentiation, no least privilege enforcement
- *Access control documentation maintained in a separate spreadsheet that doesn't reflect actual platform access
Practices Satisfied
| Practice ID | Description |
|---|---|
| AC.L2-3.1.1 | Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems). |
| AC.L2-3.1.5 | Employ the principle of least privilege, including for specific security functions and privileged accounts. |
| IA.L2-3.5.1 | Identify system users, processes acting on behalf of users, and devices. |
| IA.L2-3.5.3 | Use multifactor authentication for local and network access to privileged accounts and for network access to non-privileged accounts. |
Related Modules
Every module ships on the 1TEN appliance. No configuration required. Schedule 30 minutes and see it running with your organization's data.