Lead SCADA Security Manager common mistakes
Lead SCADA Security Manager · Understand the traps and how to avoid them.
Treating SCADA security as IT security with a different logo: answering questions about field devices, PLCs, RTUs, and safety instrumented systems with standard IT controls such as host-based antivirus, frequent patching, and full-disk encryption applied uniformly across the OT estate.
Most candidates come from an IT security background and default to controls they know. They underestimate how availability and safety constraints, legacy protocols, and long asset lifecycles change what is feasible and appropriate in OT, and they have not internalized zone/conduit thinking or the Purdue model.
What to do instead
Before answering, restate the constraint in the stem: is this a safety-critical process, a legacy device that cannot be patched, or a network segment with a conduit? Then select the control that fits the constraint (compensating controls, network segmentation, allowlisting, passive monitoring) rather than the IT default. Study IEC 62443 zone/conduit and security-level concepts and the Purdue reference model until you can map a device to its level and appropriate control set without hesitation.
Confusing detection with prevention and choosing the wrong control class for the scenario. For example, recommending an intrusion detection system where the stem asks how to prevent unauthorized commands reaching a PLC, or recommending a firewall where the stem asks how to detect a compromised engineering workstation.
The vocabulary of OT security products overlaps (passive monitoring, deep packet inspection, anomaly detection) and candidates pattern-match on product names rather than on the control objective stated in the question. Exam stems often hinge on a single verb such as prevent, detect, contain, or recover.
What to do instead
Underline the verb in the stem and write the control objective in one line before reading the options. Build a personal table mapping common OT controls (segmentation, unidirectional gateway, allowlisting, passive network monitoring, security information and event management correlation, backup and restore) to the objective each serves. Eliminate options that serve a different objective even if they are technically sound.
Treating risk assessment as a one-time documentation exercise: describing a risk register as the deliverable and stopping there, without addressing likelihood and impact estimation method, risk tolerance, treatment options, ownership, and the feedback loop into management review.
Candidates memorize frameworks and produce process descriptions instead of demonstrating judgment. Scenario questions reward showing how risk is quantified, prioritized, accepted, and re-reviewed against a defined appetite, and generic answers about maintaining a register score poorly.
What to do instead
For every risk question, structure the answer as: context and asset criticality, threat and vulnerability inputs, likelihood and consequence method (qualitative or quantitative), comparison to risk appetite, treatment choice with residual risk, named owner, and review cadence. Practice writing this chain in under two minutes so it becomes automatic in scenario items.
Answering governance questions with technical controls. When asked who should approve an OT security policy, how exceptions should be handled, or how security responsibilities should be structured across engineering, operations, and IT, the candidate describes a firewall rule set or a monitoring tool instead of an accountability, approval, or exception mechanism.
Technical candidates are more comfortable with controls than with authority structures, and they conflate the security manager's operational duties with the governance body's decision rights. They also overlook that in OT the plant manager and engineering leadership often hold operational authority that security cannot override unilaterally.
What to do instead
Learn to separate three layers: governance (who decides, who is accountable, how exceptions are approved), management (policy, standards, processes, metrics), and operations (controls and monitoring). For each governance stem, identify the decision right and the accountable role, and answer with the committee, policy, exception, or reporting mechanism rather than a technology.
Assuming compliance equals security. The candidate answers that achieving a certification or passing an audit satisfies the requirement, without addressing continuous monitoring, control effectiveness testing, scope limitations, or the gap between documented process and actual field practice.
Frameworks and standards are heavily marketed as end states, and candidates memorize control lists without learning that certification attests to a management system at a point in time, not to operational resilience. OT environments also frequently have compensating controls that auditors accept but that leave residual risk.
What to do instead
Whenever a compliance option appears, check whether the stem asks for assurance, effectiveness, or resilience. If so, pair compliance with continuous control monitoring, internal audit, metrics, and management review. Be ready to explain what a certification does and does not cover, and to name the residual risks that remain after a successful audit.
Designing recovery around data backups alone. The candidate proposes restoring servers from backup as the continuity answer for a SCADA incident, ignoring configuration and logic restoration, firmware and engineering workstation rebuild, spare hardware lead times, manual operation fallback, and the sequence needed to safely restart a physical process.
IT disaster recovery habits center on data and virtual machines. In OT the hard part is restoring known-good control logic, validated configurations, and physical process state, often with equipment that has multi-month replacement lead times and cannot be restarted without engineering sign-off.
What to do instead
Build a recovery answer in layers: safe-state and manual operation procedures, people and communications, configuration and logic backups stored offline and tested, spare parts and vendor support, staged restoration sequence with engineering validation, and post-restoration verification. Always include the tested-restore and maximum tolerable downtime dimensions, not just backup existence.
Confusing business continuity, disaster recovery, and incident response. The candidate answers a question about keeping a treatment plant operating during a prolonged cyber incident with steps for containing malware, or answers a containment question with business impact analysis and recovery time objectives.
The three disciplines share vocabulary and overlap in practice, so candidates blur their distinct purposes: incident response handles the event, continuity keeps priority services running, and recovery restores capability. Exam stems signal which is intended through time horizon and objective wording.
What to do instead
Memorize a one-line distinction and apply it: incident response is event-scoped and time-critical; continuity is service-scoped and sustained; recovery is capability-scoped and rebuild-oriented. Read the stem for the time horizon and the object being protected, then select the discipline before evaluating options.
Ignoring the human and process layer in incident scenarios. The candidate describes tooling and network actions but omits roles, escalation paths, communications with operations and regulators, evidence handling, and the decision authority to shut down or fail over to manual control.
Technical training rewards tool knowledge, and candidates fear that soft content sounds like filler. In reality, OT incident response failures are dominated by unclear authority, poor coordination between security and plant operations, and communication breakdowns, which is exactly what lead-level questions test.
What to do instead
For every incident scenario, include a people-and-process paragraph: who declares the incident, who can authorize process shutdown, how operations and engineering are notified, how external reporting and customer or regulator communication are handled, and how evidence is preserved. Practice adding this layer to any technical answer so it becomes a habit.
Proposing monitoring or testing that would disrupt the process. The candidate recommends active vulnerability scanning of live control networks, aggressive penetration testing during production, or inline traffic inspection on latency-sensitive links, without addressing scheduling, safety, or passive alternatives.
These are standard IT practices and candidates transfer them without considering scan-induced crashes of fragile devices, production windows, or the safety consequences of latency. Exam items often embed a production constraint that makes the standard IT answer wrong.
What to do instead
Before recommending any active technique, check the stem for production status, safety criticality, and device fragility. Default to passive monitoring and offline or lab-based testing, and when active testing is justified, specify the maintenance window, engineering supervision, rollback plan, and scope exclusions. Name the risk of the technique, not only its benefit.
Failing to connect security management to the organization's strategic and reporting structures. The candidate describes a security program as a set of controls and training, omitting performance metrics, board or executive reporting, budget justification, third-party and supply chain risk, and alignment with enterprise risk management.
Lead-level items test whether the candidate can operate at the management layer, but candidates prepare from technical study material and never practice articulating value, metrics, and executive communication. They also underestimate supply chain and vendor risk in OT, where integrators and remote support are major exposure paths.
What to do instead
Prepare a management narrative: the top metrics you would report (patch latency for critical assets, conduit compliance, incident mean time to detect and respond, backup restore test results), how you would justify budget in risk terms, and how vendor and integrator access is governed. Rehearse a two-minute executive briefing so strategic questions feel familiar rather than abstract.