When I started preparing for a CMMC assessment, I expected to spend most of my time focused on policies, procedures, and the System Security Plan. Those things are certainly important, but what surprised me was how much of the assessment ultimately came down to evidence.
Not whether a control existed on paper, but whether we could demonstrate it clearly, consistently, and without spending fifteen minutes digging through shared drives looking for screenshots, reports, or configuration exports.
One thing I noticed while preparing was that there is plenty of guidance available on the controls themselves. You can find countless articles explaining NIST 800-171 requirements, writing policies, developing SSPs, and performing readiness reviews. What I found much harder to locate was practical guidance around evidence collection. What should be gathered? How should it be organized? What kinds of artifacts are assessors typically looking for when they start asking questions?
Following our successful CMMC Level 2 assessment, I spent some time sanitizing the evidence collection framework we used throughout preparation. The original version contains screenshots, exports, inventories, tickets, reports, and supporting documentation that obviously cannot be shared publicly. What can be shared, however, is the process behind it.
If I were helping another organization prepare for an assessment tomorrow, this is the approach I would start with.
The Biggest Mistake Organizations Make
Most organizations assume the hard part of an assessment is implementing the controls. That certainly matters, but it’s only part of the challenge.
The real difficulty often comes from proving those controls exist, proving they’re operating, and proving they have been operating consistently over time.
I’ve seen environments with strong security controls struggle because evidence was scattered across shared drives, ticketing systems, email archives, spreadsheets, and security platforms. The organization wasn’t missing the control. They were missing the ability to quickly demonstrate it. Assessors are trying to understand how your environment works. The easier you make that process, the smoother the assessment tends to go.
The Four Layers of Evidence
One thing that became apparent fairly early in our preparation was that the controls themselves were often less complicated than the evidence supporting them.
At first, every control felt unique. Access Control looked different from Incident Response. Audit logging looked different from Security Awareness Training. The systems, screenshots, reports, and documentation were all coming from different places.
As we worked through the assessment requirements, however, a pattern started to emerge.
Nearly every control could be traced back to the same handful of evidence types. There was usually a policy or procedure explaining the requirement, a technical control enforcing it, and some form of operational evidence demonstrating that the control was actually functioning. The specifics changed depending on the control, but the overall structure remained remarkably consistent.
For example, if a policy required multifactor authentication, we needed documentation describing that requirement, configuration evidence showing where MFA was enforced, and operational evidence proving users were actually authenticating through the system. The same thought process applied to encryption, logging, vulnerability management, training, and dozens of other requirements throughout the assessment.
Once we recognized that pattern, evidence collection became significantly easier. Instead of treating every control as a completely separate exercise, we started approaching them through a common framework. Every control had a designated owner, supporting evidence, and a documented location where that evidence could be retrieved during the assessment.
That may sound like a small organizational detail, but it ended up saving an enormous amount of time once the assessment was underway.
Building Your Evidence Library
One recommendation I would make to any organization preparing for a CMMC assessment is to start building an evidence library long before the assessment is scheduled.
The obvious benefit is having documentation readily available when requests start coming in. The less obvious benefit is that it forces you to think about how evidence is stored, organized, and maintained over time. During an assessment, some requests can be answered in a matter of minutes. Others may require pulling together policy references, screenshots, reports, exports, tickets, and supporting documentation from several different systems.
The difference between those two experiences is rarely the complexity of the control itself. More often, it’s how well the evidence has been organized beforehand.
One thing that surprised me during preparation was how frequently the same evidence appeared across multiple domains. Identity systems, device management platforms, vulnerability management processes, training records, onboarding workflows, and SSP narratives often supported far more controls than we initially expected. Once we started mapping those relationships, the assessment became much easier to navigate.
Instead of collecting evidence one control at a time, we were building a library of artifacts that could be reused throughout the assessment. That shift in perspective saved a significant amount of effort and helped eliminate a lot of last-minute scrambling.
Access Control Domain
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| AC Domain | AC.L1-3.1.1 - Authorized Access Control | Limit access to authorized users, roles, and devices. | Access control / conditional access policy. Current user and permission inventory. Employee role and management roster. Provisioning and deprovisioning records. Role assignment matrix. Periodic access review evidence. |
Policy / SSP: SSP section describing identity, role-based access, and access approval workflow. Microsoft: Entra Conditional Access policy, Entra user export, Access Reviews, Intune compliance gating. Google: Context-Aware Access, Google Admin user/org-role export, BeyondCorp Enterprise policies. AWS: IAM Identity Center permission sets, IAM policy attachments, account assignment export. Okta / JumpCloud: group membership export, app assignment screenshots, lifecycle workflows. What to screenshot/export: policy name, grant controls, assigned groups, roster, user-role mapping, onboarding/offboarding ticket trail. |
| AC Domain | AC.L1-3.1.2 - Transaction & Function Control | Restrict what users are allowed to do within systems based on role or job function. | Acceptable use / authorized use policy. Role-to-function mapping. Evidence that privileged functions are restricted to authorized roles. |
Policy / SSP: acceptable use policy or SSP section defining approved actions by user type. Microsoft / Google / SaaS apps: admin role screens showing only admins can manage settings. AWS: IAM policies restricting management actions. What to screenshot/export: admin-only menu, role definitions, approval matrix, function restrictions for sensitive actions. |
| AC Domain | AC.L1-3.1.22 - Control Public Information | Prevent unauthorized public release of organizational information. | Public release / communications approval policy. Evidence of review and approval before publication. Examples of labeling or approval workflow for public content. |
Policy / SSP: communications / public information handling policy. M365 / Google Workspace: document approval workflow or sensitivity labels. Atlassian / CMS / marketing tools: approval states before publish. What to screenshot/export: approval workflow, publishing permissions, document classification guidance. |
| AC Domain | AC.L2-3.1.10 - Session Lock | Automatically lock sessions after inactivity. | Endpoint lock screen timeout policy. Identity / SSO session timeout evidence. Workstation enforcement screenshot or config export. |
Policy / SSP: workstation session lock standard. Intune / JAMF / Kandji / Fleet: passcode or screen lock timeout policy. Google / Microsoft identity: session settings showing inactivity timeout. What to screenshot/export: device compliance profile, local security setting, SSO session lifetime. |
| AC Domain | AC.L2-3.1.11 - Session Termination | Automatically terminate sessions after defined conditions or time. | Identity platform session termination policy. Evidence that sessions expire or re-authentication is required. |
Policy / SSP: session termination requirement in SSP or access control standard. Microsoft: sign-in frequency / persistent browser session settings. Google: session control settings. Okta: global session policy. What to screenshot/export: session lifetime, re-authentication requirement, termination behavior for idle sessions. |
| AC Domain | AC.L2-3.1.12 - Control Remote Access | Permit only approved remote access methods and disable unapproved ones. | Remote access policy. Evidence that unauthorized remote assistance tools are disabled. VPN enablement / disablement evidence. Remote access approval standards. |
Policy / SSP: remote access section naming approved methods only. JAMF / Intune / Kandji / Fleet: settings showing screen sharing / remote assist disabled unless approved. Meraki / Palo Alto / Cisco / Fortinet / Tailscale / Zscaler: VPN settings and approved gateway screenshots. What to screenshot/export: disabled remote assist feature, VPN settings, approved remote access architecture. |
| AC Domain | AC.L2-3.1.13 - Remote Access Confidentiality | Protect confidentiality of remote sessions. | Encrypted remote access policy. TLS / VPN encryption configuration. Evidence that remote sessions use secure channels only. |
Policy / SSP: remote access encryption requirement. VPN: IPsec / SSL VPN configuration in Meraki, Palo Alto, FortiGate, Zscaler, AWS Client VPN. Identity / access brokers: enforced secure app access via Cloudflare, Zscaler, Netskope. What to screenshot/export: encryption setting, secure tunnel requirement, disallowed plaintext protocols. |
| AC Domain | AC.L2-3.1.14 - Remote Access Routing | Route remote access traffic through approved, secured paths. | Policy describing routed remote access traffic. VPN configuration or network routing controls. Evidence that unsafe alternate routing is disabled or restricted. |
Policy / SSP: remote access architecture in SSP. Meraki / Palo Alto / AWS / Azure: route tables or VPN concentrator settings. ZTNA / SASE: Cloudflare / Zscaler / Netskope routing posture. What to screenshot/export: VPN routes, split/full tunnel choice, security cloud routing diagram. |
| AC Domain | AC.L2-3.1.15 - Privileged Remote Access | Apply tighter controls to administrative remote access. | Policy requiring stronger controls for admin remote access. MFA requirement for privileged remote sessions. Evidence that remote administration is restricted to approved admins. |
Policy / SSP: privileged remote access requirements. Microsoft: Conditional Access requiring MFA for admin roles. Okta / Duo: step-up MFA for admin apps. Network / VPN: admin-only remote access group assignment. What to screenshot/export: privileged group membership, MFA enforcement, remote admin gateway restriction. |
| AC Domain | AC.L2-3.1.16 - Wireless Access Authorization | Permit only approved wireless devices and wireless access methods. | Wireless access policy. Authorized device inventory / MAC or certificate-based authorization evidence. Wireless group policies / NAC rules. Wireless encryption configuration. |
Policy / SSP: wireless authorization standard. Meraki / Unifi / Aruba / Cisco: SSID access controls, group policy assignment, MAC auth / 802.1X config. Apple Business Manager / Intune / JAMF: managed device inventory proving enrolled devices. What to screenshot/export: SSID auth mode, allowed device policy, network access policy, managed device list. |
| AC Domain | AC.L2-3.1.17 - Wireless Access Protection | Protect wireless access using strong security settings and restricted exposure. | Wireless encryption policy. Evidence insecure SSIDs are disabled or hidden. WPA2/WPA3 or enterprise auth configuration. Managed wireless profile enforcement. |
Policy / SSP: wireless security section requiring secure encryption and managed access. Meraki / Unifi / Aruba / Cisco: WPA3/802.1X settings, hidden SSID or disabled guest SSID. MDM: device Wi-Fi profile enforcement. What to screenshot/export: SSID list, auth type, encryption standard, disabled insecure network. |
| AC Domain | AC.L2-3.1.18 - Mobile Device Connection | Control how mobile devices connect to organizational resources. | Mobile / BYOD policy. Conditional access for mobile devices. Mobile device management configuration. Evidence unmanaged devices are restricted. |
Policy / SSP: mobile device connection rules. Intune / JAMF / Kandji / Workspace ONE / Google Endpoint Management: compliance requirement before access. Microsoft / Google / Box / Google Workspace: app or resource policy requiring managed mobile device. What to screenshot/export: device compliance policy, mobile access rule, app access restriction. |
| AC Domain | AC.L2-3.1.19 - Encrypt CUI on Mobile | Ensure sensitive data on mobile devices is encrypted and protected. | Mobile encryption policy. Mobile passcode enforcement policy. SSP section describing encryption at rest on mobile devices. Evidence that managed devices require encryption and screen lock. |
Policy / SSP: SSP or mobile security standard requiring encryption and passcode. Intune: device restriction policy enforcing encryption and PIN. JAMF / Kandji / Apple MDM: FileVault / device passcode / managed app protection screenshots. Google Workspace / Android Enterprise: work profile and encryption controls. What to screenshot/export: encryption required, passcode required, noncompliant device action. |
| AC Domain | AC.L2-3.1.20 - External Connections | Restrict and monitor external connections to unauthorized destinations or services. | Boundary firewall rules. Content filtering / domain blocking policy. Custom block rules for unauthorized destinations. Security alert showing blocked or attempted external connection. Evidence of monitoring for unauthorized external access. |
Policy / SSP: SSP section identifying approved external services and blocked categories. Meraki / Unifi / Palo Alto / Fortinet / AWS security controls: deny rules, egress restrictions, URL filtering. JAMF Protect / Defender / CrowdStrike / Netskope / Zscaler / Cloudflare Gateway: content filtering or web control policy. SIEM / MDR: Sentinel, Splunk, Arctic Wolf, Rapid7, Elastic alerts for unauthorized access attempts. What to screenshot/export: firewall deny rule, DNS block category, blocked domain event, alert email/ticket, custom block policy. |
| AC Domain | AC.L2-3.1.21 - Portable Storage Use | Restrict removable media and control portable storage usage. | Removable media policy. USB device blocking policy. Default deny configuration for removable storage. Event or log showing blocked portable storage attempt. |
Policy / SSP: removable media section requiring approval or default deny. Intune / Defender / JAMF / CrowdStrike / Fleet / Kandji: device control policy disabling USB mass storage. Windows: Defender Device Control or GPO removable storage access settings. macOS: endpoint control / MDM restriction / EDR detection. What to screenshot/export: device control policy, allow-list exception workflow, blocked USB event, endpoint device log. |
| AC Domain | AC.L2-3.1.3 - Control CUI Flow | Prevent unauthorized movement of CUI and sensitive data. | DLP policy for regulated / sensitive data. Data flow diagram identifying where CUI moves. Restrictions on sharing / download / external transmission. Monitoring evidence for sensitive data movement. |
Policy / SSP: SSP section describing where CUI resides, flows, and is restricted. Microsoft Purview / Google DLP / Box Shield / Netskope / Zscaler / Druva: DLP policy and content inspection screenshots. Architecture: network / data flow diagram. What to screenshot/export: DLP rule scope, action on violation, blocked share/download, sensitive data category mapping, data flow diagram. |
| AC Domain | AC.L2-3.1.4 - Separation of Duties | Separate responsibilities so one person cannot perform conflicting sensitive actions unchecked. | Separation of duties policy. User role inventory. Role assignment matrix showing distinct duties. Management / role roster proving segregation. |
Policy / SSP: role separation statement in SSP or access control policy. IAM / SaaS: role matrix export from Entra, Okta, AWS, Google Workspace, ERP, ticketing system. What to screenshot/export: admin groups vs standard groups, approval roles vs implementer roles, responsibility matrix. |
| AC Domain | AC.L2-3.1.5 - Least Privilege | Grant only the minimum access needed for each role. | Least privilege policy. User permission inventory. Role-based access model. Review evidence showing privilege minimization. |
Policy / SSP: least privilege statement. IAM platforms: Entra role assignments, AWS IAM least-privilege policy, Google Admin roles, Okta groups. What to screenshot/export: minimal role assignment, no standing admin for general users, access review results. |
| AC Domain | AC.L2-3.1.6 - Non-Privileged Account Use | Require standard accounts for normal activity and prevent routine use of admin accounts. | Policy requiring separate admin and standard accounts. LAPS / local admin management evidence. Audit logs of privileged actions. Evidence default users are not local administrators. |
Policy / SSP: separate privileged/non-privileged account requirement. Windows: LAPS policy, local administrators group membership. macOS / MDM: no local admin for standard users, admin account issuance workflow. Microsoft / Linux / macOS: admin audit logs, sudo logs, privileged action logs. What to screenshot/export: local admin group membership, privileged account assignment, admin audit event, LAPS configuration. |
| AC Domain | AC.L2-3.1.7 - Privileged Functions | Limit who can perform privileged functions and record those actions. | Privileged function policy. Privileged account inventory. Audit logs for admin actions. Evidence that privileged tools are limited to authorized users. |
Policy / SSP: privileged functions section. Entra / AWS / Okta / Linux: admin activity logs, PIM/PAM controls, sudo log examples. What to screenshot/export: privileged action record, just-in-time admin approval, admin role membership, PAM workflow. |
| AC Domain | AC.L2-3.1.8 - Unsuccessful Logon Attempts | Detect and respond to repeated failed logins. | Account lockout / failed sign-in policy. Endpoint or identity enforcement evidence. Failed login monitoring or alerting evidence. |
Policy / SSP: lockout threshold and failure handling standard. Microsoft: sign-in risk / smart lockout / authentication method policy. Google / Okta / Duo: failed sign-in protections or brute force protection settings. Endpoint tools: local security policy or MDM enforcement. What to screenshot/export: lockout threshold, failed login event, account protection settings. |
| AC Domain | AC.L2-3.1.9 - Privacy & Security Notices | Display security and privacy warnings before system use. | Login banner policy. Banner configuration for workstations and applications. Evidence of warning text displayed to users. |
Policy / SSP: user notice / consent banner language. Windows / macOS / Linux: login banner settings. SaaS / SSO: sign-in portal or app banner where applicable. What to screenshot/export: banner text in policy and the live sign-in / lock screen banner. |
Audit & Accountability Domain
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| AT Domain | AT.L2-3.2.1 - Role-Based Risk Awareness | Train personnel on risks relevant to their roles. | Security awareness training content. Role-based or elevated-access training materials. Employee checklist showing required training. Acknowledgment records for higher-risk roles. |
Policy / SSP: training requirement in SSP or training policy. KnowBe4 / Proofpoint / LMS / Google Classroom / internal LMS: assigned role-based training module screenshots. HRIS / LMS: completion reports and acknowledgement records. What to screenshot/export: training catalog, assigned audience, completion report, signed acknowledgment. |
| AT Domain | AT.L2-3.2.2 - Role-Based Training | Provide job-specific security training for users with special responsibilities. | Elevated access training materials. Role-based training completion records. Acknowledgments for privileged users. |
Policy / SSP: privileged user training requirement. LMS: admin-specific training assignment and completions. What to screenshot/export: admin training module, completion evidence, acknowledgment for users with elevated rights. |
| AT Domain | AT.L2-3.2.3 - Insider Threat Awareness | Train personnel to recognize and report insider threat indicators. | Insider threat awareness training materials. Regulatory or policy basis for the training. Completion records or sign-off evidence. |
Policy / SSP: awareness training requirement referencing insider threat. LMS / KnowBe4 / internal slides: insider threat module, training deck, attendance log, signed completion. What to screenshot/export: module title, completion metrics, signed roster, annual training schedule. |
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| AU Domain | AU.L2-3.3.1 - System Auditing | Generate and retain logs needed for auditing and investigations. | Logging retention policy. Overview of collected log sources. Evidence centralized logging is enabled. |
Policy / SSP: logging and retention section of SSP. SIEM / MDR / XDR: Splunk, Sentinel, Elastic, Arctic Wolf, Rapid7 dashboard showing ingested sources and retention. What to screenshot/export: retention setting, log source inventory, collection overview. |
| AU Domain | AU.L2-3.3.2 - User Accountability | Tie user actions to specific identities. | User activity logs. Access event records. Exportable audit trail showing actor, timestamp, and action. |
Policy / SSP: auditing requirement for user-attributable actions. M365 / Google Workspace / Box / AWS / Okta: audit log export with actor identity. What to screenshot/export: audit event fields, user identity attached to action, exported log sample. |
| AU Domain | AU.L2-3.3.3 - Event Review | Review audit events and alerts to identify security issues. | Event review procedure. Sample reviewed alert or detection record. Evidence that alerts are triaged and acted on. |
Policy / SSP: daily/weekly review procedure in SSP or SOC process. SIEM / MDR / ticketing: reviewed alert email, case record, analyst notes, triage disposition. What to screenshot/export: reviewed alert, assigned owner, disposition, follow-up action. |
| AU Domain | AU.L2-3.3.4 - Audit Failure Alerting | Alert when logging or audit mechanisms fail. | Audit failure alerting configuration. Sample ticket or alert indicating logging failure or issue. |
Policy / SSP: logging failure response requirement. SIEM / EDR / MDR: health alert for failed sensor, disconnected agent, log ingestion failure. What to screenshot/export: failed collection alert, support ticket, health dashboard alarm. |
| AU Domain | AU.L2-3.3.5 - Audit Correlation | Correlate logs from multiple sources to improve detection and investigation. | Integrated logging sources list. Agents / sensors inventory. Data collection architecture for audit correlation. |
Policy / SSP: centralized monitoring design in SSP. SIEM / MDR: sensor inventory, cloud connectors, agent lists, API source integrations. What to screenshot/export: connector list, endpoint agent inventory, correlation rule source list, data collection diagram. |
| AU Domain | AU.L2-3.3.6 - Reduction & Reporting | Summarize and report audit information in a usable form. | Reporting dashboards. Sample summarized incident or log report. Evidence scheduled or recurring reporting exists. |
Policy / SSP: reporting requirement for security monitoring. SIEM / MDR / SOC reporting: weekly dashboard, alert digest, case summary report. What to screenshot/export: summary dashboard, weekly report, incident summary email. |
| AU Domain | AU.L2-3.3.7 - Authoritative Time Source | Synchronize systems to a trusted time source. | NTP policy or standard. NTP configuration on systems. Timezone enforcement evidence. Proof systems sync to authoritative source. |
Policy / SSP: time synchronization requirement. Windows / Linux / macOS / MDM: NTP server setting, time zone enforcement profile. Cloud / identity: domain controller or directory time sync settings. What to screenshot/export: configured NTP server, sync status, managed profile enforcing time settings. |
| AU Domain | AU.L2-3.3.8 - Audit Protection | Protect logs from unauthorized modification or deletion. | File permission / access control evidence for audit logs. Restricted ownership of log files or audit controls. Contact / escalation list for log management. |
Policy / SSP: audit log protection standard. Linux / macOS: file owner/group/mode for audit control files. SIEM / log platform: role-based access to logs, immutable storage where used. What to screenshot/export: log file permissions, admin-only access to audit config, log access roles. |
| AU Domain | AU.L2-3.3.9 - Audit Management | Limit who can configure or manage audit capabilities. | Audit configuration policy. Privileged users list for SIEM / logging platform. Evidence audit settings are admin-restricted. |
Policy / SSP: approved audit administrators in SSP. SIEM / M365 / Google / AWS: admin role membership, privileged audit-manager assignments. What to screenshot/export: security role list, admin-only audit settings page, privileged user export. |
Configuration Management Domain
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| CM Domain | CM.L2-3.4.1 - System Baselining | Define and maintain approved baseline configurations and inventories. | Baseline configuration standard or SOP. Configuration management log. Hardware inventory. Software inventory. Workstation baseline document. |
Policy / SSP: baseline configuration requirement in SSP. CIS benchmarks / internal hardening standard / MDM build sheet / CMDB: baseline documents and inventory exports. What to screenshot/export: baseline standard, current asset list, software inventory, approved workstation image or settings. |
| CM Domain | CM.L2-3.4.2 - Security Configuration Enforcement | Enforce approved security settings on systems. | Enforcement script or policy. Configuration management log. Compliance evidence against baseline. Endpoint settings proof. |
Policy / SSP: configuration enforcement requirement. Intune / JAMF / Kandji / Fleet / Puppet / Chef / Ansible / GPO: policy assignment and compliance report. What to screenshot/export: applied policy, compliance percentage, script deployment, baseline-aligned settings page. |
| CM Domain | CM.L2-3.4.3 - System Change Management | Track and manage system changes. | Change log. Change approval record. Evidence changes are documented before/after implementation. |
Policy / SSP: change control process section. Jira / ServiceNow / spreadsheet / Git PR workflow: change tickets, approvals, implementation date. What to screenshot/export: change request, approver, implementation notes, rollback/validation notes. |
| CM Domain | CM.L2-3.4.4 - Security Impact Analysis | Assess security impact before making changes. | Security impact analysis in change record. Change log showing risk consideration. Evidence changes include security review. |
Policy / SSP: change management policy requiring security impact review. ServiceNow / Jira / pull request template: security impact field or checklist. What to screenshot/export: risk field in change ticket, reviewer signoff, analysis notes. |
| CM Domain | CM.L2-3.4.5 - Access Restrictions for Change | Restrict who can make system changes. | Change control policy. Physical or logical access list for change-capable staff. Privileged user list. Role roster and approvals for change authority. |
Policy / SSP: authorized change personnel requirement. IAM / ticketing / physical access platform: privileged access list, admin groups, facility list for change locations. What to screenshot/export: approved change-admin group, change approver roles, admin roster, approval workflow. |
| CM Domain | CM.L2-3.4.6 - Least Functionality | Disable unnecessary functions, services, and features. | Baseline showing disabled features. Restricted software list. Endpoint settings showing unnecessary panes/services disabled. Proof users lack local admin. |
Policy / SSP: least functionality statement in SSP and hardening baseline. Intune / JAMF / GPO / Kandji / Fleet: disabled services, system settings restrictions, application restrictions. What to screenshot/export: policy disabling unneeded settings, allow/deny list for software, standard user configuration. |
| CM Domain | CM.L2-3.4.7 - Nonessential Functionality | Prohibit or tightly manage nonessential capabilities. | Acceptable use policy. Documentation of essential vs nonessential services. Settings showing nonessential functions disabled. Restricted software records. |
Policy / SSP: essential services definition and prohibited functionality list. Endpoint / server management tools: disabled service list, restricted software policy. What to screenshot/export: essential service baseline, blocked feature, software restriction record. |
| CM Domain | CM.L2-3.4.8 - Application Execution Policy | Restrict what applications are allowed to run. | Application allow/deny policy. Restricted software record. Sample log showing blocked unsanctioned software. |
Policy / SSP: approved software policy. Windows Defender Application Control / AppLocker / JAMF Protect / CrowdStrike / ThreatLocker / Ivanti / Kandji: application control policy and block event. What to screenshot/export: allow list, deny list, block event for unauthorized executable. |
| CM Domain | CM.L2-3.4.9 - User-Installed Software | Prevent unauthorized software installation by users. | Acceptable use policy. No-admin-by-default evidence. Approval or audit trail for software installs. Application restriction policy. |
Policy / SSP: user-installed software prohibition or approval requirement. Intune / JAMF / Kandji / Fleet / GPO: standard-user enforcement, self-service approved app catalog, install approval logs. What to screenshot/export: no local admin, software approval ticket, blocked installation event, approved app deployment portal. |
Identification & Authentication Domain
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| IA Domain | IA.L1-3.5.1 - Identification | Identify users, devices, and non-user accounts uniquely. | Acceptable use / identity policy. Managed computer inventory. User account roster. Non-user / service account inventory. |
Policy / SSP: identification requirement for users and service accounts. Entra / Okta / Google / AWS / MDM / CMDB: managed device list, account inventory, service account export. What to screenshot/export: device enrollment list, user roster, service account register, naming standard. |
| IA Domain | IA.L1-3.5.2 - Authentication | Require authentication before allowing access. | SSO configuration evidence. MFA enabled evidence. Identity security settings. Authentication method configuration. |
Policy / SSP: authentication and MFA requirement in SSP. Microsoft Entra / Okta / Google Workspace / Duo / Ping: SSO and MFA settings, app federation setup, auth method list. What to screenshot/export: SSO enabled app page, MFA status, sign-in policy, allowed auth methods. |
| IA Domain | IA.L2-3.5.10 - Cryptographically-Protected Passwords | Protect stored and transmitted passwords using approved cryptography. | Password protection policy. Identity platform documentation showing cryptographic protection. |
Policy / SSP: password storage and handling requirement. Microsoft / Okta / Google / AWS Cognito / identity docs: vendor documentation or settings proving secure password handling. What to screenshot/export: platform security settings or official configuration docs referenced by SSP. |
| IA Domain | IA.L2-3.5.11 - Obscure Feedback | Prevent systems from revealing passwords or sensitive auth data during entry. | Password masking / feedback obscuring evidence. | Policy / SSP: secure authentication UX requirement if documented. Applications / OS / identity portals: masked password entry fields. What to screenshot/export: sign-in screen with obscured password field. |
| IA Domain | IA.L2-3.5.3 - Multifactor Authentication | Require MFA for access to systems and sensitive resources. | MFA policy. MFA deployment evidence. User enrollment records. Authenticator method examples. |
Policy / SSP: MFA requirement and scope. Entra / Okta / Duo / Google / Ping: MFA enforcement policy, enrollment report, authenticator methods. What to screenshot/export: MFA rule, enrolled users, authenticator app configuration, privileged-access MFA enforcement. |
| IA Domain | IA.L2-3.5.4 - Replay-Resistant Authentication | Use authentication methods resistant to replay attacks. | Phishing-resistant or replay-resistant MFA evidence. Documentation of secure token / authenticator method. Identity platform guidance supporting replay resistance. |
Policy / SSP: SSP can cite modern MFA / token-based auth requirement. FIDO2 / WebAuthn / Microsoft Authenticator / Duo / Okta FastPass / Google passkeys: replay-resistant auth settings. What to screenshot/export: FIDO2/passkey policy, authenticator assurance setting, approved strong auth method list. |
| IA Domain | IA.L2-3.5.5 - Identifier Reuse | Prevent immediate reuse of identifiers for new accounts. | Disabled/unlicensed users list. Account lifecycle policy showing retention or disabled-state handling before reuse. |
Policy / SSP: identity lifecycle section defining no immediate reuse. Entra / Google / Okta / HRIS: disabled user list and account retention process. What to screenshot/export: disabled account state, deprovision workflow, retention timeline. |
| IA Domain | IA.L2-3.5.6 - Identifier Handling | Manage identifiers consistently across the account lifecycle. | User account roster. Disabled user inventory. Identifier issuance and retirement process. |
Policy / SSP: naming / identity issuance standard. Identity platform: active vs disabled account exports, account creation convention, HR-linked identifiers. What to screenshot/export: identifier format, active/disabled account handling, account status fields. |
| IA Domain | IA.L2-3.5.7 - Password Complexity | Enforce strong password composition rules. | Password complexity policy. Identity platform enforcement screenshot or documentation. |
Policy / SSP: password complexity requirement. Entra / Google / Okta / LDAP / AD: password rule settings or official platform configuration. What to screenshot/export: minimum length, complexity requirement, banned password settings if available. |
| IA Domain | IA.L2-3.5.8 - Password Reuse | Prevent users from reusing previous passwords. | Password history / reuse policy. Identity platform enforcement evidence. |
Policy / SSP: password history requirement. AD / Entra / Okta / LDAP: password history or vendor-supported reuse prevention settings. What to screenshot/export: password history count, password reset rule, reused-password restriction. |
| IA Domain | IA.L2-3.5.9 - Temporary Passwords | Force change of temporary passwords after first use or initial issuance. | Temporary password / initial credential policy. Evidence users must change temporary passwords. |
Policy / SSP: initial password handling requirement. AD / Entra / Okta / Google Workspace: force password change at next sign-in. What to screenshot/export: account creation workflow with forced change flag, reset screen requirement. |
Incident Response Domain
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| IR Domain | IR.L2-3.6.1 - Incident Handling | Establish and follow an incident response process. | Incident response plan and procedure. Roles, steps, and communication pathways for incidents. |
Policy / SSP: incident response section or standalone IR plan. What to screenshot/export: plan title page, incident lifecycle, severity definitions, communications workflow. |
| IR Domain | IR.L2-3.6.2 - Incident Reporting | Report suspected and confirmed incidents promptly. | Sample security alerts. Incident response contact list. Incident tracking form or ticket record. Evidence alerts are escalated and reported. |
Policy / SSP: incident reporting requirement and reporting channels. SIEM / MDR / EDR / ticketing: Sentinel, Splunk, Arctic Wolf, CrowdStrike, Defender, Jira, ServiceNow, case records. What to screenshot/export: alert email, ticket, owner assignment, incident intake form, contact list. |
| IR Domain | IR.L2-3.6.3 - Incident Response Testing | Test incident response processes periodically. | Tabletop exercise guide. After-action report. Incident tracking evidence showing exercises or simulations. |
Policy / SSP: testing frequency in IR plan or SSP. Tabletop / exercise documentation: meeting agenda, scenario, attendance, after-action report, corrective actions. What to screenshot/export: exercise schedule, findings, lessons learned, remediation items. |
Risk Assessment Domain
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| RA Domain | RA.L2-3.11.1 - Risk Assessments | Assess risks to the environment regularly. | Formal risk assessment report. External or internal security assessment summary. |
Policy / SSP: risk assessment requirement. Risk register / consulting report / spreadsheet: annual risk assessment, environmental review, threat/vulnerability assessment. What to screenshot/export: report title, date, scope, risk ratings, recommendations. |
| RA Domain | RA.L2-3.11.2 - Vulnerability Scan | Scan systems and environments for vulnerabilities. | Vulnerability scan schedule or policy. Vulnerability scan results. Evidence scans run on a regular cadence. |
Policy / SSP: vulnerability scanning requirement and frequency. Qualys / Nessus / Defender VM / Rapid7 / JAMF Protect / Tenable: scan schedule, vulnerable asset list, policy assignment. What to screenshot/export: last scan date, vulnerable devices, scan policy, recurring schedule. |
| RA Domain | RA.L2-3.11.3 - Vulnerability Remediation | Remediate identified vulnerabilities in a tracked manner. | POA&M or remediation tracker. Vulnerability remediation reports. Evidence issues move toward closure. |
Policy / SSP: remediation timeline requirement. Qualys / Nessus / Jira / ServiceNow / spreadsheet: vulnerability ticket status, aging report, remediation owner, closure proof. What to screenshot/export: vulnerability status before/after, remediation due dates, closed issue evidence. |
System & Communications Protection Domain
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| SC Domain | SC.L1-3.13.1 - Boundary Protection | Protect system boundaries and control communications at those boundaries. | Network diagram. Firewall configuration. Content filtering configuration. Network event log. |
Policy / SSP: boundary protection architecture in SSP. Meraki / Palo Alto / Fortinet / AWS / Azure Firewall / Unifi: firewall rules and event logs. JAMF Protect / Umbrella / Cloudflare Gateway / Zscaler: content filtering or web protection evidence. What to screenshot/export: network diagram, ingress/egress rules, firewall event log, blocked category rules. |
| SC Domain | SC.L1-3.13.5 - Public-Access System Separation | Separate public-facing systems from internal systems handling sensitive data. | Data flow diagram. Network segmentation diagram. Architecture showing separation. |
Policy / SSP: architectural separation documented in SSP. Cloud / network diagrams: VPC/subnet separation, DMZ design, segmented VLANs, separate public workloads. What to screenshot/export: diagram proving public-facing services are segregated from CUI systems. |
| SC Domain | SC.L2-3.13.10 - Key Management | Protect and manage encryption keys securely. | Encryption key escrow / management evidence. Admin list for who can access decryption keys. |
Policy / SSP: key management requirement. JAMF / Intune / BitLocker / FileVault escrow / AWS KMS / Azure Key Vault / Google Cloud KMS: key escrow settings and admin access lists. What to screenshot/export: escrow enabled, key-access admin roles, key vault permissions. |
| SC Domain | SC.L2-3.13.11 - CUI Encryption | Encrypt CUI when required using approved methods. | SSP or policy stating encryption requirements. Application access policy tied to secure use. Disk or connection encryption evidence. |
Policy / SSP: CUI encryption requirement in SSP. FileVault / BitLocker / TLS / VPN / app protection tools: encryption at rest and in transit evidence. What to screenshot/export: disk encryption status, VPN encryption, secure application access policy, encryption standard. |
| SC Domain | SC.L2-3.13.12 - Collaborative Device Control | Control how shared or collaborative devices connect to the environment. | SSP narrative describing collaborative device restrictions. Network diagram showing controlled placement of such devices. |
Policy / SSP: collaborative device control section in SSP. Network / MDM: restricted VLAN placement, managed conferencing devices, printer/networked-device control. What to screenshot/export: controlled device network placement, management policy, access restriction. |
| SC Domain | SC.L2-3.13.13 - Mobile Code | Control the use of mobile code. | SSP section describing mobile code restrictions or management. | Policy / SSP: mobile code policy is often primary evidence here. Browser / endpoint / app control tools: restrictions on macros, scripts, browser code execution, application control. What to screenshot/export: macro restrictions, browser script policy, SSP statement. |
| SC Domain | SC.L2-3.13.14 - Voice over Internet Protocol | Control and secure VoIP if used. | SSP section explaining use, restriction, or architecture for VoIP. | Policy / SSP: VoIP handling documented in SSP is primary evidence if environment use is limited. Unified comms / firewall: VoIP segmentation, encryption, call platform settings where applicable. What to screenshot/export: architecture or policy statement about VoIP scope and protection. |
| SC Domain | SC.L2-3.13.15 - Communications Authenticity | Protect the authenticity and integrity of communications. | Traffic routing evidence. Certificate information. Application access policy enforcing trusted communications. |
Policy / SSP: communications authenticity requirement. TLS certificates / PKI / Zero Trust / app access brokers: certificate info, trusted routing, app verification policy. What to screenshot/export: certificate details, trusted app access policy, secure routing evidence. |
| SC Domain | SC.L2-3.13.16 - Data at Rest | Protect stored sensitive data. | Data-at-rest encryption policy. Disk encryption evidence. Cloud storage protection evidence. |
Policy / SSP: encryption at rest requirement in SSP. BitLocker / FileVault / cloud encryption / database TDE / object storage encryption: status and policy screenshots. What to screenshot/export: encryption enabled on endpoints, storage service encryption, key management tie-in. |
| SC Domain | SC.L2-3.13.2 - Security Engineering | Use security engineering principles in system design. | Configuration management records. Data flow diagram. Network diagram showing secure design. |
Policy / SSP: architectural security principles in SSP. Architecture docs / change design reviews: secure segmentation, trust boundaries, review checkpoints. What to screenshot/export: system diagram, design review artifact, change record referencing security design. |
| SC Domain | SC.L2-3.13.3 - Role Separation | Separate system roles to reduce risk of misuse. | Acceptable use policy. SSP description of separated roles. User access roster showing separation. |
Policy / SSP: role separation section. IAM / admin platforms: role assignment export proving operational and security roles are separate. What to screenshot/export: user-role list, separation of admin/security duties, SSP language. |
| SC Domain | SC.L2-3.13.4 - Shared Resource Control | Control access to shared resources. | SSP section describing controls for shared resources. User access roster for shared systems or repositories. |
Policy / SSP: shared resource control narrative. File sharing / cloud storage / identity tools: group permissions, restricted shared folders, scoped access to shared apps/resources. What to screenshot/export: group permission assignment, shared resource ACL, SSP statement. |
| SC Domain | SC.L2-3.13.6 - Network Communication by Exception | Allow only specifically authorized network communications. | Content filtering or exception-based communication policy. Custom block rules. Firewall deny/allow configuration. |
Policy / SSP: deny-by-default or allow-by-exception networking standard. Meraki / Palo Alto / Fortinet / AWS NACL / SG / Cloudflare Gateway / Zscaler: explicit allow/deny rule sets. What to screenshot/export: default deny posture, allow-listed ports/domains, custom block rules, firewall rules. |
| SC Domain | SC.L2-3.13.7 - Split Tunneling | Prevent insecure split tunneling where prohibited. | Conditional access / VPN policy. Security cloud or VPN setting forcing protected traffic path. Evidence split tunneling is disabled or controlled. |
Policy / SSP: VPN/split tunneling requirement. Meraki / Zscaler / Cloudflare / Prisma / Tailscale / Cisco / Entra Conditional Access: enforced secure routing or device trust before access. What to screenshot/export: VPN client settings, tunnel mode, device trust requirement, denied noncompliant access. |
| SC Domain | SC.L2-3.13.8 - Data in Transit | Protect data in transit. | Certificate evidence. TLS/secure transport evidence. |
Policy / SSP: encryption in transit requirement. Certificates / TLS configs / reverse proxies / load balancers / app gateways: certificate details, HTTPS enforcement, TLS version policy. What to screenshot/export: valid certificate info, HTTPS/TLS setting, secure transport enforcement. |
| SC Domain | SC.L2-3.13.9 - Connections Termination | Terminate sessions and connections when appropriate. | SSO/session configuration evidence. SSP session termination narrative. Identity platform session lifetime configuration. |
Policy / SSP: session termination requirement. Entra / Okta / Google / SSO providers: sign-in frequency, session timeout, re-authentication settings. What to screenshot/export: SSO session policy, timeout duration, termination condition. |
System & Information Integrity Domain
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| SI Domain | SI.L1-3.14.1 - Flaw Remediation | Identify and remediate software flaws in a timely manner. | Patch management policy. Patch frequency / schedule evidence. Patch execution samples. Vulnerability or update policy screenshots. |
Policy / SSP: patch timeline requirement in SSP. Intune / JAMF / WSUS / SCCM / Kandji / Fleet / Linux repos / Qualys / Tenable: update schedules, patch reports, vulnerability policy. What to screenshot/export: scan frequency, patch cadence, completed remediation, policy schedule. |
| SI Domain | SI.L1-3.14.2 - Malicious Code Protection | Protect systems against malicious code. | Threat intelligence or malware protection policy. Endpoint protection configuration. Analytics or detection dashboard evidence. |
Policy / SSP: malware protection requirement. Defender / CrowdStrike / JAMF Protect / SentinelOne / Sophos / Trend / Elastic Defend: protection policy, detection analytics, subscription to threat intel feeds. What to screenshot/export: endpoint protection policy, detection dashboard, agent coverage. |
| SI Domain | SI.L1-3.14.4 - Update Malicious Code Protection | Keep malicious code protections updated. | Antivirus/EDR update policy. Definition or engine update evidence. |
Policy / SSP: AV/EDR update requirement. Defender / CrowdStrike / JAMF Protect / SentinelOne / Sophos: definition version and last update status. What to screenshot/export: update status page, current version, auto-update setting. |
| SI Domain | SI.L1-3.14.5 - System & File Scanning | Scan systems and files for malicious content. | Scheduled scan policy. Scan completion evidence. Vendor documentation if needed to explain native protections. |
Policy / SSP: scheduled scanning requirement. Defender / JAMF Protect / CrowdStrike / SentinelOne / XProtect / Sophos: scan schedule, scan result, daily scan proof. What to screenshot/export: scan policy, last scan time, result summary. |
| SI Domain | SI.L2-3.14.3 - Security Alerts & Advisories | Receive and act on security alerts and advisories. | Threat advisory subscription evidence. Vulnerability alert email or notice. |
Policy / SSP: vulnerability intelligence / advisory monitoring requirement. CISA, vendor advisories, Qualys, Tenable, Microsoft Security Center, Google security bulletins: subscription evidence and received notices. What to screenshot/export: subscription settings, advisory email, triage note. |
| SI Domain | SI.L2-3.14.6 - Monitor Communications for Attacks | Monitor communications for attack indicators. | Security alert for suspicious communications. Inbox or alert record for detected event. |
Policy / SSP: detection and monitoring requirement. SIEM / email security / network detection / MDR: alert for suspicious email, network communication, or attack behavior. What to screenshot/export: alert details, source/destination, severity, owner assignment. |
| SI Domain | SI.L2-3.14.7 - Identify Unauthorized Use | Detect unauthorized use of systems. | Acceptable use policy. SSP section describing unauthorized-use detection. Alerting evidence for suspicious behavior. |
Policy / SSP: unauthorized use monitoring requirement. SIEM / EDR / identity tools: anomaly alert, unauthorized login detection, suspicious admin activity alert. What to screenshot/export: suspicious behavior alert, unauthorized use case, policy statement, follow-up workflow. |
Remaining Domains
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| AT Domain | AT.L2-3.2.1 - Role-Based Risk Awareness | Train personnel on risks relevant to their roles. | Security awareness training content. Role-based or elevated-access training materials. Employee checklist showing required training. Acknowledgment records for higher-risk roles. |
Policy / SSP: training requirement in SSP or training policy. KnowBe4 / Proofpoint / LMS / Google Classroom / internal LMS: assigned role-based training module screenshots. HRIS / LMS: completion reports and acknowledgement records. What to screenshot/export: training catalog, assigned audience, completion report, signed acknowledgment. |
| AT Domain | AT.L2-3.2.2 - Role-Based Training | Provide job-specific security training for users with special responsibilities. | Elevated access training materials. Role-based training completion records. Acknowledgments for privileged users. |
Policy / SSP: privileged user training requirement. LMS: admin-specific training assignment and completions. What to screenshot/export: admin training module, completion evidence, acknowledgment for users with elevated rights. |
| AT Domain | AT.L2-3.2.3 - Insider Threat Awareness | Train personnel to recognize and report insider threat indicators. | Insider threat awareness training materials. Regulatory or policy basis for the training. Completion records or sign-off evidence. |
Policy / SSP: awareness training requirement referencing insider threat. LMS / KnowBe4 / internal slides: insider threat module, training deck, attendance log, signed completion. What to screenshot/export: module title, completion metrics, signed roster, annual training schedule. |
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| CA Domain | CA.L2-3.12.1 - Security Control Assessment | Assess whether required controls are implemented and effective. | System Security Plan. Formal risk assessment. Assessment narrative or test results. |
Policy / SSP: SSP itself plus assessment methodology section. Internal assessment docs / consultant reports / spreadsheets: control test results and findings. What to screenshot/export: assessment date, reviewer, control coverage, findings summary. |
| CA Domain | CA.L2-3.12.2 - Plan of Action | Track remediation work for identified gaps. | Plan of Action & Milestones (POA&M). Remediation tracking document. |
Policy / SSP: corrective action process in SSP or governance policy. Spreadsheet / Jira / Asana / ServiceNow / GRC-lite tracker: POA&M with owners and due dates. What to screenshot/export: weakness, remediation owner, due date, status, closure evidence. |
| CA Domain | CA.L2-3.12.3 - Security Control Monitoring | Continuously monitor controls and security-relevant telemetry. | Data collection architecture. Security monitoring platform overview. POA&M tied to monitoring outcomes. Recurring security reports. |
Policy / SSP: continuous monitoring section of SSP. SIEM / MDR / XDR / managed services: source integrations, report schedule, health dashboards. What to screenshot/export: monitored source list, weekly/monthly security report, control monitoring dashboard. |
| CA Domain | CA.L2-3.12.4 - System Security Plan | Maintain an SSP that documents the environment and control implementation. | Formal SSP document. Evidence SSP is current and covers implemented controls. |
Policy / SSP: the SSP itself is primary evidence. What to screenshot/export: title page, revision history, scope, control implementation sections, approval/signoff. |
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| MA Domain | MA.L2-3.7.1 - Perform Maintenance | Perform system maintenance in a controlled and documented manner. | Maintenance / patching procedure. Evidence maintenance occurred. Patching proof for systems. |
Policy / SSP: maintenance and patching procedure in SSP. Intune / JAMF / Kandji / WSUS / SCCM / RMM / Linux package management: patch deployment report, device update status. What to screenshot/export: maintenance record, patch report, completed update evidence. |
| MA Domain | MA.L2-3.7.2 - System Maintenance Control | Control who performs maintenance and how maintenance is authorized. | Authorized maintenance users list. Maintenance evidence tied to approved personnel. User/role roster proving maintenance authority. |
Policy / SSP: approved maintenance personnel requirement. IAM / ticketing / MDM / RMM: technician role assignment, maintenance approval ticket, admin group. What to screenshot/export: authorized maintenance group, maintenance ticket with assignee, role roster. |
| MA Domain | MA.L2-3.7.3 - Equipment Sanitization | Sanitize equipment before disposal, transfer, or reuse. | Sanitization policy. Vendor or internal destruction certificates. Media disposal log. |
Policy / SSP: sanitization/disposal requirement. Asset management / destruction vendor: destruction certificate, chain-of-custody, wipe certificate, disposal spreadsheet. What to screenshot/export: signed destruction certificate, serial number record, disposal log entry. |
| MA Domain | MA.L2-3.7.4 - Media Inspection | Inspect media to reduce risk before use or reuse. | Removable media control policy. USB / mass-storage restrictions. Malware scanning evidence for media or devices. |
Policy / SSP: media inspection requirement. Defender / CrowdStrike / XProtect / EDR / AV / MDM: scan result, device control policy, blocked device event. What to screenshot/export: scan status, media event, approval-before-use workflow, removable media policy. |
| MA Domain | MA.L2-3.7.5 - Nonlocal Maintenance | Secure remote maintenance sessions. | Remote maintenance policy. MFA or conditional access requirement for admins performing maintenance. |
Policy / SSP: nonlocal maintenance section. Conditional access / VPN / PAM: admin MFA policy for remote maintenance, bastion host access rule, ZTNA session control. What to screenshot/export: admin remote access MFA enforcement, restricted maintenance pathway. |
| MA Domain | MA.L2-3.7.6 - Maintenance Personnel | Ensure only authorized and appropriately managed personnel perform maintenance. | Maintenance personnel roster. Role / management status list. Visitor log or escorted maintenance personnel record where applicable. |
Policy / SSP: authorized personnel requirement and supervision expectations. HR / IAM / visitor management: employee roster, contractor list, visitor log, assignment approval. What to screenshot/export: personnel list, authorization proof, visitor sign-in for external maintainers. |
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| MP Domain | MP.L2-3.8.1 - Media Protection | Protect media containing sensitive information. | Media protection policy. CUI media tracking log or equivalent media inventory. |
Policy / SSP: media protection section of SSP. Spreadsheet / CMDB / asset system: media inventory and tracking. What to screenshot/export: media record, classification, custodian, storage location. |
| MP Domain | MP.L2-3.8.2 - Media Access | Restrict who can access media containing sensitive information. | User access roster. Role / management roster. Media tracking log with custodian information. |
Policy / SSP: media access restriction requirement. IAM / asset tracking: assigned custodian, role-based access records, access approval. What to screenshot/export: access list for media, custodian fields, approval chain. |
| MP Domain | MP.L2-3.8.3 - Media Disposal | Dispose of media securely and document the process. | Sanitization template or procedure. Destruction certificates. Media disposal log. Signed disposal record. |
Policy / SSP: media disposal process. Vendor destruction certificate / internal wipe form / spreadsheet log: certificate, signed sanitization form, disposal tracking record. What to screenshot/export: destruction certificate, signed sanitization form, serial number tied to disposal entry. |
| MP Domain | MP.L2-3.8.4 - Media Markings | Mark media appropriately to show sensitivity or handling requirements. | Media labeling policy. Example asset or media label. Evidence storage or platform markings correspond to handling requirements. |
Policy / SSP: labeling/classification policy. M365 sensitivity labels / Google labels / Box classification / physical stickers: example label on asset or file/container. What to screenshot/export: classification label setting, physical sticker, file labeling policy. |
| MP Domain | MP.L2-3.8.5 - Media Accountability | Track media throughout its lifecycle. | Media tracking log. Custody and disposition records. |
Policy / SSP: accountability/tracking requirement. Asset system / spreadsheet: issuance, return, transfer, disposal record. What to screenshot/export: chain-of-custody, assigned owner, status history. |
| MP Domain | MP.L2-3.8.6 - Portable Storage Encryption | Encrypt portable storage containing sensitive information. | Portable media policy. Device control policy for removable media. Malware/inspection evidence tied to portable media controls. Encryption requirement for approved devices. |
Policy / SSP: removable media encryption requirement. BitLocker To Go / FileVault / encrypted USB / MDM policy / endpoint device control: proof only encrypted media is allowed or media is blocked entirely. What to screenshot/export: encryption requirement, approved encrypted media list, device control policy, inspection/scanning evidence. |
| MP Domain | MP.L2-3.8.7 - Removable Media | Control the use of removable media. | Mass-storage disablement policy. Removable storage control set. Technical enforcement evidence. |
Policy / SSP: removable media section of SSP. Windows GPO / Defender Device Control / Intune / JAMF / CrowdStrike / Fleet: removable storage blocked or allow-listed. What to screenshot/export: removable storage policy, allowed device exceptions, block event. |
| MP Domain | MP.L2-3.8.8 - Shared Media | Protect media that may be shared, reused, or repurposed. | Shared/removable media restrictions. Control set for how shared media is allowed, sanitized, or prohibited. |
Policy / SSP: shared media handling requirement. Endpoint / device control tools: restrictions on shared USB or external storage, sanitization-before-reuse workflow. What to screenshot/export: shared media policy, device restriction, reuse approval and sanitization steps. |
| MP Domain | MP.L2-3.8.9 - Protect Backups | Protect backup media and backup data from unauthorized access. | Backup protection policy. Evidence backups containing sensitive data are access controlled and protected. Cloud storage access control policy for backup repositories. |
Policy / SSP: backup protection section. Backup platforms / cloud storage / Box / M365 / Google / Veeam / Druva / Rubrik: encryption, access control, retention, immutability where used. What to screenshot/export: backup repository permissions, encryption setting, retention policy, admin access controls. |
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| PE Domain | PE.L1-3.10.1 - Limit Physical Access | Restrict physical access to facilities and systems. | Physical access policy. Badge / access control system evidence. Card inventory or assigned access list. |
Policy / SSP: physical access control policy. Brivo / Verkada / Kisi / Lenel / access badge systems: access group list, assigned badge inventory, facility manager screenshot. What to screenshot/export: authorized door groups, active badges, facility access policy. |
| PE Domain | PE.L1-3.10.3 - Escort Visitors | Escort and control visitors appropriately. | Visitor policy. Visitor log showing escort process. |
Policy / SSP: visitor handling requirement. Visitor management system / paper log / Google Form: sign-in sheet showing escort field or badge issuance. What to screenshot/export: visitor log entry, escort designation, sign-in/out timestamps. |
| PE Domain | PE.L1-3.10.4 - Physical Access Logs | Maintain logs of physical access. | Badge access logs. Visitor logs. Physical access journal entries. |
Policy / SSP: logging requirement for physical access. Access control system: event journal, door access log, visitor sign-in records. What to screenshot/export: access events with cardholder, time, door, visitor entries. |
| PE Domain | PE.L1-3.10.5 - Manage Physical Access | Manage issuance, revocation, and tracking of physical access credentials. | Badge inventory. Offboarding / badge deactivation evidence. Physical security asset inventory. |
Policy / SSP: badge issuance/revocation process. Brivo / Verkada / access system / HR offboarding ticket: deactivated badge record, credential inventory, physical security device inventory. What to screenshot/export: disabled badge, active card inventory, offboarding evidence tied to access revocation. |
| PE Domain | PE.L2-3.10.2 - Monitor Facility | Monitor facilities for unauthorized activity. | Alerting for facility events. Event logs showing anomalous access or facility monitoring. |
Policy / SSP: monitoring/alarm section in physical security policy. Access control / camera / alarm platforms: event alert, anomaly detection, notification record. What to screenshot/export: alert email, event log, alarm notification, camera monitoring evidence if applicable. |
| PE Domain | PE.L2-3.10.6 - Alternative Work Sites | Apply security requirements to alternative work locations. | Remote work / alternative work site policy. Physical protection policy covering non-office environments. |
Policy / SSP: alternative work site requirements in SSP or remote work policy. HR / security policy repository: signed remote work agreement, physical protection standards for home offices. What to screenshot/export: policy language for protecting devices and CUI outside office locations. |
| Control Family | Control | Objective | Sanitized Evidence to Collect | Examples of What to Capture |
|---|---|---|---|---|
| PS Domain | PS.L2-3.9.1 - Screen Individuals | Screen individuals before granting appropriate access. | Background check policy. Completed screening evidence for personnel. |
Policy / SSP: personnel screening requirement. HRIS / screening vendor / hiring workflow: background check completion status or signed clearance record. What to screenshot/export: completed check status, screening provider result, hiring checklist. |
| PS Domain | PS.L2-3.9.2 - Personnel Actions | Manage personnel actions such as onboarding, transfer, and offboarding securely. | Onboarding records. Offboarding records. Personnel action workflow and approvals. |
Policy / SSP: onboarding/offboarding process in HR/security policy. HRIS / Jira / ServiceNow / ticketing / checklist forms: onboarding package, offboarding ticket, equipment return checklist. What to screenshot/export: onboarding workflow, offboarding approval, account disablement, equipment return. |
One Final Recommendation
Looking back, one of the biggest advantages we had going into the assessment was that evidence collection didn’t begin when the assessment was scheduled. By that point, most of the work had already been done.
As controls were implemented, we made a habit of retaining the artifacts that demonstrated those controls were working. Screenshots were saved. Reports were exported. Training records were retained. Reviews were documented. Vulnerability scans were archived. Over time, those individual pieces of evidence became a library that could be referenced throughout the assessment process.
That approach proved far more valuable than trying to assemble everything once the assessment was on the calendar. Organizations that appear well prepared during an assessment are not necessarily the ones with the most documentation. More often, they are the organizations that have established repeatable processes for collecting and maintaining evidence as part of their normal operations.
In many ways, that’s the distinction between treating compliance as a project and treating it as an operational function. Projects have deadlines. Operational processes continue long after the assessment is over.
The evidence guide that follows is a sanitized version of the framework that helped us prepare for a successful CMMC Level 2 assessment. Every environment is different, and every organization will have its own tools and processes, but I hope this provides a useful starting point for anyone trying to understand what good evidence collection looks like in practice.
Sources
- Cybersecurity Maturity Model Certification (CMMC) Program
- CMMC Level 2 Assessment Guide
- NIST SP 800-171 Rev. 2
- NIST SP 800-171A
- DoD CMMC Program Rule
AI Usage Transparency Report
AI Era · Written during widespread use of AI tools
AI Signal Composition
Rep
Tone
Struct
List
Instr
Repetition: 65%
Tone: 52%
Structure: 59%
List: 2%
Instructional: 67%
Emoji: 0%
Score: 0.38 · Moderate AI Influence
Summary
The article discusses the importance of evidence collection in CMMC assessments, highlighting the need for a structured approach to gathering and organizing evidence. It outlines four layers of evidence (policy, technical control, operational evidence) and provides a framework for building an evidence library.
Related Posts
How We Passed Our CMMC Assessment
After helping lead our organization through a successful CMMC Level 2 assessment, I share lessons learned from years of preparation, audit readiness, evidence collection, and working through the certification process.
Setting up Ollama on macOS
Recently, after some bad experiences with OpenAI's ChatGPT and CODEX, I decided to look into and learn more about running local AI models. On its face it was intimidating, but I had seen a lot of people in the MacAdmins community posting examples of macOS setups, which really helped lower the bar for me both in terms of approachability and just making me more aware of the local AI community that exists out there today.
AI Agent Constraints and Security
I really feel like in this era of AI it's essential to write about and share experiences for others who are leveraging AI, especially now that AI usage seems almost ubiquitous. Specifically, when it comes to AI in development and the rapid growth of AI-driven automations in the IT landscape, I believe there's a need for open discussion and exploration.
Vibe Coding with Codex: From Fun to Frustration
So there I was, a typically day, a typical weekend. As a ChatGPT customer, I had heard good things about Codex and had not yet tried the platform. To date my experience with agentic coding was simply snippit based support with ChatGPT and Gemeni where I would ask questions, get explanations and support with squashing bugs in a few apps that I work on, for fun, on the side. There were a few core features in one of the apps I built that I wanted to try implementing but the...
Turn Jamf Compliance Output into Real Audit Evidence
Most teams use Apple’s macOS Security Compliance Project (mSCP) baselines because they scale and they’re repeatable. Jamf’s tooling makes deployment straightforward and the Extension Attribute (EA) output is a convenient place to capture drift. What you don’t automatically get is the artifact an auditor will accept on a specific date—an actual document you can file that shows which endpoints are failing which items, plus a concise roll-up of failure counts you can act on. Smart Groups answer scope; they don’t produce evidence.
Secure Software, Secure Career: How I Passed the CSSLP
After passing the CISSP earlier this year, I decided to follow it up with the **Certified Secure Software Lifecycle Professional (CSSLP)** certification. For those unfamiliar, CSSLP is an ISC2 certification that focuses specifically on secure software development practices across the full SDLC—from requirements and design to coding, testing, deployment, and maintenance. My goal in pursuing this certification was to further develop my skills in ensuring the security of software throughout its entire lifecycle.
Good Cybersecurity policies, procedures, guidelines take time. They're not rushed and aren't rubber stamped
Cybersecurity is no longer a luxury or an afterthought—it's an absolute necessity. But how can you tell if the company you work for, as a security professional, truly values cybersecurity? Let's explore some clear indicators that demonstrate a company's commitment to implementing robust security practices in-house. A genuine commitment will be reflected in the organization's policies and procedures, which should be regularly reviewed and updated to address emerging threats.
Managing Bring Your Own Device (BYOD) for Android with Microsoft Intune
Alright, so today we're going to be talking about the management of bring your own device BYOD for Android devices. There's a lot of information out there for the management of iOS devices and you can do that with pretty much any Apple MDM on the market. We just happen to use Jamf where I work, but you could use anything from Braavos to SimpleMDM to Kanji or JumpCloud. Mosyle is also a great option.
BYO with me in 2025: iOS with User Enrollment in JAMF Pro
It really depends on your company's needs. For example, many companies need to hire 1099 contractors and in such a case they come with their own devices but not the correct security settings or enforcements. Remember BYOD is a security construct. The idea here is that you should be securing the company's sensitive data in all forms. This may involve implementing policies for contractor-owned devices, ensuring that all devices accessing company data meet minimum security standards, and regularly reviewing and updating these standards to stay ahead of emerging threats.
Securing BYOD Email Access: Exploring Strategies in Microsoft 365
In today’s mobile-first world, organizations increasingly rely on Bring Your Own Device (BYOD) programs to empower employees while optimizing costs. However, this flexibility introduces unique challenges, particularly around securing email access. To mitigate risks, we are implementing a comprehensive strategy to block email access on non-company devices by default and ensure only sanctioned apps can access organizational email accounts. This approach will help prevent unauthorized access and data breaches, aligning with our commitment to maintaining the security and integrity of company communications.
