SOT-001 — CompTIA SecOT+ V1 Quick Review
Quick Review for CompTIA SecOT+ V1 (SOT-001): high-yield OT security concepts, decision rules, common traps, and practice guidance.
Quick Review for CompTIA SecOT+ V1 (SOT-001)
This Quick Review is designed for candidates preparing for CompTIA SecOT+ V1 (SOT-001) who want a focused refresher before moving into topic drills, mock exams, and detailed explanations.
Use it to reinforce the highest-yield ideas: operational technology security priorities, industrial network architecture, asset discovery, segmentation, monitoring, vulnerability management, incident response, and common exam decision traps.
This is IT Mastery review support. It is not affiliated with CompTIA.
Exam Identity
| Item | Detail |
|---|---|
| Vendor / provider | CompTIA |
| Official exam title | CompTIA SecOT+ V1 (SOT-001) |
| Official exam code | SOT-001 |
| Review focus | Security of OT, ICS, industrial environments, and supporting IT/OT operations |
| Best next study step | Use original practice questions to test decisions under scenario pressure |
High-Yield Mindset
OT security questions often test whether you can protect systems without disrupting physical processes.
The OT Priority Shift
| In many IT environments | In many OT environments |
|---|---|
| Confidentiality is often emphasized first | Safety and availability often dominate |
| Systems can usually be patched more frequently | Patching may require testing, outage windows, or vendor approval |
| Active scanning is common | Active scanning can disrupt fragile devices |
| Endpoint agents are common | Agents may be unsupported or risky on control systems |
| Reimaging is routine | Reimaging may require validated configurations and process owner approval |
| Data loss is a major concern | Loss of view, loss of control, unsafe state, or downtime can be critical |
Practical Exam Rule
When a scenario involves production OT:
- Protect human safety first.
- Preserve process availability and integrity.
- Coordinate with operations, engineering, and asset owners.
- Prefer passive visibility before intrusive testing.
- Use segmentation, compensating controls, and change control when patching is not immediately possible.
Core OT and ICS Terms
| Term | What to remember for SOT-001-style scenarios |
|---|---|
| OT | Technology that monitors or controls physical processes. |
| ICS | Industrial control system; broad category including SCADA, DCS, PLCs, RTUs, HMIs, and related systems. |
| SCADA | Supervisory control and data acquisition; often geographically distributed. |
| DCS | Distributed control system; commonly used in plants and continuous processes. |
| PLC | Programmable logic controller; directly controls equipment and logic. |
| RTU | Remote terminal unit; common in remote monitoring/control environments. |
| HMI | Human-machine interface; operator workstation for viewing and controlling processes. |
| Engineering workstation | Used to program/configure PLCs and control devices; high-value target. |
| Historian | Collects and stores process data; often bridges OT and enterprise reporting. |
| SIS | Safety instrumented system; designed to move process to safe state. Treat as highly critical. |
| Sensors and actuators | Field-level devices that measure and affect the physical process. |
| Jump server | Controlled access point into OT networks; should be monitored and hardened. |
| OT DMZ | Buffer zone between IT and OT networks; reduces direct connectivity. |
| Conduit | Controlled communication path between zones. |
| Zone | Group of assets with similar trust level, function, or risk. |
Purdue Model Quick Review
The Purdue model is a common way to reason about industrial environments. Exact implementations vary, but the concept is high-yield: separate enterprise IT, OT operations, control systems, and field devices.
| Level | Typical systems | Security focus |
|---|---|---|
| Level 0 | Sensors, actuators, physical process | Physical safety, tamper resistance, reliable signaling |
| Level 1 | PLCs, RTUs, I/O controllers | Control logic integrity, restricted programming access |
| Level 2 | HMIs, engineering workstations, local control | Operator access, endpoint hardening, change control |
| Level 3 | Site operations, historians, OT services | OT authentication, logging, patch coordination, backups |
| Level 3.5 | OT DMZ, jump servers, data brokers | Controlled IT/OT exchange, remote access control |
| Level 4 | Enterprise IT systems | Business systems, identity, corporate apps |
| Level 5 | External/cloud/Internet services | Third-party access, cloud security, external exposure control |
Purdue Model Traps
| Trap | Better answer |
|---|---|
| Allowing direct enterprise-to-PLC access | Use OT DMZ, jump hosts, firewalls, and approved conduits |
| Treating VLANs as complete security boundaries | Use firewall rules, ACLs, monitoring, and segmentation policy |
| Sending all OT data directly to cloud | Use brokered, authenticated, monitored, least-privilege data flows |
| Giving vendors persistent VPN access | Use time-bound, approved, MFA-protected, logged access |
| Ignoring historian placement | Treat historians as potential IT/OT bridges and monitor them |
OT Security Decision Rules
| Scenario asks for… | Prefer… | Avoid… |
|---|---|---|
| Discovering assets in production OT | Passive discovery, network taps/SPAN, configuration review | Aggressive active scanning without approval |
| Reducing IT-to-OT risk | OT DMZ, firewalls, jump servers, strict conduits | Flat networks or direct routing |
| Vendor maintenance access | MFA, PAM, session recording, time-bound access | Shared accounts and always-on VPNs |
| Vulnerable PLC with no patch | Segmentation, firewall rules, vendor guidance, monitoring | Immediate untested firmware update |
| Ransomware resilience | Offline/immutable backups, tested restoration, segmentation | Backups reachable from compromised domain |
| Suspicious OT traffic | Validate baseline, compare with process state, involve operations | Blocking blindly and disrupting control |
| Legacy unsupported system | Compensating controls, isolation, allowlisting | Assuming normal IT patch cadence |
| Engineering workstation compromise | Contain carefully, preserve logic/configs, verify controllers | Reimage without process-owner coordination |
| New IIoT gateway | Certificate-based auth, least privilege, egress control | Unrestricted outbound Internet access |
| Incident in active process | Safety-first response with operations lead | Pure IT-only incident playbook |
Asset Inventory and Baselines
Asset inventory is foundational because OT environments often contain legacy systems, vendor-managed devices, undocumented connections, and fragile protocols.
What a Good OT Inventory Captures
| Inventory field | Why it matters |
|---|---|
| Asset type | PLC, HMI, historian, workstation, switch, sensor, gateway |
| Location | Plant, line, cabinet, remote site, control room |
| Process criticality | Shows safety and production impact |
| Owner | Identifies who approves changes |
| Vendor/model/firmware | Supports vulnerability and supportability checks |
| Network details | IP, MAC, VLAN, zone, conduit, protocol use |
| Software/configuration | Enables recovery and change validation |
| Communication flows | Supports segmentation and anomaly detection |
| Backup status | Confirms recoverability |
| Maintenance window | Determines when changes are possible |
| Dependencies | Shows what breaks if a system is isolated |
Baseline Concepts
A baseline is the known-normal state of assets, configurations, communications, and process behavior.
High-yield baseline examples:
- PLC-to-HMI communication patterns
- Engineering workstation programming activity
- Historian polling intervals
- Normal remote access windows
- Expected protocol commands
- Usual bandwidth and connection pairs
- Normal operator login times
- Approved firmware and logic versions
Common Inventory Mistakes
- Relying only on spreadsheets that are never reconciled.
- Using aggressive discovery tools on fragile production networks.
- Tracking IP addresses but not process criticality.
- Ignoring temporary vendor connections.
- Failing to document PLC logic, firmware, and configuration backups.
- Treating OT assets as if they are owned only by IT.
Industrial Protocols: What to Recognize
You do not need to memorize every packet field to answer many exam scenarios. Focus on the security implications.
| Protocol / technology | Common context | Security review point |
|---|---|---|
| Modbus / Modbus TCP | Industrial control communication | Often lacks native authentication or encryption in legacy use |
| DNP3 | Utilities and remote control | Secure variants may exist, but legacy deployments require protection |
| EtherNet/IP | Industrial automation | Segment and monitor command behavior |
| PROFINET | Industrial Ethernet | Protect controller and device communication paths |
| OPC DA | Legacy Windows-based data exchange | Often difficult to secure; isolate and control access |
| OPC UA | Modern industrial interoperability | Can support stronger security when configured correctly |
| IEC 61850 | Power systems/substations | High criticality; protect timing and control messages |
| BACnet | Building automation | Watch for exposed building systems and weak segmentation |
| MQTT | IIoT messaging | Secure broker, authentication, authorization, and TLS matter |
| Serial protocols | Legacy control systems | May be bridged to IP; gateway security becomes important |
| Time sync protocols | Process coordination and logging | Protect against time manipulation and preserve forensic value |
Protocol Trap
If a protocol lacks built-in security, the best answer is usually not “encrypt the PLC” in isolation. The better control is often layered:
- Segment the network.
- Restrict allowed communication pairs.
- Use protocol-aware firewalls or monitoring.
- Place gateways in controlled zones.
- Authenticate remote users and systems.
- Monitor for abnormal commands.
- Use secure protocol variants where feasible and supported.
Segmentation and Network Architecture
Segmentation limits blast radius and controls who can communicate with critical OT assets.
Strong Segmentation Patterns
| Pattern | Purpose |
|---|---|
| OT DMZ | Prevents direct IT-to-OT communication |
| Jump server | Centralizes and logs administrative access |
| Firewall between zones | Enforces allowed conduits |
| Data diode / unidirectional gateway | Allows one-way data flow where appropriate |
| Separate identity boundary | Reduces enterprise domain compromise impact |
| Remote access broker | Controls vendor and engineer sessions |
| Industrial IDS sensor | Monitors traffic without disrupting operations |
| Management network | Separates administration from process control traffic |
| Egress allowlisting | Prevents uncontrolled outbound connections |
| Network access control | Helps restrict unauthorized devices where feasible |
Segmentation Decision Path
flowchart TD
A[Need communication between IT and OT?] --> B{Is it required for operations?}
B -- No --> C[Deny by default]
B -- Yes --> D{Can data flow be one-way?}
D -- Yes --> E[Use broker, data diode, or controlled publish path]
D -- No --> F[Use OT DMZ or jump host]
F --> G[Apply MFA, least privilege, logging]
G --> H[Restrict ports, protocols, source, destination]
H --> I[Monitor and review periodically]
Segmentation Traps
- “Flat but firewalled at the perimeter” is not enough.
- VLANs help organize traffic but do not replace policy enforcement.
- Remote access should not land directly on controllers.
- Engineering workstations need extra protection because they can change control logic.
- Historians and reporting servers can become pivot points.
- Temporary vendor access often becomes permanent if not governed.
Identity, Access, and Privileged Operations
OT access control must balance accountability, safety, and operational continuity.
| Control | OT-specific review point |
|---|---|
| MFA | Strongly preferred for remote and privileged access |
| PAM | Controls and records privileged sessions |
| RBAC | Assigns access by role: operator, engineer, vendor, admin |
| Least privilege | Users get only the access needed for their function |
| Named accounts | Improve accountability compared with shared accounts |
| Break-glass accounts | Must be protected, documented, monitored, and tested |
| Session recording | Useful for vendor and privileged access review |
| Time-bound access | Reduces risk from standing privileges |
| Account review | Removes stale vendor, contractor, and former employee access |
| Password vaulting | Helps protect privileged credentials |
Exam Trap: Shared Accounts
Shared accounts are common in older OT environments, but they reduce accountability. If a scenario asks for the best security improvement, prefer named accounts, role-based access, MFA, and logging where operationally feasible.
Vulnerability and Patch Management
OT vulnerability management is risk-based. The goal is not simply to patch fastest; it is to reduce risk without causing unsafe or unplanned disruption.
OT Vulnerability Workflow
- Identify affected assets.
- Confirm process criticality and exposure.
- Check vendor guidance and compatibility.
- Test patches or firmware in a lab when possible.
- Schedule maintenance windows.
- Apply compensating controls if patching must wait.
- Monitor for exploitation.
- Document risk acceptance if required.
- Validate operation after the change.
Risk Factors to Combine
| Factor | Why it matters |
|---|---|
| Exploitability | Is there a working exploit or active exploitation? |
| Exposure | Is the asset reachable from untrusted networks? |
| Process criticality | Would compromise affect safety or production? |
| Compensating controls | Segmentation may reduce immediate risk |
| Vendor support | Unsupported patches can break systems |
| Maintenance window | Determines feasible remediation timing |
| Asset role | Engineering workstations and historians may be high-value pivots |
| Recovery capability | Backups and spares affect response options |
Vulnerability Management Traps
| Mistake | Better approach |
|---|---|
| “Patch immediately” for all OT devices | Use tested, scheduled, risk-based patching |
| Ignoring vulnerable assets because they are internal | Assess lateral movement and insider risk |
| Using only CVSS | Add exposure, exploitability, and process impact |
| Scanning production with default tools | Use passive discovery or approved safe scans |
| Applying vendor firmware without validation | Test and coordinate with operations |
| Forgetting compensating controls | Use isolation, ACLs, monitoring, and virtual patching |
Monitoring, Detection, and Logging
OT monitoring should detect abnormal behavior while preserving availability.
High-Value Data Sources
| Source | What it can reveal |
|---|---|
| Passive network sensors | New devices, unusual protocols, unexpected commands |
| Firewall logs | Blocked attempts, policy violations, remote access activity |
| Jump server logs | Administrative sessions and file transfers |
| HMI logs | Operator actions and abnormal access |
| Engineering workstation logs | Logic changes, project downloads, programming activity |
| Historian logs | Data collection anomalies and access patterns |
| Domain/authentication logs | Credential attacks and lateral movement |
| Endpoint logs | Malware, unauthorized tools, USB use |
| Backup logs | Failed backups or tampering |
| Physical access logs | Correlation with cabinet or control room activity |
Detection Examples
| Observation | Possible concern |
|---|---|
| PLC programming outside maintenance window | Unauthorized logic change |
| New device communicating with controllers | Rogue device or undocumented vendor access |
| HMI connecting to Internet | Misconfiguration or compromise |
| Repeated failed logins to jump host | Credential attack |
| Historian sending unusual outbound traffic | Data exfiltration or pivot |
| Broadcast storm or traffic spike | Misconfiguration, loop, DoS, or malware |
| Controller mode change | Potential process impact |
| Disabled security agent | Evasion or unauthorized change |
| Time drift across systems | Logging/forensics problem or time-source issue |
Monitoring Trap
Do not treat every anomaly as an immediate reason to block traffic. In OT, blocking the wrong flow can disrupt operations. The better answer is usually to validate with operations, check the baseline, assess safety impact, then contain carefully.
Incident Response in OT Environments
OT incident response must be planned with operations and engineering teams before an incident occurs.
OT Incident Priorities
- Protect life and safety.
- Stabilize the physical process.
- Preserve visibility and control.
- Contain the cyber incident.
- Preserve evidence where feasible.
- Recover using validated configurations.
- Review lessons learned and improve controls.
OT Incident Response Table
| Phase | High-yield actions |
|---|---|
| Preparation | Playbooks, contacts, backups, spares, tabletop exercises, vendor procedures |
| Detection | Correlate cyber alerts with process anomalies |
| Analysis | Determine affected assets, process impact, and attack path |
| Containment | Segment carefully; avoid unsafe shutdowns |
| Eradication | Remove malware, close access paths, reset credentials |
| Recovery | Restore from known-good backups; validate logic and process state |
| Lessons learned | Update baselines, rules, diagrams, training, and controls |
Common Incident Mistakes
- Rebooting controllers without understanding process impact.
- Disconnecting systems without preserving operator visibility.
- Letting IT responders act without operations coordination.
- Assuming ransomware only affects business systems.
- Forgetting to verify PLC logic and firmware integrity.
- Restoring from backups that were never tested.
- Ignoring vendor remote access as an entry path.
- Failing to preserve logs from jump servers, firewalls, and engineering workstations.
Ransomware and Malware Resilience
Ransomware scenarios are high-yield because they test segmentation, backup, identity, and recovery decisions.
Strong Ransomware Controls
| Control | Why it matters |
|---|---|
| Network segmentation | Limits spread from IT into OT |
| MFA | Reduces credential-based access |
| Offline or immutable backups | Prevents attackers from encrypting backups |
| Tested restoration | Confirms recovery is realistic |
| Application allowlisting | Helps control what can run on OT endpoints |
| Email and web controls | Reduces initial infection risk |
| EDR where compatible | Improves detection on supported systems |
| Least privilege | Limits damage from compromised accounts |
| Disable unnecessary services | Reduces attack surface |
| Incident playbooks | Speeds safe response |
Backup Review Points
Backups should include more than ordinary files:
- PLC logic
- HMI configurations
- Engineering workstation projects
- Historian configurations
- Firewall and switch configurations
- Server images where appropriate
- License keys and vendor installation media
- Golden images for supported endpoints
- Documentation for restore order and dependencies
Supply Chain, Vendor, and Third-Party Risk
OT environments often depend on vendors for maintenance, firmware, proprietary tools, and remote support.
| Risk | Control |
|---|---|
| Persistent vendor VPN | Time-bound access with approval and MFA |
| Shared vendor credentials | Named accounts and session logging |
| Unverified firmware | Vendor validation, integrity checks, change control |
| Contractor laptop connects to OT | Controlled access, scanning, jump host, no direct access |
| Remote support tools | Approved tools only, monitored sessions |
| Poor asset ownership | Contracts and procedures defining responsibilities |
| Untracked changes | Formal change management and configuration records |
| Unsupported devices | Risk register, compensating controls, lifecycle planning |
Vendor Access Trap
The easiest operational answer is often “let the vendor connect directly.” The safer exam answer is controlled vendor access through approved channels, with least privilege, MFA, logging, time limits, and operations approval.
Physical and Environmental Security
OT security is not only network security. Physical access to cabinets, ports, controllers, sensors, and engineering stations can create cyber and safety risk.
| Area | Review focus |
|---|---|
| Control rooms | Badge access, visitor control, locked consoles |
| Cabinets | Locks, tamper evidence, port security |
| Field devices | Protection from tampering and environmental damage |
| USB ports | Removable media control and scanning stations |
| Network closets | Switch access, spare port control, cable management |
| Remote sites | Physical inspections, cameras, alarms, secure enclosures |
| Power and HVAC | Availability and environmental reliability |
| Safety systems | Extra change control and strict access |
Secure Configuration and Hardening
Hardening in OT should be tested and coordinated. A technically “secure” setting can cause downtime if it breaks vendor support or process communication.
High-Yield Hardening Areas
| Area | Examples |
|---|---|
| Services | Disable unused services, ports, and protocols |
| Accounts | Remove default accounts, enforce least privilege |
| Passwords | Change defaults, vault privileged credentials |
| Remote access | Disable unauthorized tools, require MFA |
| Host firewall | Restrict inbound/outbound traffic |
| Application control | Allow approved software only |
| Logging | Enable useful audit trails |
| Time sync | Centralized, reliable time source |
| Removable media | Control, scan, and log use |
| Configuration backups | Store known-good versions securely |
Hardening Trap
Do not harden production OT by applying generic server baselines without testing. Use vendor-supported baselines, lab validation, change control, and rollback plans.
Cloud, IIoT, and Edge Connectivity
Modern OT environments may send operational data to cloud platforms, analytics systems, or remote monitoring services. These connections increase value and risk.
| Area | Key review point |
|---|---|
| Edge gateway | Harden, patch, monitor, and restrict access |
| Cloud identity | Use least privilege and strong authentication |
| Certificates | Manage lifecycle and protect private keys |
| APIs | Authenticate, authorize, log, and rate-limit |
| MQTT broker | Secure topics, credentials, and TLS |
| Data flow | Send only required data to approved destinations |
| Egress filtering | Prevent arbitrary outbound connections |
| Device onboarding | Verify identity before trust |
| Remote management | Use approved tools and logging |
| Data classification | Understand operational sensitivity |
Cloud/IIoT Trap
Do not assume outbound-only traffic is automatically safe. Malware and compromised devices often use outbound channels. Control destinations, authenticate systems, inspect where feasible, and monitor behavior.
Governance, Risk, and Documentation
Governance questions usually ask who approves decisions, how risk is documented, and how controls are sustained.
Useful Governance Artifacts
| Artifact | Purpose |
|---|---|
| Network diagrams | Show zones, conduits, and dependencies |
| Asset inventory | Supports risk, patching, and response |
| Risk register | Tracks accepted and mitigated risks |
| Change records | Prove what changed, when, and why |
| Access reviews | Remove stale or excessive access |
| Incident playbooks | Guide coordinated response |
| Backup and recovery plans | Support restoration |
| Vendor access procedures | Control third-party risk |
| Maintenance schedules | Align security work with operations |
| Training records | Show staff readiness |
Framework Awareness
Candidates should recognize that OT security programs often reference industry frameworks and guidance, such as NIST Cybersecurity Framework concepts, NIST SP 800-82-style ICS guidance, and IEC 62443-style zone/conduit thinking. For exam scenarios, focus less on memorizing framework labels and more on applying the control logic correctly.
Common SOT-001 Candidate Traps
| Trap | Why it is wrong | Better thinking |
|---|---|---|
| Applying IT playbooks directly to OT | Can disrupt physical processes | Adapt response to safety and operations |
| Patching first in every scenario | Patches may break control systems | Test, schedule, and use compensating controls |
| Active scanning production networks | May crash fragile devices | Prefer passive discovery or approved scans |
| Treating confidentiality as always highest | OT often prioritizes safety and availability | Match control to process risk |
| Ignoring engineering workstations | They can alter controller logic | Harden, monitor, and restrict access |
| Trusting internal networks | Flat OT networks are risky | Segment and monitor east-west traffic |
| Leaving vendor VPN always on | Persistent access increases attack surface | Time-bound, MFA-protected, logged access |
| Assuming backups are good | Untested backups may fail | Test restores and protect backups |
| Using shared admin accounts | No accountability | Named accounts, PAM, session recording |
| Blocking traffic without analysis | Could stop production | Validate with baseline and operations |
| Forgetting physical access | Local access can bypass network controls | Secure cabinets, ports, and control rooms |
| Overlooking time sync | Logs become hard to correlate | Maintain reliable time synchronization |
| Monitoring only IT logs | OT-specific events are missed | Include PLC/HMI/jump/industrial network data |
| Assuming VLAN equals segmentation | VLANs are not policy by themselves | Enforce rules with firewalls/ACLs |
| Ignoring cloud egress | Outbound paths can be abused | Allowlist, authenticate, monitor |
Quick Scenario Practice Patterns
Use these patterns when working through original practice questions.
Scenario 1: Unknown Devices on OT Network
Best reasoning:
- Do not immediately scan aggressively.
- Check passive monitoring, switch MAC tables, and network diagrams.
- Identify owner, location, and communication flows.
- Validate with operations.
- Quarantine or restrict only after assessing process impact.
- Update inventory and monitoring rules.
Scenario 2: Critical PLC Vulnerability Announced
Best reasoning:
- Identify affected PLCs and exposure.
- Review vendor guidance.
- Determine process criticality.
- Test patch or firmware where possible.
- Apply segmentation or firewall restrictions immediately if needed.
- Schedule maintenance window.
- Monitor for exploit indicators.
- Document residual risk.
Scenario 3: Vendor Needs Emergency Access
Best reasoning:
- Confirm business and operational need.
- Use approved remote access path.
- Require MFA and named account.
- Limit access to required systems.
- Record or log session.
- Set expiration time.
- Review changes afterward.
Scenario 4: Ransomware in Enterprise IT
Best reasoning:
- Assume possible OT risk until validated.
- Block unnecessary IT/OT paths.
- Confirm OT backups and monitoring.
- Review domain trust and shared credentials.
- Increase monitoring of jump hosts, historians, and remote access.
- Coordinate with operations before isolation decisions.
Scenario 5: Suspicious PLC Logic Change
Best reasoning:
- Involve operations and engineering immediately.
- Assess safety and process impact.
- Preserve logs and project files.
- Compare logic to known-good backup.
- Identify account and access path used.
- Contain compromised credentials or workstation.
- Restore validated logic if required.
Fast Review Tables
Best Control by Goal
| Goal | Strong candidate answer |
|---|---|
| Reduce IT/OT pivoting | OT DMZ and strict conduits |
| Secure vendor access | MFA, PAM, time-bound access, logging |
| Discover assets safely | Passive monitoring and documentation review |
| Protect unsupported systems | Isolation and compensating controls |
| Detect abnormal control traffic | Industrial protocol-aware monitoring |
| Recover from ransomware | Offline/immutable tested backups |
| Control PLC logic changes | Engineering workstation security and change management |
| Prevent rogue devices | Physical security, port control, NAC where feasible |
| Improve accountability | Named accounts and session logs |
| Reduce cloud connection risk | Egress allowlisting and strong device identity |
“Best First Step” Clues
| If the question says… | Think… |
|---|---|
| Production line is running | Safety and operations coordination first |
| Legacy PLCs are unstable | Avoid intrusive scanning or unsupported agents |
| Vendor must troubleshoot remotely | Controlled, logged, time-limited access |
| No accurate inventory exists | Build passive inventory and baseline |
| Flat OT network | Segment into zones and conduits |
| Patch unavailable | Compensating controls and monitoring |
| Unknown traffic appears | Compare to baseline and validate owner |
| Ransomware detected in IT | Protect IT/OT boundary immediately |
| Operator lost view | Prioritize visibility and safe process state |
| Controller behavior changed | Validate logic/configuration integrity |
How to Use This Quick Review With a Question Bank
For efficient SOT-001 preparation:
- Review the tables above for 20–30 minutes.
- Start with topic drills on OT architecture, asset inventory, segmentation, and incident response.
- After each missed question, write down the decision rule you missed.
- Use original practice questions to force scenario-based judgment, not memorization.
- Move to mixed sets only after your weak topics are improving.
- Use detailed explanations to compare your reasoning with the safest operational answer.
- Finish with timed mock exams to practice pacing and decision confidence.
Final Readiness Checklist
Before you sit for CompTIA SecOT+ V1 (SOT-001), confirm that you can explain:
- Why OT security prioritizes safety, availability, and process integrity.
- How the Purdue model supports segmentation decisions.
- Why passive discovery is often preferred in production OT.
- How to secure vendor remote access.
- How to handle vulnerabilities when immediate patching is unsafe.
- What makes engineering workstations high-value targets.
- How an OT DMZ reduces IT/OT pivot risk.
- What data sources support OT detection and response.
- How ransomware can affect OT even if it starts in IT.
- Why tested backups must include configurations and control logic.
- How to coordinate incident response with operations and engineering.
- Why compensating controls are central to legacy OT security.
Practical Next Step
Use this Quick Review as your final refresher, then move into IT Mastery practice: start with targeted topic drills, review the detailed explanations for every miss, and build up to full mixed question bank sessions before attempting mock exams.
Continue in IT Mastery
Use this Quick Review as a final concept map, then move into IT Mastery for focused topic drills, mixed practice sets, timed mock exams, and detailed explanations. The practice questions are original IT Mastery practice items; they are not official CompTIA questions, copied live-exam content, or exam dumps.