03 – Role‑Based Access Control (RBAC) & Least Privilege Policy

Prepared by: [Name ----------------]
Organization: [company name]

---

1. Purpose

This policy establishes a structured framework for assigning and managing access rights across organizational systems. It ensures that users, devices, and processes receive only the minimum privileges required to perform their duties. The policy enforces compliance with CMMC AC. L2‑3.1.5, AC. L2‑3.1.6, and AC. L2‑3.1.7, while supporting secure, efficient, and compliant operations in cloud, on‑premises, and hybrid environments.

2. Scope

This policy applies to:

• All organizational systems, applications, and data repositories.
• All users, including employees, contractors, and approved third‑party partners.
• Privileged and non‑privileged accounts managed through IAM platforms (e.g., Entra ID, Google IAM, AWS IAM, on‑prem AD).

3. Roles & Responsibilities

• Policy Owner: Oversees RBAC framework, ensures audit readiness, and reports compliance status to leadership.
• IT Security Team: Configure RBAC in IAM platforms, enforce least privilege, and monitor role assignments.
• System Owners: Validate role definitions for their systems and approve exceptions.
• Managers: Approve role assignments based on job function and business justification.
• Users: Operate only within assigned roles and report access issues promptly.

4. Policy Statements

• Access must be granted based on predefined roles aligned with job responsibilities.
• Privileged roles must be limited to essential personnel and require just‑in‑time activation.
• Non‑privileged accounts must be used for daily operations; admin accounts only for approved tasks.
• Role assignments must be documented in a Role Matrix maintained in the compliance repository.
• Access requests must follow an approval workflow with manager and IT security sign‑off.
• Role assignments must be reviewed quarterly to detect over‑privileged accounts.

5. Role Definitions

• Standard Roles: User, Contractor, Guest.
• Privileged Roles: Administrator, Security Admin, Compliance Admin, System Owner.
• Service Roles: Application Service Accounts, Automation Accounts.

6. Enforcement

• IAM Platforms (e.g., Entra ID, Google IAM, AWS IAM, AD): Assign and restrict access based on RBAC.
• Cloud RBAC (Azure, AWS, GCP): Enforce least privilege at subscription, project, resource group, and resource levels.
• Privileged Identity Management (PIM or equivalent): Require just‑in‑time activation for privileged roles.
• Conditional Access / IAM Policies: Restrict access based on device compliance, MFA, and location.

7. Monitoring

• Quarterly access reviews of all roles conducted by compliance and IT security teams.
• Automated detection of shared, unused, or over‑privileged accounts.
• Alerts for excessive privilege assignments reviewed and documented in the compliance repository.

8. References

• CMMC AC. L2‑3.1.5, AC. L2‑3.1.6, AC. L2‑3.1.7
• NIST SP 800‑171 Rev. 2
• DFARS 252.204‑7012
• Vendor technical reference guides (Microsoft, Google, AWS, etc.)

9. SSP, SOP, and Evidence Mapping

• SSP Mapping: Directly maps to CMMC AC. L2‑3.1.5, AC. L2‑3.1.6, and AC. L2‑3.1.7 under RBAC & Least Privilege Controls.
• SOP Mapping: Supporting SOPs include Role Assignment SOP, Privileged Role SOP, and Access Review SOP.
• Evidence Required:
  • Role Matrix (documented roles and privileges).
  • Access review logs signed by Managers and IT Security.
  • Privileged activation logs showing elevated role usage.
  • Conditional Access / IAM policy reports exported quarterly.
  • Remediation records for over‑privileged accounts stored in compliance repository.

End of Policy – AC 03
Date Created: [  /  /  ]

---

https://www.blogger.com/u/1/blog/post/edit/4293395378927152575/3934508185592740862