SCADA Security Audit Checklist: Evidence, Controls, and Validation Steps

A SCADA security audit should do more than confirm that policies exist or count known vulnerabilities. It should determine whether security controls are implemented, whether they operate as intended, and whether an attacker could still reach systems that affect industrial operations.

This SCADA security audit checklist organizes the work around three questions:

1. Evidence: What records demonstrate the current state?
2. Controls: What safeguards should be present?
3. Validation: How will the audit determine whether those safeguards work?

Use the checklist for an internal assessment, third-party audit, control review, or remediation validation exercise. Adapt each test to site-specific safety, uptime, regulatory, and engineering requirements.

> Important: Do not run intrusive scans, exploit code, credential attacks, or unapproved protocol tests against production SCADA assets. Coordinate all collection and validation with operations and engineering. Use passive evidence, approved maintenance windows, lab systems, or a cyber digital twin when live testing could create operational risk.

Define the audit scope and safety constraints

A reliable audit starts with a clear boundary. Define the facilities, SCADA servers, HMIs, engineering workstations, controllers, historians, remote access systems, supporting IT services, network zones, and third parties included in the review.

Checklist

• [ ] Identify an accountable audit owner and site-level stakeholders.
• [ ] Document the operational processes and critical functions in scope.
• [ ] Identify systems where failure could affect safety, availability, quality, or the environment.
• [ ] Define approved evidence-collection methods.
• [ ] Record prohibited tests and fragile or legacy assets that require special handling.
• [ ] Establish escalation, stop-work, and incident communication procedures.
• [ ] Document assumptions, exclusions, and known visibility gaps.

Evidence to collect: Scope statement, architecture diagrams, asset lists, data-flow diagrams, safety constraints, vendor restrictions, maintenance schedules, and responsible-owner records.

Validation step: Reconcile the written scope with network and facility owners. Confirm that dependencies such as identity services, remote access gateways, virtualization platforms, backup systems, and industrial DMZ services have not been excluded accidentally.

1. Asset inventory and system context

An inventory is useful only when it reflects both assets and their operational relationships. The audit should establish what exists, what each component does, and how it communicates.

Checklist

• [ ] Inventory SCADA servers, HMIs, engineering workstations, historians, controllers, gateways, and network appliances.
• [ ] Record owner, function, location, vendor, model, firmware or operating system, and support status.
• [ ] Identify criticality and operational consequence for each important asset.
• [ ] Map approved communications between assets and zones.
• [ ] Identify temporary equipment, vendor laptops, wireless links, and unmanaged devices.
• [ ] Record confidence and last-verified dates for inventory entries.

Evidence to collect: Passive discovery output, configuration exports, switch and firewall data, procurement records, maintenance databases, backup inventories, and engineering documentation.

Validation step: Compare at least two evidence sources. Investigate assets or connections present in network data but absent from the authoritative inventory. Do not assume that a discovered IP address alone provides sufficient operational context.

2. SCADA architecture and network segmentation

Segmentation should restrict communication between enterprise IT, the industrial DMZ, SCADA supervisory systems, control zones, safety-related environments, and external parties. For a deeper design methodology, review these [OT network segmentation best practices](https://frenos.io/resource/ot-network-segmentation-guide-ics-scada).

Checklist

• [ ] Define security zones and permitted conduits between them.
• [ ] Route IT-to-OT traffic through controlled boundaries.
• [ ] Use an industrial DMZ for required intermediary services where appropriate.
• [ ] Deny unnecessary inbound and outbound traffic by default.
• [ ] Restrict management interfaces to authorized administrative paths.
• [ ] Review dual-homed systems, temporary rules, and direct internet exposure.
• [ ] Assign owners and expiration dates to firewall exceptions.
• [ ] Separate high-consequence systems where operational architecture permits.

Evidence to collect: Current diagrams, routing tables, firewall configurations, access-control lists, rule-review records, remote access architecture, and approved flow matrices.

Validation step: Compare intended flows with observed communications and effective firewall policy. Test hypothetical IT-to-OT and cross-zone paths in a non-production model. Flag any route that bypasses expected inspection or authentication controls.

3. Identity, authentication, and privileged access

Shared accounts and unmanaged privileges reduce accountability and can turn a single compromise into broader control-system access.

Checklist

• [ ] Maintain named accounts for users with SCADA access where technically feasible.
• [ ] Inventory shared, service, emergency, vendor, and default accounts.
• [ ] Apply least privilege based on operational role.
• [ ] Require strong authentication at remote access and administrative boundaries.
• [ ] Protect and rotate privileged credentials using approved procedures.
• [ ] Remove access promptly when roles or vendor relationships change.
• [ ] Restrict service accounts from interactive use where possible.
• [ ] Monitor privileged sessions and failed authentication attempts.

Evidence to collect: Account exports, role matrices, authentication settings, privileged access logs, access reviews, termination records, and vendor-access approvals.

Validation step: Sample accounts from each role and trace authorization from request through approval and implementation. Confirm that disabled users cannot retain access through local, shared, service, or remote access accounts.

4. Remote access and third-party connectivity

Remote access is often operationally necessary, but every connection should be authorized, constrained, monitored, and removable.

Checklist

• [ ] Maintain an inventory of remote access methods and third parties.
• [ ] Route access through managed entry points rather than direct device connections.
• [ ] Require explicit approval and time-bound enablement where practical.
• [ ] Limit users to required systems, protocols, and time periods.
• [ ] Record sessions or equivalent audit events according to policy.
• [ ] Prohibit unmanaged access tools unless formally approved and controlled.
• [ ] Review vendor accounts and connectivity after each engagement.
• [ ] Define an emergency process for disabling remote access.

Evidence to collect: VPN and jump-host configurations, vendor contracts, access tickets, session logs, firewall rules, authentication records, and periodic access reviews.

Validation step: Select recent vendor sessions and verify who approved access, what systems were reachable, what activity was logged, and whether access was removed or disabled afterward.

5. Secure configuration and change control

Configuration reviews should account for the age and operational sensitivity of SCADA assets. Hardening guidance must not be applied blindly when it could affect process reliability.

Checklist

• [ ] Maintain approved baselines for supported asset classes.
• [ ] Change vendor default credentials and disable unnecessary accounts.
• [ ] Disable unused services, ports, and management interfaces when operationally safe.
• [ ] Protect configuration files and engineering logic from unauthorized changes.
• [ ] Synchronize time where supported and operationally appropriate.
• [ ] Document exceptions for legacy or fragile systems.
• [ ] Require testing, approval, and rollback plans for material changes.
• [ ] Monitor unauthorized changes to critical configurations.

Evidence to collect: Baselines, configuration exports, exception records, change tickets, approval histories, integrity-monitoring alerts, and rollback procedures.

Validation step: Compare a sample of deployed configurations with approved baselines. For each deviation, determine whether it is authorized, necessary, documented, and protected by a compensating control.

6. Vulnerability and patch risk management

A vulnerability list does not show which findings are reachable, exploitable in context, or capable of affecting critical operations. Prioritization should combine technical findings with asset consequence, exposure, attack paths, and available compensating controls.

Checklist

• [ ] Maintain a process for vendor advisories and vulnerability disclosures.
• [ ] Identify unsupported operating systems, firmware, and applications.
• [ ] Evaluate patches for compatibility and operational risk before deployment.
• [ ] Track remediation decisions, owners, deadlines, and exceptions.
• [ ] Apply compensating controls where patching is delayed or impossible.
• [ ] Prioritize findings that enable movement toward critical SCADA functions.
• [ ] Reassess risk after architecture, exposure, or threat conditions change.

Evidence to collect: Vulnerability records, vendor advisories, patch-test results, maintenance plans, exception approvals, firewall changes, and remediation tickets.

Validation step: Select high-priority and deferred findings. Confirm that the affected asset exists, the exposure assumptions are accurate, and compensating controls interrupt the relevant path. Use safe simulation rather than attempting exploitation against production equipment.

7. Logging, monitoring, and incident detection

Monitoring should cover security-relevant activity across IT-to-OT boundaries and within the SCADA environment, without overwhelming teams with unactionable events.

Checklist

• [ ] Define required log sources and retention periods.
• [ ] Monitor remote access, authentication, firewall, endpoint, and administrative events.
• [ ] Detect unexpected communications across zones.
• [ ] Monitor changes to controller logic, HMI projects, and critical configurations where supported.
• [ ] Establish alert ownership and escalation procedures.
• [ ] Map detection coverage to plausible SCADA attack behaviors.
• [ ] Test whether responders receive enough context to act.

Evidence to collect: Logging standards, source inventories, sample events, alert rules, investigation tickets, coverage maps, and response metrics.

Validation step: Use approved test events, historical records, tabletop exercises, or digital-twin simulations to determine whether relevant behaviors generate usable alerts. Document whether the control prevented, detected, delayed, or failed to observe the activity.

8. Backups, recovery, and operational resilience

Recovery evidence should cover more than server files. SCADA restoration may depend on controller logic, HMI projects, historian data, licenses, configuration files, firmware, and specialist knowledge.

Checklist

• [ ] Back up critical SCADA applications, configurations, logic, and supporting services.
• [ ] Protect backups from unauthorized modification and routine network compromise.
• [ ] Maintain offline or otherwise isolated recovery copies where required.
• [ ] Document recovery order, dependencies, and responsible personnel.
• [ ] Retain required software, licenses, firmware, and vendor instructions.
• [ ] Test restoration without creating production risk.
• [ ] Record recovery gaps and lessons from exercises.

Evidence to collect: Backup policies, job reports, storage architecture, restore-test records, recovery procedures, dependency maps, and corrective actions.

Validation step: Witness a controlled restoration to a safe environment or review recent test evidence. Confirm that restored configurations are usable, not merely that a backup job reported success.

9. Incident response and operational coordination

SCADA incident response requires coordinated decisions across cybersecurity, operations, engineering, safety, legal, communications, and external partners.

Checklist

• [ ] Maintain SCADA-specific incident scenarios and escalation criteria.
• [ ] Define decision authority for isolation, shutdown, and recovery actions.
• [ ] Include manual operating procedures where applicable.
• [ ] Preserve forensic evidence without delaying safety-critical actions.
• [ ] Maintain current internal, vendor, regulatory, and law-enforcement contacts.
• [ ] Exercise scenarios involving loss of view, loss of control, ransomware, and compromised remote access.
• [ ] Track corrective actions through completion.

Evidence to collect: Response plans, call trees, playbooks, exercise reports, incident records, communications templates, and corrective-action logs.

Validation step: Run a tabletop exercise based on the actual architecture. Require participants to identify affected assets, available telemetry, isolation options, operational consequences, and recovery dependencies.

10. Validate controls against end-to-end attack paths

Documentation and configuration review establish control intent. Validation establishes whether the controls can stop or expose realistic attacker movement.

Start with scenarios such as:

• Compromised enterprise credentials reaching an OT remote access service
• Movement from the industrial DMZ to a SCADA server
• Vendor access reaching systems outside its approved scope
• An engineering workstation compromise affecting controller logic
• A flat or misconfigured conduit exposing multiple control zones

For more context, see the [SCADA security architecture and safe validation guide](https://frenos.io/resources/scada/scada) and Frenos guidance on [SCADA visibility and attack paths](https://frenos.io/resources/scada/visibility-attack-paths).

Checklist

• [ ] Define the attacker starting point and intended operational target.
• [ ] Map required identities, vulnerabilities, routes, and trust relationships.
• [ ] Identify the controls expected to prevent or detect each step.
• [ ] Validate the path using approved, production-safe methods.
• [ ] Record the evidence supporting each successful or blocked step.
• [ ] Prioritize paths by exploitability, consequence, and remediation feasibility.
• [ ] Retest after corrective actions.

A cyber digital twin can support this work by modeling the environment from available OT data and simulating adversary techniques without testing live production systems. Frenos uses this approach to validate IT-to-OT and OT attack paths, assess existing defenses, and focus remediation on evidence of exploitability rather than vulnerability counts alone.

SCADA audit findings and report format

Every finding should include enough context for engineering and leadership to make a decision.

Use the following structure:

Avoid treating raw vulnerability totals as the principal measure of risk. A smaller number of validated paths to critical systems may deserve attention before a larger group of isolated findings.

Final audit completion checklist

• [ ] Scope and exclusions are approved.
• [ ] Evidence is dated, attributable, and stored securely.
• [ ] Safety and operational restrictions are documented.
• [ ] Findings distinguish missing controls from ineffective controls.
• [ ] Attack-path assumptions are supported by evidence.
• [ ] Remediation priorities reflect operational consequence and exploitability.
• [ ] Owners and due dates are assigned.
• [ ] Exceptions include compensating controls and review dates.
• [ ] Closure requires retesting or equivalent validation.
• [ ] Material architecture changes trigger reassessment.

Move from audit findings to defensible risk reduction

A SCADA audit is complete only when teams can explain what was reviewed, what evidence supports each conclusion, which attack paths remain possible, and how remediation will be verified.

Frenos helps OT security and engineering teams build cyber digital twins from available environment data, simulate adversary behavior, and validate attack paths without touching production. The result is an evidence-based view of where defenses hold, where they do not, and which corrective actions can reduce meaningful operational risk.

Request a demo to see attack paths in your OT environment and assess defenses without production impact.