J. Gregory McVerry

That's Not Logical: Segmenation and Security Controls

Sat, 10 Oct 2026 11:22:06 -0400

Everyone looks to CMMC and NIST-SP-800-171 compliance through a lens of finding a technical solution. Buying the perfect tool or adding a pay-to-play enclave.

Systems Security Engineering, however, does not rely on technology alone. Outcomes, not tools, drive compliance. Administrative, procedural, and technical controls all matter in cybersecurity compliance. An organization must understand what a security requirement demands and how an organization demonstrates that it meets that requirement.

Security Requirements

A security requirement establishes an outcome or obligation. A security control achieves that outcome. In CMMC an assessor will check if your controls have the adequacy and sufficiency to meet the 110 NIST-SP-800-171 rev requirements.

For example, a requirement might state that only authorized users may access Controlled Unclassified Information. CUI is information not meant for public release that requires safeguarding or dissemination controls under applicable laws, regulations, or government-wide policies. The requirements does not prescribe a particular product, network architecture, or implementation technology.An organization might satisfy the requirement through access policies, documented workflows, identity and access management technologies, or a combination of all three.

Security Controls

A security control acts a safeguard or countermeasure designed to protect the confidentiality, integrity, or availability of information and information systems.

These three properties form the foundation of information security:

Confidentiality: Preventing unauthorized disclosure of information.

Integrity: Protecting information against unauthorized modification or destruction.

Availability: Ensuring authorized users can access information and systems when needed.

The requirements of NIST-SP-800-171 only demand you have controls to protect the confidentiality of CUI. An organization can utilize three kinds of controls organizations can use to meet cybersecurity requirements: administrative, procedural, and technical controls.

Three Types of Controls

1. Administrative Controls: Establishing the Rules

Administrative controls are management-directed safeguards that establish the organization’s security expectations, authority, responsibilities, and governance. They define who is authorized to do something, under what conditions, and who is responsible for enforcing the rules.

Examples include:

Information classification and handling policies
Acceptable Use Policies (AUPs)
Access authorization policies
Personnel screening and authorization
Security roles and responsibilities
Risk management and governance decisions

Consider an organization handling Controlled Unclassified Information (CUI). The organization establishes a policy stating that CUI may only be processed on specifically authorized company devices and within designated systems. That policy is an administrative control.

It establishes the boundary of authorized behavior, even though the policy itself does not technically prevent someone from violating it.

2. Procedural Controls: Defining How Work Gets Done

Procedural controls are documented or established activities that describe how people implement security requirements in day-to-day operations. A procedure specifies the actions, responsibilities, and sequences necessary to implement an organization’s policies.

Separating Fact and Fiction

Logical separation does not require physical separation, but it does require effective separation.

A single device can be used to access both a commercial environment and a CUI enclave. Administrative controls establish authorized boundaries. Procedural controls direct user behavior. Technical controls provide the enforcement required by the applicable security objectives.

The important question is not whether the organization owns one laptop or two. It is whether the organization can identify, control, and demonstrate the authorized flow of CUI across its defined system boundary.

For example, an organization might establish the following workflow:

Employees receive CUI through an approved secure file-sharing service.
Employees access that information only from authorized devices.
CUI is not downloaded to personal devices.
Employees do not transfer CUI into the organization’s commercial email environment.
Completed work is returned through the approved service.

These procedures create operational separation between CUI activities and ordinary business activities. A procedure is not automatically effective simply because it has been documented. Employees must follow it, and the organization needs appropriate oversight and evidence. Nevertheless, a well-designed and consistently executed procedure can act as an important security control.

3. Technical Controls: Enforcing Rules Through Technology

Technical controls use hardware, software, firmware, or system configurations to implement or enforce security requirements.

Examples include:

Firewalls and network access control lists
Multifactor authentication (MFA)
Endpoint detection and response (EDR)
Encryption
Conditional Access policies
Data loss prevention (DLP)
Virtual local area networks (VLANs)
Application allowlisting

A firewall rule that prevents traffic between two network segments is a technical control.

A Conditional Access policy that prevents an unmanaged device from accessing a CUI repository is another. Technical controls are valuable because they can enforce restrictions automatically, reduce reliance on human behavior, and generate evidence of enforcement.But the existence of a technical solution does not mean every requirement demands that particular solution.

You can not meet administrative requirements with technical controls. If you must identify authorized users, technology can not do that for you. If a requirement needs a technical control you can not meet by writing an administrative policy or a procedural controls

Very few NIST-SP-800-171 rev 2 requirements demand technical controls First, requirements are not products. A cybersecurity requirement establishes an obligation, not necessarily a prescribed technology.

Second, administrative, procedural, and technical controls serve different but complementary purposes. No single category should be dismissed without examining what the requirement actually demands.

Third, logical separation is not synonymous with network segmentation. The appropriate means of separation depends on the system boundary, information flows, required enforcement, and applicable assessment objectives.

Logical Separation

Logical separation segregates information, users, resources, or activities through defined access boundaries without necessarily requiring physical separation. Physical separation relies on physically distinct equipment, facilities, or infrastructure.

Logical separation can involve technical mechanisms such as access control permissions, network segmentation, and isolated virtual environments. It can also involve administrative restrictions and operational procedures that limit which people, systems, and workflows are authorized to interact with particular information.

A policy that declares two systems separate does not equal as a mechanism that prevents those systems from communicating. Whether administrative and procedural controls provide sufficient coverage depends on the actual wording of the requirement, the threats being addressed, and the effectiveness of the controls.

Logical Separation on a Single Device: One Laptop, Two Security Environments

A defense contractor does not need two laptops to separate its commercial business environment from its Controlled Unclassified Information (CUI) environment. A single laptop can access both environments while maintaining meaningful logical separation through a combination of administrative, procedural, and technical controls.

Many small companies may have:

Commercial environment: Microsoft 365 Commercial for ordinary business activities, including email, accounting, scheduling, and Federal Contract Information (FCI).
CUI enclave: A FedRAMP-authorized cloud environment, such as an appropriately configured Kiteworks repository or Microsoft 365 GCC High, used to store, process, and exchange CUI.
Endpoint: A single company-managed Windows 11 laptop authorized to access both environments.

An enclave builds a collection of system components operating within an established security boundary and subject to a specified set of security controls. A security boundary identifies the systems, components, interfaces, and information flows subject to a particular set of security requirements. The laptop is a shared access point between the environments. The challenge is preventing CUI from crossing into the commercial environment through unauthorized information flows.

Administrative controls: Define what the laptop is authorized to do .

The organization establishes a written policy defining two permitted operating contexts. The Acceptable Use Policy prohibits transferring CUI into commercial email, OneDrive, SharePoint, Teams, or other unauthorized applications. The System Security Plan identifies the laptop as a component within the CUI assessment boundary and describes its connections to both environments.

The administrative designation does not create a technical security boundary by itself. It establishes which activities the organization authorizes and provides the governance necessary to assess whether the implementation is appropriate.

Procedural controls: Separate the workflows

Next, the organization establishes distinct procedures for working in each environment. In the commercial workflow, the employee uses Microsoft 365 Commercial for routine business activities. The employee does not open, upload, attach, or synchronize CUI through those applications. Outlook for Web Access gets used for Commercial work, and Outlook for CUI work. The Commercial environment can only get accessed through Mozilla’s Firefox and the CUI environment in Microsoft Edge.

The organization can establish additional procedures requiring the employee to close commercial applications before beginning CUI work, verify the correct account and destination before transferring files, and report suspected accidental disclosures.

Technical controls: Enforce the separation

Technical controls strengthen the administrative and procedural restrictions by limiting what can actually happen on the laptop.

Possible safeguards include:

Endpoint management: Intune enforces device compliance, encryption, security configuration, and application restrictions.
Identity separation: Different identities, sessions, or browser profiles distinguish commercial and CUI access. Separate profiles help avoid mistakes but do not provide strong OS-level isolation.
Conditional Access: Entra policies restrict access to approved identities and compliant devices.
Data loss prevention: Endpoint and cloud DLP policies restrict unauthorized CUI movement where supported and properly configured.
Application controls: Approved applications and browser restrictions reduce opportunities for unauthorized copying or synchronization.
Remote processing: CUI remains within an appropriately secured remote application, virtual desktop, or browser-isolated environment, rather than being downloaded to the general-purpose laptop.

A VDI can provide especially strong separation, provided the architecture prevents unauthorized clipboard use, downloads, printing, drive redirection, and other data-transfer paths. A single physical laptop can therefore serve as the access device for two logically separated computing environments.

Fort Knox? No Kids? Physical Protection and the Home Headquarters

Sat, 03 Oct 2026 12:08:09 -0400

When a solopreneur reads NIST-SP-800-171 physical security controls you feel like folks protect Fort Knox.

Security badges, guards, cameras. You do not have any of those. You run a small company from home. You have one laptop, a cloud service provider, and a household full of devices that have nothing to do with your government contract.

Before buying cameras, badge readers, and burning tokens writing pages of policy and procedure. Think about the data. Where does CUI live? Who can reach it? Which physical safeguards do you operate, and which safeguards can you inherit? If you can keep your data encrypted end to end you can keep your physical security boundary small?

A small boundary will keep much of your home and household technology outside the CMMC assessment scope. By utilizing a hardened laptop, say Windows 11 with Bitlocker and FIPS encryption and then having encrypted data traveling Transport Layer Security (TLS), what you call the Internet, and then landing in a FedRAMP Authorized Cloud you can leave much of, technically all, your house out of scope.

Physical Security and the Home Business

You do not automatically remove every physical security responsibility at home by moving to a fully remote company. Under the CMMC Assessment Process, outside NIST-SP-800-171a objectives, the address of your CAGE code determines the Headquarters. When scoping a CMMC assessment environment you include the spaces that store, processes, and transmits CUI. Fully remote companies can define their boundaries at the endpoint but a solopreneur may end up with a home office in scope. It again, depends on the data flow.

The Physical Security Family has six requirements. Across these your controls must address 16 assessment objectives. For many small businesses you may bring this home office on scope. Maybe you have a file cabinet for business records or get mail. Some of this physical media, while not controlled, could involve information about your federal contracts. Regardless, if your physical office comes into scope you do not have to bring your network, and thus physical protection of those devices in scope. You can

Boundary at the Device

For many work from home companies you have a fully remote environment. No physical devices outside a laptop and the company not does not allow the creation or possession of physical CUI.

The laptop enforces the security boundary. For this example, its configuration includes a host firewall, restricted local network communications, full-disk encryption, endpoint protection, automatic screen locking, and controlled administrative access. The cloud service controls access at the other end.

This means you inherit almost all physical security controls from your CSP, or cloud service provider. Your laptop does not need a visitors' log. Your children do not need to sign in and out if they come in the office when you are not working. The Cloud Service Provider protects the physical security of where your data lives. You protect the physical security of your device.

TLS protects information as it travels between your device boundary and the CSP. The household Wi-Fi, router, and internet connection carry the encrypted traffic. They do not terminate the TLS session or receive readable copies of the files. Thus you can keep your home network out of scope as your CUI travels encrypted end to end.

Boundary at the Home Office

You may find benefits to scoping your home office and defining the boundary at a locked door rather than the device. This would allow you to store physical and digital media about your federal contracts that isn’t for public release. You might have business records outside the purview of the Government work you want to lock up. Bringing the home office in scope does not greatly increase your physical security requirements.

Just describe how you lock or shut the door during operations. Identify how you lock up the device when not in use. You still do not need visitor logs for the family, and will meet the requirements by inheriting controls from your CSP.

Network Equipment in Scope

Even though you can keep your home network out of scope for a CMMC assessment, you should still use segmentation as a home office. You do not want your IOT listening speakers on the same network. You do not need to share resources with your kid’s compromised Roblox cryptominer box.

Given that you may use a gateway and a managed switch to create some distance between work and home, you may find benefits to bringing this network equipment in scope. You can meet many controls with your firewall rules. Most modern Gateways, routers, and switches collect important monitoring data.

If you do bring these network devices in scope you must document their physical protection. In a home office a locked door should suffice, but some may go a step further and throw the gear in a locked closet. You could order a small rack or locked cage. Probably unnecessary, but for under hundred bucks, securing the devices can appease an over zealous assessor. Sometimes we find it cheaper when tools come with an SAT: stupid assessor tax. Just risk management.

Server in Scope

Some companies may have a server in scope at a home office. This changes the defined boundaries around your controlled environment. The protected area must now include the the server and its supporting infrastructure. Limit authorized access, protect and monitor the area, escort visitors, keep physical access records, and control keys or other access devices. NIST allows different implementation methods, including written access logs. Select methods appropriate to your actual environment. You may still exclude the rest of the house and household network through effective separation. But the room, equipment, and safeguards that support the server now form part of the implementation you must explain and demonstrate.

Consider the electrician, internet installer, cleaner, and repair technician. Explain who authorizes their entry, who supervises them, and where the access record lives. You can probably use an agent built into your CSP to convert calendar entries into a visitor log. Or just make a new calendar in Google to be your visitor log. It will so rarely happen.

You will need to extend the procedure to backup drives and failed disks. A copy of your backups should remain offsite and out of the cloud. Your physical security plan if you use hard off-site back ups must describe how and where these get protected. A drive awaiting replacement can still contain CUI. Physical protection and media protection continue while you store, move, repair, or dispose of equipment.

You may have to expect a CMMC assessor doing a site visit. Running network architecture is a vastly different scope than a fully remote business. If the home office contains a CUI server, printer, or stored paper records you need to document the physical boundaries of a controlled area and maintain access-record process covering the equipment and media.

Facility Clearance License

Many small organizations working from home, often those with network infrastructure in the house and doing Defense work, may have a Facility Clearance License or FCL. This means the contract they work on may require a Security Clearance.

As part of the process you document the physical security of your facility. For a fully remote company, or those with network infrastructure at a home address, this is the same physical footprint for the controlled environment. They may code low, and push high. This often means storing moderate. Use the same plan. An FCL can be contract driven, but that does not invalidate the physical security plan developed. Don’t redo work. If you have to maintain network segmentation to ensure environments do not co-mingle your physical security will already pass a moderate baseline. I would encourage a discussion with your C3PAO. If the physical security of your controlled environment is monitored by a designated FSO and no major changes in footprint have occurred, then maybe a video walkthrough should suffice?

Visitor Logs

Situation	Recommended handling
Family or guests remain outside the protected work area	No business visitor-log entry because family entered the residence. Keep CUI and company equipment inaccessible to them.
A repair technician or other visitor enters the protected office	Record the visit, supervise the person, and secure CUI before entry. Locking the screen or shutting down the computer does not remove the need to control physical access to equipment.
The business prohibits visitors from entering the protected area	Document and enforce that restriction. Do not fabricate entries when no visits occur. Explain how you maintain the physical-access records applicable to that boundary.
The home office contains a CUI server, printer, or stored paper records	Establish a more formal controlled area and access-record process covering the equipment and media.

Maintain Audit Logs

Verbs matter. In 3.10.4 you “Maintain Audit logs.” “Maintain” is your task. “Audit” is an adjective describing the logs. NIST-SP-800-171 rev 2 gives you leeway in defining audit logs. NIST-SP-800-171 rev 2 organization defined parameters set by the Department of Defense require a 45 day review period of physical access logs.

To maintain audit logs you can list any additional home security you provide for the family available areas such as alarm door bells or commercial video cameras. Every 45 days you can check off if these are still active. Ring doorbell still working? Check. You now maintain audit logs.

If you do need someone, say doing remodeling, to access the environment you can document alternative worksite procedures to remove CUI, or create an entry in your paper audit records: “Plumber needed access on May 6, 2025 all devices containing CUI were removed until pipes unclogged.”

If you have a server in your house or basement, your visitor logs, even if still paper should be more complete. A combination of Date ,visitor name/company, purpose,area accessed,arrival/departure,escort, and exceptions.

If you use an IT company to help support your environment like wiring your house, helping you with the server set up, you can issue permanent physical access authorization credentials but still log access. Just means you do not have to escort them in the basements to the entire time.

Going for the Gold

Turn on MFA, do not give daily driver accounts admin rights. That’s the best way to protect CUI and your business, but you still need to do address your physical security.

Keep it small and take the win.

Can CMMC Save Us from Artificial Intelligence Killing Us All?

Sat, 12 Sep 2026 11:08:15 -0400

Did you just finish doomscrolling to learn how state based actors and criminal actors use AI to “hack” everything? What if I told you some common sense controls may have prevented almost every attack highlighted in the September 2026 threat intelligence report by Anthropic?

An attacker should not gain access to your company’s engineering knowledge simply because an employee connects a laptop to hotel Wi-Fi or loses control of an email account. Those events should meet several barriers before they become a business-threatening loss.

AI did not hack these devices. Stupidity, and good intentions allowed the exfiltration. You do not travel with sensitive IP to a hotel, and you do not connect a device containing sensitive IP or Controlled Unclassified Information to public wifi. Ever.

While NIST-SP-800-171 only protects the confidentiality of CUI, you can use the requirements to protect your sensitive intellectual property. Furthermore, many of the controls you design for 171 will have a halo effect on availability and integrity.

NIST-SP 800-171 has practical value. Its requirements give organizations a foundation for controlling information, restricting access, hardening devices, and responding when something goes wrong. Applied well, those safeguards can prevent some attack steps and limit the damage from others.

In its September 2026 threat intelligence report, Anthropic describes AI-assisted cyber operations involving stolen credentials, exposed API keys, vulnerable services, malicious downloads, and bulk data theft. In one espionage case, attackers compromised hospitality vendors, changed DNS records, and used hotel Wi-Fi redirection to deliver malicious lures. They also stole drone manufacturers’ mailboxes and a proprietary vision-system software development kit. Other cases involved exposed secrets and compromised software providers that opened paths into customer environments. AI helped attackers automate and accelerate their work.

Every single one of these attacks probably would have been prevented with a cybersecurity program that met NIST-SP-800-171 requirements, and Artificial Intelligence had nothing to do with it. Just like everyone else, bad guys are just accelerating manual tasks with large language models. If you make it easy to get popped. You will get popped. That’s the whole assume breach thing.

Now we only have access to reported observations. Nobody performed controlled pentests of NIST implementations. We cannot calculate how many incidents 171 would have prevented. We can identify specific opportunities to interrupt cyberattacks described in the report and explain how theoretically a system compliant with 171 requirements may have prevented or reduced the impact of an incident.

These attacks were caused by stupidity, probably more the rush to GSD, not frontier models.

Control Information Worth Stealing

Before selecting another security product, ask where your sensitive information lives. Can someone find the entire product design in ordinary email attachments? Does every engineer have access to every project? Can an account export a complete repository without additional restrictions? Do employees synchronize sensitive files onto every device they use?

For a small manufacturer, like the drone makers in Ukraine, I would begin with a simple information map: what needs protection, who needs it, which systems may hold it, and where it may travel. That map should drive the permissions and technical restrictions.

(It never gets to travel to a hotel without authorization, and if so the device can NEVER connect to public wifi)

Relevant Rev. 2 requirements include:

3.1.1 and 3.1.2 Restrict access to authorized identities and permitted functions.
3.1.3 Enforce authorized flows of CUI.
3.1.5 Apply least privilege.
3.13.16 Protect CUI at rest.
3.1.19 Encrypt CUI on mobile devices and computing platforms.

Keep sensitive engineering files in an approved, restricted repository and use authenticated sharing links. Keep data out of email. It would limit exports, restrict external sharing, and use data-loss prevention where the available technology supports the required restrictions. A project engineer would receive access to the projects they support. Routine email access would not automatically confer access to the complete design library.

A sharing link only helps if the repository independently enforces access. Anonymous links or broad permissions can recreate the same exposure. Likewise, encryption at rest does not prevent an attacker from reading files through a compromised, authorized session.

That being said, most of the token theft i saw this year involved spoof sharing links. Either to a fake help desk or to a document. If the link makes it through, people will click.

Make public Wi-Fi an Authorization Decision

Many cybersecurity experts bemoan the calls to stay off Public wifi, but attack after attack such as “Dark Hotel” demonstrates that public wifi connections can breach your devices.

The Anthropic report raises a straightforward question: why should a device used for sensitive work connect to a network that the company has not approved?

Under NIST-SP-800-171 this would not happen. 3.1.16 addresses wireless authorization, 3.1.17 addresses wireless authentication and encryption, and 3.1.20 addresses external-system connections and use. Rev. 2 does not impose a universal public-Wi-Fi ban. A company can adopt that restriction as part of its implementation.

If your computer holds the spec to your drone vision system, do not allow public wifi. Large language models had nothing to do with the exfiltration. It was caused by shitty data protection policies.

For a small defense supplier whose employees travel with access to sensitive designs, I would recommend prohibiting hotel, airport, and café Wi-Fi on those work devices. Provide an approved cellular connection, disable automatic connections to unknown networks, and enforce restrictions through device configuration. Where an exception is necessary, define who approves it and what protections must operate before work begins.

The enforcement details matter. An approved network name alone does not prove that an access point is authentic. Test whether employees can add another network, override the restriction, or connect before management controls apply.

Avoiding hotel Wi-Fi removes that particular exposure for a traveler who follows the rule. It does not protect a vendor’s infrastructure or prevent a phishing message delivered over cellular service. The organization still needs endpoint and identity protections.

If you do travel with a device do a factory reset when you get home, before connecting to your house or office network. If you travel in high risk countries bring a burner device and leave it or wipe it before returning home.

Protect the Session as Well as the Password

Anthropic also describes device-code phishing and token theft. Those techniques make “we have MFA” an incomplete answer: the attacker may obtain usable access through a legitimate authentication process rather than simply guess a password. These attacks grab tokens after MFA.

3.5.3 requires MFA for the specified account access, while 3.13.15 addresses communications-session authenticity.

I would implement phishing-resistant MFA where supported, restrict device enrollment, review application permissions, and require approved devices for sensitive access where the service supports that enforcement. Those measures address different opportunities for account abuse; none makes an already compromised device trustworthy.

If you use phishing-resistant MFA on managed devices, you stop all AITM token thefts. The AI did nothing special. These attacks could be prevented. These attacks work because the token gets intercepted after the MFA claim.

Device-code phishing deserves a specific decision. Microsoft recommends blocking device-code flow as broadly as possible and retaining only documented, secured exceptions. Organizations can first audit usage and test the restriction before enforcing it. Access control needs to drive your configuration.

A password reset also needs a response procedure around it. Investigators should examine active sessions, application grants, newly enrolled devices, and other persistence mechanisms instead of assuming that a new password ends the intrusion.

Stop the RMM Hacks

A user who encounters a fake troubleshooting page should have two opportunities to stop: recognize the deception, then encounter a technical restriction if they attempt to follow it.

NIST-SP-800-171 requirements for 3.2.1–3.2.2 for awareness and training, 3.4.7 for restricting nonessential functionality, 3.4.8 for software execution policy, and 3.4.9 for user-installed software could all prevent Remote management hacks.

According to Huntress RMM attacks grow in frequency. For this threat, training should use concrete examples: a Wi-Fi portal asking someone to paste a command, a document viewer demanding a security change, or an unexpected update requesting software installation. Give employees a clear action: stop, close the page, and contact the designated support person through a known channel.

My technical preference would be application allowlisting, denying non-essential functions so you have restrictions on unnecessary script interpreters, and separate administrative accounts. Rev. 2 permits different execution-policy approaches. Use allowlisting and deny by default. Test the policy against misuse of approved tools as well as unknown executables. An attacker may use an existing interpreter, and malware may run with ordinary user permissions.

A company gains more protection when training and configuration support each other. Employees should not need administrator rights to complete routine work, and a fake repair should not gain those rights simply by asking.

Close Exposed Services and Protect Secrets

Under 3.11.2–3.11.3 you need to address vulnerability scanning and remediation. 3.14.1 requires a company to addresses timely flaw correction. 3.4.6–3.4.7 supports reducing unnecessary functionality

For implementation, inventory internet-facing services and assign someone to act on relevant advisories. All external connections get identified under NIST-SP-800-171. Include network appliances and externally hosted applications in the review. Relying on Defender or another endpoint scanning agent cannot establish the condition of every service your business uses. Verify remediation, and restrict or remove an exposed service when a timely fix is unavailable.

Treat API keys and service credentials as access to production systems. My recommended safeguards include secret scanning before publication, managed secret storage, narrowly scoped credentials, and prompt revocation after exposure. Removing a secret from the latest version of a repository does not invalidate copies that someone already obtained.

Apply the same discipline to company AI integrations. Give an assistant only the information, tools, and permissions its task needs. Keep production secrets out of environments that do not need them. NIST’s general access-control principles help constrain the consequences of misuse, but implementing Rev. 2 does not by itself solve prompt injection or every AI-specific vulnerability.

Limit What a Compromised Provider Can Reach

A supplier relationship should have an explicit access boundary. For every integration, ask which accounts, files, mailboxes, and administrative functions the provider can reach. Decide how to revoke that access and who can do it during an incident.

When 3.1.5 and 3.1.20 exist as live controls you have documented the external connections and boundaries in the system security plan under 3.12.4. As authorization moves further towards identity these boundaries get defined by responsibilities and roles. You identify where the boundaries get enforced. Restrict the flow, encrypt the good, protect the keys.

Detect Theft and Rehearse Containment

Prevention can fail. The business needs a way to recognize suspicious access before an attacker finishes collecting everything the account can reach.

3.3.1, 3.3.3, and 3.3.5 support audit records, review, and correlation. 3.14.6–3.14.7 address attack monitoring and unauthorized use. 3.6.1–3.6.2 address incident handling, tracking, and reporting. CMMC Level 2 Assessment Guide

I would prioritize alerts for unusual mailbox access, bulk repository downloads, unexpected forwarding, new application grants, and unapproved device enrollment. Include changes that disable security tools or interrupt updates. Assign each alert an owner and a response expectation appropriate to the risk. All of the attacks Anthropic noted should have gotten flagged. None of the methods relied on novelty.

Then rehearse a scenario: an employee reports a suspicious hotel login page, and monitoring shows unusual cloud access. Can the responsible person isolate the device, revoke access, investigate affected information, and coordinate with the provider? Can they do it after hours? Logging becomes useful protection when someone can act on it.

Turn Requirements into Barriers

For a small manufacturer, the first priorities are concrete: control sensitive information, restrict travel connectivity, protect identities, constrain software execution, and prepare to contain a compromised account or device. You create controls that meet the 171 requirements. These boundaries create barriers for attackers.

An assessment result cannot establish that every attack will fail. Effective implementation can remove easy entry points, reduce what one compromised identity exposes, and give defenders a chance to interrupt theft. The value of NIST SP 800-171 appears in those operational decisions especially when the attacker works faster than the company can afford to respond manually.

That is all AI, and Large Language Models did. They took advantage of poorly designed systems. All of this, with some security engineer could be prevented.

Image credit: “Attack!” flickr photo by Masked Builder flickr.com/photos/ma… shared under a Creative Commons (BY 2.0) license

One Person, Many Roles: Building a NIST SP 800-171 Rev. 3 Awareness and Training Program

Wed, 09 Sep 2026 08:49:59 -0400

If you want to survive NIST-SP-800-171 compliance as a solopreneur you need to think small. A one-person company does not need a learning management system. You do not have to film a library of animated phishing videos, or hire a full-time training manager to build a defensible security awareness and training program.

NIST-SP-800-171 rev 3 created a philosophical shift in terminology. Instead of awareness and training we now focus on security literacy and awareness. Not much needs to change around your awareness and training program beyond explicit requirements to offer training after an incident.

How does a one person shop do this?

All you need to do is create a defensible and repeatable process.

Solopreneur often serves as the company president. You spend hours as the system owner, and respond to surveys as security officer. Other times you work as system administrator, and yet your company has only one authorized CUI user. NIST SP 800-171 Rev. 3 does not erase those responsibilities just because one person fills every role. The owner still needs general security literacy training as a system user and role-based training for the administrative and security duties that the owner performs. Basically you complete different training based on the hat you currently wear.

The most practical approach uses one short annual training package, a few event-driven refreshers, and one reliable completion record. The System Security Plan (SSP) can contain the entire procedure. This eliminates the need for a separate Awareness and Training Plan or SOP.

If you have a Facility Clearance License your existing training program will meet the requirements. You have to have an insider threat program and a risk assessment. Just supplement your existing training with the Mandatory DoD CUI training and you are done.

What Rev. 3 Actually Requires

The Awareness and Training family contains two active requirements:

03.02.01, Literacy Training and Awareness, requires security literacy training during initial training, at an organization-defined frequency, after defined events or system changes, and on recognizing and reporting insider threats, social engineering, and social mining. The organization must also define when it reviews and updates the training content.
03.02.02, Role-Based Training, requires training before a person receives access to the system or CUI, before the person performs assigned security duties, at an organization-defined frequency thereafter, and after defined events or system changes. The organization must also define when it updates the role-based content.

Those two requirements contain eight organization-defined parameters. A compliant program must choose the recurring frequency and triggering events for each type of training and for each content review. “As needed” does not make a strong definition. “Annually and within 30 days after a listed triggering event” gives the owner and an assessor something concrete to evaluate.

NIST also expects the training to match the organization, the systems, and the work environment. A solopreneur should not take a generic phishing course and call the family complete. The program must also teach the owner how the company actually protects CUI on its one-laptop system.

Wear Both Hats During the Same Training Session

A one-person company can combine security literacy and role-based training into one annual session, but it should label and document the two modules separately.

The security literacy module should cover the duties that apply to the owner as a user. Topics should include:

identifying CUI and reading its markings and dissemination controls;
using only the authorized device, accounts, applications, and storage locations for CUI;
protecting credentials and using multifactor authentication;
recognizing phishing, impersonation, pretexting, baiting, thread hijacking, and other social-engineering techniques;
recognizing social mining, including attempts to gather useful details from websites, social media, proposals, job postings, conversations, and professional networking;
recognizing insider-threat indicators, including the possibility that the owner’s own stress, convenience, or work habits can create risk;
handling, transmitting, storing, and destroying CUI according to the SSP;
responding to a suspected incident, lost device, misdirected message, or accidental disclosure; and
reporting the event through the company’s defined channel.

The last item can feel strange when the only employee would report a concern to themself. The SSP should still name an external escalation path. Depending on the company’s contracts and support model, that path may include an MSP, security consultant, prime contractor, contracting contact, or federal reporting channel. The owner should not invent the reporting path during an incident.

The role-based module should cover the duties that apply to the same person as system owner, administrator, and security officer. Topics should include:

using a standard account for daily work and a separate privileged account for administration;
reviewing alerts, logs, vulnerabilities, and security-tool status;
approving and documenting system changes;
installing patches and addressing vulnerabilities within the company’s defined timeframes;
managing accounts, licenses, devices, and external service providers;
protecting backups and testing recovery;
executing the incident-response and reporting procedures;
reviewing the SSP, risk assessment, and Plan of Action and Milestones; and
understanding which responsibilities the company retains when an MSP or cloud provider performs part of the work.

One course can cover both modules in 60 to 90 minutes. The owner should complete a short knowledge check and review every incorrect response. The goal does not involve proving that the owner watched a video. The goal involves showing that the owner understands the company’s rules and can act on them.

Your role based training should also get impacted by your solution. If you use GCCH, Preveil, or Kiteworks, speak to doing an annual training or refresher course. You want to know how to use the tools you chose.

Your risk assessment should also drive the content you choose. You need to train against the risks to the confidentiality of CUI that you identified. These can often get covered by free trainings available to the government. Just make the connection between your risk assessment and your training program explicit in your System Security Plan.

Put the Whole Procedure in the SSP

Rev. 3 makes this consolidation possible. Requirement 03.15.01 allows organizations to document procedures in the SSP instead of maintaining separate procedure documents. A small company can therefore place the policy, frequencies, triggers, training topics, completion criteria, responsibilities, and recordkeeping method directly in the Awareness and Training section of the SSP.

The SSP language, if you define learning components at the requirement could read as follows:

Responsibility and scope. The System Owner serves as the organization’s only system user and also performs the System Administrator, Security Officer, and management roles. The System Owner completes both security literacy and role-based security training.

Initial and recurring training. The System Owner completes security literacy training before receiving access to CUI. The System Owner completes role-based training before performing administrative or security duties. The System Owner repeats both training modules annually during January. The annual training contains a knowledge check. The System Owner must score at least 80 percent and review each incorrect response before recording completion.

Event-driven training. The System Owner completes relevant supplemental training within 30 calendar days after a material change to the CUI system, the adoption of a new security or administrative tool, a change in contractual or legal requirements, an assessment or audit finding related to user behavior or assigned duties, a security incident or near miss, or the identification of a new threat that materially changes the company’s procedures. The System Owner may complete the training sooner when an incident, system change, or contract requires immediate action.

Security literacy content. Training covers CUI identification, approved CUI handling, account and credential protection, multifactor authentication, authorized system use, incident recognition and reporting, insider-threat indicators, social engineering, social mining, and the company’s system-specific user responsibilities.

Role-based content. Training covers the System Owner’s management, system administration, security administration, configuration management, vulnerability management, audit review, incident response, backup, recovery, and external-service-provider oversight duties.

Content review and update. The System Owner reviews both modules annually before completing the annual training. The System Owner also reviews and updates the relevant content within 30 calendar days after any event that triggers supplemental training. The review confirms that the content matches the current SSP, system architecture, contractual requirements, threats, security tools, and reporting paths.

Records. The System Owner records the completion date, training type, content version, topics covered, score, incorrect answers reviewed, supplemental training reason when applicable, and an affirmation of completion. The System Owner stores the record in the designated training-record repository and retains it according to the company’s records-retention policy. Training records do not contain CUI, credentials, incident details, detailed vulnerabilities, or copies of the SSP.

That language creates an executable process. It also answers the questions an assessor will likely ask: Who trains? What training occurs? When does it occur? What triggers additional training? When does the content change? How does the company verify understanding? Where does it keep evidence?

At the objective level you might write:

NIST SP 800-171 Rev. 2 Awareness and Training SSP Statements at the Assessment-Objective Level, Using Rev. 3 ODP-Based Frequencies and Events
Requirement	Assessment Objective	SSP Implementation Statement
3.2.1	`3.2.1[a]` Security risks associated with organizational activities involving CUI are identified.	The organization identifies security risks associated with the System Owner’s activities involving CUI in this SSP and in the security literacy training content. Identified risks include improper CUI marking, handling, storage, transmission, or destruction; phishing, impersonation, social engineering, and social mining; credential compromise and fraudulent multifactor-authentication requests; loss or theft of the authorized endpoint; use of unauthorized software, storage, removable media, printing, or external systems; insecure remote-work practices; delayed incident reporting; misuse of privileged access; and failure to oversee external service providers. The System Owner reviews the identified risks annually before the January training session and after each defined event, and updates them within 30 calendar days when the review identifies a change.
3.2.1	`3.2.1[b]` Policies, standards, and procedures related to system security are identified.	This SSP identifies and contains the policies, standards, and procedures that apply to the CUI system, including requirements for authorized system use; CUI marking and handling; identity, authentication, and multifactor authentication; standard and privileged accounts; endpoint security; approved email and file-sharing services; media and printing; remote work; physical protection; incident recognition and reporting; configuration and change management; vulnerability and patch management; audit review; backup and recovery; and external-service-provider oversight. The System Owner reviews these requirements annually before the January training session and after each defined event, and updates the SSP and affected training content when necessary.
3.2.1	`3.2.1[c]` Managers, system administrators, and users are made aware of the security risks associated with their activities.	The System Owner serves as the organization’s manager, system administrator, security officer, and only system user. The System Owner completes initial security literacy training before receiving authorization to access the CUI system or CUI, completes recurring training annually during January, and completes relevant supplemental training within 30 calendar days after each defined event or sooner when immediate action is required. Training addresses the security risks identified under 3.2.1[a] and includes a knowledge check requiring a score of at least 80 percent and review of every incorrect response. The System Owner records the completion date, training type, content version, topics, score, incorrect-answer review, triggering event when applicable, and completion affirmation in the designated training-record repository.
3.2.1	`3.2.1[d]` Managers, system administrators, and users are made aware of applicable policies, standards, and procedures related to system security.	Initial, annual, and event-driven security literacy training makes the System Owner aware of the policies, standards, and procedures identified under 3.2.1[b]. Training explains the actions required to protect CUI, use the system securely, recognize and report suspected incidents, and perform work in accordance with this SSP. The System Owner completes training before initial access, annually during January, and within 30 calendar days after a defined event. The System Owner reviews and updates the content annually and after defined events, and records completion in the designated training-record repository.
3.2.2	`3.2.2[a]` Information-security-related duties, roles, and responsibilities are defined.	This SSP defines the System Owner, management, system administrator, and security officer roles. Defined duties include authorizing and reviewing access; using separate standard and privileged accounts; administering the endpoint, identity service, cloud services, and security tools; approving and documenting changes; reviewing alerts and audit information; managing vulnerabilities and patches; protecting and testing backups; executing incident-response and reporting procedures; reviewing the SSP, risk assessment, and Plan of Action and Milestones; and overseeing external service providers. The System Owner reviews these definitions annually and after each defined event and updates them when responsibilities, systems, services, or requirements change.
3.2.2	`3.2.2[b]` Information-security-related duties, roles, and responsibilities are assigned to designated personnel.	The organization assigns the System Owner, management, system administrator, and security officer roles to the company’s sole owner. The SSP identifies any security functions performed by an external service provider and identifies the System Owner’s retained responsibility for approving, monitoring, and verifying those services. The System Owner reviews role assignments annually and after each defined event. The System Owner documents a new or changed assignment in the SSP before performing the affected duty.
3.2.2	`3.2.2[c]` Personnel are adequately trained to carry out assigned information-security-related duties, roles, and responsibilities.	The System Owner completes role-based security training before receiving authorization to access the CUI system or CUI and before performing assigned management, administrative, or security duties. The System Owner repeats role-based training annually during January and completes supplemental training before performing a newly assigned duty and otherwise within 30 calendar days after a defined event. Training covers privileged-account use, system and security administration, access management, configuration and change management, vulnerability and patch management, audit review, incident response, backup and recovery, CUI handling, and external-service-provider oversight. The training includes an 80-percent knowledge-check threshold and review of incorrect responses. The System Owner records the completion date, training type, assigned role, content version, topics, score, incorrect-answer review, triggering event when applicable, and completion affirmation.
3.2.3	`3.2.3[a]` Potential indicators associated with insider threats are identified.	The organization identifies potential insider-threat indicators in this SSP and in the security literacy training content. Indicators include attempts to obtain access not required for assigned duties; unusual or unexplained access to CUI; unauthorized copying, transmission, printing, or removal of information; attempts to bypass security safeguards; misuse of privileged access; unexplained changes in work patterns; concealment of security-relevant activity; serious policy violations; and personal or workplace conditions that may increase security risk. Because the System Owner is the only employee, the training also addresses how the owner’s own stress, haste, convenience, dissatisfaction, financial pressure, or changing behavior can increase risk. The System Owner reviews these indicators annually and after each defined event and updates them when threat information or organizational circumstances change.
3.2.3	`3.2.3[b]` Security awareness training on recognizing and reporting potential insider-threat indicators is provided to managers and employees.	The System Owner serves as both management and the organization’s only employee. Initial security literacy training teaches the System Owner to recognize the insider-threat indicators identified under 3.2.3[a], document a suspected indicator, preserve relevant evidence, and report the concern through the external security contact and any prime-contractor or federal reporting channel identified in the Incident Response section of this SSP. The System Owner repeats this training annually during January and completes relevant supplemental training within 30 calendar days after a defined event or sooner when immediate action is required. The System Owner records completion in the designated training-record repository and does not investigate suspected insider activity beyond actions authorized by the incident-response procedure.

This table retains the nine NIST SP 800-171 Rev. 2 Awareness and Training assessment objectives. Rev. 2 does not contain the Rev. 3 organization-defined parameters. The recurring frequencies, triggering events, content-review schedule, and completion windows above deliberately apply the more explicit Rev. 3 ODP structure to the Rev. 2 implementation.

How Much Does Training Cost?

Nothing. You can find free trainings available from the government that meet your NIST-SP-800-171 needs.

How to use this table: Select training that matches an assigned security duty. A government course does not, by itself, prove that a person can perform the organization’s actual procedures. Pair each external course with a short review of the applicable SSP procedures, tools, system configuration, and reporting contacts. Retain the course certificate or transcript when one is available and record the internal review and knowledge check in the organization’s designated training record.

Free Federal Training and Training Resources That Can Support Role-Based Security Training
Agency	Free offering	Best-fit role or duty	How to use it	Access and completion evidence
DoD / DCSA CDSE	DoD Mandatory Controlled Unclassified Information (CUI) Training (IF141.16)	CUI user, CUI custodian, system owner, and manager	Use it as the federal CUI foundation, then review the company’s SSP procedures for authorized storage, transmission, marking, destruction, and incident reporting.	Approximately 45 minutes. The public Security Awareness Hub requires no sign-in and produces a certificate, but CDSE does not retain the record. STEPP retains the completion on the learner’s transcript. Save the certificate before closing the public course.
DoD / DCSA CDSE	Introduction to the Risk Management Framework (RMF) (CS124.16)	System owner, security officer, assessor liaison, and person maintaining the SSP or POA&M	Use it to introduce DoD RMF roles and the seven-step process. Follow it with an exercise that identifies the company’s own systems, responsibilities, assessment evidence, and remediation workflow.	Approximately 30 minutes. No clearance or prerequisite is listed. A score of at least 75 percent permits the learner to print a certificate. CDSE states that its courses serve DoD, other U.S. Government personnel, and contractors in the National Industrial Security Program.
DoD / DCSA CDSE	RMF: Prepare Step (CS101.16)	System owner, security lead, and personnel supporting assessment and authorization	Use it for deeper training on organization-level and system-level preparation tasks, outcomes, policies, and role assignments. Add a walkthrough of the company’s current SSP and evidence locations.	Approximately 60 minutes. No clearance or prerequisite is listed. The final exam requires a score of at least 75 percent; STEPP can retain the transcript.
DoD / DCSA CDSE	Insider Threat Awareness (INT101.16)	Manager, security officer, incident-reporting lead, and insider-threat contact	Use the scenarios to teach recognition and reporting of concerning behavior. Add the company’s reporting contacts, evidence-preservation steps, non-retaliation rules, and limits on self-investigation.	Approximately 60 minutes. The final exam requires a score of at least 75 percent and produces a printable certificate. The stated audience is military, civilian, and industry personnel with classified access, so a CUI-only company should document why the reporting concepts remain relevant.
CISA	Cybersecurity for Technical Staff	System administrator, endpoint administrator, cloud administrator, and technical security lead	Use it as broad technical-role development. Add hands-on checks using the company’s actual administrative accounts, security tools, patch process, logging, backup, and approved configuration.	Available through CISA Learning. The learner must create or use an eligible account. Retain the LMS completion record or certificate when offered and record the company-specific practical review separately.
CISA	Incident Response 101	Incident-response coordinator, system administrator, security officer, and management	Use it to establish incident-response concepts, then conduct a short tabletop using the company’s SSP: recognize an event, preserve evidence, isolate the affected asset, notify required parties, and record the incident.	Available through CISA Learning. Retain the completion evidence provided by the learning system and the internal tabletop record.
CISA	Risk Management Framework for Leaders	Owner, executive, system owner, and security-program lead	Use it for management-level risk and governance training. Add a review of accepted risks, open POA&M items, external-service-provider dependencies, and who can approve system changes.	Available through CISA Learning. Check current learner eligibility and retain the available LMS completion evidence.
CISA	Cloud Security: What Leaders Need to Know	System owner, cloud-service owner, contracting lead, and external-service-provider manager	Use it to support decisions about cloud risk and shared responsibility. Add the company’s approved services, CUI data flows, responsibility matrix, authorization requirements, and provider-monitoring procedures.	Available through CISA Learning. Retain the available LMS record and document the company-specific shared-responsibility review.
CISA	Industrial Control Systems Virtual Learning Portal	Operational-technology or manufacturing-system administrator, operator, engineer, and incident responder	Use only when the CUI environment includes operational technology or industrial control systems. Select modules that match the person’s duties, then review the organization’s own segmentation, remote-access, change-control, and incident procedures.	CISA offers virtual ICS training, but enrollment and individual-course availability can vary. Retain the completion evidence supplied for the selected course and record the internal system-specific review.
FBI	InfraGard webinars and workshops	Security officer, incident liaison, threat-intelligence contact, and critical-infrastructure owner or operator	Use sessions on current threats, incident coordination, or an applicable critical-infrastructure sector as supplemental training. Record the session title, date, topics, and how the content changes or confirms the company’s procedures.	Membership is free but restricted. Applicants generally must have a connection to critical infrastructure, be U.S. citizens, verify their identity, and pass an FBI security-risk assessment. Programs vary by chapter and may not always issue a certificate; retain registration or attendance evidence and an internal knowledge check.
FBI	FBI Virtual Academy for Law Enforcement	Law-enforcement, criminal-justice, intelligence, or military personnel with an applicable cyber-investigation or digital-evidence duty	Use a cyber or digital-evidence course only when it directly matches an assigned duty. This option is normally irrelevant to a commercial CUI contractor that has no law-enforcement or criminal-justice role.	The FBI states that thousands of topics are available at no cost, but the platform serves the criminal-justice community. Access is restricted through registration and applicable eligibility; retain the platform’s completion evidence.
NSA	Cybersecurity Speaker Series: Defense Industrial Base	Owner, security lead, supplier-risk lead, and DIB incident or threat contact	Use the public video as a short DIB-threat module. Pair it with an internal knowledge check and a review of the organization’s threat-information, incident-reporting, and external-coordination procedures.	Publicly available without a course enrollment. NSA does not present the video as a certificate-bearing course, so the organization must record the assigned viewing, source and version, completion, and knowledge-check result.
NSA	Cybersecurity Advisories and Technical Guidance	System administrator, cloud administrator, secure-configuration owner, developer, and vulnerability-management lead	Build a focused internal module from the NSA guidance that applies to the technology being administered. Require the learner to identify which recommendations apply, demonstrate or document the resulting configuration, and explain any exceptions.	Public and free, but this is technical source material rather than a standardized course. Record the document title and date, assigned sections, practical exercise, result, and reviewer approval.

Compliance caution: General awareness training does not satisfy role-based training by itself. For NIST SP 800-171 Rev. 2 requirement 3.2.2, the organization should be able to show that training matches each person’s assigned information-security duties. For Rev. 3 requirement 03.02.02, the organization should also apply its defined initial, recurring, and event-driven training frequencies. The NSA entries above are free public training materials rather than certificate-bearing courses; the organization must turn them into documented internal modules. Agency offerings, titles, access rules, and certificates can change; verify the linked page when assigning a course.

You also do not need to pay for an LMS or a system of record. As a one person shop you could create a “Tiny LMS” using Microsoft/Google forms or create a ChatGPT/Claude agent to help you track your requirements.

System One: Use Microsoft Forms as a Tiny LMS

Microsoft Forms offers the simplest option for a one-person company that already uses Microsoft 365. The owner can create one quiz with two sections: “Security Literacy” and “Role-Based Security.” The quiz should identify the training version and include a few scenario-based questions for each module.

The final section should collect or record:

the owner’s identity;
the completion date;
the training version;
whether the submission covers annual, initial, or event-driven training;
the event that triggered supplemental training, if applicable;
the quiz score;
confirmation that the owner reviewed incorrect answers; and
an affirmation that the owner understands and will follow the SSP procedures.

Require sign-in, restrict responses to the company account, and do not allow anonymous submissions. After each completion, open the Responses tab and save the results to Excel. Microsoft Forms can maintain the response workbook in OneDrive or SharePoint, and Microsoft also supports exporting the workbook or saving it as a PDF. Store that workbook in the training-record location named in the SSP.

The owner should keep the training content outside the form or attach only content that contains no CUI and no sensitive system details. The quiz can ask, “Where may you store CUI?” without including a real CUI filename, contract number, vulnerability, credential, network diagram, or incident narrative. If the company uses a commercial Microsoft 365 tenant outside the CUI boundary, this separation becomes especially important.

Maintenance takes little time. Once each year, the owner reviews the SSP and quiz, updates the version number, completes the quiz, and confirms that the response appears in the workbook. After a triggering event, the owner updates only the affected questions or adds a short supplemental section.

System Two: Use ChatGPT or Claude as the Training Clerk

An AI assistant can manage the calendar and the clerical work, but it should not become the only place where evidence lives. ChatGPT supports scheduled tasks, and Claude Cowork supports recurring scheduled tasks on paid plans. Either tool can remind the owner to conduct training, guide the knowledge check, prepare a completion record, and place or help place the record in a designated repository.

A reusable instruction could read:

Act as the training coordinator for my one-person company. Remind me each January to complete the annual NIST SP 800-171 Rev. 3 security literacy and role-based training described in my SSP. Continue reminding me until I confirm completion. During the session, cover CUI handling, insider-threat indicators, social engineering, social mining, incident reporting, standard and privileged account use, security administration, configuration changes, vulnerability management, log review, backup and recovery, and external-provider oversight. Give me a ten-question knowledge check. Require an 80 percent score and review every incorrect answer with me. After I finish, create a completion record that contains the date, training type, content version, topics, score, incorrect answers reviewed, and my completion affirmation. Save the record in the approved Training Records folder if you have access. If you cannot save it there, create a downloadable record and remind me to place it in that folder. Do not include CUI, credentials, contract details, detailed vulnerabilities, incident details, or SSP contents in the task, chat, quiz, or record.

The owner should create a second recurring reminder to review the training content before the annual session. The reminder should ask whether the system, tools, threats, contracts, laws, reporting paths, or SSP procedures changed during the year. If the answer is yes, the owner updates the module version before completing the course.

The owner should also return to the assistant after any triggering event and state, “Start the event-driven training workflow.” The assistant can then ask which trigger occurred, select the affected topics, administer a short refresher, and generate a supplemental completion record.

AI creates two risks that the SSP should address. First, the owner must verify the accuracy of AI-generated training content against the SSP and authoritative sources. Second, the owner must not paste CUI, credentials, incident evidence, detailed system configurations, or nonpublic vulnerabilities into an AI service unless the organization has authorized and scoped that service for the data. The assistant runs the workflow; the SSP governs it.

Keep Four Things, Not Forty

NIST SP 800-171 Rev. 3 does not carry the NIST SP 800-53 AT-04 Training Records control into the CUI baseline as a separate requirement. However, NIST SP 800-171A Rev. 3 lists training records among the potential objects that an assessor may examine for both 03.02.01 and 03.02.02. Keeping no evidence would make the program difficult to defend.

A solopreneur can build a reasonable evidence package with only four items:

The current SSP, including the complete Awareness and Training procedure and all eight organization-defined parameters.
The current version of the training content or quiz.
The dated Microsoft Forms response, AI-generated completion record, or course certificate that proves completion.
A dated content-review entry, which can appear in the same training record.

The company may keep older training versions and records according to its documented retention policy. It does not need to produce extra meeting minutes, attendance rosters, sign-in sheets, training plans, or standalone SOPs for a meeting attended by one person.

During an assessment, the SSP and current training material support the examine method. The owner supports the interview method by explaining the rules and demonstrating how to report a concern. Microsoft Forms or the scheduled AI workflow supports the test method by showing that the reminder, quiz, and recordkeeping process works. NIST SP 800-171A emphasizes evidence sufficiency and does not require every potential assessment object listed in the publication.

Small Does Not Mean Informal

A one-person company can keep its Awareness and Training program small because its workforce and system remain small. It cannot keep the program vague.

Define the frequencies. Define the triggers. Teach both the user role and the privileged roles. Test understanding. Keep one reliable record. Write the entire procedure in the SSP and follow it.

That approach does more than reduce paperwork. It turns annual training from a compliance performance into a short operational check: Do I still understand how my system protects CUI, and can I respond correctly when something goes wrong?

Sources

“SkillsUSA Event at Camp Withycombe” flickr photo by Oregon National Guard https://flickr.com/photos/oregonmildep/52802793150 shared under a Creative Commons (BY 2.0) license

There Can Only Be Two: The Single-User CMMC Company

Thu, 03 Sep 2026 18:25:21 -0400

A one-person company rarely wants two complete technology environments. Every additional device, mailbox, account, security tool, and login creates more work for the same person who already serves as owner, contracts manager, security officer, bookkeeper, and technical staff. It will always cost more to maintain two tenants and two devices.

Yet sometimes two devices make perfect sense. At KNC Strategic Services, we are not a single person company, but we are fully remote. We utilize a two device solution and a CUI Enclave. All of our assessors have two identities and two devices. One to access our commercial work in GCC and one to access assessor work in GCCH.

A single-user company may keep its existing commercial laptop for normal business and add one hardened laptop dedicated to Controlled Unclassified Information. Instead of pulling the entire company into the CMMC boundary, the owner creates a narrow enclave around the work that actually touches CUI. At face value, this makes little sense, but business use cases do exist for a single person company to maintain an enclave and two devices.

CMMC, the program to measure how your controls meet the NIST-SP-800-171 requirements, does not require two devices. In many cases, one properly configured device can handle the job. In total lifetime costs, an enterprise GCCH scope will set you back the least, but cost the most up front.

As your company were to scale carving out an enclave may makee more sense, but for the cost of a laptop you can control your CUI flow, and leave any commercial business out of scope. Buying a second device can protect the commercial business from the restrictions, cost, and operational friction that comes with a CUI environment.

Even as a single person company, you will want to ask:

When does a second laptop create an affordable and manageable CMMC boundary, and when does it create more trouble than it solves?

The Microbusiness Swivel Seat

For a one-person company, the swivel seat may be literal. We have reviewed, because of separation of duties, the need to have multiple licenses with multiple roles, which means instead of swivel seat we are talking swivel high-top.

If you want to have an enclave as a soloprenuer buying another computer is the easiet, and cheapest way to get the job done. The owner sits at a desk with two laptops. One handles ordinary business. The other handles protected contract work.

On the commercial laptop you read customer correspondence and prepares invoice. You may run payroll handling yourself and subcontractors. At some point you will use accounting software like Quickbooks. Just to get work done you need to join commercial video calls, manages the company website, talk to potential customers, and handle every other part of the business. Life of a soloprenuer

On the protected laptop, you open up Task Orders using packages that contain controlled data or CUI drawings. You might have to reviews specifications from a licensed engineer. Your prime makes you accesses approved government portals to submit progress reports and stuff.

Small contractors, especially those providing staffing or Defense Services, may receive email directly from the Government or a Prime that contains a file marked, or even the email, often incorrectly, is marked CUI. Think through what having two domains means.

You have to snag two identities and maintain two mailboxes. As a visual reminder you use two browser profiles, depending on the environment you need to access. or two collaboration environments depending on the architecture. Having a second device simplifies this into an easier to enforce boundary.

Why Would a One-Person Company Choose Two Devices?

Imagine that your company performs mostly commercial work and handles CUI only for one government contract. Your everyday computer may contain accounting software, CRM tools, commercial Microsoft 365 applications, marketing platforms, personal productivity tools, video conferencing software, browser extensions, and customer-specific applications.

You may also need local administrator privileges for specialized software or rely on an existing MSP that uses tools you do not want inside the CUI environment. If you turn that computer into your CUI endpoint, all of those applications and services suddenly deserve scrutiny.

It seems counter-intuitive, doubling the devices for ease, but you can understand.

This computer runs my business. That computer handles CUI.

That makes the boundary easier to explain and often easier to assess. You need to make the procedures useful for you. Just bifurcating behind boundaries allows you to understand and follow your own procedures. You can’t just have a plan. You need to follow the plan.

Left or Right. This device, that device. Easy to understand.

Two Devices Can Protect the Business From CMMC Restrictions

A properly hardened CUI laptop may restrict software installation. You do not give yourself local administrator privileges, USB devices and printing get blocked. You create technical settings or procedures to stop browser extensions, cloud storage, personal accounts, local network access, and unapproved collaboration applications.

Those restrictions make sense on the protected device.

They may create real problems on the computer you use to invoice customers, join sales calls, run payroll, manage banking, post to social media, edit the company website, or support commercial customers.

For a single-user business, breaking the owner’s primary computer can break the company. A dedicated CUI laptop isolates those restrictions from the systems that generate ordinary revenue.

Buy the Device When You Win the Work

A small contractor may not know whether an RFP will turn into an award. Building an entire enclave before the company knows whether it will ever receive CUI can create a large expense with no revenue behind it.

The company can instead design the enclave before award and provision the device after award.

The owner bids using commercial systems without receiving CUI. During proposal planning, the company identifies the expected CUI workflow and decides what the protected environment will look like. After award, the company purchases or assigns the laptop, applies the security baseline, creates the protected accounts, connects the approved security services, validates the device, and only then permits CUI access.

If CUI arrives before you know where it belongs, your scope problem has already started.

A Contract-Specific Device Can Make Cost Easier to Understand

A second laptop also gives a founder a clearer way to think about the cost of cybersecurity.

The protected environment may require the laptop itself, security licensing, a FedRAMP service, vulnerability management, monitoring, MSP support, logging, assessment preparation, and eventual secure retirement of the device.

When one government contract creates those costs, the company can at least identify them as costs associated with supporting that work. Whether the company can charge any particular expense directly to the contract depends on the contract and applicable cost rules, but the architecture makes the source of the cost easy to understand.

Instead of asking, “Why did our entire IT budget explode?” You can say, “This is what it costs us to operate the CUI environment.”

Just plan on a device refresh for every new contract.

Two Devices Work Best When CUI Work Stays Small

The model works particularly well when only the owner handles CUI and the protected workflow stays narrow. Without an ESP helping with IT, swivel seat, does mean multiple roles in each tenant. Third party file shares work well in these scenarioes.

Maybe CUI arrives a few times each month. Maybe the company works on short-duration defense contracts. Maybe the owner only needs a browser, PDF reader, Microsoft Office, or one approved engineering application.

In that situation, the hardened laptop sits in the enclave. You use it when you need to perform protected work and return to the commercial laptop for normal business. The more often you swivel, the greater the temptation to create shortcuts.

Separate Devices Also Solve Application Problems

Commercial businesses use messy software.

You may need consumer file sharing or want to use your commercial AI tools. Device may have remote-support software. You will accounting applications, payment processors, browser extensions, or an old engineering application that demands local administrator access. The earlier you can think about separating your logistics from third party data, the easier 171 will scale with you.

You may have perfectly legitimate reasons to use those applications for commercial business without wanting to approve them for CUI. A dedicated laptop gives you an easy answer. Keep those applications on the commercial device.

Keep the protected device boring. For CMMC, boring is beautiful.

A Smaller Device Boundary Can Simplify the Assessment

The second laptop does not remove any NIST SP 800-171 requirements. You still need to address the requirements that apply to the system.

Instead of inventorying every computer the company owns, you may have one CUI endpoint. Instead of reviewing dozens of applications, you maintain a short approved-software list. Instead of proving that several users follow the required configuration, you prove that one device does.

A narrow boundary can reduce the number of assets, applications, configurations, accounts, logs, and places where CUI might accidentally appear.

That does not make CMMC easy. It makes your CMMC problem smaller.

Two Devices Do Not Necessarily Mean Two Microsoft Tenants

People often jump jump from “two laptops” to “two complete cloud environments.” Getting M365 Commercial and GCCH. You do not always need that. The cloud storage boundary is a different problem than two devices.

A company may use one commercial tenant while keeping CUI in a protected repository. Another company may use a commercial tenant for ordinary business and GCC High for CUI. A third may keep the commercial laptop exactly as it works today and use a managed VDI enclave instead of a second physical CUI laptop. Each model creates a different boundary.

The question does not start with how many tenants you own. First you need to ask

Where does CUI enter, where can it travel, and which systems protect it?

Answer that first and then decide if an Enterprise or Enclave scope works better for you.

Two Mailboxes Create Their Own Problems

A second CUI environment often creates another mailbox or protected messaging identity.

This sounds trivial until you live with it. You may forget to check the protected mailbox. A customer may send information to the familiar commercial address. Suddenly things slip through the crack and a meeting invitation lands in the wrong tenant. The owner may respond from the wrong identity or attach a CUI file to the commercial message.

Automatic forwarding makes the problem worse because it can destroy the separation the company created in the first place.

A one person company needs a simple operating routine. Tell customers where they must send CUI. Use clearly different mailbox names and signatures. Do not automatically forward protected messages into the commercial mailbox. Check the protected mailbox every day when the contract remains active. Verify the active identity before attaching a file.

Small visual cues help too. Different desktop backgrounds, browser profiles, device labels, and signatures can prevent surprisingly expensive mistakes.

Keep the Office Network Out of the CUI Workflow

You may want the protected laptop to use the same internet connection as the commercial computer without turning every device in the house or office into part of the CUI environment. As a single person company defining your physical boundary at your endpoint, provides you the ability to easily meet the physical security requirements,

Keeping things out of scope in the home requires deliberate design.The protected endpoint should not talk to local printers, shared folders, media servers, NAS devices, or other commercial computers. The endpoint firewall can block local communication while allowing approved outbound services. The company can disable network discovery, peer-to-peer services, local printing, and removable media.

A dedicated cellular or other isolated connection can make the separation even clearer when the business model supports it.

You can keep your him office router or network outside scope simply because you can demonstrate that CUI stays encrypted while in transit. You are going from an hardened and encrypted endpoint, over TLS, up to a FedRAMP Moderate or High environment. Your second laptop creates one anchor of “the enclave.” with the cloud being the other.

The Desk Becomes Part of the Boundary

Two laptops sitting next to each other create another category of risk: shared stuff. If you want to simplify your physical boundary just to your one in-scope device you need to worry about stuff people stick into computers/

Think about the innocent things sitting on your desk.

A docking station for your screen or phone. You might have a printer. There are flash drives all over the place. Every shared peripheral creates a question about whether information can move between the two environments.

For a one-person enclave, the simplest answer often uses dedicated accessories for the protected device. Label the laptop with a cool cover. Give it a visibly different desktop background. Keep removable media disabled. Do not connect it to the commercial printer. Lock the device when you walk away.

The Hidden Cost of the Second Laptop

The laptop may cost $1,500.

The laptop rarely represents the expensive part.

You also have to configure it, license it, monitor it, patch it, vulnerability scan it, support it, maintain its accounts, collect evidence, document the environment, replace it eventually, and securely retire it.

Then add the cost no spreadsheet captures particularly well:

your time.

A one-person company has no spare security officer sitting in another office. Every hour you spend fixing the enclave represents an hour you cannot bill to a customer. This is one reason I keep encouraging microbusinesses to consider an MSP or managed enclave. You should understand your security program, but you do not need to spend your life administering Microsoft.

Know When the Two-Device Model Starts to Break

The second laptop works when it behaves like a specialized tool.

It starts to fail when the owner constantly moves between devices just to complete ordinary work. Warning signs appear when you repeatedly retype information from one machine into another or need the protected laptop to reach commercial applications. Once your external connections cut across the boundary the castle walls start to fall. Next you start moving USB devices between systems or find yourself emailing information between environments just to get work done.

The architecture also becomes harder to sustain when the workflow gets in the way of doing business. At that point, the friction itself becomes a security risk.

People design workarounds for systems that get in the way. If your two-device architecture constantly encourages you to bypass your own rules, you no longer have a good architecture. You have an argument with your laptop.

One Protected Device or One Per Contract?

A single-user company may eventually work on several government contracts.

That does not automatically mean you need a laptop for every contract.

A separate device for each contract can make sense when customers impose incompatible requirements. Some customers make you use a dedicated device (ask them to provide it, and bring you in their scope, then). Some contracts require unique applications that may need compensating controls.

But if every contract can use the same security baseline, the same authorized applications, and the same protected repository, one properly managed CUI laptop may support several contracts. Then you can keep all your Govcon work on a single device.

Use access controls and repository separation to keep project data apart. Do not create hardware sprawl simply because another award arrives.

The Decision Test

A second laptop makes sense when most of your revenue comes from commercial work, only one person needs CUI, the protected workflow uses a small number of applications, and you can prohibit printing, removable media, and local sharing.

It also works well when the CUI need starts and stops with particular awards and you want to protect your existing commercial environment from CMMC restrictions.

The model makes less sense when CUI drives almost everything you do. If you spend all day moving between environments, need commercial systems to complete protected work, constantly transfer information, or require several people to work simultaneously, you may have outgrown the two-device model.

At that point, a broader GCC High environment, managed VDI enclave, or more integrated architecture may create less friction and less risk.

There Can Only Be Two

For a one-person company, two devices should not mean building two complete enterprises.

Your commercial laptop keeps the company alive. It handles sales, accounting, ordinary email, customer support, marketing, commercial production, and everything else that does not require the CUI enclave.

Your protected laptop does one job. It handles CUI. That narrow purpose creates the value. It fails when every ordinary business process forces you to swivel back and forth between two computers.

Keep the enclave boring. Keep the data flow narrow. Keep the commercial business outside it.

Sometimes the easiest way to make one tiny company meet CMMC is to accept one simple rule:

There can only be two.

“Mr. Hardcast’s Seal of Approval Bar Stool” flickr photo by Hardcast65 flickr.com/photos/ca… shared under a Creative Commons (BY 2.0) license

The One-Laptop Security Department

Sat, 29 Aug 2026 17:46:31 -0400

Hats. We all have many, but for a small business owner you wear them all at the same time. This includes running your Security Program (unless, and you should, farm work out to an External Service Provider).

CMMC isn’t a framework or a standard. You need a program. A one person company does not need an enterprise security department. Instead as a founder you need a routine. All programs need routines to run.

Products Do Not Implement Controls

Microsoft Defender can find vulnerabilities. Huntress can monitor security events. Intune can enforce device settings. A FedRAMP provider can protect its cloud infrastructure. An MSP can review alerts.

None of those tools decides how your company operates.

Someone has to decide who gets access, which software the company allows, when vulnerabilities require action, what happens after an alert, and when a business change affects the CUI boundary. Wearing your security officer hat you need to turn technology into procedures.

You do not need to create 20 Standard Operating Procedures. We want to identify the small number of things our founder must actually do and later write those actions directly into the SSP. Creating wave after wave of documentation will lead to problems for a small company. Document drift will cause you to fail assessments.

Instead treat your system security plan as a top level document that describes your plan for system security. Almost like it is in the name, or something. You will need some procedures and artifacts documented, especially inventory. Basically write down things you need to do your business. Put all your security related stuff in your SSP.

Think in Rhythms, Not Departments

A one-person security program works better when you divide the work into four buckets:

things the technology does continuously,
things to review on a schedule,
things to do when something changes, and
things to do when something goes wrong.

That gives us a security department without creating a security department.

What Happens Automatically

Start with the work you already paid someone else to do.

Defender continuously evaluates the managed Windows endpoint for vulnerabilities and malware. Intune checks whether the laptop still meets the required configuration. Huntress monitors for suspicious activity. The cloud providers generate authentication, access, and file activity logs.

Do not recreate these technical processes manually. In your SSP explain that these requirements get inherited. You just need to make sure the services remain active.

Automation performs the check. The company remains responsible for the decision.

If Defender finds a vulnerability, Defender has done its job. The control still requires someone, you (or your MSP that you really should hire), to decide what to do about the finding.

The Weekly Security Routine

For a one-laptop company, start with one scheduled security review each week.

Pick a day. Put it on the calendar. Treat it like bookkeeping.

You or your MSP reviews (in our example architecture):

Defender vulnerability findings,
security alerts,
Windows and application update status,
Intune device compliance,
failed or unusual sign-ins,
Huntress alerts or reports, and
outstanding remediation items.

The review does not need to become a three-hour meeting with yourself. Most weeks, nothing interesting should happen. Feature, not bug.

You check the dashboards, handle anything that requires action, and record that the review occurred. If an MSP performs the review, you review the MSP report and follows up on anything that requires a business decision.

Now we have turned a large collection of NIST requirements into a simple habit:

Once a week, check the health of the one system that can touch CUI.

Vulnerability Management Means Running More Than a Scanner

Defender, using the E3+P2 license in our model, can continuously identify vulnerabilities on the laptop and supported applications. That solves the technical scanning problem.

You still need to spell out a process in your SSP on how to handle a vulnerability when spotted.

When Defender identifies a vulnerability, the founder or MSP reviews the finding, determines whether it affects the system, applies the update or mitigation, and verifies that the vulnerability no longer appears.

The company also needs to react when a new vulnerability appears between scheduled reviews. A Microsoft advisory, CISA notice, Huntress alert, or software vendor warning may trigger another review.

The procedure remains simple:

Find it. Decide what it means. Fix it. Verify the fix. Keep the record.

That sentence will eventually become much more valuable in our SSP than a paragraph that says, “See Vulnerability Management Policy.”

You can write directly in the SSP how you Find it. Decide what it means. Fix it. Verify the fix. Keep the record. Keep your documentation lean.

Access Control With One User

When a small business owner opens up NIST-SP-800-171 for the first time they get overwhelmed reading 3.1.1.

Many access-control requirements sound complicated because large companies need to manage hundreds or thousands of accounts. You only have one authorized CUI user.

The 1099 contractors do not receive CUI access. Their BYOD devices cannot access the CUI repository. Their Government-Furnished Equipment does not connect to company systems.

What you need are multiple identities with your multiple hats.

Access Control specifically calls for separation of duties and least privilege. Feels like an oxymoron for a one person company.

Under NIST-SP-800-171 different identities can be defined by roles. Give yourself a normal account for daily work and a separate privileged account when administrative access becomes necessary.

Microsoft already made you buy enough roles to do this. Just enforce this on your laptop. Have one user to change and update stuff, and your everyday user to do stuff.

Then once a month review your accounts and access to confirm a bunch of new users weren’t added or changes weren’t made without approval.

The review should take less than a half hour.

You need to examine the user list, privileged accounts, and file-sharing permissions. You have a small scope, make sure to create small repeatable procedures.

Change Control and the Single Computer

When you read the configuration management requirements for approving changes a single person company can get frustrated. It seems like overkill.

You do not need to form a Configuration Control Board every time you want to install something new.

What you need in your procedures is something that ensures you:

Do not install or change software without considering the security impact first.

Before adding software, you need to document what the company needs, why the company needs it, whether the vendor supports it, whether it creates a new cloud connection, and whether it changes how CUI flows.

You can make a form, send yourself an email, use a spreadsheet. Even paying for a ticketing system has value for a single person company. Having everything organized in one place with little effort can be worth the money.

After installation, you verify stuff works, close the ticket.

You must document:

what changed,
why it changed,
when it changed,
who approved it, and
whether the change affected the system boundary.

You need traceability.

A ticketing system is something I encourage every company to have. If you want to use Microsoft Forms here are instructions.

Some Events Require Immediate (up to 72 hours) Action

Scheduled reviews handle ordinary operations. Certain events should trigger immediate action.

Examples include:

Defender or Huntress reports a serious security event,
you lose the laptop,
someone sends CUI to the wrong system,
a new vulnerability creates an immediate risk,
the laptop falls out of compliance,
you detect malware,
someone attempts unauthorized access, or
you suspect that CUI may have left the approved boundary.

Having an MSP can help the single person shop handle these events.

Later in the SSP, we can spell out the exact steps.

For now, the founder only needs to understand the principle:

Routine problems follow the routine. Security events interrupt the routine.

Business Changes Can Become Security Changes

Some of the most important security events do not look like cybersecurity events at all.

You might hire another employee. A contractor suddenly needs access to CUI, or you buy another laptop. Maybe your Prime wants to change the file-transfer process.

Those requests may sound operational, but they can change the CMMC boundary.

Our founder therefore needs one more procedure:

Before changing who can access CUI, where CUI can go, or what technology can touch it, stop and review the scope.

We introduced this as a scope-change trigger in Post One.

Now it becomes part of normal security operations.

What Must I Do for CMMC Compliance?

When we strip away the product names and compliance language, the one-laptop security department has a pretty short job description.

When	Founder or MSP Action
Continuous	Security tools monitor the endpoint, identity, and authorized services.
Weekly	Review vulnerabilities, alerts, compliance, updates, and outstanding remediation.
Monthly	Review accounts, access, authorized software, and major configuration changes.
When software changes	Review the security impact, approve the change, verify the system, and record the change.
When a vulnerability appears	Review it, remediate it, verify the correction, and keep evidence.
When a security event occurs	Contain the problem, investigate it, escalate when necessary, and document the response.
When the business changes	Check whether the change affects the CUI boundary before implementing it.

That starts to look much more manageable than “implement 110 security requirements.”

The MSP Can Do Work, but the Founder Still Owns Decisions

A founder who wants to spend very little time on IT can pay an MSP to perform most of the weekly review. A managed VDI provider can take even more technical work off the company’s plate.

That does not remove the founder from the security program.

A good small-business security program separates technical work from business authority. You can buy as much technical work as makes financial sense, but you always own the business decisions.

Keep Evidence While You Work

Do not wait until the CMMC assessment and try to recreate the last year of activity from memory.

Make evidence a side effect of doing the work.

This will save a small company an enormous amount of time and money.

A weekly vulnerability review creates a review record. An Intune check creates device-compliance evidence. A Defender finding and later clean scan create remediation evidence.

If you are going at it alone how can you ensure you follow the evidence collection needs?

What We Just Built for the SSP

We now have enough information to start writing actual operating procedures into our SSP.

We know:

who reviews the security environment,
what tools operate continuously,
what the founder reviews each week,
how the company handles vulnerabilities,
how the company reviews accounts and access,
how the founder controls software changes,
what events trigger immediate action,
what business changes trigger a scope review, and
what records those activities create.

Notice what we did not create.

We did not write a separate Vulnerability Management Plan, Access Control Plan, Configuration Management Plan, Security Operations Procedure, and five other documents just to explain how one person manages one laptop.

We described what actually happens.

As a small business focus on doing the do and let the residuals of work prove the procedures in your System Security Plan.

Leverage What You Do Well: Brilliant at the Basics

Fri, 28 Aug 2026 08:26:14 -0400

Manufacturers build our nation, and they do it well.

I grew up in Aerospace manufacturing. Worked a metal lathe when I was sixteen and then taught myself CAD because we got a new laser cutter and that room had air conditioning. Real air-conditioning. I know manufacturers do many things well. Small business owners who can make payroll on 7-10% margins. True Yankees. Too often it feels like the CMMC world looks down down on the Defense Industrial Base because NIST-SP-800-171 requirements have existed for years.

But companies aren’t skimping on security out of necessity. They want to do the right thing, but too often do not know where to begin. I am a fan of the Department of War’s Brilliant at the Basics because it provides a roadmap to getting started.

We need to start with what manufacturer’s do well. A quality program does not begin with the most advanced inspection equipment. It begins with controlled processes. You need trained people and maintained machines. Companies now how to track approved materials in a BOM. They have records that prove the work occurred.

Cybersecurity works the same way.

Brilliant at the Basics

Defense manufacturers often approach NIST SP 800-171 as a list of technical tasks. You might install a firewall, write policies, run a scan, and fill out a System Security Plan. Those activities matter, but a checklist alone does not create a cybersecurity program. A company can buy security tools and still leave major business risks unmanaged.

The better approach is to leverage cybersecurity to get better at business. Address the common conditions that allow attackers to steal credentials, move through a network, expose sensitive data. You do not want bad guys to interrupt production. You do not want some hacker gang to hold systems for ransom. Those basic practices reduce real operational risk while creating many of the policies, procedures, configurations, and records that support NIST SP 800-171.

NIST SP 800-171 is not a cybersecurity framework

NIST SP 800-171 Rev. 3 provides security requirements for protecting the confidentiality of Controlled Unclassified Information, or CUI, in nonfederal systems. It applies to the system components that process, store, or transmit CUI and to components that protect them. 171 is a set of security requirements, and not complete framework for managing a manufacturer’s cybersecurity program.

To pass a CMMC assessment you only have to protect CUI confidentiality. To keep a business running a cybersecurity program must also keep production available. You must preserve the integrity of drawings and inspection data. You need to manage suppliers. Based on the most common attacks your cybersecurity program must prepare your company for incidents with good backups. You need to recover from ransomware without downtime.

Each of these is a risk-based investment decisions. NIST SP 800-171 contributes to that program, but it does not organize the mitigation strategies for the business.

I Use X Framework in my Cybersecurity Program

You can’t build a cybersecurity program around NIST-SP-800-171. Instead you should adopt a framework that builds a program which meets the requirements of NIST-SP-800-171.

I like to start with the NIST Cybersecurity Framework 2.0, which organizes cybersecurity risk around Govern, Identify, Protect, Detect, Respond, and Recover. Another good choise.The CIS Critical Security Controls v8.1, which provide a prioritized set of safeguards against common attacks also works well for manufacturers.

You embed applicable NIST SP 800-171 requirements into that larger program. In practical terms, the framework or control set tells leadership how to manage cybersecurity as an ongoing business function. NIST SP 800-171 tells the company which security outcomes it must achieve for the systems that handle or protect CUI.

Let’s use a framing manufacturers know. think of NIST SP 800-171 as a customer specification inside a mature quality management system. The specification matters, but the management system supplies the governance, ownership, and operating rhythm. It details corrective action, and continuous improvement needed

Become Brilliant at the Basics to Do Business Better

Manufacturers face a difficult mix of business and technical risk. They often depend on older equipment, specialized software, and remote vendor access. They have small or no IT teams, and tight delivery schedules. A patch or configuration change can affect production. A ransomware event can stop the plant. A stolen email or cloud account can expose drawings. An employee can paste sensitive information into an unapproved artificial intelligence service in seconds.

Attackers do not need to defeat every safeguard. They need one workable path. NIST-SP-800-171 does not address many of these risks. As a business owner worry about your information system before you protect the Government’s.

Brilliant at the Basics closes the paths attackers use most often and limits the damage when prevention fails. It helps a manufacturer:

Reduce account hijacking
Count the stuff that requires protection;
Deal with end of life and out dated software
Segment off legacy OT that can’t get updated.
Keep an incident in one area from spreading across the business;
Find and correct vulnerabilities according to operational risk;
Prevent sensitive data from flowing to unapproved services;
Restore operations after ransomware or system failure
Make security part of every employee’s job, not just the IT department’s job.

These outcomes matter even when a particular practice does not directly satisfy a NIST SP 800-171 requirement. CMMC does not care about your backups beyond CUI. A backup architecture protects manufacturers from extended downtime A flexible technology stack reduces operational and supplier risk even though the publication does not require a manufacturer to avoid vendor lock-in.

From manufacturing risk to NIST SP 800-171 controls

Manufacturing often don’t have basics of cyber hygiene place. Why start building to NIST SP 800-171 when you have risks to address that fall outside of 171.

To get better at business get brilliant at the basics:

Risk to Business	Brilliant at the Basics	SOP	171 Rev. 3
Stolen passwords give an attacker access to email, remote connections, cloud systems, or administrator tools. One compromised administrator account can affect the entire company.	1. Phishing-resistant MFA	Require MFA for every in-scope user and administrator. Prefer phishing-resistant methods such as passkeys, FIDO2 security keys, or certificates. Give administrators separate privileged accounts, limit elevated access, and review privileges regularly.	Direct: 03.05.03 Multi-Factor Authentication; 03.05.04 Replay-Resistant Authentication. Supporting: 03.01.05 Least Privilege; 03.01.06 Privileged Accounts.
The company cannot protect devices, software, cloud services, or CUI repositories that it does not know exist. Unmanaged assets create blind spots.	2. Comprehensive asset inventory management	Maintain an inventory of in-scope hardware, software, virtual and cloud assets, identities, CUI repositories, interfaces, owners, support status, and authorization status. Reconcile the inventory after changes and on a defined schedule.	Direct: 03.04.10 System Component Inventory. Supporting: 03.12.03 Continuous Monitoring.
Unsupported operating systems, abandoned applications, unnecessary services, and unapproved software increase the chance of compromise and unplanned downtime.	3. Strategic technical debt reduction	Track vendor support dates. Replace unsupported components or document and operate alternative protections. Remove unnecessary ports, protocols, features, and software. Maintain secure configurations and an approved-software process.	Direct: 03.16.02 Unsupported System Components; 03.04.06 Least Functionality; 03.04.08 Authorized Software. Supporting: 03.14.01 Flaw Remediation; 03.11.02 Vulnerability Monitoring and Scanning.
A critical security tool or service may become unsupported, unaffordable, insecure, or impossible to replace. Poorly understood supplier dependencies can trap the company in a risky architecture.	4. Flexible technology stack	Define security engineering principles and approved integration patterns. Evaluate external providers, document service boundaries, place CUI safeguards in contracts, and plan how the company will transition data and services if a supplier relationship ends.	Supporting: 03.16.01 Security Engineering Principles; 03.16.03 External System Services; 03.17.02 Acquisition Strategies, Tools, and Methods; 03.17.03 Supply Chain Requirements and Processes.
Malware or ransomware that enters through one workstation can move into engineering systems, CUI repositories, servers, or production networks.	5. Logical segmentation to limit lateral movement	Define the CUI security boundary and approved data flows. Separate business, guest, CUI, vendor, and production networks according to risk. Use firewalls and access rules that deny traffic by default and allow only approved connections. Test both allowed and blocked paths.	Direct: 03.13.01 Boundary Protection; 03.01.03 Information Flow Enforcement; 03.13.06 Network Communications—Deny by Default—Allow by Exception.
Uncorrected vulnerabilities expose the company to compromise, but poorly planned patching can also interrupt specialized systems and production.	6. Risk-based vulnerability management	Define what the company scans, how often it scans, who reviews findings, and how quickly it responds. Consider severity, exploitability, exposure, production impact, and available safeguards. Assign owners and deadlines, document risk decisions, track corrective actions, and retest fixes.	Direct: 03.11.02 Vulnerability Monitoring and Scanning; 03.11.01 Risk Assessment; 03.11.04 Risk Response; 03.12.02 Plan of Action and Milestones.
A custom application, script, integration, or automation can introduce weaknesses that become expensive and disruptive to correct after deployment.	7. Integrate security early in the development lifecycle	Apply security requirements during specification, design, development, implementation, and operation. Review architectures, manage software dependencies, scan code and components where appropriate, track defects, and require approval before release.	Direct: 03.16.01 Security Engineering Principles. Supporting: 03.11.02 Vulnerability Monitoring and Scanning; 03.14.01 Flaw Remediation.
Employees can place CUI, customer drawings, contract data, or proprietary information into an unapproved public AI service. The provider may retain, reuse, or expose the data.	8. Secure AI adoption and data protection	Approve AI services by use case and data type. Prohibit CUI in unapproved services. Define acceptable-use rules, assess providers, configure data-loss prevention or web controls where practical, train users, and monitor compliance. Remember that proprietary information does not automatically become CUI; identify and handle each data type according to its actual requirements.	Supporting: 03.01.03 Information Flow Enforcement; 03.01.16 CUI Confidentiality; 03.15.01 Policy and Procedures; 03.15.03 Rules of Behavior; 03.16.03 External System Services.
Ransomware, equipment failure, or administrative error can stop production or destroy access to critical records. Unprotected backups can also expose CUI.	9. Resilient backup and disaster recovery architecture	Encrypt backup data, restrict and monitor backup administration, separate backup credentials, protect encryption keys, verify backup jobs, and test restoration. Connect recovery activities to incident response and risk decisions.	Supporting: 03.13.08 Transmission and Storage Confidentiality; 03.13.11 Cryptographic Protection; 03.11.04 Risk Response; 03.06.01 Incident Handling.
Employees, administrators, engineers, executives, and incident responders may not understand their security responsibilities. Knowledge may reside with one person or one service provider.	10. Continuous technical workforce readiness	Train all in-scope personnel on CUI handling, phishing, AI use, and incident reporting. Create role-specific training for administrators, developers, CUI handlers, incident responders, and executives. Track course content, attendance, completion, and required refreshers.	Direct: 03.02.01 Literacy Training and Awareness; 03.02.02 Role-Based Training.

For a full mapping check out this spreadsheet

Quality of Your Cyber Hygiene

As a manufacturer leverage what you do well. Build controls the way you build quality

Manufacturers should resist the urge to begin with a stack of policies copied from templates. You need to leverage procedures to drive your work flows. Then develop plans to integrate these SOPs/

For each risk and mapped NIST requirement, build four connected layers:

Policy: What does leadership require, and why?
Procedure: Who performs the work, when do they perform it, and what happens when something fails?
Implementation: Which people, processes, configurations, and technologies enforce the requirement?
Evidence: Which records prove that the company performs, reviews, tests, and improves the control?

For example, a one-page MFA policy has little value if users can still connect through an old protocol that bypasses MFA. The manufacturer needs an enforced authentication configuration, an exception process, test results, enrollment records, and periodic review. Likewise, a network diagram does not create segmentation. Firewall rules, approved flows, change records, monitoring, and test results make segmentation real.

This approach should feel familiar. A written work instruction does not prove that a manufacturing process operated correctly. The company also needs trained personnel, calibrated equipment, completed records, inspection results, and corrective action. Cybersecurity requires the same operational discipline.

Good Operations Lead to Strong Compliance

The strongest manufacturers do not separate cybersecurity from the business. They treat it as part of quality, production resilience, supplier management, engineering, workforce development, and executive risk management.

NIST SP 800-171 provides essential requirements for protecting CUI, but it should sit inside a broader program based on CSF 2.0 or the CIS Controls. Brilliant at the Basics gives manufacturers a practical place to begin. It addresses the everyday weaknesses that cause many security incidents, reduces the likelihood and impact of business disruption, and creates a foundation for many NIST SP 800-171 controls.

Start with the risks. Build the operating discipline. Map the resulting controls to the requirements. Then collect the evidence that proves the program works.

Scoping out Costs of Solution Architecture

Thu, 27 Aug 2026 17:30:36 -0400

For many small entrepreneurs the cost of CMMC drives your scope. You may engineer a solution that allows you to buy inherited solutions so you do not have to build every security control yourself. Microsoft GCCH will always have lower lifetime costs, but not every contractor can live by five year plans.

This is the third post in the series on the soloprenuer and CMMC. You can find the first post here and the second post here.

You may live TO by TO even after winning a spot on an IDIQ. Maybe you make it from RFP response to response and need to survive lean times between awards. Paying for the costly migration of a Microsoft tenant may not be in the cards until after award. So you utilize a FedRAMP Fileshare until then.

No matter what the interwebz say, no one way exists to engineer a NIST-SP-800-171 environment for a single employee company. You have to right fit your solution to your business needs.

What do I actually need to buy?

A tiny contractor does not need one product for every NIST SP 800-171 requirement. Really the first question you need to ask, the most important thing to interview is Time and not money. How much time do you want to spend on IT, and does this have an impact on time available for Direct work?

Really try to see if your Prime will bring you in scope and provide you a device, but when they say no, four practical strategies emerge:

Keep Microsoft 365 Commercial and add a dedicated CUI repository.
Build a Microsoft 365 GCC High environment.
Rent a fully managed VDI enclave.
Use an MSP to take recurring security work off your plate.

The products may change, but the business question will not.

Cheap does not simply mean the smallest monthly bill.

A founder needs to look at the first-year check, five-year cost, implementation labor, inherited controls, and the amount of time the company must spend running the environment.

First, Set a Common Budgeting Baseline

We need an apples-to-apples starting point before comparing CUI solutions.

For this article, every architecture except GCC High starts with the same commercial Microsoft baseline:

$32 per user per month for Microsoft 365 Business Premium/E3 plus the P2 add-on.

That gives us:

$384 per user per year
$1,920 per year for five users

This baseline gives the company the Microsoft identity, endpoint-management, and Defender capabilities that support the managed endpoint. Defender handles vulnerability management, and Huntress remains the monitoring/SIEM platform.

You might be a Google Workspace customer, and of so just skip ahead to the Managed VDI section. Explaining the difference in what a Google versus Microsoft stack brings goes way beyond the scope of this post. Google shops will need a managed VDI.

The important budgeting rule looks like this:

File sharing and VDI add to the commercial Microsoft baseline. GCC High replaces the commercial Microsoft baseline.

We do not buy Business Premium/E3 + P2 and then stack equivalent GCC High licensing on top of it for the same CUI users. A one person company would rarely need a CUI enclave. You would not maintain two tenants unless you made significant commercial money overseas.

Strategy One: Keep Commercial Microsoft 365 and Add a CUI Repository

You have all seen the commercials. Heard the channel sales pitch. Building a CUI enclave, meaning logical boundaries, around a FedRAMP High File share is quite common. Many business owners will pay more to keep Microsoft 365 Commercial for ordinary business and FCI while placing CUI in a separate FedRAMP High file-sharing service. This introduces less change to how business already gets done

For this example, we budget $12,000 per year for a product-agnostic FedRAMP High file-sharing service. We also assume that price includes five CUI users.

You always need more than one user, even as a single user company.

The business still controls the laptop, approves access, reviews vulnerabilities, handles remediation, manages CUI, and keeps evidence. The cloud provider handles the infrastructure inside the CUI repository.

For one user let us assume:

$12,000 file share + $384 Microsoft baseline = $12,384 per year

One-User File-Share Model	Cost
Commercial M365 + P2 baseline	$384.00/year
FedRAMP High file share	$12,000.00/year
Annual recurring cost	$12,384.00
Five-year cost	$61,920.00

This architecture has one easy rule:

CUI goes in the CUI repository. Commercial business information stays in commercial Microsoft 365.

For a tiny contractor, that clarity has real value. Many contractors also want to pay less up front and might start with a file-share and then move to GCCH once they win award. You gamble with less, and hope you win the award.

Strategy Two: Replace the Commercial Stack With GCC High

The second strategy moves the CUI users into Microsoft 365 GCC High. GCC High can provide CUI email, SharePoint, OneDrive, Teams, identity, device management, and related security capabilities inside one Microsoft government environment. Defender still handles endpoint vulnerability management, and Huntress still supports monitoring.

The key budget difference matters:

GCC High replaces the $32-per-user commercial Microsoft baseline for those CUI users.

We do not add $384 per user to the GCC High number.

We also need to remember that one employee does not mean one GCC High identity. Our one-person company needs a licensed daily-use account, a separate licensed privileged-administrator account, and two cloud-only emergency-access identities. The architecture comparison uses this same separation because the founder should not use the account that reads email and browses the web to administer the entire tenant.

Identity	Purpose	Daily Use?
Daily user	Email, Teams, SharePoint, OneDrive, and CUI work	Yes
Privileged administrator	Tenant and security administration	No
Emergency access 1	Tenant recovery	No
Emergency access 2	Tenant recovery	No

Our current planning model puts that GCC High stack at approximately $7,871.88 per year for the one-person environment.

Then we have to build it.

GCC High Has a First-Year Problem

Let us assume a qualified Microsoft provider charges an average of $150 per hour.

A greenfield GCC High deployment requires about 100 hours of engineering. The provider needs to configure the tenant, identities, administrative accounts, device management, Defender, Conditional Access, logging, SharePoint, OneDrive, security settings, testing, and documentation.

That creates a $15,000 setup project.

One-User Greenfield GCC High	Cost
Annual GCC High stack	$7,871.88
100-hour implementation at $150/hour	$15,000.00
Year-one cost	$22,871.88
Five-year cost	$54,359.40

GCC High costs less over five years than the dedicated file-share model, but the founder has to absorb a much larger first-year bill.

That creates the cash-flow problem.

Migrating an Existing Tenant Costs Even More Up Front

A founder who already runs a commercial Microsoft tenant faces a larger project. The provider now needs to build GCC High and move identities, mail, files, permissions, devices, DNS, and configurations.

We will budget 150 hours for that work.

At $150 per hour, the migration costs $22,500.

If you know how to all the Microsoft stuff you can knock down these costs, but it will still take time. If you are in between awards time may not be scarce, if you have Direct hours to bill your time gets expensive.

One-User GCC High Migration	Cost
Annual GCC High stack	$7,871.88
150-hour migration at $150/hour	$22,500.00
Year-one cost	$30,371.88
Five-year cost	$61,859.40

Notice what happened.

The five-year cost of migrating into GCC High gets close to commercial Microsoft and adding the $12,000 file share. Two to Five users, if you can get an affordable file-share package is the sweet spot.

The business decision now depends much more on cash flow, workflow, and how much infrastructure the founder wants to manage.

Strategy Three: Rent a Managed CUI Workspace

A fully managed VDI enclave takes another path.

A service such as CuickTrac, ATX, or Midwatch moves much of the technical operation into the managed enclave. You get access to a VDI solution that keeps your endpoint out of scope. Suddenly more of your security requirements get inherited. This is as close as turn key getd

For this comparison we will assume three users. Just like the Fileshare and M365 a single person company needs multiple identities to fill roles of least privilege.

For this compliance story we will use $325 per user per month, with a three-user minimum, plus a $5,000 one-time setup fee.

The commercial Microsoft baseline still applies because this model does not replace the company’s Business Premium/E3 + P2 environment.You still need to pay for your commercial side of the business.

3 × $325 = $975 per month for Managed Enclave

Then we add our one-user Microsoft baseline:

$975 + $32 = $1,007 per month

One-User Model	Cost
Commercial M365 + P2 baseline	$384.00/year
Three-seat minimum	$11,700.00/year
Annual recurring cost	$12,084.00
One-time setup	$5,000.00
Year-one cost	$17,084.00
Five-year cost	$65,420.00

Now the fully managed VDI model sits in an interesting position.

It costs less in year one than either GCC High approach, and its five-year cost stays reasonably close to both the dedicated file share and a GCC High migration.

The founder pays a premium over greenfield GCC High but buys much more operational help.

Compare the One-Person Company

One-Person Architecture	Year One	Five Years
Commercial M365 + P2 + FedRAMP High file share	$12,384.00	$61,920.00
Cuick Trac + Commercial M365 + P2	$17,084.00	$65,420.00
GCC High — greenfield	$22,871.88	$54,359.40
GCC High — migrate existing tenant	$30,371.88	$61,859.40

The dedicated file share creates the lowest first-year cost.

Greenfield GCC High creates the lowest five-year cost.

Managed Enclaves have the highest lifetime cost but the lowest level of effort.

Migrating into GCC High costs almost exactly the same over five years as the dedicated file-share model, but the founder has to fund much more of that cost during year one.

None of those choices are right or wrong. They solve different problems.

Scale Changes the Answer

Now let the company grow from one CUI user to five.

Our commercial Microsoft baseline follows the number of users:

5 × $32 × 12 = $1,920 per year

The file-share service still costs $12,000 because our planning assumption includes five licenses.

That gives the five-user file-share model a major scaling advantage.

Five-User File-Share Model	Cost
Five Commercial M365 + P2 users	$1,920.00/year
FedRAMP High file share with five included users	$12,000.00/year
Annual recurring cost	$13,920.00
Five-year cost	$69,600.00

At one user, the company pays for file-sharing capacity it does not use. At five users, the company finally uses all five included licenses while the $12,000 repository cost stays flat.

Five Users in GCC High

A five-person GCC High company also needs more than five identities.

Our design uses five licensed daily-use accounts, one separate licensed privileged-administrator account, and two cloud-only emergency-access identities.

That gives the company eight identities, with six licensed identities in our planning model.

The current planning figure puts the five-user GCC High stack at approximately $12,335.88 per year.

GCC High still replaces the commercial Microsoft baseline. We do not add another $1,920 for Business Premium/E3 + P2.

Five-User GCC High	Year One	Five Years
Greenfield — 100-hour setup	$27,335.88	$76,679.40
Migration — 150 hours	$34,835.88	$84,179.40

GCC High now loses the five-year price advantage it had at one user because our file-share service includes five seats for the same $12,000 annual price. File-share pricing model scales unusually well from one to five users.

Five Users in Managed Enclave

Managed Enclaves scale differently because they charge per user.

Using our earlier estimage Five users cost:

5 × $325 × 12 = $19,500 per year

We then add the five-user commercial Microsoft baseline:

$19,500 + $1,920 = $21,420 per year

Five-User Cuick Trac Model	Cost
Five Commercial M365 + P2 users	$1,920.00/year
Five users	$19,500.00/year
Annual recurring cost	$21,420.00
One-time setup	$5,000.00
Year-one cost	$26,420.00
Five-year cost	$112,100.00

The managed VDI looks much more attractive at one user than at five because the three-seat minimum already forces the tiny company to buy unused capacity.

Once the company reaches five people, every new VDI user increases recurring cost.

The Five-User Comparison

Five-User Architecture	Year One	Five Years
Commercial M365 + P2 + FedRAMP High file share	$13,920.00	$69,600.00
Cuick Trac + Commercial M365 + P2	$26,420.00	$112,100.00
GCC High — greenfield	$27,335.88	$76,679.40
GCC High — migrate existing tenant	$34,835.88	$84,179.40

The file-share model wins the five-user price comparison because the $12,000 subscription already includes five CUI users.GCC High costs more over five years at this size, but it provides a much broader collaboration environment. The company gains CUI email, Teams, SharePoint, OneDrive, identity, device management, and other services under one ecosystem.

Managed Enclaves cost substantially more at five users, but price does not tell the whole story. The company pays the provider to operate much more of the environment. A founder who does not want to build or maintain the technical stack may still value that trade.

What Are You Really Buying?

The three architectures sell different kinds of inheritance.

With the FedRAMP High file-share model, you buy a controlled place for CUI while keeping the commercial Microsoft security stack.

With GCC High, the founder replaces the commercial Microsoft stack with a government cloud environment and pays a substantial engineering cost to build it correctly.

With *Managed Enclave, the founder keeps the commercial Microsoft baseline and pays a managed-enclave provider to take much more responsibility for the CUI workspace.

The cheapest choice depends on the size of the company and the kind of inheritance the founder values.

Strategy Four: Buy Back the Founder’s Time

An MSP can support the commercial Microsoft and GCC High models by reviewing Defender findings, monitoring Huntress, coordinating remediation, managing endpoint configuration, reviewing accounts, gathering evidence, and preparing reports.

The founder still owns the CMMC program, but the founder does not need to spend every Friday staring at security dashboards.

That time has value.

If a founder spends five hours each month managing cybersecurity, the company loses 60 hours per year. At a $200 billable rate, that represents $12,000 of potential revenue.

A spreadsheet that ignores the founder’s time does not show the true cost of the architecture.

Inheritance Does Not Make Responsibility Disappear

Microsoft can operate the cloud. A FedRAMP provider can secure the repository. Defender can identify vulnerabilities. Huntress can monitor security events. CuickTrac can operate a managed enclave. An MSP can review alerts.

The founder still approves users, decides who may access CUI, maintains the system boundary, manages company procedures, reviews provider responsibilities, makes risk decisions, and keeps the SSP accurate.

That gives us the real lesson behind inheritance:

You do not need to build every security control yourself. You need to understand which controls you own and which controls you bought from somebody else.

So What Should Our Founder Choose?

For a one-person company, the dedicated file-share architecture provides the lowest first-year cost, while greenfield GCC High produces the lowest five-year cost under these assumptions.

A managed VDI enclave such as CuickTrac lands between them. It costs a little more over five years than the file-share model but can dramatically reduce the amount of technical work the founder needs to perform.

Migration changes the GCC High story. Once a company already has a commercial Microsoft tenant, the 150-hour migration makes GCC High and the file-share model almost identical over five years. The founder then needs to decide whether consolidation justifies the larger first-year bill.

At five users, the dedicated file share becomes the least expensive architecture because the $12,000 subscription already includes all five users. GCC High costs more but offers broader capabilities, while managed VDI costs the most because every additional seat increases the subscription.

The goal is not to buy the most cybersecurity products or chase the cheapest advertised license.

Buy the architecture that leaves you with the fewest security problems you personally have to solve at a price your business can a afford.

What We Just Built for the SSP

We now know where CUI lives, how users reach it, which services manage identity and endpoints, how the company handles vulnerability management and monitoring, which providers operate technical controls, and which responsibilities remain with the founder.

Next: The One-Laptop Security Department

In the next post, we stop shopping and start doing. We will look at what you need to do every day, every week, every month, and every time something changes. You need to think about security controls stop as product features and start building procedures to get better at business.

One Laptop Does Not Need an Enterprise Security Program

Wed, 26 Aug 2026 08:05:37 -0400

A one-person company struggles to prepare for CMMC. Often, folks begin in the wrong place.

All month long I am focusing on how a single-user company can create controls that meet NIST SP 800-171 security requirements and pass a CMMC assessment using the NIST SP 800-171A assessment objectives. You can find the first post here.

You download NIST SP 800-171. You see 110 requirements. You throw up in your mouth when you realize you must meet 320 assessment objectives. You have no employees. How can you meet requirements meant for a large enterprise?

You start hearing about policies, SIEMs, VLANs, vulnerability scanners, privileged access workstations, firewalls, incident response plans, configuration management boards, and a dozen other things that sound like they belong in a Fortune 500 company.

Before long, a founder with one laptop tries to design an enterprise security program.

Stop this backward approach.

Before we decide how to protect the system, we need to answer a much simpler question:

What exactly do we need to protect?

For a small contractor who runs staffing agencies and hires 1099 employees to work on GFE, the simplicity of the environment matters.

Start With the Business, Not NIST SP 800-171

We work with many companies that operate on similar principles.

One founder serves as the principal contractor. She has one company-controlled Windows laptop. Only this company device can process, store, or transmit Controlled Unclassified Information.

The company also uses 1099 contractors, but those contractors perform their government work onsite using Government-Furnished Equipment. Their GFE does not connect to the company’s systems. The company does not grant those contractors access to CUI.

For ordinary company communications and Federal Contract Information, the contractors may use their own devices to access Microsoft 365 Commercial. But that Microsoft 365 environment only touches FCI. Contractors cannot access the CUI repository.

The company realizes it has:

no CUI printers,
no company servers,
no corporate LAN,
no removable-media workflow for CUI, and
no reason to drag every device the company touches into the CMMC boundary.

Your Company Does Not Automatically Equal Your CMMC Boundary

A small business may own or interact with all kinds of technology. That does not mean all of it has to become part of the system that handles CUI. Our founder may use a personal phone. The 1099 contractors may own laptops and tablets. The Government may provide computers. The company may have a commercial Microsoft 365 tenant. T he founder may have a home router. None of those facts automatically place all of those devices inside the CUI environment.

As you start to scope a single-person company, begin with critical questions:

Can the device process CUI?
Can it store CUI?
Can it transmit CUI?
Does it provide security protection to the CUI environment?

Keep the CUI Workflow Small

Our boundary may look like this:

Or like this:

We keep the center of the diagram intentionally boring.

When you realize the scope involves a single company-managed Windows laptop, you can get a handle on CMMC. That laptop connects to the authorized services used to protect and handle CUI. Everything else gets separated by function. The Government-Furnished Equipment stays in the Government environment. The contractors' personally owned devices stay in the FCI workflow.

Microsoft 365 Commercial stays an FCI environment and provides SPA support as an External Connection.

The contractors never receive access to the CUI repository. CUI does not move onto their personal devices. CUI does not move onto the Government equipment through the company’s systems. CUI does not get printed.

The result:

CUI scope, Government systems, and ordinary FCI collaboration do not have to become one giant blob.

That makes both cybersecurity and CMMC easier.

Every Asset Has a Cost

A hidden cost appears every time you allow CUI onto another device. Suppose the founder decides to let a contractor download one CUI drawing onto a personal laptop. That sounds like one small workflow change.

No. We just added another device to our boring middle, and we increased scope.

Now we have another device that we may need to inventory, configure, harden, monitor, patch, protect, assess, and describe in the SSP. We need to know who administers it. We need to control access. We need to know where the file gets stored.We need to know whether it gets backed up.

We need to think about browser caches, temporary files, local accounts, malware protection, encryption, vulnerabilities, and incident response.All because we wanted to make one file easier to access. The same thing happens with printers.

If we do not print CUI, then we do not need to design procedures for protecting CUI sitting in an output tray, storing paper records, transporting hardcopy, sanitizing printer storage, or destroying printed CUI.

The simplest printer control for a tiny company:

Do not print CUI.

That gives us one of the most important lessons in this entire series:

Every asset you keep out of the CUI workflow is an asset you do not have to protect as part of the CUI system.

That does not mean ignoring security on the rest of the business.

FCI still has safeguarding requirements. Commercial systems still need security. Employees and contractors still need safe computing practices. It simply means that we should not unnecessarily turn every business system into a CUI system.

Draw the Boundary Before You Buy Anything

This is why I would not start a small company’s CMMC project by shopping for cybersecurity tools.

I would start with a diagram.

Where does CUI come from?
Where can it go?
Who can see it?
Which device can open it?
Where can it be stored?
How does it leave the company?
What systems are expressly prohibited from receiving it?

If a founder cannot explain the boundary in plain English, you will struggle to write an accurate SSP around it.

If the assessor cannot understand the boundary, the assessment will get much more complicated.

The Boundary Builds a Business Rule

Technology alone will not keep this design small. The company also needs rules.

The 1099 contractors do not get added to the CUI access group.
The founder does not forward CUI to commercial email.
Government-Furnished Equipment does not log into company systems.
Personal devices do not download CUI.

Those operating decisions preserve the boundary.

What We Just Built for the SSP

We still have not written any of the 110 NIST SP 800-171 requirements.

But we have already created some of the most important content that will eventually go into the System Security Plan.

We now know:

the system environment,
the CUI system boundary,
the physical and logical separation of the environment,
the roles involved,
who has authorization to access CUI,
how CUI flows through the company,
which assets and workflows remain outside the boundary,
what systems cannot receive CUI, and
which changes require us to reconsider scope.

That is why I wanted to start the series here.

If we get the boundary wrong, everything we build afterward gets harder.

If we get the boundary right, a one-person company can remain a one-person security problem instead of accidentally becoming an enterprise security problem.

When it comes time to write the System Security Plan, your boundary diagram will support many controls:

3.1.3 — The company limits CUI flow to the managed laptop and authorized CUI services.
3.1.20 — The diagram shows GFE, BYOD, and Microsoft 365 Commercial as external or out-of-boundary systems and documents restricted or prohibited CUI connectivity.
3.12.4 — The diagram documents the CUI system boundary and external connections.
3.13.1 — The diagram identifies the logical boundary between the CUI enclave, Government environment, BYOD environment, and commercial FCI environment.
3.13.6 — The diagram can mark prohibited paths and support the allow-by-exception architecture.
3.13.8 / 3.13.11 — The diagram can identify approved encrypted and FIPS-protected CUI connections. The boundary diagram exists to mainly meet 3.12.4, 3.13.1, and 3.1.3. It defines everything about CMMC

Next: Now We Can Buy Something

CMMC for a Company of One: Building a Business Not a Burden

Tue, 25 Aug 2026 13:04:40 -0400

If you are a founder, independent consultant, or owner of a very small defense contractor, NIST SP 800-171 feels overwhelming. You stare at the CMMC scoping guide and know someone wrote it for a company much larger than yours.

You may have one employee, one laptop, no server room, no IT department, and no corporate network. Yet if your company handles Controlled Unclassified Information (CUI), you still need to protect that information and explain how you meet the requirements of NIST SP 800-171. You have to meet the same 110 requirements as Boeing, RTX, or General Dynamcs

I get it. That doesn’t seem fair.

In this series, we will build a complete System Security Plan (SSP) for a fictional one-person company. But we will not start with the SSP.

We will begin with how the business actually operates, define the CUI boundary, select the technology, write the procedures, identify the evidence, and only then assemble the SSP.

The goal: Create an SSP that tells the founder exactly what to do instead of constantly pointing to separate policies, plans, and procedures. You do not need to swim in pages of procedures. We will also include a cost analysis of different solutions, and consider the implications to how you do business better. We will focus on implementing controls not on how they fall in in NIST-SP-800-171 but on the ROI for security for a micro-business

Meet Our Fictional Company

Our company has one principal contractor who may receive and work with CUI. The principal uses one company-managed Windows laptop as the only company-controlled endpoint authorized for CUI.

The company also uses 1099 contractors. When performing government work, they use Government-Furnished Equipment (GFE) onsite. The company does not grant those contractors access to its CUI environment.

For normal business communications and Federal Contract Information (FCI), the contractors may use personally owned devices to access Microsoft 365 Commercial. That environment is not authorized for CUI.

There are no company servers, no CUI printers, and no removable media used for CUI.

The Boundary We Will Use

The same system boundary will be used throughout the series. The important part is the separation: the managed laptop and authorized CUI services are inside the CUI environment, while contractor GFE, BYOD devices, and the Microsoft 365 Commercial FCI environment remain outside it.

This deliberately narrow architecture gives us a manageable example for showing how a micro-business can implement NIST-SP 800-171 without designing an enterprise network it does not need. Our solution also relies on using strategic partners when it makes more economic sense than trying to do it on your own.

What the Series Will Cover

Define the Scope: Identify where CUI exists, who can access it, what is in the assessment boundary, what stays out, and what changes would require the company to reassess scope. We will compare the cost of a variety of solutions. Scoping defines budgets as much as boundaries
Build the Architecture: Select the endpoint, identity, monitoring, vulnerability-management, and CUI storage services, while separating what the company must do from controls inherited from cloud providers.
Write the Procedures: Turn NIST SP 800-171 requirements into plain-language instructions describing what the founder actually does, when it happens, and which technology supports the process.
Prove the Do: Determine what evidence demonstrates that the procedures are actually being followed, including vulnerability reviews, access records, device compliance, logs, alerts, configuration records, and remediation evidence.
Build the SSP: Bring everything together at the NIST SP 800-171A assessment-objective level and place the procedures directly into the SSP instead of sending the assessor through a maze of separate documents.

Why Build It This Way?

A common mistake small is to start with 110 requirements and immediately begin writing policies.

That reverses the process.

First understand the business. Then follow the CUI. Draw the boundary. Select the technology. Assign responsibilities. Write the procedures. Identify the evidence. You want to use CMMC to do business better.

Then write the SSP.

By the end of this series, the SSP should be more than an assessment document. It should function as the operating manual for protecting CUI in this small environment.

We will build this outcome together.

Vulnerability Scans and a Single Device Scope: Examining A System Security Plan Example

Tue, 11 Aug 2026 10:35:57 -0400

Your System Security Plan needs to tell your compliance story. We often encounter small micro-businesses who may have just a few single laptops. These companies often rely on FedRAMP File Sharing services due to the lower start up costs. Yes, a GCCH environment may have lower costs over 2-3 years, but these contractors live RFP by RFP and do not have the CAPEX to budget three years out.

They also want to inherit as many controls as possible. Utilizing a FedRAMP authorized or equivalent File Share a small contractor has less of a compliance burden than maintaining a GCCH tenant.

Companies with one in scope user want to stay nimble and small. This means not adding a third party vulnerability tool. Yet sometimes assessors more familiar with larger environments may grow suspicious to this approach. They may not know applications on the device can get scanned. They probably do not have a handle on all the Microsoft Defender product lines or the features of Microsoft Entra.

You can not bemoan the ignorance (at least during an assessment) of a CCA. Instead assume your audience knows nothing. Use the System Security Plan to remove any need for an assessor to make an inference. Spell out all your components and how they get deployed.

We divide the SSP into two parts: a narrative front matter and a spreadsheet of 320 implementation statements at the objective level. For micro-businesses we encourage them to list all compliant procedures directly in the implementation statements. A single device contractor does not need 14 policies, 14 plans, and umpteen Standard Operating Procedures. Outside of key inventory documents all procedures can live directly in your System Security Plan

You need to beat assessors over the head with your design decisions and constantly remind them of why you have the depth and breadth in your controls to meet the NIST-SP-800-171 security controls. The assessor must walk way thinking yoru controls provide adaquete and sufficient coverage.

Use the SSP front matter to your advantage. Spell out the decisions you made. Let us look at a fictional company Asterion Systems

2.3 System Environment

Asterion Systems is a fully remote organization with no corporate office, corporate local-area network, on-premises server, cloud-hosted server, domain controller, network printer, or custom-developed application. The Asterion Systems Secure Enclave is intentionally limited to one company-owned and company-managed Microsoft Windows 11 Pro laptop and the cloud services that store, transmit, or protect CUI and ITAR-controlled technical data. The physical boundary is defined at the in-scope laptop and moves with that device when it is used at an approved remote work location.

The in-scope laptop is the only company endpoint authorized to access, process, temporarily store, or transmit CUI or ITAR data. It is Microsoft Entra joined, enrolled in Microsoft Intune, and hardened to a documented customized configuration baseline derived from the CIS Microsoft Windows 11 Level 2 Benchmark and the applicable Microsoft Implementation Guidelines. When the two sources prescribe different values for the same security setting, Asterion Systems adopts the more stringent setting unless a documented operational exception and risk acceptance have been approved. Baseline compliance is monitored through Intune, Defender, and retained configuration evidence.

Microsoft 365 Business Premium provides the organization’s commercial productivity tenant, Entra identity services, Intune endpoint management, and Defender for Office protections. The licensed security add-on provides Microsoft Defender for Endpoint Plan 2 for the managed laptop. Microsoft 365 Commercial, including OneDrive and SharePoint, is not authorized to store CUI or ITAR data under this architecture. Automatic saving and synchronization of CUI to OneDrive or SharePoint are disabled, and users are prohibited from placing CUI in unauthorized Microsoft 365 applications or locations.

The authorized FedRAMP High file-sharing service is the system of record for CUI and ITAR data and the approved channel for controlled external transfer. Provider-operated infrastructure, platform services, physical facilities, and provider patching are addressed through the provider’s FedRAMP authorization package and customer-responsibility documentation. Asterion Systems remains responsible for account approval, access configuration, endpoint security, data handling, monitoring, vulnerability review, remediation, and retention of evidence for the portions of the system it administers.

Government-Furnished Equipment (GFE) used by contractors connects only to Government systems and is not administered by Asterion Systems. GFE is not permitted to access Asterion Systems Microsoft 365 or the FedRAMP High file share. Contractor-owned BYOD devices are limited to approved FCI-only activity in Microsoft 365 Commercial and are prohibited from accessing, downloading, processing, or storing CUI. No CUI printing or network printing is authorized.

2.4 System Overview

The Secure Enclave uses a narrow endpoint-and-cloud architecture. Security services that protect the endpoint or identity plane are treated as security protection assets within the assessment scope to the extent that their correct operation affects CUI confidentiality.

2.4.1 Architecture and Boundary

The one hardened laptop is the sole company-controlled CUI asset. The FedRAMP High file share is the authorized CUI repository and transfer service. Entra, Intune, Microsoft Defender, Defender for Office, and Huntress provide identity, configuration, endpoint protection, monitoring, and response functions. The home router and public Internet provide transport only and do not establish trusted boundary protections; the endpoint firewall, device configuration, identity controls, application controls, and encrypted application sessions protect the system regardless of the remote network used. GFE, BYOD, Government systems, Microsoft 365 Commercial storage, printers, removable media, and unauthorized applications remain outside the CUI enclave and may not receive CUI.

2.4.2 Identity Components and Multifactor Authentication

Microsoft Entra provides the cloud identity for the authorized user, device registration and join state, role assignment, sign-in logging, and Conditional Access enforcement. Asterion Systems assigns a unique daily-use identity and uses a separate privileged identity for administrative actions. Conditional Access requires MFA for interactive access to Microsoft cloud resources and restricts access based on the managed and compliant status of maintained, are separately protected and monitored. Access to the FedRAMP High file share also requires an individually assigned account and MFA through Entra federation or the provider’s approved MFA service. Access is limited to authorized U.S. persons when required for ITAR data. The user has two accounts for privileged access for Microsoft 365 and for administering the FedRAMP High file sharing service.

2.4.3 Endpoint Detection and Response

Microsoft Defender for Endpoint Plan 2 is onboarded to the managed Windows laptop and serves as the endpoint detection and response capability. Defender Antivirus operates in active mode with cloud-delivered protection, behavior monitoring, tamper protection, attack-surface-reduction controls, endpoint firewall enforcement, and EDR telemetry enabled according to the approved baseline. Alerts and incidents are reviewed through the Microsoft Defender portal and the integrated monitoring workflow. The organization investigates detections, isolates the device when warranted, documents response actions, and validates recovery before returning the laptop to normal CUI use..

2.4.3.1 Defender for Office

Microsoft Defender for Office protects the Microsoft 365 email and collaboration environment using the capabilities included in the purchased plan. Asterion Systems relies on including anti-phishing, anti-malware, Safe Links, and Safe Attachments policies as part of the endpoint protection plan. Defender for Office does not make Microsoft 365 Commercial an authorized CUI repository. CUI and ITAR files must remain in the FedRAMP High file share, and links or attachments that would copy CUI into Exchange, Teams, OneDrive, or SharePoint are prohibited.

2.4.5 Security Information and Event Management

Huntress Managed SIEM provides centralized security monitoring for the in-scope environment. The Huntress endpoint agent collects supported Windows security and operational telemetry from the laptop and transmits it to the Huntress cloud service using the vendor-approved encrypted connection. Microsoft 365 and security-product audit sources are connected where supported. The FedRAMP High file share is configured to provide authentication, administration, file-access, and transfer audit events to Huntress through the provider-supported integration shown in the system diagram. Huntress correlates events, identifies suspicious activity, generates alerts, and supports investigation. Asterion Systems reviews escalations, records decisions and actions, and retains incident and monitoring evidence according to policy.

2.4.6 Identity Threat Detection and Response

Huntress Managed ITDR monitors the Microsoft 365 and Entra identity environment for suspicious account activity and security-relevant configuration conditions. The integration uses an approved application identity with only the permissions required for the service and relies on Microsoft 365 audit logging. Huntress analyzes identity and tenant events, generates managed detections, and provides guided remediation when activity indicates account compromise, unauthorized privilege or configuration change, MFA weakness, or other identity risk. Asterion Systems validates each escalation, disables or contains affected identities when required, resets credentials and sessions, corrects configuration weaknesses, and documents closure. Huntress ITDR supplements but does not replace Entra access controls or Asterion Systems' account-management responsibilities.

2.4.7 Vulnerability Scanning and Management

Microsoft Defender Vulnerability Management capabilities included with Defender for Endpoint Plan 2 are used for the in-scope laptop. The onboarded Defender for Endpoint sensor continuously discovers the device’s installed software and evaluates known software vulnerabilities and security misconfigurations. The service provides device and software inventory, vulnerability and configuration assessment, risk-based prioritization, continuous monitoring, and remediation tracking. This endpoint architecture does not rely on server scanning, virtual-machine scanning, Defender for Servers, or an agentless cloud-server scanner.

Automation does not complete Asterion Systems' vulnerability-management responsibility. The designated administrator reviews Defender findings at least monthly and when Microsoft, CISA, a software vendor, the file-share provider, Huntress, or another authoritative source identifies a new vulnerability that may affect the system. Findings are dispositioned in a ticket or vulnerability register; remediation, mitigation, approved risk acceptance, and false-positive decisions are documented; and rescans or device evidence are used to validate closure. Reports, software inventories, recommendations, tickets, exceptions, and validation results are retained as assessment evidence. Under this defined one-endpoint architecture, a separate third-party vulnerability scanner is not required while the endpoint remains fully onboarded and licensed and this review process is performed.

Organization-Defined Vulnerability Management Parameters

Parameter	Organization-Defined Value
Periodic vulnerability scanning frequency	Continuous assessment while the in-scope endpoint is online, with results reviewed and documented at least weekly.
New-vulnerability trigger	A newly published vulnerability, addition to the CISA Known Exploited Vulnerabilities Catalog, Microsoft or vendor advisory, Defender alert, Huntress notification, or other credible threat intelligence that may affect the system or an installed application.
Known-exploited, actively exploited, or critical vulnerability remediation	Within 72 hours after the organization determines that the vulnerability affects the in-scope endpoint or an installed application.
High-risk vulnerability remediation	Within 14 calendar days after the organization determines that the vulnerability is applicable.
Moderate-risk vulnerability remediation	Within 30 calendar days after the organization determines that the vulnerability is applicable.
Low-risk vulnerability remediation	Within 90 calendar days after the organization determines that the vulnerability is applicable.
Failed sensor or interrupted assessment response	Investigated within one business day after the interruption is identified.
Remediation validation	Successful remediation is confirmed using installation, version, update, or configuration evidence and updated Microsoft Defender Vulnerability Management results.

2.4.8 Patching and Update Management

Intune policies and Windows Update for Business controls manage Windows quality, feature, driver, and Microsoft product updates on the laptop. Update rings define deployment timing, deadlines, restart behavior, and reporting. Microsoft Edge and Microsoft 365 Apps use their approved managed update mechanisms; authorized third-party applications use vendor-supported update tools or are manually updated or removed when Defender identifies an exposure. Critical or actively exploited vulnerabilities are expedited according to the vulnerability-management and change-management procedures. The administrator reviews update compliance, investigates failed or pending installations, records exceptions, and confirms remediation in Defender or Intune.

Asterion Systems inherits the secure development, testing, publication, and distribution of Microsoft updates from Microsoft and the patching of provider-operated FedRAMP High file-share infrastructure from the file-share provider. These inherited functions do not transfer responsibility for configuring update policy, maintaining the laptop, approving operational exceptions, installing applicable third-party updates, or retaining evidence that the endpoint is current.

2.4.9 Encryption and Authorized CUI Data Flow

The laptop uses full-volume BitLocker encryption with TPM protection and recovery-key escrow under administrative control. CUI is downloaded only when required for an authorized business purpose and any local copy remains on the encrypted managed volume. CUI is not synchronized to OneDrive or SharePoint, copied to BYOD or GFE, stored on removable media, sent through ordinary email, or printed. The FedRAMP High provider encrypts CUI at rest within its authorized boundary and applies the provider’s approved key-management controls.

CUI and ITAR data move between the Prime CUI Portal, the hardened laptop, and the FedRAMP High file share only through authenticated HTTPS sessions using TLS 1.2 at minimum and TLS 1.3 when supported and negotiated by both endpoints. External release occurs only through the file share’s authenticated restricted-transfer workflow to an authorized recipient, including U.S.-person restrictions where required. Access controls, audit logging, expiration, revocation, and transfer records are enabled according to provider capability and Asterion Systems policy.

3.0 System Boundary Diagram

Then in your implementation statements explain how you enforce the systems described in your SSP front matter

3.11.2 — Vulnerability Scanning

Security requirement: Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.

3.11.2[a] — Vulnerability Scanning Frequency Is Defined

Assessment objective: Determine if the frequency to scan for vulnerabilities in organizational systems and applications is defined.

Implementation statement: The organization defines vulnerability scanning as the continuous assessment performed by Microsoft Defender for Endpoint and Microsoft Defender Vulnerability Management while the in-scope Windows laptop is powered on, connected to the internet, and communicating with the Microsoft Defender service. Vulnerability and configuration assessment results are reviewed and documented by the designated Security Administrator at least weekly.

The defined vulnerability-scanning scope includes:

The Windows operating system on the in-scope laptop.
Microsoft and third-party applications installed on the laptop.
Installed software versions and associated known vulnerabilities.
Missing operating-system and application security updates.
Unsupported or end-of-life software.
Security configuration weaknesses affecting the endpoint.
Microsoft Defender security recommendations applicable to the endpoint.

Event-driven vulnerability assessment is also required whenever a newly disclosed vulnerability may affect the Windows operating system, a system component, or an installed application. Triggering events include Microsoft or vendor security advisories, additions to the CISA Known Exploited Vulnerabilities Catalog, Microsoft Defender alerts, Huntress notifications, and other credible vulnerability or threat information.

The organization has no servers, network printers, custom-developed applications, or organization-managed network infrastructure within the CUI environment. Provider-owned infrastructure supporting Microsoft 365 GCC High and the FedRAMP High file-sharing service is scanned and maintained by the applicable cloud service provider. The organization verifies this inherited responsibility through applicable FedRAMP authorization documentation, customer responsibility matrices, service descriptions, contracts, and provider security communications.

3.11.2[b] — Organizational Systems Are Scanned at the Defined Frequency

Assessment objective: Determine if vulnerability scans are performed on organizational systems with the defined frequency.

Implementation statement: The in-scope Windows laptop is onboarded to Microsoft Defender for Endpoint and continuously assessed through Microsoft Defender Vulnerability Management. Defender collects operating-system, software, configuration, update, and exposure information whenever the laptop is online. Defender correlates this information with current Microsoft vulnerability and threat intelligence to identify known vulnerabilities, missing updates, and configuration weaknesses affecting the system.

At least weekly, the Security Administrator:

Confirms that the in-scope laptop appears in the Microsoft Defender device inventory.
Verifies that the laptop has recently communicated with the Defender service.
Reviews the endpoint’s onboarding status and Defender sensor health.
Reviews identified CVEs, exposed-device results, missing updates, security recommendations, and configuration weaknesses.
Compares current findings with the results of the previous review.
Creates or updates remediation tickets for actionable vulnerabilities.
Confirms that open findings remain within the organization-defined remediation periods.
Records the review date, reviewer, findings, applicability decisions, assigned actions, responsible person, and remediation due dates in the vulnerability management log.

If the laptop does not report current vulnerability information, the Security Administrator investigates the interruption within one business day. The Security Administrator documents the interruption, restores Defender sensor health or service connectivity, and confirms that vulnerability assessment results resume before closing the administrative ticket.

3.11.2[c] — Applications Are Scanned at the Defined Frequency

Assessment objective: Determine if vulnerability scans are performed on applications with the defined frequency.

Implementation statement: Microsoft Defender Vulnerability Management continuously inventories Microsoft and third-party applications installed on the in-scope laptop and evaluates installed application versions against known vulnerability information. Application assessment includes Microsoft 365 desktop applications, supported web browsers, document and PDF utilities, endpoint security software, file-sharing client components, and all other authorized software installed on the laptop.

During the weekly vulnerability review, the Security Administrator:

Reviews the Microsoft Defender software inventory.
Identifies applications associated with known CVEs or missing security updates.
Identifies unsupported or end-of-life applications.
Confirms that installed applications are authorized.
Determines whether reported vulnerable application versions are installed on the endpoint.
Opens remediation tickets for applicable findings.
Updates, removes, disables, or replaces unauthorized, unsupported, unnecessary, or vulnerable software as appropriate.
Documents the application vulnerability review in the vulnerability management log.

The organization does not develop or maintain custom applications. Provider-owned Microsoft 365 GCC High and FedRAMP High file-sharing applications are assessed by their respective cloud service providers. The organization remains responsible for locally installed clients, browsers, browser extensions, endpoint applications, and customer-controlled service configurations.

3.11.2[d] — Systems Are Scanned When New Vulnerabilities Are Identified

Assessment objective: Determine if vulnerability scans are performed on organizational systems when new vulnerabilities are identified.

Implementation statement: When a newly disclosed vulnerability may affect Windows or another system-level component, the Security Administrator performs an event-driven applicability assessment without waiting for the next weekly review.

The Security Administrator:

Records the vulnerability source, CVE or finding identifier, publication date, and organizational review date.
Determines whether the affected Windows version, operating-system component, driver, firmware, or security feature is present on the in-scope laptop.
Confirms that the endpoint is online and reporting current Defender telemetry.
Reviews Microsoft Defender weaknesses, exposed-device results, security recommendations, and threat analytics.
Determines whether Microsoft has incorporated the vulnerability into Defender Vulnerability Management.
Determines whether the in-scope laptop is affected.
Documents the basis for the applicable or not-applicable determination.
Assigns an organizational risk rating and remediation deadline when the vulnerability is applicable.
Opens a remediation ticket and begins corrective action.

If Microsoft Defender has not yet incorporated a credible vulnerability into its assessment content, the Security Administrator manually tracks the vulnerability using authoritative vendor information, installed-version information, and direct configuration inspection. Manual tracking continues until the vulnerability is remediated, determined not applicable, or incorporated into an authoritative detection method.

A Microsoft Defender Antivirus malware scan is not treated as a substitute for vulnerability assessment.

3.11.2[e] — Applications Are Scanned When New Vulnerabilities Are Identified

Assessment objective: Determine if vulnerability scans are performed on applications when new vulnerabilities are identified.

Implementation statement: When a new vulnerability is reported for an application that may be installed on the in-scope laptop, the Security Administrator performs an event-driven application assessment without waiting for the next weekly review.

The Security Administrator:

Records the CVE or finding identifier, affected application, affected versions, authoritative source, publication date, and organizational review date.
Compares the affected product and versions with the Microsoft Defender software inventory and Intune application inventory.
Confirms that the endpoint has recently communicated with the Defender service.
Searches Defender Vulnerability Management for the applicable CVE, application weakness, exposed-device result, or security recommendation.
Verifies the locally installed application version when necessary.
Documents whether the affected application and version are installed and whether the vulnerability is applicable.
Assigns an organizational risk rating and remediation deadline for each applicable vulnerability.
Updates, removes, disables, or replaces the vulnerable application within the applicable organization-defined remediation period.
Retains the basis for any not-applicable determination.

If an application vulnerability is not yet represented in Microsoft Defender, the organization manually evaluates the installed application version against the vendor advisory. The finding is manually tracked until the application is remediated or authoritatively determined not applicable.

3.11.3 — Vulnerability Remediation

Security requirement: Remediate vulnerabilities in accordance with risk assessments.

3.11.3[a] — Vulnerabilities Are Identified

Assessment objective: Determine if vulnerabilities are identified.

Implementation statement: The organization identifies vulnerabilities through continuous Microsoft Defender Vulnerability Management assessment, weekly administrative reviews, Microsoft threat intelligence, the CISA Known Exploited Vulnerabilities Catalog, vendor security advisories, Huntress notifications, Intune compliance and update reports, and cloud service provider security notifications.

For every potentially applicable vulnerability, the Security Administrator:

Records the CVE or finding identifier.
Identifies the potentially affected operating system, application, software version, component, or configuration.
Records the vulnerability source and identification date.
Confirms whether the affected component is present in the environment.
Determines whether the vulnerability is applicable.
Evaluates CVSS severity, exploit availability, active exploitation, CISA KEV status, endpoint exposure, potential impact to CUI, and existing safeguards.
Assigns an organizational risk rating.
Establishes the required remediation deadline based on the assigned risk.
Creates a remediation ticket for each applicable finding.
Retains the basis for each not-applicable determination.

Provider-owned vulnerabilities affecting Microsoft 365 GCC High and the FedRAMP High file-sharing service are managed by the applicable cloud service provider. The organization reviews provider notifications and inherited-control documentation to identify customer actions, configuration changes, or security events that may affect its authorized use of those services.

3.11.3[b] — Vulnerabilities Are Remediated in Accordance with Risk Assessments

Assessment objective: Determine if vulnerabilities are remediated in accordance with risk assessments.

Implementation statement: The organization remediates identified vulnerabilities according to the risk assigned during the vulnerability assessment.

Known-exploited, actively exploited, or critical vulnerabilities are remediated within 72 hours after applicability is determined.
High-risk vulnerabilities are remediated within 14 calendar days after applicability is determined.
Moderate-risk vulnerabilities are remediated within 30 calendar days after applicability is determined.
Low-risk vulnerabilities are remediated within 90 calendar days after applicability is determined.

The Security Administrator may shorten a remediation period based on CISA KEV status, evidence of active exploitation, availability of public exploit code, endpoint exposure, potential access to CUI, or the absence of effective mitigating safeguards.

Remediation is performed through Intune, Windows Update for Business, Microsoft Update, Microsoft Defender remediation actions, vendor-supported application updates, configuration correction, feature disablement, application removal, or product replacement.

For each applicable vulnerability, the organization:

Confirms the vulnerability and its assigned organizational risk.
Creates a remediation ticket containing the identification date, risk rating, remediation deadline, affected asset or application, and responsible person.
Selects and documents the corrective action.
Applies the update, removal, replacement, or corrective configuration within the applicable organization-defined remediation period.
Restarts the endpoint when required to complete remediation.
Confirms successful installation or configuration through Intune, Windows update history, installed application-version information, or direct configuration inspection.
Confirms that Microsoft Defender Vulnerability Management no longer reports the endpoint as exposed to the vulnerability.
Attaches remediation and validation records to the ticket.
Closes the finding only after remediation has been verified.

If remediation cannot be completed within the applicable period, the issue is escalated to organizational leadership before the deadline. The organization restricts or suspends CUI processing on the affected endpoint until the vulnerability is eliminated or an effective temporary safeguard is implemented.

Temporary mitigation, documented risk acceptance, or entry of a vulnerability into a Plan of Action and Milestones does not constitute permanent remediation while the underlying vulnerability remains present. The organization continues to track the vulnerability until permanent remediation is completed and validated.

These implementation statements might seem longer than usual. As a micro-business Asterion Systems tries to keep documentation to a minimum so all procedures got spelled out in the System Security Plan.

These procedures can probably get simplified, but this is a blog post, so not worth the effort to write shorter procedures.

Even with just a a single laptop, and using existing tools Asterion Systems realized vulnerability management required specialized help. They did not have the deep Defender and and Entra expertise needed. The monitoring and audit logging meant spening money on indirects and not charging customers for direct work. In the end Asterion Systems realized free got too expensive and they reached out to their MSP that sold them Huntress and revised the Service Level Agreement so they took over all vulnerability scans.

Can I Walk Alone? Vulnerability Scanning and NIST 171

Sat, 08 Aug 2026 13:04:51 -0400

Often times for small businesses it feels as if NIST-SP-800-171 does not scale down.

It seems to protect the confidentiality of Controlled Unclassified Information the Government built an overlay, meant for large organizations, from NIST-SP-800-53

For example, small and micro-businesses often struggle with vulnerability scanning. They get overwhelmed and this risk management family leads to a high number or organizations failing their CMMC assessments.

Vulnerability Scanning and Fully Remote Companies

A one-person company has limited time, personnel, and technical resources but must still ensure that all in-scope systems and applications are scanned for vulnerabilities. The owner wears all the hats.

This means they serve as the system administrator, security officer, and compliance manager. To meet NIST SP 800-171 requirement 3.11.2, the owner must do a ton of work.

First they must identify every device and application within the CUI environment and determine an appropriate scanning method for each. Then automated vulnerability-management software continuously assesses the company’s managed endpoint and installed applications, while any servers, printers, or network devices receive supplemental scans or documented firmware and vendor-advisory reviews.

The company must define a manageable scanning frequency, such as continuous automated assessment with a documented monthly review. The owner also monitors approved vulnerability sources and performs or confirms additional scans when a newly identified vulnerability may affect the environment.

They need to scan reports, make applicability determinations, and maintain remediation records. These must get retained in a folder or ticketing system. This approach allows the company to demonstrate that systems and applications get scanned at the defined frequency and when new vulnerabilities are identified, without requiring a large security staff or an expensive enterprise platform.

That still seems like a heavy lift for a one person company, fully remote, with a single in-scope laptop, and they struggle. What NIST-SP-800-171 specifically asks for is:

3.11.2 Scan for vulnerabilities in organizational systems and applications periodically and when new vulnerabilities affecting those systems and applications are identified.

3.11.2[a] the frequency to scan for vulnerabilities in organizational systems and applications is defined.
3.11.2[b] vulnerability scans are performed on organizational systems with the defined frequency.
3.11.2[c] vulnerability scans are performed on applications with the defined frequency.
3.11.2[d] vulnerability scans are performed on organizational systems when new vulnerabilities are identified. 3.11.2[e] vulnerability scans are performed on applications when new vulnerabilities are identified.

That seems overwhelming

Can I do It Alone?

Assuming a very small, fully remote company has only company-managed Windows endpoints, Microsoft 365 GCC High, Intune, no servers, no network printers, no custom applications, and Defender for Endpoint Plan 2, doing vulnerability management internally is practical.

Defender automates discovery and scanning, but the company must still operate and document the vulnerability-management process. Microsoft confirms that Plan 2 includes continuous monitoring, vulnerability and configuration assessment, software inventory, prioritization, and remediation tracking.

You do not need to purchase a third party vulnerability scanner if you have a fully remote company using a FedRAMP Moderate or High CSP. If you have a Business Premium account with Microsoft Defender for Servers Plan 2 (P2) you can utilize built-in vulnerability assessments powered by Microsoft Defender Vulnerability Management.

MDVM uses both agent-based tracking via Defender for Endpoint and automated agentless scanning to map software inventories, spot misconfigurations, and flag real-time security weaknesses across cloud and hybrid virtual machines. Combined with what you inherit from the CSP you have enough coverage. You still probably want an MSP to help.

What Must I do

What the company must do itself can seem daunting, but with Defender P2 add on and Defender Vulnerability Management add-on you can manage vulnerability scans.

Define the scope

Maintain an inventory of every in-scope endpoint and application. Reconcile it against Defender’s device and software inventories monthly. Investigate missing, inactive, or improperly onboarded devices.

Once you introduce printers, custom applications, or servers vulnerability scanning gets much more burdensome and a 1-3 person company should rely on farming out the work to a third party.

Define the scanning frequency

A reasonable procedure could state:

Defender Vulnerability Management continuously assesses enrolled endpoints and supported installed applications. The Security Administrator formally reviews results monthly. Additional applicability reviews and reassessments are performed when newly identified vulnerabilities may affect organizational systems or applications.

This addresses the frequency element of 3.11.2[a]. The company should avoid saying only “Defender scans continuously” without defining the formal review and new-vulnerability process. So beyond verifify Defender operates you must:

At least monthly, confirm:

Every in-scope endpoint is onboarded.
Devices are actively reporting.
Defender sensors are healthy.
Vulnerability intelligence is updating.
No endpoint has disappeared from reporting.
Software inventory corresponds to approved applications.
Intune and Defender integration remains enabled.
Review and prioritize findings

The owner must review:

Critical and high-severity vulnerabilities.
Vulnerabilities with known exploits.
CISA Known Exploited Vulnerabilities.
Vulnerabilities affecting CUI endpoints.
Unsupported or end-of-life software.
Findings that have remained open beyond the company’s remediation target.

While NIST-SP-800-171 doe snot requite The CISA KEV Catalog, it provides an appropriate prioritization source.

Address application-coverage gaps

Defender identifies vulnerabilities in supported installed applications, but not every detected application is necessarily vulnerability-assessed. Microsoft explains that software without a supported CPE may appear in inventory without vulnerability information. Microsoft software inventory documentation.

For unsupported applications, the company must do one of the following:

Monitor new vulnerabilities

Defender continuously receives vulnerability intelligence, but the company should document how it responds to important new vulnerabilities. A lightweight process means you:

Subscribe to CISA KEV and relevant Microsoft notifications.
Determine whether the affected product and version exist.
Confirm Defender has reassessed the affected endpoints or perform a supplemental version check.
Record whether the vulnerability is applicable.
Create a remediation record when applicable.
Remediate and verify

Scanning alone does not satisfy 3.11.3. The company must patch, upgrade, uninstall, mitigate, or formally manage each material finding based on risk.

Defender findings can be converted into remediation activities and Intune security tasks, although creating a remediation request does not itself install the fix.

Retain evidence

You must also save a monthly evidence package containing:

Current device inventory.
Vulnerable-devices or vulnerability export.
Security recommendations.
Open and completed remediation activities.
Newly identified vulnerability reviews.
Exceptions and false-positive determinations.
Evidence that remediated findings cleared.
Monthly review record identifying the reviewer and date.

Defender’s vulnerable-device report can show historical trends, but organizations should export and retain their own assessment evidence

Is Outsourcing Cheaper?

If you do not have the skills to correctly set up and maintain Defender does the question really matter? Still you can do a cost benefit analysis

Owner’s effective hourly value	Internal cost at 4–6 hours/month
$75/hour	$300–$450
$100/hour	$400–$600
$150/hour	$600–$900

Outsourcing becomes attractive to a fully remote 1-3 person shop when:

The owner lacks Defender or vulnerability-analysis experience.
Monthly reviews get missed.
The provider produces assessor-ready evidence.
The service includes remediation assistance
Billable hours surpass the cost of farming out work

Outsourcing does not eliminate company effort. The owner must still approve disruptive changes, accept risks, verify the provider’s work, and ensure all assets and applications are covered.

For CMMC, a provider accessing Defender data or performing security functions may process Security Protection Data and become an External Service Provider within the assessment scope. The relationship, services, and responsibilities must then be documented in the SSP, service description, and customer responsibility matrix. 32 CFR § 170.19.

A one-person company should rely on a hybrid solution for best value. The owner performs the monthly Defender review and routine remediation, while a qualified provider conducts a quarterly review and is available for significant vulnerabilities. This keeps recurring costs lower while providing independent technical support and stronger assessment evidence

For a fully remote Windows company, Microsoft Defender for Endpoint Plan 2 provides an adequate vulnerability-scanning platform because its endpoint agent assesses laptops wherever they have internet access. The company can then outsource operation of the Microsoft vulnerability-management process to an MSP or MSSP

What to outsource

The strongest arrangement would require the provider to:

Confirm weekly that all in-scope endpoints are active and reporting.
Review critical, high, exploitable, and CISA KEV vulnerabilities.
Review newly identified system and application vulnerabilities within a defined period, such as one business day for critical notices.
Determine whether affected products and versions exist.
Create and track Defender or Intune remediation tasks.
Identify software that Defender inventories but cannot vulnerability-assess.
Review vendor advisories for unsupported software.
Verify that updates or mitigations cleared the findings.
Maintain false-positive, exception, and risk-acceptance records.
Produce a monthly vulnerability-management package.
Notify the owner immediately when remediation requires downtime, application removal, licensing, or risk acceptance.

Service model	Owner effort in a normal month
Provider only reviews and reports; owner remediates	2–4 hours
Provider triages, creates tasks, tracks remediation, and prepares evidence	1–2 hours
Provider also administers Intune remediation	0.5–1.5 hours

If you do not know how Microsoft Defender works, or your billable hours surpass the cost of spending six hours a month on scanning you should outsource. If you have the skills, or willing to learn, a hybrid approach provides the lowest price point.

“You will never walk alone…” flickr photo by Thomas Leuthard flickr.com/photos/th… shared under a Creative Commons (BY 2.0) license

You want me to Count What? CMMC and Inventory

Wed, 05 Aug 2026 10:31:38 -0400

What counts when counting for CMMC?

The thing about the CMMC pause, it hasn’t really changed how one should get started with building systems that meet NIST-SP-800-171 requirements. Getting started involves getting better at doing the basics. Staying compliant for CMMC just means counting chickens and mending fences.

The discovery phase for many organizations means getting a handle on inventory. Businesses that struggle with inventory often have good problems. They have grown quickly and procedures have not kept up with contractual demands. You have different software platforms that count different things and all make pretty different dashboard, but nobody can see the full picture.

On the flip side you have microbusinesses of 1-3 employees who struggle with what feels like an overwhelming documentation burden to do Government contracting.

Most small businesses fall somewhere in the middle. For Manufactures you know how to inventory. You track BOMs and QM documents all the time. Lean into what you do well. If you

So What do you need to count?

At KNC we recommend doing your inventory with a mind toward NIST-SP-800-171 rev 3. You want these procedures to last, and under rev 2 rules you can set the frequency of what and when you count.

Site Inventory
Personnel Assets
Endpoints
Network Devices
Manufacturing Equipment
Printer Inventory
USB Assets
Mobile Devices or Enrolled BYOD
Software
SPA tools
External Connections
Service Accounts
Documentation

Each of these has it’s own worksheet in our workbook. The headings customized to follow NIST Guidance for inventories.

Chances are a small or medium size company, you already gather much of this information, but you need to have it organized to complete a self-assessment of NIST-SP-800-171. This does not have to be a spreadsheet.

A ticketing system that notes when an authorized user gets added to the system can generate reports that serve as an inventory of users authorized to access systems that store, process, or transmit CUI.

But many companies like to maintain a Source of Truth for these assets outside of any external system or tool. Just a regular old workbook with a worksheet for each item. For small companies, maintaining this data manually gets built into the boundaries you build. You will need to think about the Security Protection Assets like Endpoint Detection and Response or your security cameras (like a Ring Doorbell).

Maybe in the Age of AI doing somethings manually is the best approach to protecting the integrity and availability of your source of truth and the resiliency of your procedures overall.

What Must I Count

NIST-SP-800-171 Rev 3 explicity calls for an inventory that, while part of Configuration Management and Access Control was more assumed to happen in Rev 2.

03.04.10 – System Component Inventory

Develop and document the component inventory; review and update it at the organization-defined frequency; update it during installations, removals, and system updates.

What must be explicitly inventoried under 03.04.10

Your inventory must cover system components within the NIST SP 800-171 boundaries. Anything that

Process CUI
Store CUI
Transmit CUI
Provide security protection for components that process, store, or transmit CUI.

“System components” include identifiable hardware, software, and firmware elements such as:

Workstations, laptops, and servers
Smartphones and tablets
Printers, scanners, copiers, and other input/output devices
Firewalls, routers, switches, wireless access points, and other network components
Operating systems
Virtual machines
Database management systems
Applications
Security tools and services installed within or protecting the CUI environment
Embedded firmware and other identifiable firmware components

Inventory then comes up as evidence of your controls satisfying other NIST-SP-800-171 requirements. 03.08.01 – Media Storage states that physically controlling stored CUI media includes conducting inventories, check-out/check-in procedures, and maintaining accountability. Counting your stuff gets brought up again in the next requirement as well, Media Access 03.08.02 when inventories get mentioned as a means of controlling access and maintaining accountability for stored media.

Of course 03.03.05 – Audit Record Review, Analysis, and Reporting will rely on your inventory. You need to audit your system component inventory from 03.04.10

What else must I count

NIST-SP-800-171 rev 3 requirements may ask you to count stuff but not call it an inventory. For many small businesses much of this gets maintained by your MSP/IT consultant. Having a template to give them that explicitly lays out the requirements to count stuff will help to ensure your CMMC compliance.

Requirement	Required record
03.04.08 – Authorized Software – Allow by Exception	List of software authorized to execute, reviewed and updated at the defined frequency
03.04.11 – Information Location	Documented locations of CUI and the components on which CUI is processed or stored, including location changes
03.07.06 – Maintenance Personnel	List of authorized maintenance organizations or personnel
03.10.01 – Physical Access Authorizations	Approved and maintained list of individuals authorized to access facilities containing the system
03.15.02 – System Security Plan	Definition of constituent system components, information types, interconnections, dependencies, and individuals assigned system roles
03.05.07 – Password Management	Maintained list of commonly used, expected, or compromised passwords; this is a prohibited-password list, not an asset inventory

Nobody says counting your stuff will stop an Advanced Persistent Threat. Foxes will get it in, but you can’t understand the risk if you have not count your chickens. . A few birds will fall, but if you don’t know how many hens stay in your boundary how can you protect them at all?

Discovery and CMMC

When doing the discovery stage of a CMMC call we really focus on the documentation. The data flow diagram, another key discovery element, uses a different methodology

A company does not need to have all of these documents, many 1-3 person companies will have few to none of these documents, but these are the docs we often see that companies already have that can provide evidence or be built into an inventory of components. Many manufacturers do inventory well. You might have a mature document control process and have much of this data somewhere.

I have not updated this discovery list with Rev 3 requirements yet, but during discover really we just want to know if inventory exists, and not so much complete your inventory. More often than not we discover that you may not have an adequately organized inventory, or have no real inventory at all.

If an item on the list below is missing nobody says you have to within your organization. You need your documentation to work for you. Create stackable procedures that allow you to do business better.

(if you want a copy of the full spreadsheet send me an email to greg.mcverry@kncss.com.)

No.	Document or Evidence Requested	Associated Rev 2 Requirement(s)
1	System Security Plan	3.12.4
2	Plan of Action and Milestones (POA&M)	3.12.2
3	Information Flow Control Policy, including how and where data is handled and any external information systems used	3.1.3
4	Incident Response Plan, Policy, and/or Procedures	3.6.1, 3.6.2
5	Tabletop Exercise After-Action Report	3.6.3
6	Physical Security Policy and/or Procedures	3.10, 3.7.4
7	Sanitization and Destruction Procedures	3.7.3
8	Media Protection Policy	3.8
9a	Employee Handbook: Authorized User Agreement	3.1.1
9b	Employee Handbook: Company Acceptable Use Policy	3.1.6, 3.1.7
9c	Employee Handbook: User Agreements or User Rules of Behavior	—
9d	Social Media Policy, if not included in the Employee Handbook	3.1.22
9e	Telework Policy	3.10.6
10	HR and employee procedures covering onboarding, offboarding, transfers, background checks, access revocation, and termination	3.9
11	Employee training requirements and/or programs covering information security awareness, CUI, and insider threats, including evidence of completion and training records	3.2
12	Data Handling Procedures, Data Retention Policy, and Data Destruction Policy and Procedures	3.1.3, 3.8
13	Most Recent Risk Assessment and Risk Register	3.11
14	Prior assessments or analyses, including Level 1 or Level 2 assessments	3.11, 3.12
15	Data Flow Diagrams	—
16	Organizational Chart	—

No.	Document or Evidence Requested	Details
1	List of External Service Providers	Include External Service Providers (ESPs), Managed Service Providers (MSPs), and Cloud Service Providers (CSPs)
2	Cloud Service Provider Agreements	Agreements governing cloud services used within the assessed environment
3	Subcontractor Agreements	Agreements with subcontractors that handle CUI or provide security-related services
4	Shared Responsibility Documentation	Identification of customer, provider, and subcontractor security responsibilities and inherited controls
5	FedRAMP Authorization Documentation	Applicable FedRAMP authorization package, Marketplace listing, authorization level, and supporting documentation
6	CUI Flow-Down Clauses	Contractual clauses requiring applicable CUI safeguarding requirements to flow down to subcontractors

No.	Document or Evidence Requested
1	Facility Access Procedures
2	Badge Access Documentation
3	Visitor Log Procedures
4	CUI Storage Procedures
5	Media Destruction and Shredding Procedures
6	Site Map
7	Camera Coverage Documentation
8	Server Room Access Controls
9	Documentation of Locking Cabinets Used for CUI
10	Media Storage Area Documentation
11	Clean-Desk Practices
12	Physical Destruction Processes, Including Shredders and Destruction Bins

No.	Document or Evidence Requested
1	Physical and/or Logical Network Diagrams
2	Hardware Device Inventory
3	Software Allowlist or Whitelist
4	Data Flow Diagrams
5	Allowed List of Ports, Protocols, and Services
6	Firewall Rulesets and Other Boundary-Control Configurations
7	Recent Vulnerability Scan Reports
8	Patch Management Procedures
9	Backup Policy and Procedures
10	Business Continuity Plan and Disaster Recovery Plan
11	Change Management Procedures
12	Configuration Management Procedures
13	Mobile Device Management Documentation and/or Procedures
14	Password Policy and/or Procedures
15	Role-Based Access Control Matrix
16	User Access List, Including Privileged, Non-Privileged, and Service Accounts

No.	Security Requirement Family	Requested Documentation
1	Access Control	Policy, procedures, and plan
2	Awareness and Training	Policy, procedures, and plan
3	Audit and Accountability	Policy, procedures, and plan
4	Assessment, Authorization, and Monitoring	Policy, procedures, and plan
5	Configuration Management	Policy, procedures, and plan
6	Contingency Planning	Policy, procedures, and plan
7	Identification and Authentication	Policy, procedures, and plan
8	Incident Response	Policy, procedures, and plan
9	Maintenance	Policy, procedures, and plan
10	Media Protection	Policy, procedures, and plan
11	Physical and Environmental Protection	Policy, procedures, and plan
12	Planning	Policy, procedures, and plan
13	Program Management	Policy, procedures, and plan
14	Personnel Security	Policy, procedures, and plan
15	Risk Assessment	Policy, procedures, and plan
16	System and Services Acquisition	Policy, procedures, and plan
17	System and Communications Protection	Policy, procedures, and plan
18	System and Information Integrity	Policy, procedures, and plan
19	Supply Chain Risk Management	Policy, procedures, and plan
20	Records Retention	Records Retention Schedule

Chickens flickr photo by chumlee10 shared under a Creative Commons (BY-SA 2.0) license

Stacking Procedures Like Legos to Build Foundations of a Security Program

Tue, 04 Aug 2026 10:59:11 -0400

As a small organization creating a security plan knowing where to begin can feel overwhelming. Especially when you must also protect the confidentiality of Controlled Unclassified Information within your cybersecurity program.

Do not open up NIST-SP-800-171a and begin at 3.1.1. If you begin by creating a System Security Plan you will fail. NIST-SP-800-171 can not serve as your cybersecurity framework. CMMC does not work as a cybersecurity program.

Instead begin by focusing on how you want to do business and start to mitigate the biggest risks to your business.

Inventory
Access Control
Backups

Start to write down how you will get things done. Basically you create a Standard Operating Procedure for doing your inventory or testing your backups.

Many people find the documentation requirements to meet NIST-SP-800-171 overwhelming. That happens when you try to put in a foundation after building the house.

Instead look at your SOPs as lego blocks that you will utilize to create a cybersecurity program

You stack these SOPs into your NIST-SP-800-171 plans that can align to NIST-SP-800-171.

Begin by creatign a baseline. What do you already do? It may not have enough meat on the bones to meet 171 requirements, but you have a place to begin. Then revise your SOP so it meets the requirements.

A quick an easy template to follow would include:

Purpose: Write one or two sentences explaining why this task is done.
Scope: State who should do the task and when to use the guide.
Tools / Resources: List the software, logins, or hardware required.
Steps: Write numbered actions using active verbs (like click, save, or open).
Definition of Success: Describe what the final correct result looks

You want a document you will find useful to getting things done.

Then as you build your Procedures you will have source materials for creating the Plans to ensure your cybersecurity program meets NIST-SP-800-171. Here your LLM or large language model, commonly referred to as artificial intelligence can help out immensely. When you have your lego pieces all collected ask your LLM to create a plan to stack them together.

It helps if you feed a policy to the LLM with your SOPs and ask for it to “Create an Identification and Authentication” plan that incorporates your SOPs while meeting the regulations set forth in a policy. I have always said having 14 policies that regurgitate your intent to meet specific control families does not serve a small business, but that did not account for LLMs. The policies provide the guardrails to ensure your plans stay in compliance when creating generative content.

Now start stacking your documentation and your CMMC journey will help you do business better.

Tue, 04 Aug 2026 10:25:41 -0400

Doing the Do: Verbs and the Source of Truth with Your System Security Plan

Mon, 03 Aug 2026 15:15:45 -0400

When writing a NIST-SP-800-171 System Security Plan we have a mantra, “Say what you do, Say how it gets done, Prove you do it.”

Lot of action in that sentence, but in the end six verbs drive how you protect the confidentiality of Controlled Unclassified Information (CUI) in your system:

Defined
Specified
Identified
Established
Documented
Developed

These verbs denote a declaration of a “thing.” Then your System Security Plan points to a source of truth on the subject or thing, the security requirement. Often this happens directly in the System Security Plan and other times you point to a policy, plan, or procedure.

Defined- Clearly stated explanation of exactness or fixed limits
Specified- A condition, quantity, frequency, method, or constraint stated precisely enough to implement and test.
Identified-The applicable people, roles, devices, events, connections, can be named or listed with a specificity that allows testing
Established- A policy, process, baseline, capability, or organizational arrangement has been formally instituted and put in place which can be verified through testing.
Documented- The required information, decision, event, result, or action has been recorded in a retrievable form.
Developed- A required plan, process, capability, or artifact has been created and sufficiently elaborated for its intended use.

Across NIST-SP-800-171a almost every security requirement includes one of these six verbs in the first one or two objectives. You have to say what you do to have a System Security Plan

SSP verb	Rev. 2 objectives	Rev. 3 objectives
defined	75	95
specified	15	6
identified	62	16
established	9	23
documented	8	20
developed	2	26
Unique objectives containing at least one verb	167	173

Real World Example

Let us examine the requirements around a password in NIST-SP-800-171a

NIST SP 800-171 Rev. 2 Requirement 3.5.7 states:

“Enforce a minimum password complexity and change of characters when new passwords are created.”

You need to prove how you enforce password complexity and you can not enforce what you do not define, so we turn to the assessment objectives.

Assessment objective	Determine whether…
3.5.7[a]	The organization’s password-complexity requirements are defined.
3.5.7[b]	The required change of characters between passwords is defined.
3.5.7[c]	The system enforces the defined minimum password-complexity requirements when new passwords are created.
3.5.7[d]	The system enforces the defined minimum character-change requirements when new passwords are created.

In the first two objectives 3.5.7[a] and [b] you get to define the rules.

The organization decides what complexity means and how much a new password must differ from the previous password. The next two objectives [c] and [d] enforce the rules you just defined. Technical mechanisms must prevent users from creating passwords that violate those defined requirements.

So you do not define “Change of characters” as a password-expiration period. You must explicitly restate how many characters must differ when a user creates a replacement password. Password reuse history is addressed separately by 3.5.8.

NIST-SP-800-171a rev 2 dictates what you must define, but not where that definition lives. If you do not want a ton of new documentation you can 100% define all this directly in the SSP. Nobody says you must have a password policy.

3.5.7[a] — Password-complexity requirements are defined.

The organization defines a compliant password as one containing at least 15 characters, including at least one uppercase letter, one lowercase letter, one number, and one special character. Passwords may not contain the user’s account name, the organization’s name, or commonly used or compromised passwords.

3.5.7[b] — Required change of characters is defined.

When a password is changed, the organization requires the new password to differ from the immediately preceding password by at least four characters. Changing only capitalization does not satisfy this requirement.

3.5.7[c] — Password-complexity requirements are enforced.

The organization’s centralized identity-management system technically enforces the defined minimum password-complexity requirements. The password-policy engine evaluates proposed passwords during password creation and reset and rejects passwords that do not satisfy the minimum length, character-type, prohibited-content, and compromised-password screening requirements. Users cannot override the password-policy engine.

3.5.7[d] — Character-change requirements are enforced.

The identity-management system’s password-policy engine compares each proposed password with the user’s immediately preceding password. The system rejects the proposed password when fewer than four characters have changed or when the difference consists only of capitalization. The password cannot be activated until the defined character-change requirement is satisfied.

Some companies who must meet multiple regulatory frameworks may want to keep their definitions outside of the SSP so if they make a change the System Security Plan does not drift. You can point to the source of truth in your SSP and not include the definition._

3.5.7[a] — Password-complexity requirements are defined.

The organization’s minimum password-complexity requirements are defined in the Identification and Authentication Plan, Section 7.3, “Password Composition and Complexity Requirements.” which identifies the applicable account types and defines the minimum length, permitted and prohibited characteristics, character-composition requirements, and prohibited-password screening requirements.

3.5.7[b] — Required change of characters is defined.

The required change of characters between the current password and a newly created password is defined in the Identification and Authentication Plan, Section 7.3.2, “Password-Change Requirements.” The defined requirement applies to user-initiated password changes, administrative password resets, and password changes following account recovery.

3.5.7[c] — Password-complexity requirements are enforced.

The organization enforces the password-complexity requirements defined in the Identification and Authentication Plan through the technical configuration and administrative procedures established in the Password Policy, Section 6.2, “Password-Complexity Enforcement.” The centralized identity-management system evaluates proposed passwords and rejects passwords that do not satisfy the defined requirements. Section 8 of the Password Policy requires administrators to periodically verify the configuration and retain the resulting evidence.

3.5.7[d] — Character-change requirements are enforced.

The organization enforces the character-change requirements defined in the Identification and Authentication Plan in accordance with the Password Policy, Section 6.3, “Password-Change Enforcement.” The password-policy mechanism evaluates proposed passwords against the preceding password and prevents activation when the defined minimum character change has not been achieved. Configuration changes, exceptions, verification activities, and corrective actions are managed and documented under Sections 7 through 9 of the Password Policy.

Either option works in your SSP. You utilize the System Security Plan as a source of truth or you point to the source of truth.

“Passwords” flickr photo by paul.orear flickr.com/photos/pa… shared under a Creative Commons (BY-SA 2.0) license

DIYDy. (2026, July 31). Think of it this way, there are six verbs where the action is to write something down. “Defined,” “specified,” “identified” [Discord post]. Discord. discord.com/channels/…

You Want Me to Track What? Configuration Management and CMMC

Wed, 29 Jul 2026 10:44:34 -0400

CMMC does not scale down, because NIST-SP-800-171 did not get built for small and micro-businesses. 171 got carved from NIST-SP-800-53 which nerds and academics trained in gov speak genres wrote for the federal government.

NIST-SP-800-171 also assumes you do things as a small business that provide a foundation for cybersecurity. Sometimes this can feel like theater of the absurd to a small business.

Especially things like change management. The idea of writing a ticket to yourself, so you can do a security review, report back to yourself, so you can decide to tell yourself to make a change seems silly.

Everyone should track changes

As silly as it seems I think every company large or small should have a “ticketing system” and a record of change. I don’t care if you sit at the only desk in a company with no physical headquarters or have a staff of a hundred. Tracking the decisions about what you change, and why, makes you better at business.

You do not need a commercial ticketing system. Though the price point of many may make them cheaper than manually doing it for free. Regardless of your solution rely on more than email or disorganized notebooks

I will always recommend, even the smallest of companies to have a ticketing system. More likely you bring the ticketing system from your MSP in scope. You may still want your own internal ticketing system. The price of your labor doing this manually will exceed the monthly licensing costs.

Some companies, because of data security may want to keep all their data within their boundary. Utilizing Microsoft Forms with Conditional Access eliminates an external connection to your system. If you know how to do stuff with Automate and Powershell you can utilize the data in fun ways.

NIST-SP-800-171 demands you track changes, and revision three only gets more explicit.

What Changes Must I Track

I am a huge fan of starting your change process early in your 171 implementation and letting it grow with your maturity. You do have certain baselines you must meet for CMMC compliance.

Change-management topic	Rev. 2 requirement	Rev. 3 requirement
Configuration change control	3.4.3: Track, review, approve or disapprove, and log changes to organizational systems.	03.04.03: Define configuration-controlled change types; review and approve or disapprove changes considering security impacts; implement and document approved changes; and monitor and review change activities.
Security impact analysis	3.4.4: Analyze the security impact of changes before implementation.	03.04.04(a): Analyze potential security impacts before implementation. 03.04.04(b): Verify security requirements remain satisfied after implementation.
Security consideration in approval	Security-impact analysis was a separate requirement; 3.4.3 did not expressly require it as part of the approval action.	03.04.03(b): Approve or disapprove changes with explicit consideration of security impacts.
Defining what requires change control	Discussed in supporting material, but not an explicit requirement statement.	03.04.03(a): Define the types of configuration-controlled changes.
Documenting implementation and reviewing activity	Tracking and logging were required; implementation and testing appeared primarily in discussion.	03.04.03(c)–(d): Implement and document approved changes; monitor and review change activities.
Access restrictions for changes	3.4.5: Define, document, approve, and enforce physical and logical access restrictions associated with changes.	03.04.05: Same substantive requirement.
Baseline update and review	3.4.1: Establish and maintain baseline configurations and inventories throughout the system lifecycle.	03.04.01: Review and update baselines at an organization-defined frequency and update inventories when components are installed, removed, or updated.
Approved deviations from settings	3.4.2: Establish and enforce security configuration settings.	03.04.02(b): Identify, document, and approve deviations from established configuration settings.

In Rev 2 you had to track, review, approve or disapprove, and log changes to organizational systems. Rev. 3 turns the single requirement into four explicit outcomes. A procedure should now define the changes requiring tickets/approval, record the security consideration, document implementation, and require monitoring/review of the completed change. Meaning your ticket should have these fields

Rev. 3 also added a post-change validation, and not just a pre-change impact assessment like Rev 2. The ticket should record a test/validation result, such as confirmation that Intune compliance, MFA, logging, segmentation, encryption, or other affected controls still work.

The security review required in Rev 2 also got more explicit in Rev 3. Any change ticket should record a security review. Large organizations would probably rely on a secondary ticket or a security review form. Small shops should just include this in your ticket. You must also explicitly define your change types. Either ask your LLM to spin up definitions in your Configuration Management plan or add the explicit definitions right to the body of your ticket.

You also need to prove you reviewed what happened after the change. I would add a field to your ticket, but you might want to save other evidence along the way.

For a Rev. 3-ready change-management procedure, the minimum ticket workflow is:

Classify whether the requested work is configuration-controlled.
Document the proposed change and security impact.
Obtain approval or disapproval.
Implement and document the work.
Test that affected security requirements remain satisfied.
Update the baseline, inventory, and approved-deviation record where applicable.
Retain logs and periodically review completed changes.

How Can a Small Business Manage All This

Not by email. Companies who try to track these procedures almost always fail. People do not hit reply all when they should and hit hit reply all when they shouldn’t. Template emails don’t get used. You have to search through mailboxes.

Why not just use a Microsoft (or Google) form?

You can create all the fields, and have a tidy spreadsheet to track everything:

You can even record who made the ticket, restrict it just to people at your company, or only to people authorized to request changes.

Directions

🧩 Build the form structure

Create a new form
- Open Microsoft Forms.
- Select New Form.
- Set the form title to: NIST SP 800‑171 System Change Record.
- Add the form description exactly as written in your template.
Section 1 — Change identification
- Question 1 — Change ID
  - Add → Text
  - Title: Change ID
  - Required: On
  - Subtitle: Enter the same Change ID on every submission…
- Question 2 — Record type
  - Add → Choice
  - Title: Record type
  - Required: On
  - Choices:
    - Open/Authorize Change
    - Close Change
    - Cancel or Roll Back Change
  - You will add branching later.
Section 2 — Open/Authorize Change
- Shown only when Record type = Open/Authorize Change.
- Question 3 — Proposed change
  - Add → Text → Long answer
  - Required: On
  - Title: Proposed change
  - Description: Describe the proposed change…
- Question 4 — Security impact and implementation plan
  - Add → Text → Long answer
  - Required: On
  - Title: Security impact and implementation plan
  - Description: Describe the potential security impact…
- Question 5 — Authorization decision
  - Add → Choice
  - Required: On
  - Title: Authorization decision
  - Choices:
    - Approved
    - Disapproved
    - Emergency change—approved for immediate implementation
    - More information required
  - Subtitle: Only the owner or another person designated…
  - Branching: Any answer → End of form
Section 3 — Close, cancel, or roll back
- Shown when Record type = Close Change or Cancel or Roll Back Change.
- Question 6 — Result and validation
  - Add → Text → Long answer
  - Required: On
  - Title: Result and validation
  - Description: State what was implemented…
- Question 7 — Final status and documentation disposition
  - Add → Choice
  - Required: On
  - Title: Final status and documentation disposition
  - Choices:
    - Completed—baseline and affected documentation updated
    - Completed—no baseline or documentation update required
    - Completed—documentation update still pending
    - Rolled back
    - Cancelled
    - Unsuccessful—additional action required
  - Subtitle: A documentation update may include…
  - Branching: Any answer → End of form

🔀 Configure branching

In Microsoft Forms:
- Click … (More options) → Branching.
For Record type:
- Open/Authorize Change → Question 3
- Close Change → Question 6
- Cancel or Roll Back Change → Question 6
For Question 5 — Authorization decision:
- All choices → End of form
For Question 7 — Final status:
- All choices → End of form

This creates the requested workflow.

⚙️ Configure form settings

Go to … → Settings.
- ✔ Only people in my organization can respond
- ✔ Record name
- ✖ One response per person — turn off
- ✖ Allow respondents to edit responses — turn off
- ✔ Email notification of each response
- Optional: Response receipts

This ensures identity tracking and timestamps appear in the Excel workbook.

📊 Excel output

Forms will automatically create columns such as:
- Name
- Start time
- Completion time
- Change ID
- Record type
- Proposed change
- Security impact and plan
- Decision
- Result and validation
- Final status
Filter the workbook by a Change ID such as CHG-YYYY-### to view the complete lifecycle of that change.

When you read the standards thinking about a “Change control board” for a company of one can seem silly. You don’t need to think that big. Come up with a change system that works for you, and a ticketing system will work better.

If you want to, or need to roll your own, this form provides a tool that can work as part of your 171 system.

Img credit: “Confused” flickr photo by slava https://flickr.com/photos/slava/1167335643 shared under a Creative Commons (BY 2.0) license

Tue, 28 Jul 2026 16:12:50 -0400

CUI vs ITAR in your shop work flow

Creating Role Based Training Programs

Tue, 28 Jul 2026 10:05:39 -0400

When you compare the evolution of NIST-SP-800-171 rev 2 to NIST-SP-800-171 rev 3 you can see the emphasis on training grow. We now focus not just on awareness and training, but on security literacy and awareness. Patching the people has become an even greater priority.

Yet companies can struggle with developing role-bases trainings. Large companies rely on commercial products, but may have workers who can not dedicate time to training. Small companies with one to two people may not understand how you differentiate role based training when you have all the roles.

In NIST-SP-800-171 rev 3 you must:

Provide training before personnel receive access or perform assigned security roles, and repeat training at an organization-defined frequency and following specified changes or events.

Yet companies do not know where to begin with role based training. Many end up providing a compliant solution without thinking deeply on how to patch their people. You have many routes to meeting the role based training requirements

Certifications Required Before Hiring

NIST-SP-800-171 rev 3 requires training before people have access to Controlled unclassified information and the security stackFor companies big and small you can do your role training a priori, or before hiring. You simply require a specific certificate for a role. Say a Security+, CISSP, or specific AWS cloud certifications if that fits your stack.

Then during the course of a year employees must maintain their CEUs based on that certification. If your company utilizes a GCC or GCCH stack you can require employees to have specialized certifications.

For a small organization using Entra, Intune, Defender, and Purview, I would prioritize:

SC-900 — Security foundation. Appropriate for management, compliance staff, help desk personnel, and technical personnel who need a common Microsoft security vocabulary.
MD-102 — Endpoint administration. Primary credential for personnel administering Intune-managed CUI endpoints, Windows security settings, applications, updates, and Defender for Endpoint.
SC-300 — Identity and access. Primary credential for Entra ID, MFA, Conditional Access, access reviews, privileged roles, and account lifecycle management.
SC-401 — Information Protection. Appropriate when Purview, DLP, retention, insider risk, or sensitivity labels protect or prevent the mishandling of CUI.
SC-200 — Security monitoring and incident response. Appropriate for personnel reviewing Defender XDR alerts, logs, incidents, and threat information.
SC-100 — Security architecture. Appropriate for the individual designing or approving the overall Microsoft security architecture and integrating identity, endpoints and GCC or GCCH.

Sponsoring Certification Trainings

Companies do not have to require certifications before someone gets hired. This just helps to to meet requirements that training gets complete before authorized access. For ongoing role based training companies may choose to sponsor employees classes and certification demands

Assigning Required 171 Training Per Role

A micro-business can meet this requirement by relying on content required under NIST-SP-800-171 and assigning it to only specific roles. Have a CUI enclave? Only assign the Mandatory CUI training to inscope users. Need to do Internal threat training? Just have management complete it. Want to address the new incident response training requirements? Assign it to the IR team.

You now have role based training and did not need to create additional content beyond what NIST-SP-800-171 requires.

Annual Conference Attendance

Some companies provide a professional development budget for their staff. This counts as role-based training. Just make sure you have procedures in place to ensure employees select conferences related to your security role.

Contributing to the Knowledge Base

Most companies struggle with documentation and maintaining a knowledge base for their procedures. Editing and maintaining your company docs takes time and skill. Recognize this effort as part of official training. As your IT folks write, or curate AI written procedures, they learn much better than they do with a passive PowerPoint.

You do have to think about the role of AI and how the offboarding of cogntive load impacts using the Knowledge bases as a training device/

Policy Acknowledgements

Having assets read and sign a policy acknowledgement gets used by many small and micro businesses to meet the role based training requirements.

You collect the acknowledgement sheet or have employees sign an electronic form.

Create an Annual Professional Growth Plan

A company can get employees to participate in their role based training. Have a procedure in place where employees must choose annual learning goals and describe the steps they will take. If you have an annual professional development budget developing personal learning plans provides great accountability.

You may already submit a plan for an annual review that can be updated to track self selected role-based training.

Department Meetings

You do not have to sit for a formal training to gather evidence for NIST-SP-800-171 rev 3. Maybe you have department meetings to discuss which alerts should get required reporting. Maybe you host a lunch and learn for all your machinists and review the policy of not putting the USB drive attached to the big ugly stick in your pocket. These scheduled security meetings count as role based training.

The minutes and agendas, combined with a sign in sheet can meet your evidence requirements. Pizza helps with compliance.

Commercial Curriculum

If you utilize a vendor like KnowBe4 or have the learning add-on for Huntress you can create a role based training program. Many vendors include a commercially available training product. If you assign some content to some people and different content to others, you have done role based training.

Your vendor, if you utilize different companies for vulnerability scans, SIEM, EDR, Firewalls, etc., probably have training available to customers, or at least documentation you can use to create lessons. Many vendors offer weekly or monthly webinars assets with security roles can attend.

Just map existing curriculum to your roles.

Make it Your Plan: Take Back Control of Your POAM

Mon, 27 Jul 2026 12:47:08 -0400

You may toil with a consultant for hours over your System Security Plan. You have probably marked a dozen snakeoil emails as spam after they promised to get plans in place in hours or minutes. But have you ever used your SSP as the document to guide your CUI protection? Have you created a plan that actually helps you get stuff done?

Your plan, for your business, must assist you in planning to do your business, or you have no plan at all. Stop thinking of your Plan of Action & Milestones as a required CMMC compliance document.

Plans take steps to get stuff done. Your POAM describes the steps and sets key milestones to getting that stuff done. It should list who will get that stuff done, and when they will complete the steps to do the stuff.

You do not have to wait until you have a System in place for NIST-800-171 to handle Controlled Unclassified Information. Once you know will engineer a system to protect the confidentiality of CUI start a POAM. Make a punch list. Get it done.

Plan of Action And Milestones

The POAM comes out of NIST-SP-800-53, which NIST designed for federal systems. This means guidance, and AI created templates may not fit the unique needs of your business.

Just think of the POAM as your punch list for getting things done. Directly from NIST-SP-800-53 we get a definition o the Plan of Action and Milestone as:

Control: a. Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system; and

b. Update existing plan of action and milestones [Assignment: organization-defined frequency]based on the findings from control assessments, independent audits or reviews, and continuous monitoring activities.

People may read the first bullet point and think, “Gee the POAM comes after the assessment,” but if you look to the second half you update your existing Plan. Meaning it existed before the assessment

Meaning a POAM does not pop out as some bastard child of a a Gap Analysis, you create a Plan of Action and Milestone when you begin to engineer a system to protect the confidentiality of CUI. That system came into existence when you accepted 7012 flow downs.

Make your list, start getting stuff done. In related controls of -53 NIST goes on to define the POAM process:

PLAN OF ACTION AND MILESTONES PROCESS

Control:

a. Implement a process to ensure that plans of action and milestones for the information security, privacy, and supply chain risk management programs and associated organizational systems:

Are developed and maintained;

Document the remedial information security, privacy, and supply chain risk management actions to adequately respond to risk to organizational operations and assets, individuals, other organizations, and the Nation; and

Are reported in accordance with established reporting requirements.

b. Review plans of action and milestones for consistency with the organizational risk management strategy and organization-wide priorities for risk response actions.

That sounds like a lot for a small business. Remember, NIST wrote 53 for federal systems. In 171 revision three we find:

03.12.02 Plan of Action and Milestones

a. Develop a plan of action and milestones for the system:

To document the planned remediation actions to correct weaknesses or deficiencies noted during security assessments and

To reduce or eliminate known system vulnerabilities.

b. Update the existing plan of action and milestones based on the findings from:

Security assessments,

Audits or reviews, and

Continuous monitoring activities.

The important commonality? You make a risk based decision based on your businesses. So many companies try to get a CUI enclave built and they don’t have basic back ups and MFA solved across the commercial enterprise. Those companies, unless facing pressure on a contract or from a Prime, have set the wrong milestones based on risks.

CMMC does not serve as your cybersecurity plan. NIST-SP-800-171 does not give you a cybersecurity framework. You nest how you meet the requirements within your larger security plan. That does not mean you can’t use CMMC and 171 to get better at the basics. If you create a punchlist based on risks, you by nature of thise risks knock out the basics, first, on your way to meeting 320 objectives.

Now let’s say you used this for your punch list to towards CMMC compliance. Would your Plan of Actions and Milestones move you toward the goal?

Item	POA&M Action	Primary NIST SP 800-171 Rev. 2 Requirement	Related Requirements	Compliance Considerations
1	Inventory hardware, software, firmware, and other system components.	3.4.1 — Establish and maintain baseline configurations and inventories of organizational systems.	—	The inventory should include hardware, software, firmware, and relevant documentation within the CUI system boundary.
2	Establish a method for tracking system changes.	3.4.3 — Track, review, approve or disapprove, and log changes to organizational systems.	3.4.4, 3.4.5	A spreadsheet may be sufficient if it records the requested change, security-impact analysis, approval, implementation, testing, and closure.
3	Document where CUI enters, moves through, and leaves the organization.	3.12.4 — Develop, document, and periodically update the System Security Plan.	3.1.3, 3.13.1, 3.13.2	Business-flow, data-flow, and network diagrams should identify the CUI boundary, external connections, internal connections, users, systems, and service providers.
4	Implement and test multifactor authentication.	3.5.3 — Use multifactor authentication for privileged and nonprivileged accounts when required.	3.5.1, 3.5.2	Rev. 2 requires MFA for local and network access to privileged accounts and network access to nonprivileged accounts. Testing should cover every applicable access path.
5	Remove, replace, or protect unsupported and end-of-life systems.	3.14.1 — Identify, report, and correct system flaws in a timely manner.	3.11.3, 3.4.6, 3.4.7	Unsupported products should be upgraded, replaced, removed, isolated, or addressed through documented alternative safeguards.
6	Back up information and test restoration procedures.	3.8.9 — Protect the confidentiality of backup CUI at storage locations.	—	Rev. 2 does not contain a general backup or restoration-testing requirement. Requirement 3.8.9 applies when backups contain CUI and focuses on protecting their confidentiality.
7	Conduct vulnerability scanning and review the results.	3.11.2 — Scan for vulnerabilities periodically and when new vulnerabilities are identified.	3.11.3	Scanning addresses 3.11.2. Findings must also be prioritized, tracked, and remediated under 3.11.3.
8	Establish a controlled enclave for processing, storing, and transmitting CUI.	3.12.4 — Document the system boundary and security requirement implementation.	3.1.3, 3.13.1, 3.13.2	NIST SP 800-171 does not specifically require a CUI enclave. An enclave is an architectural approach that can reduce scope and support multiple security requirements.
9	Restrict and test access to the CUI enclave.	3.1.1 — Limit system access to authorized users, processes, and devices.	3.1.2, 3.1.3, 3.5.1, 3.5.2, 3.12.1, 3.13.1	Testing should verify authorized users, approved devices, permitted functions, authentication, information-flow restrictions, and boundary protections.
10	Establish rules governing AI use and information sharing.	3.1.3 — Control the flow of CUI in accordance with approved authorizations.	3.1.20, 3.1.22, 3.2.1, 3.2.2	Rev. 2 contains no AI-specific requirement. Policies should prohibit entering CUI into unapproved AI services and should be supported by training, access restrictions, and technical controls.

As a small business owner, which Plan of Action will serve you better as a punchlist? You might make more headway with a simplified POAM, like the one in the image, and by the time you complete you would understand the mappings to NIST-SP-800-171 in the second table.

Don’t wait on the POAM. Make your punch list today and do the work. How you get stuff done.

Overtime your POAM will evolve, and it will look more formalized following your Gap Analysis, but never forget the “action” in POAM. The tool lives in situ, not as an artifact. And don’t forget the word Plan in both SSP and POAM. If you don’t find these documents useful to getting stuff done do you really have a plan at all?

Start small and iterate.

Patching your People with Rev Three ODPs

Fri, 24 Jul 2026 09:50:16 -0400

I don’t have a naughty nature, so I will refrain from ODP puns and discuss how Patching your People through your Security Training program needs to evolve with the transition to NIST-SP-800-177 Rev 3 from Rev 2.

NIST SP 800-171 Revision 3 introduces both theoretical and operational changes to the Awareness and Training family. Over the years the emphasis on training becomes stronger and stronger while we spend more assuming breach and expecting systems have already failed. We know over 80% of breaches begin with your people. Revision three of NIST-SP-800 171 went beyond the general requirements found in Revision 2. Revision 3 replaces the general awareness requirement with security literacy training.

This new theoretical definition seeks to emphasize that personnel must not only complete security information training but must understand and be able to apply foundational security knowledge.

Literacy as Security or GRC = General Reading Comprehension

Scholars and nerds have used the word “literacy” for differentiating applied knowledge and contrasting this with declarative knowledge for a long time. Basically knowing and doing = literacy. Sylvia Scribner in her 1984 piece “Literacy in Three Metaphors" kicked off the trend and argued literacy does not have a single, context-free essence. She analyzed three metaphors:

Literacy as adaptation — the skills needed to function effectively in everyday life.
Literacy as power — the capacity to analyze conditions and act upon them.
Literacy as a state of grace — literacy as intellectual, cultural, or personal development.

The first metaphor finds a home wit compliance and NIST. Under the adaptation model, literacy allows functioning in a particular social and technological environment.

Think about stuff like:

security literacy
health literacy
financial literacy
scientific literacy;
information literacy
digital literacy

In 1999 the National Research Council published, “Being Fluent with Information Technology.” The committee deliberately preferred fluency over basic “computer literacy.” It described information-technology fluency as having three interconnected components:

contemporary skills — the ability to use current technological tools
foundational concepts — understanding the enduring principles underlying technology
intellectual capabilities — the ability to reason about information, manage complexity, solve problems, and adapt knowledge to new situations

The NIST definition included in NIST-SP-800-53, which spawned the revision to 171, best aligns with theoretical constructs similar to Yoram Eshet-Alkalai’s,“Digital Literacy: A Conceptual Framework for Survival Skills in the Digital Era,” which was published in 2004.

Folks would make academic careers writing pieces debating if we really meant technology fluency or literacy (technically my PhD was from the New Literacies Research Lab…we really stretched the metaphor).

Training Roots

The emphasis gets placed on functioning effectively, not possessing declarative knowledge alone. NIST baked this functional definition of security literacy in long-standing awareness-and-training model in SP 800-50 and SP 800-16.The original NIST SP 800-16 (1998) contains a section expressly titled “3.1 Definition and Purpose.” which defines IT security literacy as:

“An individual’s familiarity with—and ability to apply—a core knowledge set…needed to protect electronic information and systems.” definition fits squarely within these broader educational traditions.

It defined IT security literacy as familiarity with and the ability to apply a core knowledge set needed to protect information and systems.The first version of SP 800-50 contained descriptive definitions in Chapter 2, although it did not use “literacy training” as a principal formal term. It distinguishes the learning continuum as following awareness, training, education, and professional development

NIST publication	Concept	Meaning
NIST SP 800-53 Rev. 5 — AT-2	Literacy Training and Awareness	Foundational security and privacy learning for system users, delivered initially, recurrently, and when changes or events require it. Users learn why security matters, what actions they must take, and how to respond to suspected incidents.
NIST SP 800-50 Rev. 1 — Appendix B	Awareness Training	The foundational cybersecurity or privacy training program for all personnel. It helps learners understand their role in protecting information, cybersecurity, and privacy-related assets. SP 800-50 Rev. 1 expressly notes that this is called “literacy” training in SP 800-53 Rev. 5.
NIST SP 800-16 — Chapters 2–3	Security Basics and Literacy	An individual’s familiarity with—and ability to apply—a core knowledge set needed to protect electronic information and systems. Security literacy represents the transition between passive awareness and specialized, role-based training.
CyberDI	Security Literacy	The ability to understand and apply foundational security knowledge so a person can recognize risk, protect information and systems, and take the correct action in context.

Literacy in Action

This concept of security literacy training gets operationalized through role based training. This now reflects a more lifecycle approach. Revision 2 required organizations to make managers, system administrators, and users aware of security risks and applicable security requirements; train personnel to perform their assigned security duties and provide awareness training on recognizing and reporting potential insider-threat indicators. Revision 3 incorporates the former standalone insider-threat requirement into this broader literacy requirement rather than eliminating it.

The assessment objectives in NIST-SP-800-171a call for some evidence of measuring a users’ knowledge and identifies continuing awareness activities that reinforce literacy. These can include advisories, login messages, videos, webinars, and other awareness events.The revisions also call for specific content. A training must address the actions users are expected to take to maintain security. Rev 3 includes explicit requirements to train employees to respond to incidents and protect CUI. They must continue, like Rev 2 to recognize and report indicators of insider threats. Revision three does explicitly add social engineering and social mining as required content.

Awareness and Training: CMMC Rev. 2 to Rev. 3 Crosswalk
Rev. 2 Requirement	Rev. 2 Focus	Rev. 3 Requirement	Rev. 3 Focus	Change
3.2.1	Ensure managers, system administrators, and users understand the security risks associated with their activities and the applicable policies, standards, and procedures.	03.02.01 — Literacy Training and Awareness	Provide and periodically update security literacy training. Training includes recognizing and reporting insider threats, social engineering, and social mining.	Expands general awareness into recurring security literacy training with defined content, update requirements, and event-driven training.
3.2.2	Ensure personnel are trained to perform their assigned information security duties and responsibilities.	03.02.02 — Role-Based Training	Provide training before personnel receive access or perform assigned security roles, and repeat training at an organization-defined frequency and following specified changes or events.	Adds explicit timing, frequency, role-based content, and training-update requirements.
3.2.3	Provide security awareness training on recognizing and reporting indicators of insider threat.	03.02.03 — Withdrawn and incorporated into 03.02.01	Insider-threat recognition and reporting are included within Literacy Training and Awareness under 03.02.01.	The requirement is retained but consolidated with general security literacy training rather than maintained as a separate requirement.

Security Literacy and Organizational Defined Parameters

One of the biggest changes to the training family involves frequencies and triggers. Under Revision 2 an organization assigned frequency and just needed to prove the rules got followed. In Rev 3 the annual requirement remains but specific triggers for content update were added to organizational defined parametersOverall, the change from Revision 2 to Revision 3 moves awareness and training from a relatively static, compliance-oriented activity toward a continuous, role-sensitive learning program. Organizations must now define training frequencies and triggering events, periodically review and update course content, and revise training after events such as system changes, audit findings, incidents, changes in threats, or changes to applicable requirements. The practical expectation is no longer satisfied merely by assigning an annual awareness course and retaining a completion record.

Organizations should be able to demonstrate that training is timely, relevant to their environment and CUI-handling practices, appropriate to each person’s responsibilities, reinforced through continuing awareness activities, and effective in developing the knowledge personnel need to recognize risks and act securely.

NIST SP 800-171 Rev. 2 and NIST SP 800-171 Rev. 3.

NIST SP 800-171 Rev. 3 — 03.02.01 Literacy Training and Awareness ODPs
Requirement	Objective	Organization-Defined Parameter	Assigned Value
03.02.01	03.02.01.a.01	Frequency after initial security literacy training	Annually
03.02.01	03.02.01.a.02	Events requiring additional security literacy training	Significant changes Incidents or breaches Legal, regulatory, or contractual changes Audit or assessment findings Material threat changes
03.02.01	03.02.01.b.01	Frequency for reviewing and updating security literacy training content	Annually
03.02.01	03.02.01.b.02	Events requiring security literacy training content updates	Significant changes Incidents or breaches Legal, regulatory, or contractual changes Audit or assessment findings Material threat changes

Updating your Security Training Program

If you have a mature Awareness and Training Program for your organization you can easily update for NIST-SP-800-171 rev 3. You need to add new content around social engineering and mining, and update your plans to account for ODP triggers.Need to begin formulating a real security training program beyond the annual video you make staff suffer through?

Start with your risk assessment. Your employees must get trained on the risks to CUI in your system. You can not develop a compliant training without first conducting a risk assessment
Identify all the learning objectives you want to cover in your program. I expand beyond the security literacy domain and think about all controls that could benefit from training. For example, take removable media. At a minimum employees should sign an Acceptable Use Policy they understand how to handle removable media. That’s training.
Then decide which role must demonstrate they met the objective.
Next map all the training you currently provide* Then crosswalk against the objectives to make sure they all get met* Create any custom content to fill in the holes
Develop a flexible plan that allows you to deliver just in time awareness training.

Feel free to check out and remix my training matrix.

The list of potential classes in my example aligns more with a mid-size company. You can collapse much of the content into a single learning event. For example you could require specific certs and CEUs for role based training. Your social media mining might get covered in the general training for all employees.

You would delete my row of content and add the current training you require. Mark off what objectives get hit, and then fill in the holes by revising content or making new lessons.

Wed, 22 Jul 2026 22:11:24 -0400

Updated the “Is it CUI” decision tree again with feedback from Discord. Added a a contract review step once unmarked files are stored in systems meant for Controlled Unclassified Information.

Wed, 22 Jul 2026 15:43:36 -0400

Updated draft of “Is it CUI?” Flowchart.

Wed, 22 Jul 2026 11:23:59 -0400

Very early draft of a CUI marking decision tree. Not an export lawyer. Welcome feedback.

Wed, 22 Jul 2026 09:59:08 -0400

Draft of Scoping Decision Tree