Requirement
FAR 52.204-21 / CMMC 2.0 Level 1 - Control - AC.L1-B.1.II – Limit information system access to the types of transactions and functions that authorized users are permitted to execute.
Understanding the Requirement
This control requires that users can only perform the specific transactions and functions needed for their job — nothing more. Practically, that means defining what each job role must be able to do (objectives: define allowed transactions/functions and enforce them) and configuring systems so those role-based permissions are the only access granted. For an SMB this covers access to SharePoint sites, network file shares, servers, applications, and administrative privileges: users should be assigned to groups/roles that map to clearly documented duties and those groups should be the only mechanism granting access. This is consistent with the FAR 52.204-21 / CMMC 2.0 Level 1 expectation of least-privilege access for mission-related tasks.
Technical Implementation
- Inventory roles and map transactions. Create a simple role-to-function matrix: list every job role (e.g., HR clerk, developer, helpdesk) and jot the transactions/functions each role requires (view HR folder, edit payroll spreadsheet, deploy to dev server). Keep the matrix concise and stored where managers can review it.
- Use groups and RBAC, not individual ACLs. Implement role-based access control using your identity provider (Azure AD, Active Directory, Google Workspace, or your IAM). Create security groups that correspond to roles and assign permissions to those groups on file shares, SharePoint sites, servers, and apps. Add and remove users from groups rather than changing individual permissions.
- Limit administrative privileges. Maintain a small, documented list of admin accounts. Use separate accounts for daily work and administration, and apply just-in-time (JIT) or time-limited elevation where possible for higher privileges. Disable local admin rights for standard users and restrict server/DB admin rights to designated IT staff.
- Automate provisioning and deprovisioning. Implement a simple onboarding/offboarding workflow that ties HR hires and terminations to your identity system: new hires are added to role groups, and access is revoked automatically when employees leave. If full automation isn’t feasible, enforce a checklist and ticketed approval for access changes.
- Enforce application-level transaction controls. For critical applications, configure in-app roles/permissions so users can only perform allowed transactions (e.g., finance staff can create invoices but not change vendor bank data). Where apps lack granular controls, restrict access to the app entirely and provide a controlled service account or a lightweight workaround with supervisory review.
- Periodic reviews and logging. Schedule quarterly access reviews where managers verify their team’s group memberships and transaction permissions. Enable audit logging (access events, permission changes) and review unusual permission grants or elevated sessions monthly. Keep logs for an appropriate retention period for accountability and incident investigation.
Example in a Small or Medium Business
Acme Consulting has 45 employees and uses Azure AD for identity and SharePoint for document storage. The IT lead, Maria, creates three primary security groups: HR-Team, Engineers, and Finance. She maps out allowed transactions for each group—HR can access the HR SharePoint site and edit personnel spreadsheets, Engineers can access dev servers and the engineering document library, and Finance can generate invoices in the accounting system but cannot modify payroll bank details. New hires are added to these groups during onboarding; when someone changes roles, their manager requests group changes through a simple ticket so permissions are updated consistently. Administrative accounts are limited to two IT staff and use a separate admin-only login; the team uses time-limited elevation for server maintenance. Every quarter Maria sends a spreadsheet to managers to confirm group memberships; any discrepancy is corrected and logged in the ticketing system. As a result, employees only execute transactions their role requires, and Acme can demonstrate defined roles, group-based enforcement, and periodic reviews for audits.
Summary
By defining role-based transactions and functions, enforcing those definitions through groups and RBAC, restricting administrative privileges, and instituting provisioning/deprovisioning plus periodic reviews and logging, an SMB can meet AC.L1-B.1.II. The combination of simple policy (role-to-function mapping), practical technical controls (groups, RBAC, JIT admin), and regular manager-driven reviews produces a repeatable, auditable process that limits users to only the transactions and functions they are authorized to execute.