OT Security • Self-Assessment

OT Security Self-Audit:
A 30-Point Checklist

Merobix Engineering • • 12 min read

You do not need a security operations center, a consulting engagement, or a six-figure budget to know where your OT security actually stands. You need an honest afternoon and a list that does not flinch. This is that self-audit: 30 evidence-based checks across six domains - identity and access, network and remote access, devices and gateways, data protection, detection and response, and governance - each scored one point, each answerable by a two-person team in a day. The output is a number you can track, a remediation list ordered by real risk, and a clear-eyed view of what to demand from your SCADA vendor versus what only you can fix.

Back to Blog

Part of our SCADA security guide library - 60+ articles on securing industrial operations.

30Evidence-Based Checkpoints
6Security Domains Covered
1Day for a Two-Person Team to Complete

How to Use This Checklist

Three rules make the difference between a useful audit and a feel-good exercise. First, score on evidence, not memory: a point is earned only if you can produce the artifact - a screenshot, a config export, a log entry, a dated test record. "I'm pretty sure MFA is on" is a zero. Second, one point per item, no partial credit: partial credit is how 12-point programs report themselves as 25s. Third, write down the gap while you are looking at it - the remediation list you build during scoring is worth more than the score.

The checklist draws on the control families that recur across NIST SP 800-82 Rev. 3, the ISA/IEC 62443 series, and the CISA cross-sector performance goals, compressed to what a small team can actually verify. It applies whether your SCADA is on-premise, cloud, or hybrid - items your platform vendor should be answering for you are flagged as vendor questions, and our 50 vendor security questions covers that side of the fence in full. Interpret your total with this rubric:

Score What It Means What to Do Next
0–14Foundational gaps - likely including exposed access paths, shared logins, or untested backupsStop planning, start fixing: the five highest-risk items below, this quarter
15–22Typical mid-maturity operation - core hygiene present, discipline unevenWork the remediation list top-down; re-score in six months
23–27Strong program by most industry standardsShift energy to drills, reviews, and independent validation
28–30Excellent - or optimistically scoredHave someone outside the team re-check the evidence; consider a professional assessment

Domain 1: Identity & Access (Items 1–5)

  1. Every user has a named, individual account. No shared "operator" logins anywhere - on the SCADA platform, HMIs, or engineering workstations. Shared accounts make audit trails fiction and offboarding impossible.
  2. MFA is enforced on all remote access to OT systems. TOTP at minimum; phishing-resistant FIDO2/passkeys - the strongest authenticator class in NIST SP 800-63B's digital identity guidelines - where supported. A password alone between the internet and your process is a 2015 posture.
  3. Roles enforce least privilege, including on control actions. Viewers cannot write setpoints; role boundaries cover commands, not just screen visibility. Platforms like Merobix ship graded roles - viewer through operator, engineer, and admin - with site-level authorization, so a user's reach is bounded by both role and site.
  4. Access reviews happen on a schedule and leave a record. Quarterly for control-capable accounts. If you cannot produce the last review's dated record, score zero - then read our user access review guide.
  5. Failed logins lock out and alert. Brute-force attempts should hit a lockout and generate a notification a human sees, not just a log line nobody reads.

Domain 2: Network & Remote Access (Items 6–10)

  1. Nothing in the OT network is reachable inbound from the internet. No forwarded ports, no exposed HMIs, no VNC/RDP. Verify from outside - check your public IP ranges the way an attacker would, because Shodan already has.
  2. OT is segmented from corporate IT. A firewalled boundary with explicit, minimal rules; a laptop on the office network cannot ping a PLC. Flat networks turn one phishing email into a process event.
  3. Remote connectivity is outbound-only or tightly brokered. The strongest pattern is a gateway that initiates outbound TLS with zero inbound rules - the architecture detailed in our secure SCADA for OT networks guide. If you run a VPN instead, it is patched, MFA-protected, and monitored.
  4. Vendor and integrator remote access is controlled and time-bounded. No standing tunnels; access granted per engagement, logged, and revoked after.
  5. Firewall rules are documented and reviewed at least annually. Every rule has an owner and a reason. Rules nobody can explain are removed, not inherited forever.

Domain 3: Devices & Gateways (Items 11–15)

  1. Default credentials are gone from every PLC, RTU, HMI, and network device. Yes, including the cellular router from 2019. Default passwords remain a leading initial access vector in ICS incidents.
  2. You have a current asset inventory of OT devices. Make, model, firmware version, location, owner. You cannot patch, segment, or replace what you have not listed.
  3. Each device or gateway has a unique identity and credentials. No fleet-wide shared secrets: one compromised device should never impersonate the rest. Merobix registers each device with unique credentials and device-generated signing identities for exactly this reason.
  4. Gateway and edge software updates are verified before install. Signed artifacts, checked on the device - not unsigned binaries from a USB stick or an email attachment.
  5. Field sites buffer data through outages. Store-and-forward at the edge means a connectivity failure costs you nothing but latency - and means an attacker cannot create blind spots by cutting a link.

Domain 4: Data Protection (Items 16–20)

  1. All telemetry and platform traffic is encrypted in transit. TLS on cloud, MQTT, and remote industrial connections. Legacy serial links inside a locked cabinet are one thing; plaintext across networks is another.
  2. Telemetry integrity is protected, not assumed. Best practice is cryptographically signed data with replay detection - the case for it is in our telemetry integrity guide. Minimum bar: you can articulate how you would detect forged or replayed values.
  3. Backups exist, and a restore has actually been tested. The item ransomware audits first. An untested backup is a hope, not a control; validate archives and drill restores on a schedule.
  4. Audit trails are tamper-evident and retained. Every login, config change, and control action attributed to a person, in records that cannot be quietly edited - immutable or hash-chained where the platform supports it.
  5. Data ownership, retention, and export are settled in writing. You know where your data lives, how long it is kept, and how you would get it out - the contract questions in our data residency and export guide.

Domain 5: Detection & Response (Items 21–25)

  1. Security-relevant events generate alerts a human actually receives. Repeated auth failures, lockouts, privilege probes, and suspicious control activity reach someone by email, SMS, or SIEM - with delivery that retries on failure rather than dying silently.
  2. Telemetry freshness is monitored. You can tell the difference between "site is quiet" and "site stopped reporting twenty minutes ago." Stale data that looks live is both an operational and a security blind spot.
  3. An OT-specific incident response plan exists on paper. Who isolates what, who calls whom, what keeps running - written before the bad day, per our OT incident response guide.
  4. You have exercised the plan at least once. A two-hour tabletop counts. A plan that has never been walked through is a document, not a capability.
  5. Security events can be exported to central logging or a SIEM. Even if you do not run a SOC today, the export path should exist so your insurer, auditor, or future MSSP can plug in.

Domain 6: Governance & Vendors (Items 26–30)

  1. Someone owns OT security by name. Not a committee, not "IT generally" - a person whose job description says so, with a deputy.
  2. Offboarding removes all access the same day. Platform accounts, VPN, shared spreadsheets of credentials (which should not exist), gate codes. Test it against the last departure.
  3. Your SCADA vendor has answered your security questions in writing. Architecture, MFA, tenant isolation, patching, breach notification. If you have never asked, start with our 12-control cloud SCADA security checklist.
  4. API keys and integrations follow a lifecycle. Scoped to least privilege, inventoried, rotated or revoked when owners leave or integrations retire.
  5. Management of change covers security. New connections, new remote access, and new integrations get a security review before energization - MOC discipline applied to the digital side of the plant.

How This Maps to the Frameworks

If a customer, insurer, or regulator later asks which standard your self-audit follows, the honest answer is "the intersection of several." Items 1–5 and 26–30 track the identification, access control, and governance functions of the NIST Cybersecurity Framework and the account-management expectations that appear in every IEC 62443 conversation about asset owners. Items 6–10 are the zone-and-conduit segmentation model of IEC 62443-3-2 and the network architecture chapters of NIST SP 800-82. Items 11–15 correspond to component and device hardening themes from 62443-4-2, and items 16–25 line up with the data protection, detection, and response functions that CISA's cross-sector cybersecurity performance goals distilled for operators without security teams. None of this makes a self-audit a certification - but it does mean the evidence folder you build here becomes the starting inventory for any formal assessment you pursue later, from a 62443 gap analysis to an insurer's questionnaire, instead of starting that work from a blank page.

What to Do With Your Score

Prioritize by risk, not by domain order. One internet-exposed HMI (item 6) outweighs five missing documents; fix exposure, MFA, shared accounts, backup restores, and lockout alerting before anything else on the list. Then work the remainder as a standing backlog - one or two items per month is a realistic pace for a small team, and it compounds fast. Re-run the audit twice a year and after major changes, and track the trajectory rather than worshiping the number. If you are a three-person operation wondering how any of this is feasible without headcount, the honest answer is that platform choice does a third of the list for you - a cloud platform with MFA, roles, signed telemetry, audit trails, and alerting built in converts a dozen of these items from projects into defaults, which is the argument laid out in SCADA security for small operators.

Key takeaway: a self-audit's value is not the score - it is the honest, evidence-backed remediation list it forces into existence. Thirty questions, one day, no consultants: you will finish knowing your five most dangerous gaps, and most operations can close all five inside a quarter. Merobix was built so that many of these items are platform defaults rather than customer projects - see the security architecture, or walk the checklist against the live platform in a demo.

Frequently Asked Questions

How do I audit my own OT security without hiring consultants?

Use a structured checklist, answer from evidence rather than memory, and score honestly. This guide's 30 points cover six domains - identity and access, network and remote access, devices and gateways, data protection, detection and response, and governance and vendors. For each item, award the point only if you can produce the evidence: a screenshot, a config export, a log entry, a dated document. A two-person team - one operations, one IT - can complete the exercise in a day, and the output doubles as a prioritized remediation list.

How often should I run an OT security self-audit?

Twice a year as a rhythm, plus after any significant change - a new site, a SCADA migration, a vendor switch, an incident, or a major staffing change. Some items deserve their own faster cadence: user access reviews are commonly quarterly, and backup restore tests should happen at least quarterly as well. The score matters less than the trajectory; a 19 that was a 14 six months ago is a healthy program, while a 24 that nobody can evidence is theater.

What is a good score on a 30-point OT security checklist?

As a rough band: below 15 means foundational gaps that deserve urgent attention - typically exposed remote access, shared accounts, or untested backups; 15 to 22 is a typical mid-maturity operation with a clear remediation list; 23 to 27 is a strong program by most industry standards; 28 or higher usually indicates either genuine excellence or optimistic self-scoring - re-check the evidence. Prioritize by risk, not score: one exposed inbound port outweighs five missing policy documents.

Which OT security checklist items matter most?

If you can only fix five things, fix these in order: eliminate internet-exposed inbound access to OT (VPN-less port forwarding, exposed HMIs and VNC/RDP); enforce MFA on every remote account; eliminate shared logins so every action traces to a person; prove a backup restore actually works before ransomware asks; and turn on lockout plus alerting for repeated failed logins. These five close the doors most real-world industrial incidents walk through.

Does a self-audit replace a professional assessment or penetration test?

No - it complements one. A self-audit finds the gaps you can see and fixes the cheap ones, which makes a later professional assessment dramatically more valuable because the assessors spend time on subtle problems instead of re-discovering missing MFA. Standards like IEC 62443 and guidance like NIST SP 800-82 expect periodic independent assessment for higher-criticality environments, and self-audits keep you honest between them. Run the self-audit first; bring in professionals when the obvious list is closed.

Sources & Further Reading

Safety & engineering notice. This article is general educational information, not site-specific engineering, safety, or legal advice, and it does not reflect any particular facility. Standards and regulations (for example OSHA, API, IEC, ISO, NFPA, NIST, and NERC CIP requirements) change and vary by edition, jurisdiction, and application. SCADA and remote monitoring cannot verify physical isolation, atmosphere, lockout/tagout, permit status, or a safe go/no-go decision. Qualified personnel must perform site-specific engineering, hazard analysis, and safety review, and confirm current requirements with the authority having jurisdiction, before acting.

Turn Checklist Items Into Defaults

MFA, roles, unique device identities, signed telemetry, audit trails, and alerting - built into the platform so your self-audit starts from twenty, not zero.

Request a Demo → See Our Security Architecture
Free SCADA operator training
Merobix University - 70 video lessons & 261 quiz questions, from first login to compliance reporting. No demo call required.
Start free →