I have read a lot of SOC 2 reports. At data centers, at manufacturers, at SaaS companies. One pattern keeps showing up at industrial customers: the SOC 2 scope is defined in terms of the corporate IT environment. The OT environment — the BMS, the DCIM, the plant-floor controllers — is silent, excluded, or sometimes explicitly out of scope.
That is not SOC 2's fault. SOC 2 is a flexible framework; scope is defined by the service organization. But the practical consequence is that many data center and manufacturing SOC 2 reports do not actually cover the systems that would cause a customer-visible outage if compromised. That is a problem worth being deliberate about.
Why SOC 2 scope drifts away from OT
Three reasons, in rough order of frequency:
- Inertia. The first SOC 2 was scoped by someone focused on SaaS-style controls. Subsequent years inherit the scope.
- Ownership. OT is operated by facilities or plant operations. The SOC 2 is run by security or compliance. The org chart doesn't connect them.
- Fear. Including OT in scope means OT has to meet controls. Controls that have not been met become audit findings. Easier to scope it out.
All three are understandable. None of them are defensible when a customer reviews the report and notices that the BMS — the system that keeps their equipment cool — is not mentioned.
What "in scope" would mean
Including OT in SOC 2 scope is not an all-or-nothing move. At most data centers and manufacturers, a phased approach works:
- Year 1: Explicitly name the BMS, DCIM, and physical access control systems as in-scope for the Availability trust service criterion. Document the controls that actually exist. Accept that some will be marked "not implemented" — this is a baseline year.
- Year 2: Close the most critical gaps. Add Security trust service criterion for OT zones. Expect a cleaner report.
- Year 3: Mature operations. Demonstrate continuous monitoring. The report now reads as a genuine statement of operational resilience.
This is a 24-month journey, not a quarterly project. But it's durable, and it produces a report that holds up under enterprise customer scrutiny.
What customers are actually looking for
When a sophisticated enterprise customer reviews your SOC 2 report, they are looking for two things in particular:
- Scope clarity. What exactly is covered? What exactly is not?
- Availability controls. For data center and manufacturing suppliers, availability is the headline.
If your report is ambiguous on scope, or if the controls named under Availability are generic IT controls that happen to be applicable, sophisticated customers will notice. Some will push back in the vendor review process. Others will simply mark your report as "basic" internally and prefer a competitor with a more credible posture.
The PCI angle
Similar pattern on PCI DSS v4.0. At data centers that host payment environments, the PCI scope often stops at the logical cardholder data environment and does not include the physical infrastructure — the BMS and DCIM that would, in an outage, render the cardholder data environment unavailable. PCI DSS v4.0 Requirement 9 (physical security) is increasingly where this pressure shows up in assessments.
What to do
Three actions, in order:
- Read your current SOC 2 report. Ask: is the OT environment named? If not, why not?
- Have a deliberate conversation with your auditor about scope. "We would like to include OT next year" is a legitimate starting position.
- Engage a third party to assess OT readiness before the audit. Findings found by your assessors during the audit are expensive. Findings found in a pre-assessment are remediable.
OT compliance readiness is one of our primary service lines. If you would like an independent read on your current scope, we can help.
This article was written by the Cascadia OT Security practice, which advises Pacific Northwest data centers and manufacturers on industrial cybersecurity. For engagement inquiries, reach our practice team.