CMMC Scoping for Defense Contractors: What to Map First

CMMC scoping starts with a practical question: where does contract information actually move, and what makes that work possible? A useful answer is rarely limited to one folder or a list of laptops. It includes the people who handle the work, the business process they follow, the accounts they use, the systems that store or transmit information, and the supporting services that make those systems available and protected.

That level of clarity matters before a contractor buys tools, writes policies, or begins remediation. Without it, teams either try to secure the entire company as if every system carries the same risk, or overlook a supporting account, vendor, or workflow that can still affect the environment. Neither creates a reliable readiness path. The goal is a boundary leadership can understand, validate, and keep current as contract work changes.

1. Start with the contract work, not the technology inventory

Begin with the solicitation, contract, task order, delivery order, and any security clauses connected to the opportunity. The DFARS CMMC requirements make the contract the starting point for determining when a CMMC level applies. That means the first scoping conversation should focus on the work being performed, the information being exchanged, and the parties involved, rather than starting with a generic list of every technology asset the company owns.

Ask the business team to describe the workflow in plain language. Who receives the information? Who reviews, creates, changes, approves, or sends it? Does a prime contractor, subcontractor, outside consultant, or cloud provider participate? Does the work happen from an office, a home office, a client site, or more than one location? The answers give the technology team a factual path to follow.

It is also important to distinguish federal contract information from controlled unclassified information. Both are nonpublic in the contract setting, but controlled unclassified information carries handling or safeguarding controls. Do not decide the category from a filename or an assumption. Keep the contract language, the program office's direction, and any relevant marking or handling instruction with the scoping record so the organization can explain why a particular workflow belongs inside or outside the boundary.

2. Trace the information through the real workflow

Once the work is clear, follow the information from arrival to retention or disposal. A simple map can begin with a single example: a file arrives through email, is saved to a collaboration platform, is reviewed by an employee, shared with an approved partner, and backed up. That one path immediately raises useful questions. Which account received it? Where is the service administered? Which devices can open it? What identities have access? Which logs, backups, and help desk tools can expose or protect it?

Do not make the map a technical art project. Its value is that a contracts lead, operations leader, and technology owner can look at it together and spot omissions. Give each workflow a clear name, show the main systems and users involved, and note where a handoff leaves the company or crosses into a supporting service. When a workflow cannot be explained in a few minutes, it is usually a sign that ownership or system design needs closer attention.

Include the ordinary paths as well as exceptions. Employees may download a document to work offline, forward a message to a personal mailbox, print a record, join a meeting from a phone, or ask an outside technician for support. The goal is not to assume bad behavior. It is to understand how the business actually gets work done, then make deliberate choices about which paths are permitted and how they are protected.

3. Include systems that protect the environment

The systems holding files are not the whole story. NIST SP 800-171 Rev. 3 applies its security requirements to components that process, store, or transmit controlled unclassified information and to components that provide security protection for those components. In practical terms, a company needs to look beyond the document repository to the identity platform, endpoint management, security monitoring, backup service, network equipment, remote support tools, and administrator accounts that can affect the protected environment.

Start with a short list of supporting services and test each one. Could this service grant access, reset a password, manage a device, change a security setting, copy data, restore files, or otherwise affect the protected workflow? If the answer is yes, capture the relationship. That does not automatically mean every service receives the same treatment, but it prevents a false boundary based only on where documents are stored.

Cloud services deserve the same direct questions. Record the service name, business owner, administrator roles, information handled, access method, logging approach, backup or retention arrangement, and the vendor documents that support the intended use. A cloud platform can reduce operational burden, but it does not remove the contractor's need to understand where information resides and how access is governed.

4. Map people, privileges, and external access

Scope is also an access question. List the people who can perform the contract work, administer the systems involved, approve changes, review logs, restore data, or support users. Include executives, temporary staff, internal IT, managed service providers, cloud administrators, software vendors, and subcontractors. A person does not need to handle a contract file directly to affect the environment. Privileged access, remote support, account recovery, and vendor administration can all matter.

For each role, document why access is needed, which systems the role can reach, who approves it, and what should happen when the responsibility changes. This is where an ordinary onboarding and offboarding process becomes part of readiness. If a former employee, contractor, or vendor retains access because ownership is unclear, a carefully drawn scope on paper will not protect the real environment.

Pay special attention to shared accounts, break-glass administrator accounts, legacy vendor access, and unmanaged personal devices. These are not always instant failures, but they deserve a conscious decision and an owner. When a company cannot identify who controls a powerful account, it has found a priority before an assessor needs to point it out.

5. Confirm locations, connections, and devices

People and systems operate somewhere. Note the office locations, remote-work arrangements, network connections, devices, printers, removable media, conference rooms, and physical storage involved in the workflow. A laptop used only by one employee can still be part of scope when it accesses relevant information. A home router may not become a fully managed business asset, but remote access, device controls, and the way sensitive work is performed still need a practical answer.

Use the map to identify connections between in-scope and other business systems. An accounting platform, marketing tool, or general file share may be outside the primary contract workflow, but an integration, shared identity, administrator account, or broad network connection can create a dependency worth documenting. Scope should be precise, not optimistic. The right boundary is the one that reflects the environment as it operates today.

Inventory quality improves during this work because every asset has a reason to be examined. Record the owner, location, function, operating system or service, and connection to the protected workflow. Where an asset is unknown, mark it as an open item rather than guessing. An honest list of questions is more useful than a polished inventory with false confidence.

6. Document the boundary and its assumptions

Bring the findings together in a scoping package that a business leader can review. At a minimum, include the contract or workstream, information types, process map, people and roles, systems and supporting services, locations, external parties, and known dependencies. Add a short narrative explaining the proposed boundary, the reason for including each major component, and the assumptions that still need confirmation.

Assumptions matter because environments change. A cloud migration may be underway, a subcontractor may not have been selected, or a new project team may not yet have accounts. Record the decision owner and a target date for every unresolved point. This turns the scope document into a working management tool instead of a one-time diagram that goes stale before the next review.

Use a short inclusion decision for each gray area: does this component handle the information, provide security protection, administer a system that does, or create a dependency that could affect the workflow? Record the answer and the evidence behind it. This makes later reviews faster because the organization can revisit the reasoning instead of reconstructing it from memory after people, vendors, or systems have changed.

NIST's SP 800-171A Rev. 3 assessment procedures organize evaluation around examination, interview, and testing. That is a helpful standard for internal scoping work as well. The organization should be able to show the system relationship, explain how the process works, and test whether the stated boundary matches actual access and configuration.

7. Use scope to prioritize the right work

Scoping does not replace remediation. It gives remediation a sensible order. Once the boundary is visible, leadership can ask which risks affect the contract workflow most directly: uncontrolled administrator access, an unsupported endpoint, weak identity practices, missing logging, uncertain vendor access, untested recovery, or incomplete evidence. The result is a plan tied to a real operating environment rather than a generic control list.

Some improvements will help across the business, while others should be intentionally limited to the protected environment. Both can be valid. The important point is that the decision is deliberate, funded, and owned. When every gap is treated as equally urgent, teams often spend time on easy documentation while the access or recovery issue that creates the highest exposure waits.

Revisit the scope after meaningful change: a new contract, new information type, acquisition, office move, cloud migration, major vendor change, merger of business units, or significant staffing change. A short review at those moments is much easier than discovering that the written boundary no longer reflects the business just before a contract deadline.

For leadership, the output should be a manageable action plan: what is in scope, what needs validation, which safeguards need attention first, what evidence already exists, and who owns each next step. That creates a practical way to approve budgets and sequence work. It also gives the organization a better foundation for conversations with primes, assessors, and outside support partners because the facts of the environment are already organized.

Source imagery: U.S. Department of Defense Acquisition Regulations System and the National Institute of Standards and Technology.