Put Cybersecurity into the Scope of Work for EAM–OT integration

01

Map data flows and trust boundaries

List sources, destinations, protocols, direction, frequency, acceptable latency and sensitive data. Distinguish read-only OT data from paths able to write commands or configuration. Give every exception an owner and a business reason.

02

Design identity and permissions

Do not share service identities with personal accounts. Define provisioning, credential rotation and revocation; separate read, draft and write rights. Remote access needs a time limit, approval and session logging consistent with site policy.

03

Plan for availability

Specify what happens when a historian, gateway or EAM is unavailable: retry, queueing, stale-data markers, alarms and manual procedure. An analytics fault should not impair process control. Patching and change windows need to respect plant operations.

04

Define acceptance evidence

The Scope of Work should name architecture documents, asset inventory, permission configuration, logs, loss-of-connection tests, backup and restore, incident response and the acceptance owner. A line saying “comply with Cybersecurity” cannot be tested or assigned.

05

Keep advisory limits explicit

This is an architecture discovery checklist, not a substitute for an authorized OT security assessment. Final controls must follow risk, existing systems and the operator's requirements.

06

Define the integration at data-flow level

For every interface, the Scope of Work should state source, destination, protocol, port, connection direction, frequency, volume, latency, data classification, and owner. Draw trust boundaries among OT, DMZ, and IT according to the site's architecture; identify which component initiates a connection and whether any path can issue commands. Read-only historian feeds still need query-load checks, cache rules, and behavior for network interruption.

Avoid a generic “bidirectional integration” requirement when the use case only needs equipment data delivered to EAM. Write paths require separate business justification, architectural approval, and limit testing. An approved data-flow register lets firewall, OT, EAM, and vendor teams implement and accept the same design. Temporary pilot connections also need an expiry date and removal procedure.

07

Turn controls into deliverables and test cases

Make requirements testable: least-privilege service accounts, credential storage and rotation, login and configuration logs, time synchronization, backup, recovery, fault monitoring, and access revocation. Assign certificates, firewall rules, host hardening, and patch windows to named parties. A generic “follow Cybersecurity policy” clause leaves delivery and acceptance open to interpretation.

Acceptance tests should cover loss of connectivity, late data, a full queue, expired credentials, revoked access, backup restore, and unauthorized configuration change. For each case, define the safe state, required log, alert recipient, and response time set by the operator. Retain test evidence, witnesses, and open actions.

08

Assign operational responsibility

After handover, who owns service accounts, gateway health, log review, remote access, patches, and incident response? A RACI should distinguish IT, OT, EAM application owner, SOC, and vendor. Support terms should define hours, escalation, remote-access conditions, and site supervision. Without these roles, an integration may work on day one yet be hard to maintain safely.

Design degraded mode as well: when EAM cannot reach OT, displayed data needs a timestamp and stale status; an AI portal must not treat old values as current. Changes to systems, protocols, or permissions belong in change control and should trigger a data-flow review. The site's OT security owner must approve the final controls.

09

Illustrative example: historian data for EAM

A pilot needs equipment status from a historian to support EAM maintenance decisions. The data-flow register specifies tags, frequency, connection direction, gateway, protocol, owner, and acceptable latency. The gateway reads only required data; EAM has no command path to process control. UAT disconnects the gateway: records queue or show a fault, the dashboard displays the last timestamp and stale status, and operations receives an alert. The team also tests expired credentials and backup restore, retaining logs and witness sign-off. After handover, the OT owner manages the connection, the EAM owner manages application data, and the security team reviews rights and logs. The Scope of Work assigns these roles before acceptance.