SCADA Security Assessment: Scope, Method and Reporting

A SCADA security assessment is a structured review of the systems that monitor and control your physical processes. It maps what is connected, finds the weaknesses an attacker could use, ranks them by operational consequence, and produces a remediation plan you can verify by retesting. Done well, it does this without stopping a pipeline, a substation or a plant. This guide covers how to scope the work, which testing methods are safe, what a vulnerability assessment examines, how an audit differs, and how to report findings to leadership.

TL;DR

• A SCADA assessment starts with a written plan: targets of evaluation, goals, rules of engagement, schedule and resources. Testing comes after reconnaissance, not before.
• Active scanning can disrupt control equipment, so test in a non-production environment where possible and coordinate every live test with the system owner.
• A vulnerability assessment looks at active services, patch levels and known vulnerabilities, then tracks fixes and retests. An audit checks that your policies and controls work as intended.
• Energy operators may have mandatory requirements: NERC CIP-010-5 calls for a vulnerability assessment at least every 15 calendar months for BES Cyber Systems.
• Report at the right level of detail for each audience and rank findings by the consequence they could cause, not by raw severity scores alone.

Table of Contents

• What a SCADA security assessment covers
• How to scope a SCADA risk assessment
• Testing without disrupting operations or safety
• What a SCADA vulnerability assessment examines
• Assessment, penetration test and audit: what is the difference?
• Standards and U.S. requirements for energy and oil and gas
• Reporting findings and prioritizing remediation
• Getting help with your SCADA assessment
• FAQ
• Sources

What a SCADA security assessment covers

Supervisory control and data acquisition (SCADA) systems sit between your operators and the physical process. They typically include control servers, human-machine interfaces (HMIs), remote terminal units (RTUs), historian databases, communications links and the networks that connect them to the business side. An assessment examines how these components are configured, how they connect to each other and to the outside world, and where an attacker could get in or cause harm.

The scope usually spans four layers:

1. Assets and architecture. What is on the network, what talks to what, and where the boundaries between corporate IT and operational technology (OT) sit.
2. Configuration and patch state. Operating systems, control software, firmware, services that are running and protocols that are exposed.
3. Access paths. Remote access, vendor connections, wireless links, removable media and any third-party connection into the control environment.
4. People and process. Policies, change control, incident response plans, backup and recovery, and how operators and vendors actually behave.

The same exercise goes by several names. Readers searching for a SCADA risk assessment, vulnerability assessment, security audit or security testing are often looking at different slices of one program. We explain the differences below, and our guide to industrial cybersecurity assessment types goes deeper on choosing between them.

How to scope a SCADA risk assessment

Scoping decides whether an assessment is useful or merely expensive. The U.S. Department of Energy's Idaho National Laboratory describes the starting point as a detailed assessment plan that sets the targets of evaluation, goals, rules of engagement, schedule and resources. The team then examines system configuration and external connections and prioritizes targets by operational criticality.

In practice, a workable scoping sequence looks like this:

1. Define the business question. Are you preparing for a NERC audit, responding to a customer security questionnaire, evaluating a new remote access design, or establishing a baseline for a first security program? The answer sets depth and cost.
2. Name the targets of evaluation. Pick the systems whose failure would hurt most: a control center, a compressor station, a terminal, a water or power facility. Start with the most critical, not the most convenient.
3. Write rules of engagement. Specify what may be scanned, what may only be reviewed on paper, which hours are allowed, who can stop a test and who is on call at the plant.
4. Map connections through reconnaissance. Assessment teams should map links such as ICCP servers, RTUs and historian databases to find the most critical risk areas before any penetration testing begins.
5. Choose the rigor. NIST's assessment guidance for security requirements describes three methods, interview, examine and test, applied at varying levels of rigor. NIST stresses that scope and depth should follow an organization's operational dependencies and risk tolerance. That guidance is written for protecting controlled unclassified information, but the three-method structure transfers well to OT reviews.
6. Agree on deliverables. Decide up front what you will receive: an asset inventory, a ranked findings list, a remediation roadmap, an executive summary.

A useful rule: if the scope document does not say who at the facility approves each test, it is not finished.

Testing without disrupting operations or safety

This is the question operators ask first, and rightly so. Government guidance is blunt that security testing in a SCADA environment carries risk. The UK's national infrastructure protection agency notes that port and vulnerability scans, particularly those using invalid data, may cause process or machine failure, which is why careful planning and communication with system owners are required.

Safe practice follows from that:

• Prefer a non-production environment. INL researchers advise that a safe test environment should include the connecting components and functionality, ideally with components configured with actual signals so interoperability can be assessed.
• Use passive methods first. Reviewing configurations, network diagrams and captured traffic reveals a great deal without sending a single probe to a controller.
• Throttle and schedule active tests. Run them during planned maintenance windows with operators present and a rollback plan.
• Exclude fragile devices. Legacy PLCs and RTUs that cannot tolerate unexpected traffic can be assessed through configuration review and vendor documentation instead.
• Treat testing as recurring. The same UK guidance says testing should be iterative and triggered by events, such as new vulnerability disclosures or configuration changes, rather than a one-time project.

If you want to understand how scanning differs in IT and OT settings, our primer on what vulnerability scanning is is a good place to start before you approve any live scan on a control network.

What a SCADA vulnerability assessment examines

A vulnerability assessment is the most concrete part of the program. Department of Energy guidance on improving SCADA security says it should examine active services, patch levels and common vulnerabilities, analyze each identified vulnerability for significance, track corrective actions and retest to confirm the weakness is gone.

The same guidance offers a caution worth repeating: commercial tools can show paths of least resistance, but they do not replace systemic problem-solving, and every corrective action should be verified by retesting. A scanner report is an input, not a finished assessment.

Typical areas of review

CISA's recommended practices for industrial control systems point to several fixes that assessments frequently recommend: encryption for protocols, application whitelisting on HMIs, and security event monitoring that correlates logs across the network.

Two of those areas deserve their own attention. Segmentation is usually the highest-value finding, and our zones-and-conduits blueprint for OT network segmentation shows how to structure it. Patching in control environments is rarely simple, and the practical guide to ICS patch management explains how operators handle systems that cannot be taken offline on demand.

Assessment, penetration test and audit: what is the difference?

These terms overlap in search results, but they answer different questions.

• Risk assessment: What could go wrong, how likely is it, and what would it cost us? It weighs threats, vulnerabilities and consequences.
• Vulnerability assessment: Which weaknesses exist in these systems right now, and how significant is each?
• Penetration test: Can a skilled attacker actually exploit those weaknesses to reach something that matters? It is the specific flaw-hunting step, and in SCADA it should follow reconnaissance and careful planning.
• Security audit: Are our defensive processes and internal controls working as our policies and standards say they should? UK infrastructure protection guidance describes this as a periodic review confirming compliance with security policies and standards, a broader check than either a penetration test or a vulnerability assessment.

Most mature programs use all four on a rhythm: an annual risk assessment, vulnerability assessments on a recurring cycle and after major changes, targeted penetration testing of the highest-consequence paths, and an audit before any external certification or regulatory review.

Standards and U.S. requirements for energy and oil and gas

Whether an assessment is voluntary or mandatory depends on what you operate.

NIST SP 800-82. NIST's Guide to Operational Technology Security, now in Revision 3 (2023), provides guidance on securing OT while addressing its performance, reliability and safety requirements. It is the most commonly used reference for building the technical scope of an OT assessment, and the one we would hand to any operator who needs a starting framework.

NERC CIP for the bulk electric system. For entities with BES Cyber Systems, CIP-010-5 requires a vulnerability assessment, performed either on paper or through active testing, at least once every 15 calendar months. Vendor relationships are covered by CIP-013-3, which requires documented supply chain cyber security risk management plans, including processes to identify risks from vendor products, to have vendors notify you of incidents, and to coordinate remote access controls. NERC's own CIP Roadmap published in January 2026 notes that existing standards provide a baseline while the grid's operating environment digitizes and interconnects faster than standards can be revised, which points toward risk-based methods that go beyond baseline compliance.

If you are not a registered NERC entity, CIP does not apply to you directly, but many customers and insurers use it as a yardstick. Oil and gas operators, midstream companies and utilities should confirm with counsel and their regulators which federal and state requirements cover each facility.

Vendors are part of the attack surface in every one of these settings. Our guides on energy company third-party risk and oil and gas vendor cybersecurity risk factors cover what to ask suppliers, and the article on secure remote access for OT teams explains how to close the most common vendor pathway.

Reporting findings and prioritizing remediation

A findings list nobody can act on is the most common failure of an otherwise good assessment. UK national security guidance on risk assessment recommends that results be reported to stakeholders at the appropriate level of detail, and that attack scenarios be prioritized according to the capabilities required and the potential consequences. The same process covers establishing system context and scope, defining threat sources and conducting a preliminary analysis of hazards.

Translate that into a report with three layers:

1. Board or managing-partner summary. One page: overall risk position, the top five exposures in business terms, the decisions you need and the cost and time to address them.
2. Operations and engineering view. Each finding with affected asset, evidence, consequence for the process, recommended fix and any operational constraint on the fix, such as needing an outage window.
3. Technical appendix. Raw results, scan outputs, configuration details and retest evidence.

Rank findings on consequence first. A moderate vulnerability on a system that can open a valve or trip a breaker outranks a high-scoring flaw on an isolated historian copy. Where a fix is impractical in the short term, record a compensating control, such as segmentation, monitoring or tighter remote access, and a date to revisit. Then retest. A finding is closed when evidence shows it is closed.

Our 10 OT security controls for regulated SCADA operators is a ready checklist for turning a findings list into a sequenced plan.

Perspective

In our experience with regulated organizations, the assessment is rarely the hard part. The hard part is what happens in the ninety days afterward. Law firms with industrial clients, oil and gas operators and energy companies tell us the same thing: they receive a long report, and nobody owns it.

That is why we pair assessment work with ongoing leadership. A virtual CISO turns the findings into a risk roadmap, writes the policies and controls that make fixes stick, plans incident response and presents progress to the board in language it can act on. Our platform supports the repeatable parts: automated testing, compliance intake across 50+ frameworks and professional reporting, so each reassessment builds on the last instead of starting from zero.

We built CISOSafe to give mid-market and regulated SMB teams enterprise-grade security leadership at a fraction of the cost and time of hiring a full-time CISO. For SCADA environments, we believe the right model is a scoped, safety-first assessment followed by a continuous program of verification, not a once-a-year document.

vCISO

Getting help with your SCADA assessment

If you operate control systems and need an assessment that your operators, executives and auditors can all use, CISOSafe can help. Our virtual CISO services, security risk assessments, policy and controls development and audit readiness support are built for regulated organizations in oil and gas, energy, legal and other compliance-sensitive industries.

We start with scope and rules of engagement, so the work fits your operating realities, then deliver a ranked roadmap and board-ready reporting. To discuss your environment, start at cisosafe.com. If you are still building your understanding of the field, our overview of OT cybersecurity for regulated U.S. SMBs and our analysis of industrial IoT security mapped to IEC 62443 are useful companions.

FAQ

How often should a SCADA security assessment be performed?

At minimum, on a regular recurring cycle, and again whenever something significant changes. Government guidance recommends treating testing as iterative, triggered by new vulnerability disclosures or configuration changes. If you are a NERC registered entity with BES Cyber Systems, CIP-010-5 sets an outer limit of 15 calendar months between vulnerability assessments.

Can a SCADA vulnerability scan crash my control system?

Yes, it can. Scans that send unexpected or invalid data may cause process or machine failure on fragile devices. Reduce the risk by testing in a representative non-production environment, using passive methods first, scheduling active tests with operators present, and excluding legacy devices from live scans.

Is a SCADA security audit the same as an assessment?

No. An assessment looks for weaknesses and risk. An audit checks whether your policies, standards and internal controls are actually being followed and working as intended. Many organizations run an assessment first, fix what it finds, then use an audit to confirm readiness for a regulator, customer or certification body.

Who should be involved in a SCADA assessment?

You need control engineers and operators who know the process, IT and security staff who know the networks, and an executive sponsor who can approve downtime and budget. Key vendors should be part of planning when their equipment or remote access is in scope. A vCISO can coordinate these groups and keep the work tied to business risk.

What should I receive at the end?

Expect an asset and connection map, a findings list ranked by consequence, a remediation roadmap with owners and dates, an executive summary and a retest plan. If the report is only a scanner export, ask for the analysis and prioritization that should accompany it.

Sources

• Cyber Assessment Methods for SCADA Security (U.S. Department of Energy / INL)
• NIST SP 800-171A Rev. 3, Assessing Security Requirements for Controlled Unclassified Information
• Cyber security assessments of industrial control systems (CPNI)
• 21 Steps to Improve Cyber Security of SCADA Networks (U.S. Department of Energy)
• Recommended Cybersecurity Practices for Industrial Control Systems (CISA)
• NIST SP 800-82 Rev. 3, Guide to Operational Technology Security
• NERC CIP-010-5
• NERC CIP-013-3
• NERC Critical Infrastructure Protection Roadmap, January 2026
• CAE Risk Assessment Process (NPSA)

Recommended

• 10 OT Security Controls for Regulated SCADA Operators (NIST/CPG)
• Industrial Cybersecurity Assessment Types: A 2026 Guide
• Security Assessment for Mid-Market Companies: 2026 Guide