Industrial switchgear and control infrastructure

Guide | 12 min read

How to prepare for an OT cybersecurity assessment

A practical guide to preparing drawings, asset records, remote access information and operational context before an OT cybersecurity assessment.

Why preparation matters

Preparation should make the assessment boundary and evidence state visible before detailed review starts. Current drawings, asset records, support routes and operational constraints allow the assessment to examine risk instead of spending most of its time reconstructing the site history.

Do not delay the work until every record is complete. Mark what is confirmed, inferred, obsolete or unknown; uncertainty is useful assessment evidence when it is stated honestly.

1. Start with the purpose of the assessment

Write down the decision the assessment must support. A baseline review of an operating site, a project risk assessment and a requirement-by-requirement IEC 62443 gap assessment need different inputs and outputs.

Also record the applicable standard, regulatory or client context. This prevents a general framework review from being mistaken for a detailed compliance decision.

Useful evidence

  • current OT architecture
  • exposed or poorly controlled connections
  • remote access arrangements
  • asset visibility and ownership
  • segmentation between systems
  • IEC 62443-aligned evidence
  • regulatory, client or internal assurance requirements

2. Prepare the drawings before the assessor arrives

Drawings are usually the fastest route into understanding an OT environment, but only when they are current enough to be trusted.

The assessor does not need polished drawings at the start. Marked-up drawings are often more useful than issued drawings that no longer reflect reality.

The key is to show what is believed to be installed, what is confirmed, and what is uncertain.

Existing design, process and safety documentation should be used as an initial step towards creating a definitive OT system architecture record.

Useful evidence

  • network architecture drawings
  • panel general arrangement drawings
  • system block diagrams
  • cable and fibre schedules
  • power distribution drawings
  • control system architecture drawings
  • firewall or router topology drawings
  • remote access architecture drawings
  • vendor system diagrams
  • mark-ups from previous modifications

3. Build a usable asset record

An OT asset record does not need to start as a complex database. A spreadsheet is often enough if it captures the right information.

Do not hide unknowns. Unknowns are useful because they show where further discovery is needed.

A weak asset register pretends everything is known. A strong asset register makes uncertainty visible.

Useful evidence

  • Asset name: Unit 1 PLC
  • Asset type: Safety PLC, BPCS PLC, SCADA server, HMI, switch or firewall
  • Manufacturer: Siemens, Schneider, Rockwell, Cisco or Moxa
  • Model: S7-1517F, M580, Stratix or SCALANCE
  • Firmware or software version: version number where known
  • Location: control room, MCC room, field panel or turbine package
  • Network zone: safety, control, supervisory, vendor or corporate
  • IP address: where applicable
  • Communication protocols: PROFINET, Modbus TCP, OPC UA, EtherNet/IP or PROFIBUS
  • Owner: operations, engineering, maintenance or vendor
  • Support status: supported, obsolete or unknown
  • Criticality: high, medium or low
  • Backup available: yes, no or unknown
  • Remote access required: yes, no or unknown

4. Identify the important systems first

Not every asset carries the same risk. Before the assessment, identify the systems that matter most to safe and reliable operation.

The assessment should focus first on systems where compromise could affect safety, production, availability, environmental protection or regulatory compliance.

This is where operational context matters. A flat network is a technical issue. A flat network containing safety systems, compressor controls and remote vendor access is a business risk.

Useful evidence

  • safety instrumented systems
  • emergency shutdown systems
  • fire and gas systems
  • turbine or compressor control systems
  • process control systems
  • SCADA servers and historian systems
  • engineering workstations
  • domain controllers used by OT
  • remote access gateways
  • network switches and firewalls
  • vendor package controllers
  • critical HMI stations

5. Document remote access clearly

Remote access is one of the most important areas to prepare. A good assessment needs to know the access path, authentication method, approval process, reachable assets and monitoring arrangements.

Remote access should never be described only as the vendor logs in. That is not enough.

Useful evidence

  • who uses each route and why it is needed
  • which system each route reaches
  • how access is approved
  • whether MFA is used
  • whether sessions are logged
  • whether access is time-limited
  • whether vendor accounts are named or shared
  • whether access is always-on or enabled only when required
  • whether the route bypasses normal network controls
  • whether the route can reach more systems than intended
  • VPNs, jump hosts, remote desktop services and cellular routers
  • vendor modems, cloud management portals, dial-in connections and third-party support tools

Worked example: evidence confidence for a remote-access route

EvidenceWhat it supportsWhat remains unknown
Issued network drawingThe intended VPN, firewall and jump-host pathWhether the installed path still matches the drawing
Firewall exportCurrent permitted source, destination and servicesWhether the upstream identity and approval process are effective
Access procedureThe expected request, approval and close-out stepsWhether recent sessions followed the procedure
Sample log setA recorded connection and associated security eventsWhether retention and time synchronisation are reliable across every target

The assessment record should distinguish design intent, installed configuration and operating practice. One source rarely proves all three.

This is a worked technical example, not a completed Meridian client engagement.

6. Capture the operational context

Cybersecurity controls in OT cannot be assessed properly without understanding how the site operates.

This prevents unrealistic recommendations. For example, patch all systems monthly may be normal in IT but unrealistic in an OT environment with validated systems, outage constraints, vendor dependencies and safety assurance requirements.

The better question is: what is the current patching constraint, what compensating controls exist, and what practical improvement is possible?

Useful evidence

  • what the process does
  • what the main operating modes are
  • what systems are safety-critical or production-critical
  • when planned outages are possible
  • what systems cannot be interrupted
  • what vendor support is relied on
  • what legacy systems cannot easily be changed
  • what previous cyber or availability issues have occurred
  • what changes are already planned

7. Prepare evidence of existing controls

The assessment should not only find gaps. It should also recognise what is already in place.

This evidence helps separate undocumented controls from missing controls.

A control that exists but is not documented may still reduce risk, but it is harder to rely on. A control that is documented but not implemented is worse.

Useful evidence

  • firewall rules and switch configurations
  • backup procedures
  • antivirus or application control evidence
  • patching records
  • vulnerability scan outputs
  • access control lists
  • user account reviews
  • engineering workstation controls
  • remote access approvals
  • change control records
  • incident response procedures
  • disaster recovery plans
  • network monitoring evidence
  • IDS alerts or dashboards
  • physical security arrangements
  • removable media procedures

8. Be honest about legacy systems

Most OT environments contain legacy assets. That is not automatically a failure. The issue is whether the risk is understood and managed.

The assessment should not simply produce a list of old equipment. It should explain what those systems mean for risk, resilience and future investment.

Useful evidence

  • why the system remains in service
  • whether it is still supported
  • whether spares and backups are available
  • whether it can be patched
  • whether it can be isolated
  • whether it requires old operating systems
  • whether it uses insecure protocols
  • whether it has known replacement plans
  • whether compensating controls exist

9. Walk the site before the formal assessment

A short internal walkdown before the assessment is valuable.

This avoids the common problem where the assessment begins with a drawing review and ends with the discovery that the real system has changed significantly.

Useful evidence

  • cabinets shown on drawings still exist
  • unmanaged switches have not been added
  • cables are labelled
  • fibre links match the architecture
  • engineering workstations are where expected
  • vendor equipment is accounted for
  • temporary connections have not become permanent
  • spare ports are understood
  • modems or routers are not hidden in panels
  • local HMIs match the asset list

10. Prepare a clear assessment pack

Before the assessment starts, assemble a simple pack. Include a short readme explaining what documents are current, what documents are historical, what is missing, what is uncertain, and who owns each information area.

This saves time and gives the assessor confidence that the site is organised, even where gaps exist.

Useful evidence

  • 01_Assessment_Scope
  • 02_Site_Overview
  • 03_Network_Drawings
  • 04_Panel_Drawings
  • 05_Asset_Register
  • 06_Remote_Access
  • 07_Firewall_and_Switch_Configs
  • 08_Backups_and_Recovery
  • 09_User_Access
  • 10_Patching_and_Vulnerability_Management
  • 11_Incident_Response
  • 12_Change_Control
  • 13_Known_Issues
  • 14_Planned_Projects
  • 15_Previous_Assessments

11. Define what good output looks like

Before the assessment begins, agree what the output should contain.

Avoid outputs that only list generic best practice. A useful OT cybersecurity assessment should explain what matters for that specific site, why it matters, and what should be done next.

Useful evidence

  • current-state architecture summary
  • asset and connectivity findings
  • remote access findings
  • segmentation findings
  • key risks
  • quick wins
  • longer-term improvements
  • risk-ranked recommendations
  • drawing mark-ups
  • evidence gaps
  • assumptions and limitations
  • roadmap for improvement

12. The real goal: reduce uncertainty

The value of preparation is not paperwork. It is clarity.

A well-prepared OT cybersecurity assessment helps answer four basic questions: what do we have, how is it connected, who can access it, and what could realistically go wrong?

When drawings, asset records, remote access information and operational context are prepared in advance, the assessment becomes sharper, faster and more valuable.

The best outcome is not a perfect report. The best outcome is a defensible understanding of the OT environment and a practical route to reducing risk.

Where this connects to project work

If the issue described here forms part of a wider assessment or engineering programme, Meridian's ot cybersecurity assessments covers the scope, evidence and technical decisions needed for a defined engagement.