Scoping OT & ICS for CMMC

The most expensive sentence in your SSP

Long before a C3PAO looks at a single control, you make one decision that quietly governs the cost, the timeline, and the pass-or-fail outcome of your entire CMMC effort: where you draw the boundary. For a defense manufacturer, that boundary runs straight through the plant floor — and the floor is exactly where most CMMC programs are scoped wrong. Declare too little in scope and you build your System Security Plan on a fiction an assessor will dismantle in the opening conversation. Declare too much and you drag a flat factory network, fragile controllers, and decades-old engineering workstations into a 110-control assessment that costs more than the contracts you are trying to protect.

Scoping is not paperwork you do at the end. It is the architecture decision you make first, and the one that is hardest to walk back once your SSP and network diagram are written around it.

What CMMC asks you to define before anything else

Under 32 CFR Part 170, a Level 2 assessment evaluates a defined set of assets — the CMMC Assessment Scope — against the NIST SP 800-171 controls. You, the contractor, propose that scope. The assessor does not hand you a boundary; they react to the one you assert, and they are free to challenge any scope that leaves an obvious path for CUI to slip outside the box you have drawn. That dynamic is the whole game. A defensible boundary you can prove and operate is worth more than a clever one that collapses under a single "walk me through how a drawing gets to that machine" question.

The objective is not the smallest possible scope, and it is not the safest-looking large one. It is the smallest boundary you can honestly defend — one that contains every place CUI actually lives and moves, and legitimately excludes everything else.

The five asset categories — and where the plant floor lands

Section 170.19 sorts every asset in your environment into one of five categories, and each carries different documentation and assessment weight:

• CUI Assets — anything that processes, stores, or transmits CUI. These are the core of the assessment and face the full control set.
• Security Protection Assets — systems that provide security functions to the environment, such as your SIEM, identity provider, or jump hosts. In scope, assessed against the requirements relevant to what they do.
• Contractor Risk Managed Assets — assets that can access CUI but are not intended to, separated by policy rather than architecture. Documented and managed — with the catch that at Level 3 they are treated as CUI Assets.
• Specialized Assets — the category that matters most for manufacturers. It explicitly includes Operational Technology, IoT and IIoT devices, Government Furnished Equipment, restricted information systems, and test equipment: systems that may touch FCI or CUI but cannot be fully secured the way a laptop can.
• Out-of-Scope Assets — assets physically or logically separated from the CUI environment, with no path to it.

Here is the lever, and the misconception that wastes the most money: Specialized Assets are not exempt. They sit inside the assessment scope. What changes is how they are handled — you document them in the SSP, show that they are managed under a genuine, risk-based security policy, place them on your network diagram, and they undergo limited checks rather than a full march through all 110 requirements. "Limited checks" is not "ignored." An assessor reads the SSP to confirm the risk-based management is real and operating, not a sentence added to make the category fit.

Used correctly, the Specialized Assets pathway is how a manufacturer keeps a PLC, an HMI, or a CNC controller from being assessed as if it were a domain-joined workstation. Used as a dumping ground for anything inconvenient, it is the fastest way to fail.

How CUI actually reaches your floor

Every categorization above turns on one question — does the asset process, store, or transmit CUI — and that is precisely the question generic consultants get wrong on the plant floor, because they assume machinery does not touch sensitive data. On a real defense manufacturing line, it does, constantly. A technical data package, drawing, or 3D model arrives as CUI and lands on an engineering workstation that programmers open every day. That model becomes toolpaths and G-code, derived from CUI and often still CUI, pushed to a CNC controller or carried over on removable media. A historian or MES aggregates production data, some of it tied to controlled technical information, and replicates it upstream. An operator emails a marked drawing to the shop, prints it at a floor kiosk, or moves it on a USB stick because that is how the line has always run.

Every one of those is a CUI flow, and the moment an OT asset sits in one, it stops being a tidy Specialized Asset and becomes a CUI Asset, with the full obligations that follow. Device type does not decide the category. Data does. You cannot scope a plant floor you have not data-flow-mapped, and most of the painful surprises in an assessment are CUI flows nobody wrote down because "that's just the machine."

The two ways floor scoping goes wrong

Under-scoping is the more dangerous of the two. It looks like declaring the production network out of scope, or sweeping every controller into Specialized Assets, when CUI is in fact moving across that equipment. It produces an SSP that reads cleanly and describes a company that does not exist. The first time an assessor traces a drawing from receipt to the machine that cuts it, the boundary falls — and now you are renegotiating scope mid-assessment with your credibility already spent.

Over-scoping is less catastrophic and far more common, and it is the one that quietly drains budgets. With no segmentation between business systems and the floor, the entire flat network becomes the CUI environment by default, and every aging HMI and unpatchable controller inherits requirements it was never built to meet. You end up trying to enforce session lock, validated cryptography, and aggressive patch cycles on equipment whose vendor will void support the moment you touch it — spending heavily to make the impossible auditable.

Both failures share one root cause: scoping the network you happen to have, instead of designing the boundary you need.

Why you cannot just harden it like IT

The instinct, once OT lands in scope, is to treat it like the rest of the estate — push the baseline, run the scan, apply the policy. On the plant floor that instinct is dangerous, because OT inverts the priorities IT security is built around. Where business systems optimize for confidentiality, control systems optimize for availability and safety. A workstation that locks or reboots is an annoyance; a controller that does the same mid-process is scrap, downtime, or a hazard.

A note from the field. Compliance programs love a hardening baseline — a STIG or SCAP scan, a group-policy push, a benchmark rolled across the environment in an afternoon. On a production control system I worked, that exact move, applied without OT-aware staging, cascaded across multiple nodes and took the environment down. The controls did not malfunction; they did precisely what IT hardening is designed to do, and in doing so they severed the authentication trust the nodes used to talk to one another, broke the database connections the operator screens depended on, and rewrote the local security policy the platform needed simply to start. Recovery was node by node — re-establishing the trust relationships, restoring the service and database accounts, unwinding policy that looked correct on paper and was fatal in practice, and validating each layer before touching the next. The lesson carries straight into CMMC: a control that is mandatory and correct for your business systems can be an outage, or a safety event, on your floor. OT control selection cannot be a copy of your IT baseline — and whoever scopes your environment needs to understand that before they write it into your plan.

This is the practical reason the Specialized Assets pathway exists, and the reason it has to be used honestly. The goal is to protect CUI without pretending a thirty-year-old controller is a managed endpoint — to select compensating, risk-based controls an assessor will accept and that will not take your line down.

A scoping method that survives the assessment

The sequence that holds up is unglamorous and strictly order-dependent:

1. Inventory everything, OT included. Every controller, HMI, historian, engineering workstation, jump host, and piece of test equipment — not just the IT asset list. You cannot categorize what you have not counted.
2. Map the CUI flows. Trace each piece of controlled data from the moment it arrives to every place it rests and every machine it reaches. This step determines the categories, and it is the one most often skipped.
3. Categorize deliberately. Assign each asset to one of the five categories based on the flows you mapped — not on whether it is labeled "IT" or "OT."
4. Segment to shrink the boundary. Use zones and conduits, a CUI enclave, jump hosts, and where warranted unidirectional gateways or data diodes to legitimately move equipment out of the CUI environment. Architecture, not assertion, is what lets OT qualify as Specialized or Out-of-Scope honestly.
5. Document the risk-based management. For Specialized Assets, write the real policy: how each is monitored, isolated, patched or compensated for, and recovered. A one-line mention will not survive review.
6. Draw the network diagram to match reality. The diagram is the scoping conversation. It must show the CUI flows, the boundary, and every specialized asset — and it must match what an assessor finds when they walk the floor.

Done in this order, the C3PAO scoping discussion becomes a confirmation rather than a negotiation. Skip the data-flow mapping and you are guessing — expensively.

Where Praedyn fits

This is the work I do, and it is deliberately the corner of CMMC most consultants avoid, because it requires being fluent in both the assessment framework and the plant floor. I scope CUI boundaries against ISA/IEC 62443 zones and NIST SP 800-82 guidance, and I have been inside production control systems when security and availability collided — which is the experience that keeps a scoping decision from turning into an outage. If your environment has real OT in it, you do not want a boundary drawn by someone who has only ever seen a network from the IT side. Start an intake and you will see a planning estimate as you describe your environment, OT included.