A CMMC unauthorized use assessment checklist can establish a defensible SI.L2-3.14.7 baseline in roughly three hours if you first define authorized use, identify available monitoring sources, test whether suspicious activity is visible, and retain evidence of the review. For a merged organization, do not wait for every policy, tool, and directory to be unified: document the current-state controls for each environment, identify gaps, and assign a short-term owner. The goal is not a mature detection program on day one; it is credible evidence that the organization can recognize activity outside approved use of its systems.
What is the minimum-viable definition of compliant for SI.L2-3.14.7?
NIST SP 800-171 Rev. 2 and CMMC 2.0 Level 2 practice SI.L2-3.14.7 require an organization to identify unauthorized use of organizational systems. At minimum, an assessor should be able to follow a clear chain: the organization defines what authorized use looks like, collects records that can reveal deviations, reviews those records or alerts, and can show what happens when suspicious activity is identified.
For an M&A integration, avoid treating “we have Microsoft 365 logs” or “our MSP watches the firewall” as a complete answer. Those statements may be true, but they do not establish the expected use baseline or prove that someone reviews evidence for unauthorized behavior. The minimum viable state is a documented and repeatable process, even if the two organizations are temporarily operating separate security stacks.
| Check | Minimum evidence to collect | Fast pass criterion |
|---|---|---|
| 1. Authorized-use baseline | Acceptable use policy, employee handbook section, or interim executive memo | Defines permitted business use of devices, accounts, network services, and internet access |
| 2. Role-specific expectations | Administrator, technician, and standard-user responsibilities | Privileged activities and support access have stated boundaries |
| 3. System inventory scope | List of in-scope endpoints, servers, cloud tenants, and network devices | Each acquired environment has an accountable owner and monitoring source |
| 4. Identity activity visibility | Microsoft Entra ID, Active Directory, VPN, or privileged-access logs | Failed sign-ins, unusual logons, and privilege changes can be reviewed |
| 5. Endpoint visibility | Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, or equivalent console evidence | Malware, suspicious process, and device-control events generate alerts or reports |
| 6. Network and system monitoring | Firewall, IDS/IPS, SIEM, server audit, or network monitoring reports | Unauthorized connections, scanning, or anomalous traffic can be identified |
| 7. Review and response record | Ticket, case, email review record, or incident log | A named person reviews findings and escalates confirmed events |
This baseline depends on adjacent CMMC practices. AC.L2-3.1.1 helps establish which users, processes, and devices should have access. AU.L2-3.3.1 supplies audit records. IA.L2-3.5.1 and IA.L2-3.5.2 support identity and authentication confidence. SI.L2-3.14.7 uses those building blocks to determine whether observed behavior is outside authorized use.
How do you run the CMMC unauthorized use assessment checklist in Hour 0–4?
Use a three-hour working session with a one-hour buffer for evidence retrieval, stakeholder delays, or a second environment. As the vCISO, run this as a fact-finding session, not a policy debate. During an acquisition, label every artifact by organization, tenant, domain, and owner so the post-close integration team can distinguish an actual control gap from an unintegrated control.
Hour 0–1: Define what “authorized” means today
- Collect the current acceptable use policy, employee handbook, remote-work policy, administrator standards, and any managed-service agreement that defines monitoring responsibilities.
- Write a one-page interim authorized-use statement if existing documents are incomplete. Cover standard users, administrators, technicians, contractors, and terminated users.
- Identify the systems that process, store, or transmit CUI, plus the identity providers, endpoint platforms, firewalls, VPNs, and cloud services that support them.
- Record differences between the legacy and acquired organization. For example, one may use Microsoft Entra ID and Defender for Endpoint while the other uses on-premises Active Directory and CrowdStrike Falcon.
Your interim statement does not need legal-polish perfection. It needs to say that users may access only assigned accounts and approved systems for business purposes; administrators may use privileged accounts only for approved administrative work; and technicians may access client systems only through approved support processes.
Hour 1–2: Prove that unauthorized activity is observable
Open the actual consoles rather than relying on screenshots prepared months ago. Verify that logging is enabled, events are recent, and someone has access to investigate alerts. Select one identity source, one endpoint tool, and one network or infrastructure source for each environment.
Microsoft Sentinel KQL example: identify repeated failed sign-ins followed by success
SigninLogs
| where TimeGenerated > ago(24h)
| summarize FailedAttempts=countif(ResultType != "0"),
SuccessfulAttempts=countif(ResultType == "0")
by UserPrincipalName, IPAddress
| where FailedAttempts >= 10 and SuccessfulAttempts >= 1
| order by FailedAttempts desc
For organizations not using a SIEM, export a report from Microsoft Entra ID sign-in logs, the VPN appliance, or the endpoint detection platform. A manual review can support the quick-start baseline when it is documented, assigned, and performed consistently. Automated correlation is preferable, but CMMC does not require every organization to deploy a particular SIEM product for this practice.
Hour 2–3: Perform and document seven targeted checks
- Review new administrative accounts, role assignments, and disabled-account reactivations from the prior 30 days.
- Review excessive failed sign-ins, impossible travel alerts, unfamiliar VPN locations, or repeated authentication prompts.
- Review endpoint detections for malware, suspicious PowerShell, credential dumping, unauthorized remote tools, and blocked USB activity.
- Review firewall or IDS/IPS events for port scanning, denied outbound connections, command-and-control indicators, or access to prohibited destinations.
- Review audit events for changes to logging, endpoint protection exclusions, security group membership, or retention settings.
- Confirm that remote-access tools such as ScreenConnect, TeamViewer, AnyDesk, or RDP are approved, restricted, and monitored.
- Open at least one historical alert or ticket and verify that it shows triage, disposition, and escalation where needed.
Capture the date, reviewer, source system, search or report used, result, and ticket reference. If the review finds no suspicious activity, record “no unauthorized use identified during the review period” rather than leaving a blank worksheet. A blank record looks like an unperformed control; a documented negative result demonstrates monitoring occurred.
Hour 3–4: Build the evidence packet and gap register
Create a compact evidence folder containing the authorized-use baseline, screenshots or exports from each log source, a completed review record, the alert or ticket example, and a gap register. Keep the evidence dated and read-only after collection. For merged organizations, use a naming convention such as AcquiredCo-Entra-SignInReview-2026-07-19.pdf and LegacyCo-Falcon-DetectionReview-2026-07-19.pdf.
The quick-start output should state which organization has which capability. “Central SIEM integration pending” is acceptable as a gap if the organization can still demonstrate manual or tool-native monitoring in the interim.
What should happen during Day 1–7 after the quick-start review?
Within the first week, convert the assessment result into an operating routine. Assign a control owner, usually the security manager, IT director, or managed security provider with internal oversight. Define a review frequency based on risk: daily for high-severity EDR and identity alerts, weekly for privileged-account and remote-access reviews, and monthly for broader trend reporting.
Update the acceptable use policy or issue an interim merged-company standard. It should explicitly cover use of organizational devices, cloud accounts, internal services, internet access, removable media, personal accounts, remote support tools, and privileged credentials. Have executive leadership approve the interim standard while HR and legal align the long-term policy language.
Also create a simple escalation path. A help desk analyst should know when to route an alert to the security owner; the security owner should know when to disable an account, isolate a device, involve legal or HR, and invoke the incident response process. This turns an unauthorized-use assessment into evidence of an operational capability rather than a one-time audit exercise.
What have you intentionally deferred, and why is that acceptable?
A quick-start unauthorized-use assessment intentionally defers full SIEM consolidation, complete log normalization, advanced user and entity behavior analytics, custom detection engineering, and the final harmonization of every policy across both organizations. Those projects matter, especially after an acquisition, but they are not prerequisites to showing that the organization currently identifies unauthorized use.
You may also defer replacement of overlapping endpoint tools, firewall platforms, and identity systems. Replacing tools before documenting present coverage often creates blind spots. For now, preserve existing telemetry, identify each environment’s reviewer, and ensure alerts can be escalated. Document deferred items with an owner, target date, risk statement, and compensating measure such as manual review of native console alerts.
When should you upgrade from quick-start to a mature unauthorized-use program?
Upgrade when the merged organization has stable identity architecture, shared incident-response ownership, and enough operational capacity to manage centralized detections. Immediate triggers include repeated suspicious activity, unmanaged privileged accounts, inconsistent log retention, a CUI system entering production, or an assessment finding that evidence is incomplete or reviews are not repeatable.
A mature program centralizes logs from identity, endpoints, network devices, cloud applications, and critical servers; maps detection rules to authorized-use scenarios; tunes false positives; retains investigation records; and regularly tests whether alerts reach the right owner. The mature-state assessment checklist for unauthorized use should also include metrics such as alert review timeliness, overdue investigations, disabled-account activity, and coverage of monitored in-scope assets.
Schedule a 30-day follow-up with each organization’s IT and security owners to turn this baseline into a unified SI.L2-3.14.7 monitoring roadmap with named owners and due dates.
