Checklist

OT–IT Integration Checklist & Risk Controls

A practical, actionable checklist for integrating PLC/SCADA and other operational signals with IT dashboards and analytics. Collects key decisions, owners, risk controls, testing and rollback plans, and compliance items so integrations are secure, safe, and auditable.

Interactive Tool

OT–IT Integration Checklist & Risk Controls

Purpose

Use this checklist to capture the technical, operational, and risk-control decisions needed before, during, and after integrating PLC/SCADA/edge systems with IT dashboards, analytics, or business systems. The form records owners, requirements, mitigations, and readiness so integrations don’t become brittle or unsafe.

Please answer each item honestly. Where a short answer is expected, add details in the notes fields. This checklist is intended to be saved as part of project documentation and to support traceability, testing, and incident response.

Short, identifiable name for this integration (e.g., PlantA_PLC_to_Analytics).
Person/team accountable for the OT system (name or role).
Person/team responsible for delivering and operating the integration (name or role).
Brief description of what data/signals will be transferred and the intended business/analytic purpose.
Have source-to-target mappings and types been documented?
Link or describe the mapping, field types, sampling intervals, units, and any transformation rules. If mapping does not exist, note next steps.
State expected max latency, acceptable freshness, and retention policy for the integrated data (e.g., raw telemetry at 1s -> aggregated to 1m, retain raw 30d).
Where will processing and storage occur? Capture the chosen architecture and rationale.
Select methods to be used between OT endpoints, edge gateways, and IT services.
Describe how credentials/certs are issued, rotated, stored, and revoked. Note vaulting or HSM use if applicable.
Describe VLANs, firewalls, industrial DMZs, jump hosts, or flow restrictions between OT and IT networks.
Will the integration impact any safety loops or interlocks? Ensure no change weakens safety behavior.
If yes or unsure, document which interlocks, how they remain independent of the integration, and who validated safety behavior.
Choose the process that will govern changes to OT, edge, or integration logic.
Name or role responsible for change approvals and scheduling.
Is a tested rollback plan in place that restores the prior safe state?
Describe rollback steps, preconditions, verification steps, and responsible persons. Include how to revert configuration and data flows.
Who owns alerts, where are dashboards/metrics, escalation steps, and what runbooks exist for common failures? Include thresholds for critical alerts.
Describe unit/integration/staging/soak tests, safety tests, performance tests, and the criteria required for go-live.
Reference schema version or contract location (e.g., repo path, schema registry).
Who owns the data, who may consume it, and expected availability/quality SLAs.
Select regulations or standards this integration must satisfy.
List compliance controls, required evidence, and where artifacts will be stored.
Rate overall risk of this integration from 1 (low) to 5 (high) considering safety, security, and data integrity.
1.0 10.0
Assess whether the integration is ready to go live based on testing, controls, and approvals.
Planned calendar date (YYYY-MM-DD) or descriptive timing. Update as plans change.
Use this space to capture open action items, links to diagrams, repos, runbooks, or tickets.
You can explore this tool now. Sign in or create an account to save your responses and return to them later.
Sign In to Save Create an Account
Make this tool part of your work

Save a personal copy, bring it to your team, or tailor the questions and workflow to fit what you are hungry to improve.

Member customization and team collaboration are coming soon.
Discuss Ask the Librarian

Discussion

Comments and conversation will live here.