RA.L2-3.11.1 requires organizations handling Controlled Unclassified Information (CUI) to perform and document organization-defined risk assessments; this post explains how a small business can implement a practical, auditable checklist and template that satisfy the Compliance Framework expectations for NIST SP 800-171 Rev.2 / CMMC 2.0 Level 2.
What RA.L2-3.11.1 requires (practical interpretation)
At its core, RA.L2-3.11.1 expects a documented risk assessment process that is repeatable, scoped to systems that process/store/transmit CUI, and updated on a defined schedule and after significant changes. For compliance purposes you must show: the assessment scope and owner, the threats and vulnerabilities considered, a likelihood/impact determination, a risk rating, mitigation recommendations (with owners and timelines), and evidence that the assessment was performed (reports, signed risk acceptance, POA&M entries). The Compliance Framework expects that assessments are more than a checklist—they must tie to specific assets and controls and be defensible to an assessor.
How to build a practical risk assessment checklist
Start by designing a checklist that forces consistent scoping and evidence capture. The checklist should require: defined assessment scope (systems, networks, cloud tenants), inventory of CUI data flows and repositories, unique asset identifiers (hostname, IP, owner), last authenticated vulnerability scan date and results, control status for key technical controls (MFA, encryption at rest/in transit, endpoint protection, logging), known vulnerabilities with CVE references and patch status, residual risk rating (using a documented 1–5 or 1–10 scale), recommended mitigations with owners and target dates, and linkages to POA&M or remediation tickets. In addition, include verification checkpoints for documentation artifacts: scan exports (CSV/PDF), configuration baseline snapshots (CIS Benchmarks, registry export), and change-control records showing when mitigations were implemented.
Checklist example (core items to include)
Make the checklist read like an inspection sheet: 1) Scope defined (systems, cloud apps, third parties) with justification; 2) CUI flow map attached (where CUI is created, stored, transmitted, archived); 3) Asset inventory present with OS and patch level; 4) Credentialed vulnerability scan performed within X days and report attached (include tool and scan configuration like Nessus credentialed scan or Azure Security Center findings); 5) Threat & vulnerability entries: CVE ID, CVSS score, observed exploitability, exploit maturity; 6) Control assessment: MFA enabled for remote access, TLS >=1.2 enforced, AES-256 or NIST-tested encryption for at-rest data, endpoint AV/EPP status, logging/forwarding to SIEM; 7) Likelihood and impact scoring with documented thresholds (e.g., Likelihood 1–5, Impact 1–5, Risk = LxI); 8) Mitigation steps with ticket numbers and owners; 9) Executive risk acceptance or POA&M linkage if mitigation deferred; 10) Date of reassessment trigger (e.g., quarterly, after major change, or when exploit published publicly).
Template fields and specific technical details
Build the template as a simple spreadsheet or form with fixed fields for evidence links. Key fields: Assessment ID, Assessor, Date, Scope description, Asset ID, Asset type (workstation/server/cloud), CUI classification, Data flow path, Vulnerability (CVE, CVSS), Patch status (patch name/version/date), Control status (Yes/No/Partial—for MFA, encryption, EDR), Detection capability (SIEM rules, last log ingestion), Risk scoring (Likelihood, Impact, Score), Remediation action, Owner, Target completion date, Evidence link(s) (scan PDF, config export, ticket). For technical accuracy include whether scans were credentialed vs unauthenticated, whether the asset is reachable on internal network only, and the configuration baseline used (e.g., CIS Windows Server 2019 Benchmark). Define scoring thresholds in the template (e.g., Score >= 12 = High, 6–11 = Medium, <=5 = Low) so the assessor sees consistent categorization.
Small business example scenarios and actionable steps
Example A: A 12-person subcontractor uses Microsoft 365 for email and a single on-prem file server for CUI. Actionable steps: map CUI stored in SharePoint/Teams and the file server; run Azure AD sign-in report and enable Conditional Access requiring MFA for all external access; run a credentialed Nessus or Qualys scan against the file server and remediate critical CVEs within 30 days; capture evidence (M365 admin export, scan PDF, patch ticket) and enter residual risks in the template; schedule next assessment quarterly and after any major staff or architecture change. Example B: A small manufacturer with an OT/IT bridge discovers CUI on an engineering workstation connected to the ICS network. Actions: isolate CUI processes, apply host-based controls (disk encryption, EDR), implement network segmentation and firewall ACLs to separate OT from IT, perform authenticated scans of the workstation and use a configuration baseline (CIS) to harden settings, document the segmentation rule and test logs showing blocked traffic, and record findings in the assessment template with a remediation plan and owner.
Compliance tips and best practices
Make the process reproducible and defensible: assign a named risk owner, store assessments in a versioned repository (GIT or controlled document library), timestamp and sign-off each assessment (electronic signature is acceptable), and link every high/medium finding to a POA&M entry with a ticket number. Automate evidence collection where possible: schedule weekly automated vulnerability scans, export authentication/conditional access logs daily to your SIEM, and use API-driven inventory (Azure AD, AWS inventory APIs, PowerShell scripts for on-prem AD) to keep the asset list current. Keep remediation SLAs aligned with risk—critical/active exploit should be 7–30 days; important within 30–90 days—and ensure the executive sponsor signs off on any residual risk acceptance forms. Finally, run tabletop exercises to validate that the mitigations listed in your assessment actually prevent or detect the modeled threats.
Risks of not implementing RA.L2-3.11.1
Failing to implement documented, repeatable risk assessments exposes a small business to data breaches that could lead to loss of CUI, contract termination, suspension from DoD procurement, and reputational damage. Practically, an unassessed environment means unpatched critical servers or misconfigured cloud storage (e.g., a public SharePoint site or misconfigured S3 bucket) can remain exploitable—one real-world example: small contractors have lost bids and been removed from contract eligibility after CUI exfiltration via misconfigured collaboration sites. Noncompliance also makes remediation ad-hoc and defensibility weak during assessments, increasing audit time and costs.
Summary: Build a simple, repeatable checklist and a structured template that capture scope, asset identifiers, scan evidence, CVE and control status, risk scoring, remediation actions, and sign-off. Use credentialed scans, automated inventory, and documented scoring thresholds; assign owners and link findings to a POA&M. For small businesses this approach creates an auditable trail that satisfies RA.L2-3.11.1 while materially reducing the risk of CUI exposure and protecting your ability to compete for DoD contracts.
