SPRS score calculator

Build an authoritative list of every user, service account, and device permitted to touch the CUI environment, then enforce it through your directory (Active Directory, Entra ID, or Google Workspace) so nothing outside that list can authenticate. Remove or disable shared, orphaned, and vendor default accounts as a quick win. Document an account provisioning and deprovisioning procedure with a required approval step. Evidence: the account inventory, a directory export showing only approved accounts, and completed access request forms.

Define what each role is actually allowed to do (read CUI, modify CUI, administer systems) and enforce it with security groups and file share or SharePoint permissions rather than granting broad access. Strip Everyone and Domain Users permissions from CUI repositories as an immediate fix. Restrict high-impact functions such as exporting data or changing security settings to named roles. Evidence: a role-to-permission matrix and screenshots of ACLs on CUI shares.

Map how CUI moves through your environment, then put technical enforcement at the choke points: DNS/web filtering to block unsanctioned cloud storage, firewall egress rules, and DLP or conditional-access policies in Microsoft 365 GCC High or Google Workspace that block CUI from leaving approved locations. Blocking personal email and consumer file-sharing sites at the gateway is a fast, high-value win. Document approved flows in a data flow diagram. Evidence: the diagram, DLP policy exports, and firewall/proxy rule screenshots.

Identify combinations of duties that would let one person both commit and conceal harm (for example, the same admin approving and implementing changes, or administering systems and reviewing the audit logs of those systems). Split them across different people or, in a very small shop, add compensating review by a second person with documented sign-off. Capture the split in a separation-of-duties matrix. Evidence: the matrix, distinct admin group memberships, and samples of second-person reviews.

Audit group memberships and remove standing admin rights from anyone who does not need them daily: most small contractors find local admin granted to entire departments. Create a small, named set of privileged accounts and consider a PAM approach (even just LAPS for local admin passwords plus separate admin accounts) rather than shared credentials. Review privileged access quarterly and record the review. Evidence: privileged account inventory, group membership exports, and quarterly review records.

Issue administrators two accounts: a standard account for email and daily work and a separate admin account used only for administrative tasks. Configure conditional access or logon restrictions so admin accounts cannot sign in to email, browse the web, or use productivity apps. This is a low-cost policy plus configuration change achievable in a day. Evidence: naming convention documentation and directory screenshots showing the paired accounts.

Configure UAC, sudo, or your endpoint management tool so standard users cannot run installers, change security settings, or execute admin utilities, and enable audit logging (Windows Security log, sudo logs, or your EDR) for privileged command execution. Removing local admin rights from standard users is the single biggest win here. Forward those logs to a central location so they survive tampering. Evidence: GPO/MDM policy exports and sample log entries showing privileged actions attributed to specific admins.

Set an account lockout policy in Group Policy, Entra ID Smart Lockout, or your identity provider: a common baseline is 5-10 failed attempts triggering a 15-minute lockout. Apply it to VPN, cloud, and local logons, not just domain workstations. This is typically a one-hour configuration task. Evidence: the policy export and a screenshot of a test account locking out after repeated bad passwords.

Deploy a logon banner referencing authorized use, monitoring consent, and CUI handling on all interactive entry points: Windows logon (GPO interactive logon message), VPN portal, and cloud sign-in pages where supported. Have counsel or your compliance lead approve the wording once, then push it everywhere via policy. This is one of the cheapest controls to close. Evidence: banner text approval and screenshots of the banner at each logon point.

Enforce an inactivity screen lock (15 minutes or less is typical) with a password or PIN to resume, pushed via GPO, Intune, or your MDM so users cannot disable it, and confirm the lock hides screen contents rather than showing open documents. Include mobile devices in the policy. Evidence: policy exports and a spot-check video or screenshot of a workstation locking on schedule.

Define session termination conditions (VPN idle timeout, cloud session lifetime, RDP session limits, after-hours disconnects) and configure them in the respective systems (firewall/VPN concentrator, Entra ID conditional access sign-in frequency, RDS session host settings). Start with the VPN, since remote sessions carry the most risk. Evidence: configuration exports showing timeout values and your documented rationale for each.

Consolidate all remote access to one or two sanctioned methods (VPN with MFA, or a ZTNA product) and disable everything else: hunt down TeamViewer, AnyDesk, and exposed RDP as a first step. Log every remote session with user, source, and duration, and review those logs on a schedule. Document who is authorized for remote access and from what devices. Evidence: remote access policy, VPN configuration, session logs, and firewall rules blocking unsanctioned tools.

Ensure every remote access path is encrypted with FIPS-validated cryptography: enable FIPS mode on your VPN appliance and verify its cryptographic module holds a CMVP certificate, and use TLS 1.2+ for web-based access. Replace legacy protocols (PPTP, raw RDP over the internet) immediately. Record the certificate numbers of the modules you rely on. Evidence: VPN cipher configuration, CMVP certificate references, and a scan showing no unencrypted remote access services exposed.

Funnel all remote traffic through a small number of managed access control points (typically your firewall/VPN concentrator or ZTNA gateway) and block direct inbound paths to individual hosts. Scan your public IP space for stray RDP, SSH, or vendor remote-access listeners and close them. Evidence: network diagram showing the managed entry points and external scan results showing no bypass paths.

Require explicit authorization before anyone can run privileged commands or reach security tooling remotely: restrict remote admin protocols to a dedicated admin VPN group or jump host, and keep an approved list of who may administer what remotely. A jump box with MFA and session logging is a practical pattern for small teams. Evidence: the authorization list, jump host configuration, and firewall rules restricting remote admin paths.

Inventory every wireless network in your facilities (including printer hotspots and rogue APs), then document which SSIDs are authorized, who approves device connections, and how guests are handled. Use certificate or credential-based onboarding (WPA2/WPA3-Enterprise with RADIUS, or at minimum MAC allowlisting on small networks) so unapproved devices cannot join the CUI network. Evidence: wireless authorization policy, AP inventory, and controller screenshots of the access configuration.

Configure WPA2-Enterprise or WPA3 with 802.1X authentication on any wireless network that can reach CUI: a small RADIUS deployment or cloud RADIUS service (via Entra ID or JumpCloud) makes this attainable for small shops. Retire WEP/WPA-Personal on corporate SSIDs and isolate the guest network from the CUI environment entirely. Evidence: wireless controller settings showing the auth and encryption modes, and VLAN configuration separating guest traffic.

Deploy MDM (Intune, Workspace ONE, or similar) and require enrollment before any phone or tablet can access company email or files, enforcing a passcode, encryption, and remote wipe. Block legacy ActiveSync connections from unenrolled devices via conditional access. Decide and document whether BYOD is permitted at all for CUI: prohibiting it is the simplest compliant answer. Evidence: MDM policy exports, enrolled device inventory, and conditional access rules.

Enforce full-device encryption on every laptop and mobile device that could hold CUI: BitLocker via Intune/GPO on Windows, FileVault on macOS, and native encryption verified through MDM on phones. Verify FIPS-validated modules where feasible and escrow recovery keys centrally. Run a compliance report to catch unencrypted stragglers. Evidence: encryption compliance reports from your management console and the enforcement policy itself.

Inventory every external system your users touch with company data (personal devices, partner portals, consumer cloud apps) and either bring them under agreement, block them, or formally prohibit their use for CUI. Use conditional access to block unmanaged devices from cloud tenants and web filtering to block unsanctioned SaaS. Publish an acceptable use policy naming the approved external systems. Evidence: the policy, conditional access rules, and the approved external systems list.

Set policy on whether company USB drives and portable media may be used on non-company systems: prohibition is the cleanest answer for most small contractors. Where portable storage is needed, issue encrypted, inventoried drives and restrict their use to managed systems via endpoint USB controls (Intune, Defender device control, or EDR policy). Evidence: the media policy, the issued-drive inventory, and device control configuration.

Establish a review gate before anything is posted to your website, social media, or public portals: name the reviewers trained to recognize CUI, require their sign-off, and keep a record of each review. Sweep existing public content once for inadvertently posted technical data as a quick win. Evidence: the publication procedure, reviewer designation memo, and completed review logs.

Roll out annual security awareness training covering CUI handling, phishing, acceptable use, and incident reporting using an affordable platform (KnowBe4, Proofpoint, or even a structured slide deck with quiz for very small teams), and require completion before system access for new hires. Track completion to individual names. Evidence: training content, completion records with dates, and the policy requiring it.

Identify roles with security duties (system admins, the ISSO/security lead, anyone handling incident response) and give them role-specific training beyond general awareness: vendor courses, CompTIA/SANS material, or documented internal training on your own procedures. Refresh when duties or systems change. Evidence: a roles-to-training matrix and certificates or attendance records for each named person.

Add an insider threat module to your annual training covering behavioral indicators (unusual data hoarding, disgruntlement, unexplained foreign contacts) and exactly how and to whom employees report concerns. Most awareness platforms include this content, so this is often a one-checkbox fix. Evidence: the module content showing indicator and reporting coverage, plus completion records.

Enable audit logging on domain controllers, servers, firewalls, VPN, and cloud tenants (Microsoft 365 unified audit log is often off by default: turn it on today), and ship logs to central storage with retention of at least 90 days online and one year archived. A low-cost SIEM or log platform (Microsoft Sentinel, Wazuh, Graylog) fits small-contractor budgets. Document which event types you log and why. Evidence: the logging standard, retention configuration, and a sample query pulling events across sources.

Eliminate shared and generic logons so every action traces to a person: give each user and each admin a uniquely named account, and where shared service accounts are unavoidable, restrict them to non-interactive use. Verify your logs actually capture username on key events. Evidence: account listing showing no shared interactive accounts and sample log entries tied to named individuals.

Schedule a periodic (at least annual) review of which event types you log, adjusting for new systems, new threats, and gaps found during incidents, and record the outcome even when the conclusion is "no change." This is a lightweight documented process, not a tool purchase. Evidence: the review procedure and dated meeting notes or tickets showing the reviews occurred.

Configure alerts for logging failures: SIEM heartbeat/agent-offline alerts, disk-space thresholds on log volumes, and notifications when a log source goes silent. Define in writing who receives the alert and what they do. Most SIEMs can do this with a built-in rule, making it a same-day fix once central logging exists. Evidence: the alert rule configuration and a test alert with the response documented.

Bring your key log sources into one place where they can be reviewed together: a SIEM correlating firewall, identity, and endpoint events, or at minimum a documented weekly review that examines them side by side. Enable built-in correlation/analytics rules (impossible travel, brute force followed by success) as quick wins. Evidence: the SIEM data source list, enabled correlation rules, and dated review notes.

Provide the ability to filter and summarize audit data on demand: saved SIEM queries, dashboards, or scheduled reports that reduce raw logs to reviewable summaries (failed logons by user, admin actions by system). Build a handful of saved searches for your most common investigation questions. Evidence: screenshots of the saved queries/dashboards and a sample generated report.

Point all systems at an authoritative time source: domain-joined machines sync to the domain controller, which syncs to NTP (e.g., NIST or pool servers); configure network gear and standalone hosts to the same source. Spot-check clock drift across systems as verification. This is usually a one-hour configuration task. Evidence: NTP configuration on the DC and network devices, and log samples showing consistent timestamps.

Restrict access to log storage and SIEM consoles to a named security/admin group, make collected logs append-only or forward them off-host so a compromised system's attacker cannot erase their tracks, and enable immutability or retention locks where your platform supports them. Evidence: ACLs on log repositories, SIEM role assignments, and retention/immutability settings.

Limit who can change audit policy, clear logs, or administer the SIEM to a small named subset of your privileged users: ideally different people than those being audited, or with alerting on audit-config changes as a compensating measure in tiny teams. Evidence: the SIEM admin role membership list and GPO/permission settings restricting audit policy changes.

Stand up a hardware and software inventory (an RMM tool, Intune, or PDQ can auto-populate it) and document baseline configurations for each system type: OS version, required agents, key security settings. Capture golden images or configuration profiles so rebuilds match the baseline. Keep the inventory current through automated discovery rather than spreadsheets. Evidence: the inventory export, baseline documents per system type, and the imaging/profile artifacts.

Adopt a recognized hardening benchmark (CIS Benchmarks or DISA STIGs) and apply it via GPO, Intune security baselines, or configuration scripts, documenting any deviations with justification. Start with Windows endpoints and domain controllers, then firewalls and servers. Run a CIS-CAT or similar scan to measure conformance. Evidence: the applied baseline policies, deviation register, and scan results.

Implement lightweight change control: changes to servers, network gear, and security settings get a ticket describing the change, an approval by someone other than the implementer, and a record of the result. A shared ticketing tool or even a structured change log works at small scale: the key is that undocumented changes stop. Evidence: the change procedure and a sample of completed change tickets with approvals.

Add a required "security impact" field to your change process where the requester answers whether the change affects CUI protection, opens ports, alters access, or touches security tooling, with the approver reviewing that analysis before sign-off. This costs nothing beyond a template update. Evidence: the change template showing the impact analysis section and completed examples.

Restrict who can push changes: lock server room and network closet access physically, limit GPO/Intune/firewall admin roles to named change-authorized personnel, and remove developer or vendor write access to production. Document these restrictions in your change policy. Evidence: admin role membership exports, physical access lists, and the documented restrictions.

Strip systems down to what the mission needs: uninstall unused software, disable unneeded services and features (SMBv1, legacy protocols, sample applications), and use your hardening baseline as the enforcement mechanism. Reviewing one server and one workstation image for unnecessary services is a productive first afternoon. Evidence: baseline documentation of permitted services and scan output showing nonessential services disabled.

Run an internal port/service scan (Nmap or your vulnerability scanner) to find open ports and running services, then disable or firewall everything without a documented business need: keep a permitted ports/protocols/services list as the reference. Host firewalls (Windows Defender Firewall via GPO) enforce this at the endpoint. Evidence: the permitted list, scan results before/after cleanup, and firewall policy exports.

Deploy application control: Windows Defender Application Control or AppLocker in enforcement (or start in audit mode and tighten), or at minimum an EDR-based blocklist of known-unwanted software. Allowlisting by publisher/path is achievable for small fleets with standardized software. Document the policy choice (deny-by-exception or permit-by-exception) and who approves additions. Evidence: the AppLocker/WDAC policy export, approval records, and blocked-execution log samples.

Remove local admin rights so users cannot install software, and provide a request path (ticket plus approval) for legitimate needs: pair this with an approved software catalog or a self-service portal in your RMM/Intune. Run periodic software inventory reports to catch unauthorized installs. Evidence: the software request procedure, local admin removal policy, and inventory reports showing detection of unapproved software.

Ensure every user, service process, and device has a unique identifier in your directory: unique usernames per person, dedicated named service accounts per application (no reuse), and device identities via domain join or MDM enrollment. Purge duplicate and legacy identifiers. Evidence: directory exports showing the naming convention and a device inventory tied to unique device identities.

Require authentication before any access to systems handling CUI: no anonymous shares, no blank passwords, no auto-logon, and 802.1X or equivalent for network-level device authentication where feasible. Audit for and eliminate any unauthenticated access paths (open file shares are a common finding). Evidence: authentication policy settings, a share permissions audit, and screenshots showing login enforcement on each system type.

Enforce MFA via your identity provider (Entra ID, Duo, Okta) on all accounts, covering local and network access for privileged accounts and network access for all users: including VPN, email, and cloud apps. Prioritize privileged and remote users first: under DoD scoring, MFA implemented for remote and privileged users but not general users scores a 3-point deduction instead of the full 5, so partial rollout still improves your SPRS position while you finish. Use Duo for RDP/Windows logon to cover local privileged access on servers. Evidence: conditional access/MFA policy exports, enrollment reports showing 100% coverage, and VPN MFA configuration.

Use authentication protocols that resist replay: modern MFA with time-based or challenge-response tokens, Kerberos, and TLS-protected logons all qualify: the practical work is disabling legacy protocols (NTLMv1, basic auth in Exchange Online, unencrypted LDAP binds) that do not. Blocking legacy authentication in your cloud tenant is a high-impact quick win. Evidence: conditional access rules blocking legacy auth and domain policy settings disabling NTLMv1.

Set a written rule that user and device identifiers are never reassigned to a different person or device for a defined period (many organizations simply never reuse them: disabled accounts are archived, not recycled). Enforce it in your provisioning procedure. This is a documentation-plus-process fix with no tooling cost. Evidence: the identifier management procedure and directory records showing departed users' accounts retained in disabled state.

Automate disabling of accounts inactive beyond your threshold (commonly 30-90 days): a scheduled PowerShell script against last-logon timestamps, an Entra ID access review, or your identity platform's built-in inactivity policy. Run a one-time cleanup of stale accounts immediately: most environments find several. Evidence: the automation script/policy, its schedule, and a report of accounts disabled by it.

Enforce password complexity and minimum length via GPO or your identity provider (14+ characters is a common modern target), and consider a banned-password list (Entra ID Password Protection) to block trivial choices. Ensure the policy requires changed character content when passwords are updated. Evidence: the password policy export and a test showing weak passwords rejected.

Enable password history in your directory policy so previous passwords cannot be reused for a defined number of generations (24 is the common Windows default target). This is a single policy setting: verify it applies to cloud accounts as well as on-prem AD. Evidence: the password history setting in your policy export.

Configure "user must change password at next logon" for all temporary and initial passwords issued at onboarding or reset, and deliver temporary credentials out-of-band from the username. Write this into your account provisioning procedure so helpdesk staff apply it consistently. Evidence: the provisioning procedure and a screenshot of the change-at-next-logon flag on a newly created account.

Verify passwords are stored only as salted cryptographic hashes and transmitted only over encrypted channels: modern AD and cloud identity providers handle storage correctly, so the real work is hunting down plaintext passwords in scripts, config files, spreadsheets, and legacy apps, and eliminating protocols that send credentials in the clear (telnet, FTP, HTTP logins). Deploy a password manager for the team as a quick win. Evidence: a credential-scanning sweep of file shares and repos, and scan results showing no cleartext authentication services.

Confirm every login interface masks password entry (dots/asterisks) and returns generic failure messages rather than revealing whether the username or password was wrong: check internally developed apps and legacy systems, since mainstream OS and cloud logons already comply. Evidence: screenshots of each custom login screen showing obscured entry and generic error text.

Write an incident response plan covering the six phases (preparation, detection, analysis, containment, recovery, and user response) with named roles, contact numbers, and simple playbooks for your likely scenarios (phishing compromise, ransomware, lost laptop). Keep it to a usable length; a 10-page plan that people follow beats a 60-page binder. Train the response team on it. Evidence: the approved plan, role assignments, and training/distribution records.

Stand up an incident log (ticketing category or register) that tracks each incident's timeline, actions, and status, and document your external reporting obligations: for defense contractors, DFARS 252.204-7012 requires reporting cyber incidents to DIBNet within 72 hours, which requires a DoD-approved Medium Assurance Certificate obtained in advance. Get that certificate now, before you need it. Evidence: the incident register, the reporting procedure naming DIBNet and the 72-hour clock, and the certificate acquisition record.

Run at least an annual tabletop exercise walking the team through a realistic scenario (ransomware on a CUI file server is a good default), capture what worked and what did not, and update the IR plan from the findings. A two-hour facilitated tabletop satisfies this without expensive red teams. Evidence: the exercise scenario, attendance list, after-action report, and the resulting plan revisions.

Establish a documented maintenance program: a monthly patch cycle for OS and applications (automate with WSUS, Intune, or your RMM), firmware update reviews for network gear, and preventive maintenance records for servers and infrastructure. Consistent, logged patching is the core of this control for most small contractors. Evidence: the maintenance schedule, patch deployment reports, and maintenance tickets.

Control the tools used for maintenance: keep an approved list of remote support and diagnostic tools, remove unapproved remote-access utilities, and vet or supervise vendor-supplied tools before they touch your systems. Restrict maintenance tool installation to admin roles. Evidence: the approved tools list, endpoint reports showing no unauthorized remote tools, and vendor tool review notes.

Before any device leaves the building for repair or warranty service, remove or sanitize CUI-bearing storage: pull the drive when possible, or cryptographically erase/wipe it per NIST SP 800-88, and record each event in a sanitization log. Where drives cannot be removed, require the vendor to sign data handling terms. Evidence: the off-site maintenance procedure and completed sanitization log entries.

Scan any media containing diagnostic or test software with your antivirus/EDR before connecting it to production systems, and prefer downloading vendor tools directly over accepting USB media from technicians. Write this into your maintenance procedure so vendor visits follow it. Evidence: the procedure and logged scan results from maintenance events.

Require MFA on every remote maintenance path (vendor VPN accounts, remote support sessions, and your own admins working from home) and configure sessions to terminate when the work is done rather than persisting. Disable vendor accounts between uses and enable them only for scheduled maintenance windows. Evidence: MFA configuration on remote maintenance accounts, session logs showing termination, and the vendor account enable/disable records.

Escort and supervise any maintenance personnel who lack authorized access (copier technicians, HVAC contractors, unvetted IT vendors) while they work near systems or CUI, and log the visit with escort name and duration. A simple visitor/escort log plus a policy statement closes this control cheaply. Evidence: the escort policy and completed visit log entries.

Store CUI media (paper files, USB drives, backup drives, DVDs) in locked cabinets or rooms with access limited to authorized staff, and define the storage locations in a media handling policy. Buying a locking cabinet and consolidating loose media into it is a same-week fix. Evidence: the policy, photos of the secured storage, and the key/combination holder list.

Limit who can access stored CUI media: keep a named list of authorized personnel, control keys or badge access to the storage location, and use a check-out log for removable media so accountability is maintained. Evidence: the authorized personnel list, access control records for the storage area, and the media check-out log.

Sanitize media per NIST SP 800-88 before disposal or reuse: cryptographic erase or multi-pass wipe for drives (tools like Blancco or built-in secure erase), physical destruction for failed drives and optical media, and cross-cut shredding for paper CUI. Keep a destruction log or vendor certificates of destruction. Evidence: the sanitization procedure, destruction certificates, and the disposal log.

Label media containing CUI with appropriate CUI markings per the CUI Registry (a "CUI" label with category where applicable), including external drives, backup tapes, and file folders. Pre-printed labels and a one-page marking guide for staff make this fast to operationalize. Evidence: the marking procedure and photos of labeled media.

Control media leaving your facility: require sign-out with name, date, destination, and return date, restrict transport to accountable personnel or tracked couriers, and prohibit unlogged removal in policy. Evidence: the transport log with completed entries and the policy language restricting media movement.

Encrypt CUI on any media transported outside controlled areas: issue hardware-encrypted USB drives (FIPS 140-validated models such as Apricorn or Kingston IronKey) as the only approved portable media, and enable BitLocker To Go enforcement so unencrypted drives are read-only or blocked. Evidence: the encrypted-drive inventory, endpoint policy enforcing removable media encryption, and the FIPS certificates of the chosen drives.

Define which removable media types are allowed and block the rest through endpoint device control (Intune, Defender for Endpoint, or EDR policies can block USB storage by default and allowlist approved encrypted drives). Prohibiting personal USB drives entirely is the cleanest small-business posture. Evidence: the removable media policy and the device control configuration with block events.

Block media with no identifiable owner: configure device control to allow only serialized, organization-issued drives, and instruct staff (via policy and training) never to plug in found or unlabeled USB devices. This pairs naturally with the 3.8.7 allowlist. Evidence: the policy statement, training content covering found media, and the device allowlist keyed to specific hardware IDs.

Encrypt backups containing CUI both in transit and at rest: enable encryption in your backup product (Veeam, Datto, cloud backup) with FIPS-validated crypto where available, protect the backup repository's access with MFA, and verify offsite/cloud copies are encrypted too. Confirm with a restore test that keys are recoverable. Evidence: backup encryption settings, key management documentation, and a successful test restore record.

Screen individuals before granting CUI access: run background checks (identity, criminal history, employment verification) through a screening service as part of hiring, and document the screening requirement in HR policy: including for contractors and temps who will touch CUI. Apply it retroactively to current CUI users if never done. Evidence: the screening policy and completion records (dates, not report contents) for each person with CUI access.

Build a termination/transfer checklist executed the day of the event: disable all accounts (directory, cloud, VPN, SaaS), collect badges, keys, laptops, and media, and adjust access on role change rather than letting permissions accumulate. Automate account disablement via an HR-to-IT notification step so nothing depends on memory. Evidence: the checklist template and completed checklists for recent departures, plus directory timestamps showing same-day disablement.

Limit physical access to areas housing CUI systems (server rooms, network closets, work areas with CUI) to a named list of authorized personnel enforced by locks, badge readers, or keyed access. Move any exposed network gear (switches in open areas) into locked enclosures. Evidence: the authorized access list, photos of the physical controls, and badge system permission exports.

Protect and monitor the facility: alarm system or monitored cameras covering entrances and the server room, documented after-hours protection, and periodic checks that monitoring works. A small camera/alarm package from a commercial provider typically satisfies this for a single-site contractor. Evidence: monitoring system documentation, camera placement diagram, and sample footage retention settings.

Require all visitors to sign in, wear a visitor badge, and be escorted while in areas containing CUI or CUI systems: no unescorted vendor or guest movement. Print a one-page escort policy and brief the staff who receive visitors. Evidence: the visitor policy, completed sign-in logs, and visitor badge stock.

Maintain physical access audit logs: badge system logs where deployed, and the visitor log plus a key/entry register for facilities on physical keys. Retain them for at least a year and review them if an incident occurs. Evidence: badge system log exports and the retained visitor logs.

Control and account for physical access devices: keep a register of who holds which keys, badges, and fobs; recover them at termination (tie into your 3.9.2 checklist); and rekey or deactivate promptly when devices are lost or unreturned. Evidence: the key/badge register with issue and return dates and records of deactivations.

Define safeguards for CUI at alternate work sites (home offices): company-managed encrypted laptops only, VPN for connectivity, locked storage or a clean-desk rule for any printed CUI, and a signed telework agreement acknowledging the rules. Prohibiting printed CUI at home entirely is a simplifying option. Evidence: the telework policy and signed agreements from remote workers.

Conduct and document a periodic (at least annual) risk assessment covering threats to CUI confidentiality across your operations, assets, and people: a straightforward spreadsheet of threats, vulnerabilities, likelihood, impact, and planned treatment satisfies this at small scale; NIST SP 800-30 provides the method. Repeat after major changes like new systems or offices. Evidence: the dated risk assessment report and the risk register with treatment decisions.

Deploy a vulnerability scanner (Nessus Essentials is free for small environments; Tenable, Qualys, or Defender Vulnerability Management scale up) and scan on a defined cadence (monthly is a common baseline) plus after new vulnerabilities are announced for your stack. Scan both infrastructure and applications, authenticated where possible. Evidence: the scan schedule/policy and recent scan reports covering the CUI environment.

Establish a remediation SLA tied to severity (for example: critical 7-15 days, high 30, medium 90), track findings to closure in a ticket or register, and document risk acceptance with sign-off for anything you deliberately defer. Rescan to verify fixes rather than trusting the patch report. Evidence: the remediation SLA, closed remediation tickets, and before/after scan results.

Perform a periodic self-assessment of all 110 requirements using the NIST SP 800-171A assessment objectives, scoring each as met or not met, at least annually: this platform's engagement workflow is designed to produce exactly this artifact. Have someone other than the implementer assess where headcount allows. Evidence: the dated assessment report with per-control results and assessor name.

Create and actively maintain a Plan of Action & Milestones (POA&M) for every deficiency: the weakness, remediation milestones with dates, responsible party, and resources needed. Review it monthly and close items with evidence; note that under CMMC, POA&M items are only permitted for limited lower-weight requirements and must close within 180 days. Evidence: the current POA&M with milestone dates and the review/closure history.

Monitor your controls on an ongoing basis rather than only at assessment time: a monthly or quarterly checklist verifying key controls still operate (MFA coverage, patch compliance, log review occurring, backup restores tested), with results recorded. Automate what you can via compliance dashboards in your management tooling. Evidence: the continuous monitoring plan/schedule and completed monitoring records.

Develop a System Security Plan describing your system boundary, environment, how CUI flows, and how each of the 110 requirements is implemented (or not yet). This is the priority document: without an SSP you cannot submit an SPRS score at all (DoD assessment methodology treats a missing SSP as having no completed assessment to report) and it is the first artifact any CMMC assessor requests. Use the NIST SP 800-171 SSP template as the skeleton and update it as the environment changes. Evidence: the current, dated, approved SSP with a revision history.

Protect communications at the network boundary and key internal boundaries: a business-class firewall with default-deny inbound, an IDS/IPS capability (built into most NGFW licenses), and segmentation of the CUI environment from guest and general networks. Review the firewall ruleset and remove any-any rules as a first pass. Evidence: the network diagram, firewall rule export, and IPS enablement screenshots.

Bake security into how you design and change systems: document security architecture principles (segmentation, least privilege, encrypted transport) in your engineering/change standards and show they are applied when systems are added: a security review step in the change process covers this at small scale. Evidence: the architecture/engineering standard and change records showing the security review applied.

Separate user functionality from system management: administer systems through dedicated admin accounts and, ideally, a management VLAN or jump host rather than from the same context as email and browsing; do not expose management interfaces (firewall admin pages, iDRAC/iLO, switch consoles) to the user network. Evidence: management VLAN/jump host configuration and firewall rules restricting management interface access.

Prevent information leakage via shared system resources: keep operating systems patched and supported (this control is primarily met by modern OS memory protections), clear temp and spool files holding CUI on shared systems, and avoid shared local accounts on multi-user machines. Retire any end-of-life operating systems in the CUI boundary. Evidence: OS inventory showing supported versions and configuration of shared-resource protections.

Place public-facing systems (web servers, external portals) in a DMZ or separate cloud network segment so a compromise there cannot reach the internal CUI network: most business firewalls support a DMZ zone natively. If your only public presence is vendor-hosted (website at a hosting provider), document that separation instead. Evidence: network diagram showing the DMZ/subnetwork and firewall rules isolating it from internal segments.

Set firewall policy to deny-all by default and permit only documented, needed traffic: inbound and, importantly, outbound (egress filtering is commonly missing). Review the ruleset, remove permissive legacy rules, and record the business justification for each allow rule. Evidence: the firewall configuration export showing default-deny and the rule justification register.

Prevent split tunneling on remote clients: configure the VPN for full tunnel (or a carefully documented exception set), so remote devices cannot bridge your network and untrusted networks simultaneously. This is a VPN profile setting deployable in an afternoon. Evidence: the VPN client profile/configuration showing split tunneling disabled.

Encrypt CUI in transit outside the protected boundary: TLS 1.2+ for web and email connections, encrypted VPN or SFTP for file transfer, and a secure file transfer or email encryption solution (such as your GCC High tenant's encryption or a managed SFT service) instead of plain email attachments for CUI. Prefer FIPS-validated implementations. Evidence: TLS configuration scans, the approved transfer methods list, and encryption settings for email/file exchange.

Configure network connections to terminate after sessions end or after a defined idle period: firewall TCP session timeouts, VPN idle disconnects, and load balancer/server keep-alive limits. These are configuration values in devices you already own. Evidence: the timeout settings exported from the firewall and VPN with your documented values.

Manage cryptographic keys formally: document how keys and certificates are generated, stored, rotated, and revoked; escrow BitLocker recovery keys in AD/Entra; protect private keys in secure stores rather than files on disk; and calendar certificate expirations. A one-page key management standard covers a small environment. Evidence: the key management procedure, key escrow configuration, and the certificate inventory.

Use FIPS-validated cryptography wherever cryptography protects CUI confidentiality: enable FIPS mode where supported, and verify each product's cryptographic module has an active CMVP certificate: "uses AES" is not the same as FIPS-validated, and assessors check the certificate. Note the SPRS partial credit here: encryption employed everywhere but not FIPS-validated scores a 3-point deduction instead of the full 5, so encrypt everything first, then chase validation. Evidence: a table mapping each CUI encryption use to its CMVP certificate number, plus FIPS-mode configuration screenshots.

Prevent remote activation of cameras and microphones on collaborative devices: configure conferencing tools so meetings cannot auto-answer or activate devices without user action, provide an on-device indicator (built into modern OSes), and cover/disable devices in sensitive areas. Verify Teams/Zoom settings and endpoint privacy controls. Evidence: the collaboration platform settings and endpoint policy for camera/mic permissions.

Control mobile code (browser scripts, macros, plugins): block Office macros from the internet via policy (a top ransomware defense and a same-day GPO/Intune change), restrict browser extensions to an allowlist, and keep Java/legacy plugin runtimes off endpoints that do not need them. Evidence: the macro-blocking policy export and browser extension management configuration.

Control VoIP usage: put phones on their own VLAN, change default credentials on the PBX and handsets, encrypt call signaling/media where the platform supports it (Teams/cloud VoIP handles this natively), and patch the phone system with the rest of your infrastructure. If you have no on-prem VoIP, document that cloud telephony is in use and how it is secured. Evidence: VoIP VLAN configuration, platform security settings, and the patch record.

Protect the authenticity of communications sessions so parties cannot be impersonated mid-session: enforce current TLS with valid certificates on internal and external services, use IPsec/modern VPN protocols, and disable protocol versions vulnerable to session hijacking (SSLv3, TLS 1.0/1.1). Run an SSL configuration scan to find weak endpoints. Evidence: TLS scan results and certificate inventory showing valid, trusted certificates on services.

Encrypt CUI at rest: full-disk encryption on endpoints (BitLocker/FileVault), encryption on servers and NAS volumes holding CUI, and confirmed encryption-at-rest for cloud storage (default in GCC High/major clouds: capture the documentation). Sweep for CUI on unencrypted legacy storage and migrate it. Evidence: encryption status reports across endpoints and servers, plus the cloud provider's encryption documentation for your tenant.

Identify, report, and correct flaws on a defined timeline: subscribe to vendor and CISA advisories for your stack, run the monthly patch cycle across OS, applications, and firmware, and track exceptions with compensating controls. Measure patch compliance with your RMM or vulnerability scanner rather than assuming success. Evidence: the patch management policy with timelines, deployment reports, and the exception register.

Deploy malicious code protection at the endpoints and the gateway: a modern EDR/antivirus (Defender for Endpoint, CrowdStrike, SentinelOne) on every workstation and server, plus email attachment/link scanning in your mail platform. Verify coverage: unprotected servers are the usual gap. Evidence: the EDR console showing full device coverage and email protection policy screenshots.

Monitor security alerts and advisories and act on them: designate who watches CISA alerts, vendor bulletins, and your EDR/SIEM notifications; define response actions (emergency patch, config change, threat hunt); and log what was done for significant advisories. A weekly advisory review habit with notes satisfies this at small scale. Evidence: the monitoring responsibility assignment and dated records of advisories reviewed and actions taken.

Ensure malware protection updates automatically: cloud-managed EDR handles definitions continuously, but verify update status in the console and alert on agents that fall behind or go offline. Remediate stale agents as found. Evidence: console reports showing definition/agent currency across the fleet and the stale-agent alert configuration.

Enable both real-time protection and periodic scanning: on-access scanning everywhere, scheduled full or quick scans on a defined cadence, and automatic scanning of removable media and downloaded files on connection/receipt. These are policy toggles in your EDR/AV product. Evidence: the protection policy export showing real-time, scheduled, and removable-media scan settings.

Monitor systems and traffic for attack indicators: enable your firewall's IDS/IPS, alert on suspicious identity events (impossible travel, brute force) via your SIEM or cloud identity protection, and use EDR behavioral detections at both the boundary and endpoints. A managed detection and response (MDR) service is a cost-effective way for small teams to get 24/7 coverage. Evidence: enabled detection rules, sample alerts with triage notes, and the MDR agreement if used.

Detect unauthorized use of your systems: alert on logons at unusual hours or from unusual locations, new device connections, and unauthorized software execution, using your SIEM, identity protection, and EDR detections; define in writing what "authorized use" means so violations are recognizable. Review these alerts as part of your regular log review. Evidence: the acceptable use definition, configured alert rules, and samples of investigated alerts.