5 Questions to Ask Your Integrator or Engineering Team Before Your Next Automation Project
For many manufacturers, CMMC starts as an IT and governance conversation.
The first discussions are usually around things like:
- Microsoft 365 and email
- servers and file storage
- user accounts and MFA
- laptops and endpoints
- firewalls and networks
- policies, documentation, and assessments
Those are logical places to start. But eventually Engineering or Plant Maintenance/Operations needs to modify a machine, send an electrical drawing to someone, provide a PLC program, connect an engineer’s laptop, or allow an outside integrator to remotely support a piece of equipment.
That is where things get more complicated.
Modern manufacturing environments are increasingly interconnected. Depending on your architecture and the information involved, controlled information can move from business systems into engineering workstations, industrial PCs, SCADA or MES platforms, programming environments, and other systems supporting production.
That is when CMMC stops being exclusively an IT and governance conversation and starts requiring Operations and Engineering to have answers.
Here are five questions worth asking before your next automation project begins.
1. What information are we actually sharing?
Automation projects can require a surprising amount of information to move outside the group that originally created it.
That may include:
- electrical schematics
- mechanical drawings
- process specifications
- PLC and HMI programs
- network diagrams
- equipment configurations
- technical manuals
- machine or production data
- customer-furnished engineering documents
Not every engineering drawing or PLC program is automatically Controlled Unclassified Information (CUI)—the information CMMC Level 2 is primarily designed to protect.
But engineering drawings, specifications, technical reports, source code, and other technical information are all examples of information that can fall into controlled categories depending on the contract, markings, and underlying requirements.
The important question for Engineering is not, “Does this look sensitive?”
It is:
Has someone already determined what information associated with this project has handling requirements?
That determination should ideally come from the organization’s contract requirements, cybersecurity team, established information-flow documentation, or other approved guidance.
An integrator should not be expected to decide whether your information is CUI, but they should be able to understand and support any special handling requirements you define.
2. Where does that information go?
Just like the products we manufacture, information flows from source materials and gains value—and with it real risk—as it evolves and moves through the business.
Take a fairly normal controls project:
Customer sends existing electrical drawings → estimator reviews them → engineer downloads them → project folder is created → engineer modifies the drawings to be issued for construction later → PLC software is opened on a programming laptop → files travel to the plant during commissioning → final backups are retained.
The machine itself may have stayed in one location.
The information surrounding that machine may have traveled through six or seven different systems and environments.
That is why it helps to follow the information, not just the machine.
Instead of asking only:
“Is our PLC CMMC compliant?”
A more useful question is:
Where does controlled information enter, move through, and leave this project?
That path may include:
- cloud file storage
- project-management systems
- engineering workstations
- programming laptops
- removable media
- virtual machines or test environments
- plant networks
- machine-connected systems
- backup and archive systems
This is where a documented map of controlled information flows becomes useful. The goal is not to lock information away so tightly that Engineering cannot use it. The controls around that information still have to preserve its availability to the people and systems that need it, its integrity as it moves through the process, and confidence that it is only reaching the right audiences at the right times.
3. What plant-floor systems could interact with it?
Controls environments are different from ordinary IT environments, and those differences matter.
Current CMMC Level 2 scoping rules specifically account for Operational Technology (OT), Industrial Internet of Things (IIoT), Internet of Things (IoT), and test equipment as Specialized Assets when they can process, store, or transmit CUI but cannot be fully secured.
That does not mean every PLC suddenly needs to be managed like a corporate laptop with full endpoint security controls, user accounts, and software restrictions.
It does mean the industrial environment cannot simply be assumed to sit outside the scope of the conversation.
It is also important to look beyond the individual control device.
A PLC may be a Specialized Asset, but it rarely operates in complete isolation. Information from that PLC may be monitored, collected, historized, displayed, or passed upstream through SCADA servers, historians, MES platforms, engineering workstations, OPC servers or gateways, and other IT/OT systems.
Those connected systems may have very different capabilities—and potentially different CMMC scoping implications—than the PLC itself.
Depending on the project and how information is being processed, stored, or transmitted, the discussion may need to include:
- engineering workstations
- industrial PCs
- SCADA servers
- data historians
- MES platforms
- HMIs
- OPC servers or gateways
- plant networks
- programming laptops
- remote-access infrastructure
- test equipment
- machine-connected devices
- removable media
The question is not only whether a PLC or machine is in scope. It is what information that asset interacts with, where that information goes next, and what other systems become part of that path.
Controls environments also introduce practical challenges that do not always exist in ordinary business IT.
Equipment may remain in service for decades. Software may require specific operating systems or licensing. Production availability may limit when systems can be patched or modified. Vendors may need temporary access. Legacy equipment may not support the security controls available on newer platforms.
Those realities do not make cybersecurity requirements go away.
They mean Engineering, IT, and Operations need to work together to apply those requirements in a way that recognizes how industrial systems actually operate.
4. What will your integrator need to receive, connect to, or take custody of?
When we talk about information security on an automation project, it is easy to think only about files.
In practice, an integrator may interact with much more than that.
Information could include:
- electrical drawings
- PLC and HMI source code
- specifications
- network documentation
- machine data
- configuration backups
Systems could include:
- customer servers
- SCADA or MES systems
- plant networks
- remote-access systems
- PLCs and HMIs
Physical hardware could include:
- customer-provided computers
- industrial PCs
- PLC processors
- hard drives
- removable media
- controls hardware containing customer programs or configurations
The integrator also has its own environment.
Project information may move through engineering laptops, development virtual machines, file repositories, test PLCs, simulation environments, backup systems, removable media, or remote-access tools.
That makes a simple question surprisingly valuable:
If we give our integrator this drawing, PLC program, laptop, processor, or hard drive, what happens to it next?
When controlled information is involved, both parties need to understand whether contractual safeguarding requirements extend into the integrator’s environment and, if they do, what systems will be used to receive, develop, test, and retain that information.
That conversation should happen before work begins on the project.
5. Have we agreed on the rules before engineering starts?
The worst time to discover a cybersecurity or information-handling restriction is halfway through engineering.
Imagine a familiar project sequence.
Engineering sends the project package. The estimate is completed. The integrator starts programming. Project files are now on engineering computers. Commissioning is being scheduled.
Then someone from Cybersecurity or Contracts asks:
“How are those drawings being handled?”
Now the project team may need to revisit:
- file-sharing methods
- personnel access
- computers being used
- development and test environments
- remote-access methods
- removable media
- backups
- retention requirements
- vendor requirements
What started as a cybersecurity issue has now become a project execution issue.
That is why the right time to establish the information boundary is during project intake—not halfway through engineering.
Before the Project Starts, Know Three Things
1. What are we sharing?
Drawings, specifications, programs, network information, machine data, customer-supplied hardware, or other technical information.
Verify the requirements against established contract documentation, markings, cybersecurity guidance, or documented controlled-information flows.
2. Where will it go?
Understand the expected path:
Email → file repository → estimator → engineering workstation → programming laptop → test environment → plant-floor system → archive
That path should be understood before controlled information begins moving through it.
3. How must it be handled?
Identify any requirements associated with:
- CUI
- FCI
- export-controlled information
- customer NDA requirements
- contractual restrictions
- retention requirements
- access limitations
These requirements do not need to turn every engineer into a cybersecurity expert.
They do need to be clear enough that Engineering and outside partners know the boundary they are expected to work within.
Put the Boundary in Place Before the Project Starts
Customers know their contracts and cybersecurity requirements. Trola knows industrial controls and the engineering workflow.
The right answer comes from putting those two pieces together before the project starts.
Our role is not to determine what your organization considers controlled information. Our role is to understand the boundary you have established and make sure the automation project can be executed within it.
That allows Engineering, IT, Operations, and outside integrators to focus on the same goal: getting the machine built, modified, or running without discovering a new set of constraints halfway through the job.
A Note on the Current CMMC Rollout
CMMC continues to evolve.
In July 2026, the Department of War suspended implementation of CMMC Phase II while continuing other cybersecurity compliance efforts, including NIST SP 800-171 self-assessments and selected government-led assessments. Phase I self-assessment requirements remain in place, and contractors and subcontractors remain responsible for safeguarding covered defense information under applicable DFARS requirements.
The Department’s July 13, 2026 announcement can be read here:
Department of War Suspends CMMC Phase II Requirements Regardless of how CMMC implementation evolves, understanding where controlled information travels during an automation project remains good engineering practice.
👉 [Reach out to Trola to get started].
Contact Trola today for a private consultation and discover how we can help you plan for the future while building for the now.