Drive Regulations into Response: Compliance That Reduces Consequence

Every few years, the ICS/OT security community circles back to the same question:

Does regulation actually make our environments safer?

The latest data gives us a more precise, and more useful, answer.

According to the SANS 2025 State of ICS/OT Security Report, regulated environments do not experience materially fewer cyber incidents than their unregulated peers. Intrusions, misconfigurations, ransomware, and operational disruptions still occur at roughly the same rate.

What does change is what happens next.

Regulated organizations report roughly 50% fewer financial and safety impacts from those incidents. Less downtime. Fewer cascading failures. Lower recovery costs. Reduced operational risk to people and communities.

That gap matters. And it forces us to confront a long-standing assumption in our field:

that regulation itself is the protective mechanism.

It is not.

What reduces impact is not the mandate. It is what some organizations do with the mandate once the auditors leave.

Why Compliance is a Security Enabler

Most practitioners already understand that passing an audit does not mean an environment is secure. That point is well-worn. What deserves more attention is the pattern hiding behind the survey data.

High-performing regulated organizations treat compliance as a forcing function to build operational capability.

Low-performing ones treat it as a reporting exercise.

The difference shows up long before an incident occurs.

In audit mode, teams optimize for evidence.

Logs are collected. Policies are written. Diagrams are updated once a year. Access reviews happen on a cadence that aligns with the requirements, not with operational reality.

In operational mode, those same requirements are translated into tools people actually use.

Access models are tested during outages. Logging pipelines are validated during maintenance windows. Architecture diagrams are pulled up during tabletop exercises because everyone expects them to be accurate.

Both groups may pass the audit. Only one group shortens detection time and reduces blast radius when something goes wrong.

This is where “compliance theater” creeps in. Over time, teams learn that the system rewards proof of existence, not proof of effectiveness. High-performing organizations break that habit deliberately.

Turning Mandates into Daily Operational Capability

Regulated environments are often required to demonstrate controls around access management, logging, monitoring, incident response, and recovery. On paper, these look like bureaucratic overhead. In practice, they map directly to resilience outcomes when implemented with intent.

Take access control.

In audit mode, it is a quarterly spreadsheet exercise.

In operational mode, it becomes a living understanding of who can touch which systems, from where, and under what conditions.

That understanding matters when an operator calls at 2 a.m. because a vendor session is behaving strangely.

It matters when credentials show up in a place they should not.

It matters when you need to distinguish legitimate remote work from adversary persistence.

Logging follows the same pattern.

Compliance language often emphasizes retention and periodic review. Operational teams care about whether logs answer questions under pressure:

• What changed?
• When did it change?
• Was this expected?
• Can we correlate this with process behavior?

Incident response plans are another example. Many regulated organizations are required to have them. Far fewer have exercised them in ways that reflect real ICS constraints: engineering dependencies, safety interlocks, fragile legacy systems, and limited vendor availability.

The survey data suggests that those who do exercise them see measurable reductions in impact, even when prevention fails.

None of this happens automatically. It happens because someone decided to treat a requirement as a capability-building opportunity, not a checkbox.

From Compliance Artifacts to Resilience Metrics

One way to reframe this conversation is to stop talking about controls and start talking about outcomes.

Access control maturity shows up as detection speed. When roles, trust boundaries, and access paths are well understood, anomalous access stands out faster.

Logging and monitoring maturity shows up as response coordination. When OT, IT, engineering, and security teams share the same telemetry, conversations get shorter and decisions get clearer.

Recovery planning shows up as recovery effectiveness. Teams that have rehearsed integrity checks and restoration steps are less likely to improvise under stress.

These are not abstract benefits. Practitioners see them during events that never make the news:

• A misapplied firmware update
• A vendor laptop behaving oddly
• A remote connection that persists longer than expected

In environments where compliance artifacts are operationalized, these situations are contained quickly. But in environments where they exist only to satisfy auditors, they often escalate.

Like any journey or maturity model, many organizations start in audit mode because external pressure rewards it. The survey data suggests that those who move beyond it are the ones seeing real-world benefits.

Dual-Use Artifacts: Audit-Ready and Incident-Ready

One of the most consistent patterns in resilient environments is the use of dual-use artifacts. These are documents and models that satisfy regulatory expectations and earn their keep during incidents.

Architecture diagrams are a classic example. In high-performing organizations, diagrams reflect real data flows, trust boundaries, and choke points. They are kept current because operators rely on them during troubleshooting and response.

Access models work the same way. Instead of static spreadsheets, they become living references that help teams answer questions during abnormal conditions. Logging schemas and asset inventories also fall into this category. When built for operational use, they reduce time-to-understanding during incidents. When built purely for compliance, they tend to be ignored until the next audit cycle.

The organizations seeing lower impact are not producing more documentation. They are producing documentation that actually gets used.

Not a Regulated vs. Unregulated Story

It would be easy to read these results as an argument for more regulation. That misses the point.

This is an industry story.

We share adversaries, technologies, and failure modes regardless of regulatory status. The lesson from regulated environments is not that mandates work. It is that capability-building under constraint works.

Unregulated organizations can adopt the same mindset without waiting for external pressure. Regulated organizations can share patterns and lessons without claiming superiority.

The divide that matters is not regulated versus unregulated. It is operationalized versus performative.

Why This Matters Now

ICS/OT incidents are no longer edge cases. They are part of the operating environment for business and critical infrastructure alike.

The real question most teams face is not if something will happen.

It is how much damage it will cause when it does.

The 2025 survey gives us evidence that impact is not fixed. It can be reduced through deliberate choices about how we interpret and implement requirements.

That should be encouraging.

It suggests many of the tools we need already exist.

The work is in how we use them.

Training for Practical Realities

Using tools appropriately requires a trained and educated workforce. Fortunately, at SANS we have built many of these hard lessons learned into our courses. For practitioners looking to deepen their capability-focused approach, SANS courses like ICS456: Essentials for NERC Critical Infrastructure Protection help translate regulatory language into operational design and response practices. Built around the North American Electric Reliability Corporation (NERC) Critical Infrastructure Protection (CIP) Reliability Standards, ICS456 arms students with the “what” and the “how” to comply—but also how to build better capabilities beyond checking the box.

The five-day course hits every mandatory requirement for electric utilities, but, more importantly, it also provides guidance on maturing programs. A small subset of examples can be seen below:

This is the mindset ICS456 is designed to reinforce: taking language from CIP-005, CIP-007, CIP-010, and CIP-008 and translating it into daily engineering and security practice. The goal is not to memorize standards. It is to use them as design inputs for systems that hold up when something breaks.

Meanwhile, ICS418: ICS Security Essentials for Leaders offers a complementary lens, focusing on governance and leadership alignment in complex environments. It looks at the leadership and governance side of resilience:

• How decisions get made under uncertainty
• How engineering, security, and leadership stay aligned
• How organizations move from audit cadence to operational cadence
• How risk is framed in business terms without losing technical reality

That layer matters because capability is not just technical. It is cultural. Teams stay in audit mode when incentives reward it. They move out of it when leadership makes operational readiness visible and valued.

Neither course is a silver bullet. They are shared learning spaces. Practitioners compare notes, challenge assumptions, and refine how compliance can support real-world resilience.

The survey data makes one thing clear. Regulation did not save anyone on its own. People did, by turning obligations into capabilities that matter when it counts.

Learn more about SANS’s ICS Security curriculum here.  

Download your copy of the SANS State of ICS/OT Security 2025 Report here.