OT–IT Integration Runbook & Security Checklist

Purpose & Scope

This runbook helps cross-functional teams (OT engineers, IT/digital teams, security, and analytics owners) safely, predictably, and audibly connect operational equipment (PLCs, RTUs, sensors, historians) to IT analytics, BI, and dashboards. It focuses on pragmatic patterns, required security controls, explicit data contracts, testing steps, and a troubleshooting decision tree you can follow during design, build, test, and handover.

Key Principles

• Define data contracts up front: agree which tags, types, formats, and timestamps will cross the boundary before integration work begins.
• Keep OT autonomy: protect control network determinism and safety by using edge aggregation, unidirectional flows, or carefully segmented gateways.
• Minimize attack surface: avoid direct PLC exposure to enterprise networks; prefer brokers, historians, or secure gateways.
• Test both function and security: a successful data flow is not enough — verify authentication, authorization, encryption, and failover behavior.

Common Integration Patterns

1. Edge Aggregation (recommended first choice)

Local edge nodes collect PLC tags, perform basic validation/normalization, and publish sanitized data to IT. Benefits: reduced PLC load, clearer data contracts, local buffering for intermittent network.

2. MQTT / Message Broker

Use a broker to decouple producers and consumers. Implement TLS, client certs, and topic-level access control. Ideal for telemetry where near-real-time publish/subscribe is required.

3. Historian Extracts / ETL

Periodically export aggregates or excerpts from the OT historian into IT storage (files, database, or data lake). Use for bulk analytics where strict low-latency is not required.

4. Unidirectional Diode or Data Diode

When the highest safety or security assurances are required, use a data diode to permit only one-way flow from OT to IT.

Data Contracts & Mapping

Before mapping begins, create a simple data contract document that includes tag identifiers, friendly names, data types, units, sampling rate, precision, and ownership.

Example mapping (for analytics schema)

• Raw PLC tag: PLC1/AreaA/Motor1.Speed
• Analytics field: motor_1.speed_rpm
• Type: integer, Units: RPM, Sample rate: 1s, Null policy: LastKnownValue + null flag

Suggested analytics schema fields

• timestamp_utc — ISO8601 UTC timestamp
• device_id — canonical device identifier
• point_id — canonical tag identifier
• value — numeric/string as agreed in contract
• quality — numeric or enumerated quality code (e.g., Good, Bad, Stale)
• source_sequence — incremental counter from edge for deduplication

Network Segmentation & Perimeter Checklist

1. Place OT control systems on a dedicated OT VLAN(s). Do not put PLCs on the corporate VLAN.
2. Use firewalls or access control lists (ACLs) between OT and IT zones. Document allowed flows in both directions.
3. Deploy a DMZ or broker zone for edge gateways and historians that need IT access.
4. Prefer one-way flows (data diode) where appropriate for sensitive systems.
5. Limit management access to jump boxes that are tightly logged and MFA-protected.
6. Monitor segmentation with network flow logs and periodic verification tests.

Authentication, Authorization & Encryption

• Mutual TLS (mTLS) for broker/edge connections where possible.
• Use client certificates or strong machine identity for automated agents; rotate certificates regularly.
• Implement least-privilege topic/queue permissions at the broker layer.
• Encrypt in transit (TLS) and at rest for persisted data that leaves OT boundaries.
• Audit and log authentication failures, and integrate logs into centralized SIEM or monitoring.

Data-Latency Expectations & SLAs

Agree on expected latency tiers up front. Typical tiers:

• Real-time/near-real-time: 0–5s (for control-room dashboards).
• Operational analytics: 5s–1min (edge aggregation, KPIs).
• Batch & historical: 1min–24h (ETL/historian extracts).

Document acceptable data gaps, retry/backoff behavior, and how sequence numbers or timestamps will be reconciled.

Functional & Security Test Plan

Run combined functional and security tests in a staged environment that mirrors production. Use the following steps and acceptance criteria.

Preconditions

• Data contract document signed by OT and analytics owners.
• Network ACLs and firewall rules created (staged environment applied).
• Certificates and credentials provisioned in a secrets vault.

Test cases (minimum)

1. Connectivity: verify edge node can read PLC tags and publish to broker/historian.
2. Schema conformance: verify published messages match the agreed schema (fields, types).
3. Throughput & latency: inject nominal and peak loads; measure end-to-end latency.
4. Authentication: attempt connection with/without proper client certs and credentials; unauthorized connections must fail.
5. Encryption: validate TLS is used and certificates are valid and trusted.
6. Failover: simulate edge node failure and verify buffering/replay behavior on restore.
7. Data quality: introduce sensor anomalies and verify quality flags propagate and are visible in analytics.
8. Access control: verify a user/service with limited permissions cannot access unauthorized topics or tags.
9. Audit logging: confirm connection, access, and error logs are captured and forwarded to monitoring.

Acceptance criteria

• All required tags arrive at analytics store within agreed latency, with expected schema and quality flags.
• Unauthorized connections are rejected; authorized connections succeed with mTLS.
• Network segmentation rules enforce expected traffic patterns during verification tests.
• Monitoring alerts are triggered for simulated failure modes.

Operational Handover Checklist

• Data contract and tag mapping stored in configuration management (versioned).
• Runbook for incident response and rollback published and accessible to both OT and IT teams.
• Credentials and certificates are stored in a secure vault and a rotation schedule is defined.
• Monitoring dashboards and alert thresholds configured; run a simulated incident drill.
• Define contact matrix for escalation (OT owner, IT owner, security, vendor).

Troubleshooting Decision Tree (common failures)

1. Data not appearing in analytics?
   1. Check edge node health and local buffers. If offline, restart agent and examine edge logs.
   2. If agent is publishing, verify broker received message (broker metrics/queues).
   3. If broker shows messages but analytics does not, validate consumer credentials and parsing errors; check ingestion logs for schema mismatches.
2. Authentication failures?
   1. Confirm client certificate expiry and trust chain.
   2. Check time-skew between systems (TLS client certs and token-based auth can fail with clock skew).
3. High latency or backlog?
   1. Measure network bandwidth and broker throughput; check for resource saturation on edge or broker nodes.
   2. Temporarily reduce sample rate or enable aggregation to reduce load while investigating.
4. Inconsistent or duplicate data?
1. Check source_sequence and deduplication logic; ensure each published message has sequence or unique ID.

Example Checklist (Quick Go/No-Go)

• [ ] Data contract agreed and stored
• [ ] Edge agent configured and reading expected tags
• [ ] TLS/mTLS certificate validated
• [ ] Network ACLs applied and verified
• [ ] Test cases 1-9 executed and passed
• [ ] Monitoring dashboards in place and alerting tested
• [ ] Handover notes, contacts, and runbook published

Appendix: Practical Tips

• Label tags with owner and intended consumer to avoid accidental mass exports.
• Start small: pilot a small set of tags and expand after proving reliability and security.
• Use semantic naming in the analytics schema to make dashboards and queries easier to build and maintain.
• Keep a versioned mapping table so analytics can reconcile historical data when tag names or types change.
• Consider using a sidecar or adapter pattern at the edge to translate proprietary PLC protocols to modern, secured transports.

References & Standards

Consult relevant standards and vendor guidance for details (for example, industrial control system security frameworks and your PLC vendor's recommended practices). Include site-specific safety constraints and compliance requirements in your planning.

Next Steps

Use this runbook as the baseline. For repeatable deployments, capture the data contract, mappings, and test results in a reusable kit that other sites can adopt and adapt. Consider converting the Quick Checklist and Test Plan into interactive forms to record test results and automate evidence collection.