Starting CMMC? Write an Access Control Policy You Can Actually Follow
You have been told you need CMMC Level 2, somebody has sent you a spreadsheet full of requirements, and the folder called Policies is empty. Meanwhile, you still have a business to run.
Here is where I would start. Find out where your Controlled Unclassified Information, or CUI, lives and which systems protect it. Then make Access Control the first policy you put into practice.
Picture a small shop that hired a vendor to fix an application. The technician finished six months ago, but his account still works and nobody can explain why he still has administrator access. You stopped paying him, but apparently the login came with a lifetime membership.
That is a hypothetical example, and it is exactly the kind of question this work should answer. Who approved the access? What could that account do? When should it have stopped working, and who checked?
You can make useful progress on those questions today.
Know which systems you are protecting
Before you start filling in templates, trace how CUI reaches your business, where it is stored, who uses it, and where it goes next. Identify the systems involved and the systems providing their security. That gives you the basis for defining your CMMC assessment scope.
Start your System Security Plan, or SSP, while you do that work. It needs to describe your system boundary, operating environment, connections, and how the requirements are implemented. It can reference other documents. You can build and maintain it alongside your policies and procedures without waiting for an enormous binder to appear on your desk.
CMMC requires a defined assessment scope, and its Level 2 guidance explains what the SSP must contain. Both are part of understanding what you are protecting. 32 CFR Part 170 and the Level 2 Assessment Guide spell that out.
Why I would write Access Control first
CMMC Level 2 incorporates the 110 security requirements in NIST SP 800-171 Revision 2, across 14 families. Access Control is the largest family, with 22 requirements. It covers who and what can access systems, what they can do, how CUI moves, and controls for sessions, remote access, wireless connections, mobile devices, and external systems.
Authentication supports that work. MFA is formally in the Identification and Authentication family, so including it in your Access Control policy connects related requirements. It does not move them all into one family.
I would start here because you can connect the words to something concrete. Pull the account list. Check the permissions. Find the owner of that service account nobody wants to touch. Ask a manager whether their team still needs every system listed next to their names.
Those answers help you write a policy that somebody can actually follow.
A short policy needs something behind it
A single page can work as a governing policy. Two pages can work too. CMMC does not award extra points because your printer ran out of paper.
The policy establishes the rules and who owns them. The procedures explain how your people carry those rules out. Your system configurations, completed tickets, review records, and logs help demonstrate that the controls operate as described.
The document without the evidence is just wishing.
If the policy says access gets reviewed quarterly, somebody needs to do the review, record the decisions, remove access that is no longer appropriate, and verify the changes. A recurring calendar invitation proves you scheduled something.
Keep the documentation short enough to use and specific enough to verify. The right length depends on the environment and the detail covered in your supporting documents.
An Access Control policy you can build on
The example below is a starting point for an organization preparing for CMMC Level 2. Fill in the organization and approval details, assign real owners, and align the rules with your systems and supporting procedures before adopting it.
If an applicable requirement has not been implemented, record the gap and give someone responsibility for fixing it. Deleting the sentence will not close the gap. If a requirement genuinely does not apply, document the reason in your assessment and SSP as appropriate.
The quarterly review cadence in this example is an organizational choice. Confirm that you can carry out every commitment you adopt. Referenced standards and procedures need enough detail to run the controls; an empty document with the right filename will not do that.
Access Control Policy
Purpose
Protect company systems and Controlled Unclassified Information (CUI) by limiting access to authorized users, processes, and devices and enforcing approved permissions.
Scope
This policy applies to employees, contractors, vendors, temporary users, service accounts, devices, and services accessing company systems. The System Security Plan (SSP) identifies the CUI assessment boundary, supporting security systems, and connections to other systems.
Responsibilities
The policy owner maintains this policy and supporting procedures. Managers and system or data owners approve access based on business need. IT administrators implement controls and retain evidence. HR and managers notify IT of departures and role changes before access must change. Users protect credentials and report suspected misuse through the Incident Response process.
Requirements
Authorized access. Permit access only to approved users, processes acting on their behalf, and authorized devices or systems. Define and enforce permitted transactions, functions, and CUI flows, including approved recipients and destinations.
Accounts and privileges. Assign unique accounts to individuals; shared human logins are prohibited. Assign service accounts an accountable owner and approved purpose. Apply least privilege and separate conflicting duties. Use separate administrator accounts for privileged work and standard accounts for routine work. Prevent unauthorized privileged functions and log the execution of privileged functions.
Authentication. Require multifactor authentication for local and network access to privileged accounts and for network access to nonprivileged accounts. The Authentication Standard defines implementation requirements and how enforcement is verified.
Account lifecycle. Obtain recorded approval before granting access. Disable departing users’ accounts and revoke active access at the effective time employment or authorization ends. Remove obsolete permissions when roles change. Review accounts and permissions at least quarterly and remove inappropriate access. Disable inactive accounts after the period defined in the Access Control Procedure. Vendor and guest access requires written approval and a defined expiration.
Sessions. Limit unsuccessful login attempts, display required privacy and security notices, lock inactive sessions while concealing displayed information, and terminate sessions under defined conditions. The Access Control Procedure specifies thresholds, timing, and termination conditions.
Remote access. Authorize, monitor, and control remote sessions. Use encrypted connections through managed access points. Explicitly authorize remote execution of privileged commands and remote access to security relevant information.
Wireless and mobile access. Approve wireless connections before use and protect them with authentication and encryption. Authorize and control mobile device connections. Protect CUI on mobile devices with encryption using FIPS validated cryptographic modules in their validated configurations.
External systems and media. Verify and control connections to and use of external systems. Restrict organization controlled portable storage on external systems to uses explicitly permitted by the Media Protection Procedure.
Public information. Prohibit CUI on publicly accessible systems. Limit publishing authority, review content before release, and review published content for unauthorized CUI. Remove and report any identified exposure through the Incident Response process.
Implementation and evidence
Supporting procedures define settings, approval workflows, responsible personnel, response timing, and retained evidence. The SSP describes implementation. Maintain access approvals, account and device inventories, completed reviews, removal records, configurations, and relevant logs sufficient to demonstrate operation. Document implementation gaps and corrective actions. Policy approval alone does not establish compliance.
Enforcement
Violations may result in access removal and disciplinary action under company policy. Report suspected unauthorized access through the Incident Response process.
Supporting documents
Access Control Procedure; Authentication Standard; Media Protection Procedure; Incident Response Plan; System Security Plan. The policy owner maintains current approved versions and document references. The account lifecycle procedure covers only part of this policy.
Approval
Approved by: [Name and title]
Approval date: [Date]
Now make the account procedure usable
This procedure covers account creation, changes, removal, temporary access, and reviews. You will still need the settings and procedures for the other requirements in the policy, including session controls, remote access, wireless and mobile devices, CUI flow, and public content review.
Pay attention to the cutoff. If someone’s authorization ends at 9 a.m., a procedure that gives IT until the end of the business day leaves a hole in your own policy. Coordinate the timing and verify that access actually stopped.
Check MFA enforcement too. A screenshot showing that someone enrolled a phone does not establish that the required access paths demand MFA. Keep the configuration evidence and test what happens when the user tries to connect.
Account Lifecycle Procedure
Purpose and scope
Define how to approve, create, change, remove, and review account access. This procedure covers account lifecycle only. Separate procedures implement the remaining Access Control Policy requirements. The quarterly review cadence and ten business day response deadline below are organizational choices to confirm before adoption.
Create an account
Request and approve. The manager records the user, role, systems, required permissions, CUI need, start time, and any expiration in a ticket. The appropriate manager and system or data owner approve access before IT provisions it. IT verifies identity and current employment or contractor authorization.
Provision and verify. IT creates a unique account and assigns only approved permissions. Configure and test MFA enforcement for required network and privileged access before release. Confirm that access cannot succeed without the required factors. Record applicable settings, scope, test results, and time. Enrollment alone does not prove enforcement.
Evidence. Retain the approved ticket, account identifier, permissions export, MFA enforcement settings, test result, and completion timestamp. Do not retain passwords, recovery codes, or session tokens as evidence.
Change access
Approve before changing. The manager records the new role or elevated need, effective time, and any expiration. Obtain the required access approvals before granting new permissions.
Remove and verify. At the role change, IT removes obsolete permissions and applies approved replacements. Use a separate administrator account for privileged work. Verify MFA enforcement, permitted access, and removal of prior access. Retain approval, before and after permissions, test results, and timestamps.
Disable access
Coordinate the cutoff. HR or the manager gives IT the effective end date and time in advance. For an involuntary departure, coordinate the cutoff with the termination meeting. For an unexpected immediate departure, notify IT immediately and disable access without delay.
End access. At the effective cutoff, IT disables the user’s ordinary and privileged accounts across relevant systems, terminates active sessions, and revokes refresh tokens and other user access credentials as supported. Include VPN and application accounts outside central sign in. Remove group memberships and handle mailbox and file ownership under company rules.
Verify completion. Check that new sign ins and existing sessions can no longer reach protected resources. If access remains, escalate immediately and block the remaining path. Retain the notice, affected accounts, action timestamps, verification results, and any escalation record.
Review accounts and permissions quarterly
Review actual access. IT exports active human, privileged, service, guest, and vendor accounts with permissions and expiration dates. Managers and system or data owners confirm continuing need, current ownership, and appropriate permissions.
Resolve findings. Remove known unauthorized access immediately. Obtain recorded reapproval for remaining access within ten business days of the review request; disable or remove access that remains unapproved at that deadline. Retain the reviewed export, approvals, remediation tickets, and closure timestamps.
Manage temporary and inactive accounts
Assign each vendor or guest an owner and an approved expiration; enforce expiration or verify removal at that time. Configure inactivity disabling using the approved threshold of [number of days]. Document how inactivity is measured for service accounts and approve any justified exceptions. Define the review owner and frequency of [frequency] before adopting this procedure.
Approval
Approved by: [Name and title]
Approval date: [Date]
Keep the assessment honest as you go
As you put this into practice, maintain the SSP and map the implementation and evidence to the assessment objectives. Complete the supporting authentication, media protection, incident response, and access procedures that your policy depends on. Work through the remaining requirements and track what still needs to be fixed.
The Supplier Performance Risk System, or SPRS, records assessment results. An assessment can identify unmet requirements. Report the actual result when required by your contract and the applicable process; do not wait for every gap to disappear before meeting a submission obligation. A submitted score by itself does not establish eligibility for every contract.
For CMMC, the rules distinguish final status from conditional status and limit which gaps can remain on an assessment plan of action. An unfinished control still needs to be assessed honestly. A policy promising to implement it is not evidence that it already works.
If your policies folder is empty today, begin with the systems and accounts in front of you. Establish who should have access, get the decisions approved, enforce them, and keep the records. Then check the result.
And if that old vendor account still works, shut it down. Six months was a generous enough going away present.
References: 32 CFR Part 170, including sections 170.14, 170.19, 170.21, and 170.24, and the CMMC Level 2 Assessment Guide, version 2.13. The examples require adaptation and implementation in your environment; downloading or approving them does not establish compliance.