Scoping is the decision that sets the cost of your entire compliance program. Here is how we actually trace controlled information through a shop, and the paths almost everyone misses on the first pass.
A Practical CUI Data-Flow Map for a 40-Person Machine Shop
Tony Ciovacco, CEO | TeknaByte Consulting
A machine shop we work with, roughly 40 people, running DoD subcontracts through two primes, came to us holding a compliance proposal priced against every endpoint in the building. Sixty-three devices, all of them in scope, all of them getting the full treatment.
We spent a day and a half tracing where the controlled information in that shop actually went. The answer was nine workstations, one share on the file server, one inbound email flow, and a transfer path to the floor that nobody had written down. Two of the CNC controllers on the original list never touched controlled data at all. One that was not on the list did.
Same obligation, same regulation, dramatically different program. The difference was a diagram that did not exist yet.
Why the map is the artifact that matters
NIST SP 800-171 applies to the systems that process, store, or transmit Controlled Unclassified Information, plus the systems that provide security protection for those. That sentence is the whole scoping problem. You cannot apply it until you know where the information goes, and in most shops nobody has ever written that down, because the information moves through people and habits rather than through an architecture somebody designed.
Get it wrong in the generous direction and you are implementing and maintaining controls across machines that never see controlled data. That is expensive, and on a shop floor it is operationally miserable in ways that generate workarounds, which is its own security problem.
Get it wrong in the narrow direction and you have controlled data sitting on systems outside your declared boundary. That is a compliance failure, and it is also a genuine exposure, which is the part that should bother you more.
In our experience the honest answer is never the whole network, and it is never as small as the first guess.
Start by deciding what is actually controlled
Before you can trace it you have to recognize it, and in a machine shop controlled data is rarely labeled as helpfully as the regulation imagines. What we typically find:
- Technical data packages and drawings carrying distribution statements B through F
- Prints marked with export control warnings, or marked
CUI//SP-CTIfor controlled technical information - Specifications and process sheets that arrived attached to the drawing
- NC programs derived from a controlled drawing, which generally inherit its status
- Inspection records, including first article inspection forms, that reproduce the drawing or its dimensions
Two practical rules save a lot of argument. First, if a prime sent it to you under a DFARS 252.204-7012 flowdown, treat it as controlled until someone can demonstrate otherwise. Second, keep Federal Contract Information and Controlled Unclassified Information separate in your head. Nearly every shop with a federal contract holds the former. The latter brings the heavier requirements, and conflating them is how a shop ends up scoping the accounting department into a CUI boundary.
The four states, and the question people forget
For every category of controlled data, answer four questions: where does it enter, where does it rest, how does it move, and where does it leave.
Then ask the fifth, which is the one that gets skipped: who touches it, and under what identity. A shared login that four operators use turns every other answer on the map into a guess, because you cannot attribute anything that happens downstream of it.
Walk the shop, station by station
Do this on the floor, not in a conference room, and ask the person who does the job rather than the person who believes they know how it is done. The gap between those two answers is where the findings live.
1. Intake
The package arrives through a prime's portal, through a government file exchange, or as an email attachment. Portal downloads land wherever the browser puts them, which is usually a Downloads folder that is not part of anybody's plan. Sometimes a print still arrives on paper, and paper is in scope too.
2. Estimating and job setup
The estimator opens the drawing to quote it. The job gets written into the ERP, and the traveler that prints for the floor may carry the drawing number, the revision, and occasionally the drawing itself.
3. Engineering and programming
The drawing opens on a CAD or CAM workstation and a toolpath comes out the other side. That derived program is the asset most shops forget to classify, and it is often the one that travels the furthest.
4. Storage
Almost always a jobs folder on a file server, organized by year and job number, and almost always readable by everyone in the company because that was the fastest thing to set up in 2014.
5. Transfer to the machine
This is the path that is missing from most first-draft maps. Ask specifically. A USB stick carried out to the controller, a DNC share the machine reads from, a drive mapped directly on the control, or a serial drip feed from a dedicated PC. Each one is a different boundary, and the USB answer in particular tends to surface a second, unofficial copy of the program living somewhere nobody sanctioned.
6. Inspection
The CMM workstation, the inspection reports, and the first article package. These reproduce controlled dimensions and frequently get emailed straight back to the customer, which makes inspection an exit point as well as a storage point.
7. Outbound
Finished records to the prime, and, importantly, prints to outside processors when parts go out for heat treat, plating, or anodize. That is not only a data-flow event. It is a flowdown obligation, and it is the moment your compliance boundary quietly extends into somebody else's building.
CUI data-flow map for a 40-person machine shop.
The paths almost everyone misses
These come up often enough that we now ask about each one directly rather than waiting for it to surface:
- The multifunction printer. Scan-to-email is a transmission path, and the device keeps job history on an internal disk that nobody thinks about until it goes back to the leasing company.
- The phone camera. A photo of a print taken at the machine so somebody can check a dimension from home.
- The laptop that leaves. Usually engineering, occasionally quality.
- Personal email as overflow when an attachment is too large for the corporate limit.
- Cloud storage and backup. If controlled data lands there, the cloud service provider requirement in DFARS 252.204-7012 comes with it, and that is a contract question as much as a technical one.
- Remote support tools, including the ones your IT provider uses. We hold ourselves to the same question we ask our clients here.
- Disposal. The drive in a retired controller, and the printer mentioned above.
Turn the map into a boundary
Once the flows are drawn, sort every system on the page into the categories the CMMC scoping guidance uses. This is the step that converts a picture into a defensible decision:
|
Category |
What lands here in a machine shop |
|
CUI assets |
The CAD/CAM workstation, the jobs share, the estimator's machine, the CMM PC |
|
Security protection assets |
Firewall, identity provider, endpoint detection tooling, the log platform, the backup system |
|
Contractor risk managed assets |
Systems that could touch controlled data but are policy-restricted from doing so, documented as such |
|
Specialized assets |
CNC controllers, test equipment, government furnished equipment, other operational technology |
|
Out of scope |
Only what genuinely cannot process, store, or transmit controlled data |
Two cautions on that table. Specialized assets, which is where most machine controllers land, still belong in your asset inventory and your System Security Plan. They are documented, isolated, and risk-managed rather than exempt, and the Windows 7 box running a press brake is a constraint you describe honestly, not a machine you leave off the drawing.
And out of scope has to be earned. Telling people not to put controlled data on a system is a policy, not a control. If the only thing keeping a machine clean is that nobody has done it yet, it is not out of scope.
How to draw it so it survives contact with an assessor
Swimlanes by function. One box per system, not per device model. Label every arrow with the transport, whether that is a portal download, SMB, email, or a USB stick, because the transport is what you will be asked to secure and demonstrate. Color the controlled path so it reads at a glance. Keep it to one page.
Then do the two things that make it a living document rather than a decoration: put a named owner and a review date on it, and re-open it whenever a new prime, a new machine, or a new outside processor enters the picture. A map that was accurate eighteen months ago is worse than no map, because it is confidently wrong.
Make the boring version. The beautiful version tends to get drawn once and never touched again.
What the map actually buys you
The System Security Plan needs a system description and a boundary. The map is most of both, which means you are not paying to produce this twice. Your self-assessment score becomes something you can defend line by line, because you can point at the systems each requirement applies to. Your plan of action targets the real gaps instead of the whole building. And when third-party verification comes back around, and the direction of policy over the last several years suggests some form of it will, you are handing over a current document rather than starting one under time pressure.
There is also a benefit that has nothing to do with any of that. Every shop we have done this with found at least one copy of controlled data somewhere nobody intended it to be. Finding that is worth the day and a half on its own.
The failure modes we see most
- Mapping the org chart instead of the data. Departments are not boundaries. Follow the file.
- Mapping intent instead of behavior. Ask the operator how the program gets to the machine, not the manager.
- Treating segmentation as drawn rather than demonstrated. A flat network on unmanaged switches cannot show separation between the business network and the controlled environment no matter what the diagram claims. That is a hardware problem with a hardware fix and a lead time.
- Leaving the map in your IT provider's head. If your provider is the only one who can produce it, you do not have an artifact. You have a dependency.
Where to start on Monday
Pick one active job that you know carries controlled data. Follow that single job end to end, from the moment the package arrived to the moment the last record went back to the customer, and write down every system and every hand it passed through. One job, one afternoon.
That trace will be about seventy percent of your map, and the remaining thirty percent is usually the part that changes how you scope. The compliance deadlines around this have moved more than once. The underlying obligation in DFARS 252.204-7012 has not moved at all, and neither has the reason it exists.
We have walked this trace with a number of shops doing IT and security work for manufacturers, and we are always happy to talk through how it played out for a shop about your size.
Tony Ciovacco founded TeknaByte Consulting in Indianapolis in 2016 and serves as CEO. His team provides managed IT and 24/7 security operations to small and mid-sized organizations across 25 states, including CMMC compliance for defense manufacturers. Born and raised in Central Indiana, he writes about what actually works in small-business security operations.
The content & opinions in this article are the author’s and do not necessarily represent the views of ManufacturingTomorrow
Featured Product
