This is one of the two hardest remaining AC practices. The challenge isn’t the concept. Administrators need remote access, they need to execute privileged commands, and you need logs. The challenge is the audit trail. Most contractors have logs somewhere, but they’re scattered. VPN logs show who connected. Windows Event Viewer shows what commands ran, but nobody’s looking at it. RDP gateway logs show the session, but not the detailed commands. The assessor wants to see one coherent picture: admin logged in, executed specific commands, here’s the proof in the logs, and someone reviewed it to confirm it was authorized. This practice depends on AC.L2-3.1.12 (remote access control) and AU.L2-3.3.2 (privileged command logging).
Small contractors often struggle here because privileged access is informal. The owner’s laptop is admin, they VPN in and make changes. Where’s the approval? Where’s the audit? If you can’t articulate this during the assessment, expect a finding.
What the assessor is actually evaluating
The assessor wants to trace a single privileged action from authorization through execution to logging. They’re checking four things. First, was the administrator authorized to execute privileged commands? This comes from AC.L2-3.1.5 (least privilege), where admin roles are defined and approved. Second, is there a formal approval process for specific privileged actions, or standing authorization documented somewhere? Third, are the actual commands that were executed logged in detail? Fourth, are those logs reviewed to ensure only authorized actions happened?
Most contractors fail because they conflate “the admin has remote access” with “the admin is authorized to run arbitrary commands.” Those aren’t the same thing. Remote access authorization and privileged command authorization are related but distinct controls.
What a realistic SSP definition looks like
[Organization Name] authorizes all remote execution of privileged commands. System administrators are granted remote access via VPN and multi-factor authentication. Privileged commands are defined as any command requiring administrator rights on Windows or sudo on Linux systems, including system configuration changes, security policy modifications, and user account administration.
System administrators are pre-authorized to execute privileged commands relevant to their role. All remote administrative sessions are logged, including the systems accessed, commands executed, and outcomes. Session logs are maintained in [logging system] and reviewed weekly by the CIO. Any unusual or unexpected administrative activity is investigated and documented.
If a system administrator needs to execute a privileged command outside the scope of their normal role, they must submit a change request ticket, receive approval from the IT Director, and document the action taken. Logs from this out-of-scope execution are reviewed by the IT Director within 24 hours and retained as evidence of the approved action.
This SSP language is doing several things right. First, it defines “privileged commands” so there’s no ambiguity. Second, it divides into two scenarios: normal admin commands (pre-authorized) and out-of-scope commands (per-request approval). Third, it names the logging system and review frequency. Fourth, it covers both authorized and potentially unauthorized commands, describing how investigation and documentation work.
The weekly review frequency is important. The assessor wants to know someone’s actively examining the logs and identifying anomalies, not passively confirming their existence.
How to present your evidence
- Administrator role definition showing which privileges are granted and why
- Approval documentation for out-of-scope privileged actions (change request tickets)
- Remote session logs showing which admin accessed which system and when
- Detailed command audit logs from Windows Event Viewer, sudo logs, or PAM system
- Evidence of weekly log review (summary report or review log with sign-off)
- Documentation of any investigation into unusual administrative activity
- If applicable, screenshots of a PAM system showing command logging and approval workflow
This is a lot of evidence because privileged access logging is complex. Have these ready:
Administrator role documentation. From AC.L2-3.1.5, you should have admin role definitions. Pull up the document showing which administrator has which privileges and why. This is your authorization baseline.
Remote session logs. From AC.L2-3.1.12, you have logs of who accessed the VPN or RDP gateway. Pull up a few entries showing an administrator connecting. This proves who initiated the remote session.
Command audit logs. This is the most critical piece. Windows administrators should pull up Windows Event Viewer showing privilege escalation events or specific admin command execution. Linux administrators should show sudoers logs. If you’re using a Privileged Access Management (PAM) system, pull up its command logs. The logs should show:
- Who executed the command (username)
- When (timestamp)
- What they executed (command text)
- What system (which server)
- Outcome (success or failure)
Review evidence. Pull up a recent weekly log review record. Could be a spreadsheet with a sign-off date. Could be a summary email from the CIO listing which admins did what. Could be a SIEM dashboard showing a weekly audit report with the review date. The point is showing that someone deliberate reviewed the logs and documented it.
Change request for out-of-scope actions. If you have examples of an admin needing to execute a command outside their normal scope, show the change request ticket. Show the approval by the IT Director. Show the command logs from that action. Show the IT Director’s review and sign-off on what actually happened.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Common failures
No evidence of log review. Logs exist but nobody's looking at them. The assessor will ask "when did you last review the admin logs?" and silence or "uh, the MSSP might be looking at them" is damning. You need dated proof that someone reviewed them.
Shared admin accounts. "Our IT guy uses a shared admin account called 'admin.'" The assessor will push hard here. Shared accounts prevent you from knowing who executed a command. Unacceptable. Every admin must have their own account, even if it has the same privileges.
Vague privilege definitions. "We have admin and regular user." What exactly can an admin do? What systems? What commands? Vagueness creates doubt about whether remote execution is actually controlled. Define privileges specifically.
No approval process for out-of-scope actions. If an admin needs to do something unusual, how is it approved? SSP doesn't mention it, no evidence of approval tickets, no change control process. The assessor will ask "how do you know an admin isn't running commands beyond their role?" and you won't have an answer.
Command logs don't show detail. You have logs, but they only say "admin logged in." They don't show which commands were executed, on which systems, or what the outcomes were. Insufficient. Logs need to be detailed enough to answer "what did this admin actually do?"
Admin has local laptop with admin rights that connects via VPN with no gateway or control.** Remote admin access that bypasses the logging infrastructure. If an admin's laptop is fully admin and VPNs directly to your network, you have no centralized log of what they do. Use an RDP gateway, PAM system, or jump host so commands flow through something you can monitor.
Clear admin role definitions. Detailed command audit logs from Windows Event Viewer, sudoers, or a PAM system. Weekly or more frequent log review with documented evidence. A defined approval process for out-of-scope privileged actions. Individual admin accounts (not shared). If you can walk the assessor through a recent privileged command execution from start (admin identity) to finish (command logged and reviewed), this practice closes. Effort upfront in getting this right pays dividends in the assessment room.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
If you use an MSP/MSSP
This is the practice where contractor and MSSP responsibilities often get blurry. Your MSSP is typically executing privileged commands on your behalf. Your job is oversight and approval.
What’s on you (the contractor):
- Defining what privileged commands are allowed and under what conditions
- Approving out-of-scope or unusual administrative actions
- Reviewing logs of privileged execution (at least weekly)
- Deciding when an action warrants investigation
What’s on the MSSP:
- Maintaining the infrastructure that logs command execution (RDP gateway, PAM system, SIEM)
- Executing approved administrative actions
- Providing detailed logs in a format you can review
- Documenting their own admin actions so they can be logged and reviewed alongside contractor actions
- Implementing controls that prevent direct server access in favor of gateway-mediated access
The assessor will expect to see an MSSP admin’s logs too. If the MSSP is the only entity executing privileged commands and they never show those logs, that’s suspicious. The best MSSPs keep their own admin accounts separate from the contractor’s and log everything the same way.
This is one of the hardest practices because it requires multiple pieces to align: authorization, logging, and review. Assessors will ask you to walk them through a specific privileged command execution. Can you identify who ran it, when, what they changed, and evidence that it was authorized? If your answer is "I'd have to check multiple systems," you're losing points. Have all the logs aggregated in one place where you can show the complete story. If your MSSP executes commands, you need their logs too.
This is where the separation between "your responsibility" and "their execution" gets concrete. Before the assessment, have a conversation with your MSSP: "I need to review logs of your privileged access. What's your logging process? How do I get those logs weekly?" The best MSSPs will say "we log everything into [tool], here's your access, here's a weekly summary we provide." If your MSSP says "we handle it internally, don't worry about it," that's a problem. You need visibility into their administrative actions on your systems. The assessor will ask about it, and "we don't log MSSP actions" is a finding.
This page covers AC.L2-3.1.15 from NIST SP 800-171 Rev 2 (3.1.15). The guidance here is based on experience in real CMMC assessments and is intended to help you prepare. It is not legal or compliance advice. Your organization’s situation is unique, and you should work with qualified professionals for formal assessment preparation.