Why workflow automation in energy and utilities starts with asking where flows may run
Self-hosted n8n, Node-RED or Temporal can fit IT-side integration in an energy or utility business, such as meter-data handoffs to billing, outage notice distribution or dispatch scheduling into a field service system. Flows that touch operational technology, especially anything that can reach a BES Cyber System, need a classification decision first, and that decision is made by the compliance and OT teams, not by the automation tool. The boundary is set by the scope of the NERC CIP Reliability Standards in the United States and by the NIS2 sector list in the EU, where energy is a sector of high criticality. Before building, ask which assets are in scope, whether a flow would cross an Electronic Security Perimeter, and whether it creates a remote access path that CIP-005-7 would require to pass through an Intermediate System with multi-factor authentication.
Those questions are answered by the asset inventory and network architecture, so write them down before choosing a tool. Confirm with your registered entity's compliance lead which systems are BES Cyber Systems and their impact rating under CIP-002-5.1a, and whether any workflow would send data or commands into those networks. Treat meter-to-cash, customer notifications and back-office reconciliations as IT-side candidates, and keep field dispatch and any control-adjacent step behind a documented segmentation design. CIP-013-2 also applies where a vendor, including an automation partner, can initiate remote access, so the supply chain plan should cover who maintains the flows.
The tool matters once the boundary is settled, and the license is part of that tool decision. n8n is licensed under the Sustainable Use License, which permits use only for your own internal business purposes or non-commercial use, and files marked .ee require an n8n Enterprise License. SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, and multi-main high availability is limited to Enterprise self-hosted deployments. Confirm with your legal team that internal operation fits the license, and confirm with n8n which edition supplies the SSO, audit log and high availability features your controls require. Node-RED, under Apache-2.0, and Temporal, under MIT, carry different terms and are worth comparing on the same criteria.
Which regulatory requirements shape the automation build
This table maps each regulatory requirement in scope to the source fact that states it and to what it means for where flows run, how credentials are held and which vendor-maintained nodes can be used. Read it as a starting checklist: each row changes a design decision, and the placement questions should be settled with compliance and OT owners before any flow is built.
| Requirement | What it asks for | What it means for the automation build |
|---|---|---|
| CIP-002-5.1a impact classification | Sorts BES Cyber Systems into high, medium or low impact using bright-line criteria | Classify the systems a flow touches before design. A flow that reads or writes to a high or medium impact system inherits stricter placement and access rules, so keep the impact rating in the flow's design record. |
| CIP-005-7 Electronic Security Perimeter and Intermediate System | Routable-connected high and medium impact assets sit inside an ESP; all Interactive Remote Access passes through an Intermediate System with encryption and MFA | Run workflow engines and workers inside the perimeter, not on a corporate network reaching in. Vendor or engineer access to the automation platform must route through the Intermediate System, so remote editing from outside is not an option. |
| CIP-013-2 vendor supply chain duties | Supply chain risk management plans covering vendor incident notification, vulnerability disclosure, software integrity and vendor remote access, reviewed at least every 15 calendar months | Any vendor-maintained node, partner support session or community package is a supply chain item. Record provenance, verify integrity of images and packages, agree notification terms with the implementation partner, and schedule the plan review within 15 calendar months. |
| CIP-011-3 information protection | Requires entities to identify and protect BES Cyber System Information through documented information protection practices | Execution logs, exported payloads and workflow definitions can contain BCSI such as network addresses or configurations. Restrict who can read execution data, set retention deliberately and avoid copying operational detail into shared chat or ticket tools. |
| NIS2 Annex I energy sector scope | Lists energy, including electricity, district heating and cooling, oil, gas and hydrogen, as a sector of high criticality | Entities in these subsectors fall under NIS2 obligations for risk management and incident reporting. Confirm with national transposition whether your entity is in scope, then treat automation platforms as part of the security-relevant estate covered by those measures. |
| Delegated Regulation (EU) 2024/1366, cross-border electricity flows | Network code on sector-specific cybersecurity rules for cross-border electricity flows, supplementing Regulation (EU) 2019/943 | Flows that exchange data across borders or with cross-border market participants may fall under these rules. Confirm applicability with the regulator or transmission operator, and document which flows cross a border and which systems they touch. |
| Credentials for utility systems | Not a single cited control: follows from CIP-005-7 access rules and CIP-011-3 information protection | Store credentials to meter, SCADA-adjacent and billing systems in an encrypted vault, scoped per flow. Plan the n8n encryption key, or the equivalent secret for other engines, as a controlled asset, because workers need it to read stored credentials. |
How to separate IT automation from operational technology flows
Start with a classification step, before any flow is built. Inventory every system the automation might touch and record three things for each: whether it is a BES Cyber System, what impact level CIP-002-5.1a assigns it (high, medium or low, using bright-line criteria), and whether it is routable-connected or only exchanges data with IT systems. Systems that are routable-connected at high or medium impact must sit inside an Electronic Security Perimeter under CIP-005-7, so an automation platform that reaches them from the IT side is part of that perimeter question, not a convenience integration. Confirm the classification with your compliance team and your Regional Entity's interpretation, because the inventory defines every later boundary.
Place n8n or Node-RED in the IT zone and keep the automation engine out of the OT network. Where a flow must carry operational data toward OT or pull values back, use a one-way data diode or a brokered exchange with a defined message schema, rather than opening direct sessions from the workflow host into control networks. Use the segmentation and zone concepts in NIST SP 800-82 Rev. 3 and the zone and conduit model in the ISA/IEC 62443 series as guidance to read with your OT engineers. Treat the editor itself as an asset: n8n's Community edition has no SSO, and Node-RED flow files are plain JSON that can carry credentials, so restrict who can open the editor, require change approval for every flow edit, and store flow files in version control with a recorded approver. Confirm which of these controls your chosen edition and deployment model actually supports before you commit to a design.
Which open-source automation platforms fit utility work and why
Utility automation spans business back office, field and edge protocols, long-running outage work and batch metering data, and no single platform covers all of them well. The cards below match each platform to the workload it handles best, along with the licence, edition and security checks that decide whether it can run where the utility needs it.
n8n for internal IT integration
n8n suits customer-service, billing and back-office integrations that stay on IT networks. Its Sustainable Use License permits use for your own internal business purposes, so a utility should confirm with counsel that no contractor or affiliate use falls outside that grant. SSO and Git-based environments are paid features on the Business and Enterprise plans, so budget for them before promising controlled promotion. In queue mode, every worker needs the main instance's encryption key to read stored credentials, which makes key distribution a control to document, not a default.
Node-RED at the IT/OT boundary
Node-RED is licensed under Apache-2.0, which makes it straightforward to review for internal and distributed use. Its flow-based model fits edge gateways that read field and telemetry protocols and pass selected values to historians or IT systems. Keep flows on segmented OT-adjacent hosts, not in the IT automation cluster, and confirm which protocol nodes are community-maintained. The editor is open by default, so restrict access to named engineers and place it behind authentication and a change process.
Apache NiFi for high-volume data routing
NiFi is an Apache-2.0 project with no paid edition, and it is a common choice for moving meter and SCADA-derived data between segments with provenance tracking. Plan for NiFi 2.x: the 1.x line has reached end of support and cannot be maintained further. NiFi supports OpenID Connect, SAML 2.0 and LDAP, and it binds to 127.0.0.1 when no security configuration is provided, so confirm that the secured configuration is applied before any network exposure. Java 21 is the minimum runtime.
Temporal for durable outage and field workflows
Outage restoration, switching orders and field dispatch can run for hours or days and must survive worker restarts without losing state. Temporal is built for durable execution, which fits these long-running processes better than a short-lived integration flow. Confirm the license and hosting model with the vendor before committing, and define which steps need human confirmation and how an interrupted workflow is resumed safely. Keep activities that touch OT systems idempotent so a retry cannot reissue a command.
Flowable or Camunda for approvals
Permit-to-work, customer complaint escalation and vegetation-management approvals need named approvers, deadlines and an audit record of each decision. Flowable is Apache-2.0 and suitable for production, so it is the simpler choice where licensing must be clean. Camunda 8 source code is under the Camunda License 1.0, which permits use only in non-production environments without a commercial license. Confirm the commercial terms before any production rollout, and treat approval records as evidence for change and access reviews.
Airflow or Dagster for metering batches
Meter reads, interval data validation and settlement extracts run on schedules and depend on upstream completion. Apache Airflow and Dagster both schedule and monitor batch pipelines with clear dependencies and retries, which suits metering data better than event-driven flows. Decide which tool owns each batch, keep customer and meter identifiers out of logs, and record run history for the retention period your regulator expects. Confirm the rules for handling estimated reads with the billing team.
How the automation tiers connect across IT, OT and cloud
The corporate IT zone holds the automation that touches billing, customer information systems, work management, ERP and enterprise directories. These flows rarely send commands to field equipment, so they sit furthest from the BES Cyber Systems that CIP standards govern. In a queue-mode deployment, the main n8n instance receives webhooks and triggers here, while workers and the PostgreSQL database run in the same network segment under the utility's own change control.
- Workflows that belong here: meter read exports to billing, outage notifications to customer systems, work order creation in the asset management platform and HR or contractor onboarding.
- Credentials held: service accounts for ERP, CRM and billing APIs, stored encrypted in the n8n database, with the main instance encryption key shared with every worker and webhook processor.
- Placement: main instance, workers and PostgreSQL inside corporate networks, with multiple workers scaled for run volume. Multi-main high availability is limited to self-hosted Enterprise deployments, so confirm the edition before designing failover.
- Boundary crossings: outbound calls to the DMZ gateway only, with no inbound connections from the IT zone into OT networks.
- Logging: execution data and audit records retained in the utility's own storage, with access restricted to named administrators.
Confirm with your compliance team which CIP-related assets, if any, are reachable from these flows before assuming the zone is out of scope.
The DMZ zone sits between corporate IT and operational technology. It is where data from control and metering systems is staged, normalized and passed onward, and where n8n or Node-RED workers can read from historians without placing automation on the plant network. CIP-005-7 requires that routable-connected assets of high and medium impact BES Cyber Systems sit inside an Electronic Security Perimeter, so the DMZ design must be checked against each perimeter boundary.
- Workflows that belong here: historian and SCADA data extracts for reporting, meter data validation before it reaches billing and alert forwarding from OT monitoring tools.
- Credentials held: read-only service accounts for historians and staging stores, with no write credentials to control systems held in this zone.
- Placement: queue-mode workers may run here to reach historian interfaces, while the main instance and PostgreSQL stay in the corporate or utility-controlled zone to limit how much of the automation estate sits in the DMZ.
- Boundary crossings: traffic passes through an API gateway such as Apache APISIX or Kong, with authentication, rate limiting and logging enforced at each hop.
- Interactive access: remote access into this zone must pass through an Intermediate System with encryption and multi-factor authentication.
Check with OT engineers and your NERC CIP or NIS2 advisers which asset impact classification applies to each source system before a flow is placed in this zone.
The utility-controlled cloud or data center zone holds analytics, long-term storage and workflows that do not need direct contact with field or control networks. Here the utility runs its own accounts or facilities rather than a third-party SaaS, so encryption key custody, data residency and vendor access are governed by the utility's own controls. CIP-013-2 requires supply chain risk management plans that cover vendor incident notification and coordination of vendor-initiated remote access, which applies to any external support for this zone.
- Workflows that belong here: aggregated load forecasting inputs, regulatory report generation, data quality checks across meter populations and archival exports to the data lakehouse.
- Credentials held: scoped service identities for storage and analytics platforms, with secrets held in a vault the utility controls rather than in workflow definitions.
- Placement: the PostgreSQL database and queue-mode workers can run here for scale, provided the main instance encryption key is managed and rotated under documented procedures.
- Boundary crossings: inbound data arrives only through the DMZ gateway, and outbound calls to external regulators or vendors pass through a logged egress path.
- Vendor access: support engineers connect under approved, recorded sessions, with credentials revoked when a support engagement ends.
Ask your implementation partner how keys are generated, stored and rotated in this zone, and which team holds the database administrator role.
How a utility rollout moves from inventory to supported operation
The sequence starts with knowing which systems and data are in scope, then builds, hardens and tests flows in the order that keeps operational technology separate, and ends with a supported operation that has an upgrade and retirement plan.
Inventory systems, impact levels and data
Map every system a candidate flow would touch, including metering, SCADA-adjacent historians, customer information systems, billing and field work management. Classify each asset by NERC CIP impact (high, medium, low or outside scope) where the entity is registered, and by NIS2 relevance for EU operations. Record the personal and operational data each flow would carry. Done when the inventory names an owner for each system and each asset has a documented classification that compliance and OT engineering have both reviewed.
Build a flow register with zone and licence checks
Create one register entry per proposed flow with a business owner, a technical owner, the network zone it runs in, the systems it reads or writes, its credential set and its execution data location. Add a licence check for each platform: n8n's Sustainable Use License restricts internal versus commercial use, and any .ee components need an Enterprise License. Done when every flow has an approved zone and a licence position signed off by legal or procurement, and any flow that would cross into an OT zone is flagged for a separate design review.
Harden the platform before any connection
Deploy the automation platform in the zone approved in the register, with encryption keys generated and stored in the organization's key management process rather than in a shared file. Where n8n queue mode is used, confirm the main instance key is distributed to every worker and webhook processor. Connect single sign-on to the corporate identity provider, restrict editor access by role, and close any default bindings that expose an editor to the wider network. Done when a security review confirms the configuration, administrator accounts are individually named, and credentials for utility systems are held in the platform's encrypted store with access logging enabled.
Pilot on non-OT flows first
Start with flows that have no path to operational technology, such as customer outage notifications, appointment confirmations for meter reads, or internal approval routing for field tickets. Run the pilot against test data and sandbox endpoints, then in production with a limited user group and monitored execution. Measure failed executions, retry behavior and alert delivery against the register entry. Done when the pilot owner signs off that error handling alerts a named person, that the flow behaves as specified under failure, and that any issue has a recorded fix.
Put change control and evidence capture in place
Require a documented approval for every workflow change, with the reviewer, the diff, the test result and the promotion record stored in version control or the platform's Git-based environment features where the plan provides them. Keep execution logs, configuration history and access records in a location the security team controls. Done when a sample change can be traced from request to approval to production deployment, and the evidence set maps to the CIP and NIS2 controls that the entity has chosen to cite.
Operate, upgrade and retire on a plan
Move each approved flow into supported operation with a named owner, a patch and upgrade calendar, a test suite for regression, and a review cycle for supplier and vendor access. Track platform releases against the upgrade policy, and where a component reaches end of support, schedule its replacement. Define a retirement path for flows that are no longer needed, including credential revocation and removal of stored execution data. Done when every production flow appears in the register with a current owner, the last review date is recorded, and the retirement steps are written down for each flow.
What compliance evidence the automation platform should produce
This table lists the evidence an energy or utility automation platform should be able to produce, the component that generates each item, and what an assessor will ask for. Read it as a checklist for design decisions made before the first flow goes live. DeployOpen prepares this evidence, but independent auditors and the relevant regulator assess it.
| Evidence item | Producing component | What the assessor will ask for |
|---|---|---|
| Flow inventory with impact classification | Git repository holding exported workflow definitions, plus the entity's asset register for BES Cyber Systems | A current list of every flow, the systems it touches, its impact classification under CIP-002 and the owner who approved that classification |
| Access and change records for editors | n8n user management and SAML or LDAP logs, forwarded to the SIEM, plus Git commit and approval history | Who could edit or run each flow, when access was granted and removed, and evidence that each change was reviewed before promotion |
| Execution logs and retention settings | n8n execution data in PostgreSQL, log streaming on a plan that includes it, and Node-RED or NiFi logs sent to central storage | Proof that execution records exist for the required period, how long they are kept, and that deletion follows the documented retention rule |
| Credential ownership and rotation records | n8n credential store with the encryption key managed outside the workflow host, and the vault or key management system used for utility credentials | A named owner for each credential, the rotation schedule, dated rotation events and confirmation that worker nodes do not hold keys they should not have |
| Vendor component and version records for CIP-013-2 | Software bill of materials and version inventory for n8n, Node-RED, NiFi, PostgreSQL and their plugins, with vendor notification contacts | Current component versions, vendor incident contacts, vulnerability notices received and the date each patch was applied, reviewed at least every 15 calendar months |
| Boundary and remote access records for IT-to-OT flows | Network flow logs at the Electronic Security Perimeter, firewall rules and the Intermediate System logs for interactive remote access | Evidence that flows touching high or medium impact systems sit inside the perimeter and that remote sessions pass through the approved intermediate system with multi-factor authentication |
| AI or decision logs where applicable | Event records from any AI component in the flow, stored by the gateway or observability tool, with retention set by policy | Automatically recorded events for high-risk AI systems under AI Act Article 12, retained for at least six months under Article 19 unless other law requires longer |
What utilities ask before self-hosting workflow automation
Can a utility use n8n internally under its license?
Yes, for internal business purposes. n8n is fair-code under the Sustainable Use License, which allows use or modification only for your own internal business purposes or for non-commercial or personal use. The same license limits distribution to free, non-commercial use, so a utility running flows for its own staff and systems is in a different position from a company offering automation to customers. Files marked .ee are not covered by that license and require a valid n8n Enterprise License, so confirm with legal which files your deployment will include. Read the n8n license text and have counsel confirm the position for your specific use before rollout.
What drives the cost of self-hosted workflow automation at a utility?
The software license is rarely the largest item. Costs split into infrastructure you run in your own data centers or cloud accounts, paid n8n plans if you need features such as SSO or environments with Git, the build and testing of workflows against meter, billing and field systems, and ongoing maintenance as those systems change. n8n's pricing page lists a free self-hosted Community edition, with Business at 667 euros per month billed annually and Enterprise at custom pricing, so ask which edition each feature requires. Ask any implementation partner for a fixed-scope quote that separates one-time build work from recurring support, and state which integrations and environments it covers.
How long does a utility rollout take and what does it depend on?
The duration depends on the number of processes, the approval path for each system, and how many environments you need, and no supplied figure gives a standard timeline. The main variables are the systems each flow touches, such as a meter data management system or a customer information system, the security review required before a connection is allowed, and whether queue mode and high availability are needed. Ask for a written scope with deliverables and milestones before work starts, and confirm which change approvals and maintenance windows your operations group requires.
Can internal staff maintain the flows after handover?
Yes, if the team has ownership, documentation and a change process before the handover. Flows built in n8n or Node-RED are visual, so operators can read them, but credentials, custom code, error handling and promotion between environments need named owners. Ask the partner to document each workflow, its data sources, its credential scope and its retry and alert logic, and to train the staff who will own changes. Confirm whether your team will also maintain the platform itself, including upgrades and backups, or whether that stays with a support retainer.
Can operational technology flows run on n8n?
IT business automation and OT control should be kept separate, so n8n should not be placed inside an operational control path without a formal architecture review. NERC CIP-005-7 requires routable-connected assets of high and medium impact BES Cyber Systems to sit inside an Electronic Security Perimeter, and all Interactive Remote Access must pass through an Intermediate System with encryption and multi-factor authentication. Where a flow must read data from OT, the usual pattern is to move it through a controlled boundary, such as a historian or a one-way data diode, into IT systems. Confirm your impact classification under CIP-002-5.1a and review NIST SP 800-82 Rev. 3 with your OT security team before any flow touches a plant or substation network.
Which n8n features require a Business or Enterprise plan?
SSO and LDAP, environments with Git, and log streaming are included only in the Business and Enterprise plans, according to n8n's pricing page. SAML single sign-on is available on those plans, and n8n publishes setup guides for Okta Workforce Identity and Azure AD. Multi-main setup for high availability is restricted to Enterprise self-hosted deployments, so a utility that needs failover for critical flows should plan for Enterprise. Verify each feature against the current pricing page before you finalize budget or architecture, because feature placement can change between releases.
How does the NiFi 1.x end of support affect existing flows?
NiFi 1.x can no longer be maintained, so existing flows should be migrated to the 2.x line. The project states that 1.28 is the last minor release of the version 1 series, that 1.28.1 reached end of support on December 8, 2024, and that 1.x depends on Jetty 9.4, Spring Framework 5.3 and AngularJS 1.8, which cannot be upgraded in that line. Migration requires upgrading to 1.27.0 before moving to 2.0.0 and changing the flow file from flow.xml.gz to flow.json.gz. Also review the variable registry and distributed map cache changes in the migration guidance, and ask your partner for a flow inventory and a test plan for each flow.
Questions to put to an implementation partner before a utility pilot
Start with classification. Ask the partner how they will support your impact classification of BES Cyber Systems under CIP-002-5.1a, and who signs off on it. A partner can help you document which flows touch systems that could be high, medium or low impact, but the classification decision and its evidence stay with your compliance team. Ask for a written list of the flows they propose to exclude from the IT automation platform, with the reason for each exclusion, and ask how they will keep OT-facing flows out of n8n or any other IT tool. Request the network diagram showing where the automation server sits relative to any Electronic Security Perimeter and how Interactive Remote Access is routed through an Intermediate System, as described in CIP-005-7.
Next, ask about keys and promotion. In n8n queue mode, the main instance's encryption key must be shared with every worker and webhook processor so they can read stored credentials. Ask how the partner distributes that key to each node, where it is stored, who can read it, and how a rotation is performed without breaking running executions. Ask for the change approval path for Git-based promotion from a development environment to production, who approves a workflow edit, and whether production credentials are ever visible to the developer who built the flow. Ask how failed executions alert a named operator on a shift rota, and what happens when the alert channel itself is down.
Finally, ask how vendor-maintained and community nodes are reviewed. Under CIP-013-2, your supply chain risk management plan must address vendor incident notification, vulnerability disclosure and software integrity verification, so ask how the partner verifies the integrity of each node package before installation and how they track vulnerability notices. Confirm which n8n features your pilot needs, such as SSO or environments in Git, and whether they require the paid Business or Enterprise plan. Ask the partner directly what they will not do: they prepare systems, controls and evidence for an assessment, but they do not issue audit reports or attestations, and an independent auditor or the regional entity makes that determination.
How DeployOpen scopes and supports utility workflow automation
The sequence runs from a written scope and a register of every flow, through a build on the client's own infrastructure, to tested flows, evidence for assessors and an optional support retainer. Each step ends with a specific artifact the utility can check.
Agree a written, fixed scope
DeployOpen and the utility agree the scope, deliverables and timeline in writing before work starts. The scope names the processes to automate, the systems each flow touches, the environments in scope and who at the utility owns each decision. Compliance responsibilities stay with the utility and its auditors, and the scope states that DeployOpen prepares systems and evidence without issuing attestations. The signed scope document is the reference for every later step.
Classify systems and build the flow register
Each candidate flow is mapped to the systems it reads or writes and classified by whether it touches IT, metering and customer data, or operational technology. The classification uses the utility's own impact assessment, including any BES Cyber System categorization the utility has already made under CIP-002. The output is a flow register listing each workflow, its data, credentials, owner, network zone and whether it may run in a given location. The register is reviewed by the utility's compliance and OT owners before any build begins.
Design the network zones and access paths
DeployOpen documents where each workflow runs, which zones it can reach and which paths it uses to cross between IT and OT. Remote and vendor access is designed around the controls the utility has chosen to meet its CIP or NIS2 duties, including how any interactive access routes through controlled intermediate systems. Credential vaults, encryption key custody and the separation of editor access from execution are set out here. The completed design is approved by the utility's security architecture owner, and any flow that cannot be placed in an approved zone is removed from scope.
Build and harden the platform on client infrastructure
DeployOpen installs the chosen platform, such as n8n, Node-RED or Temporal, inside the utility's own data center, cloud account or isolated network. Hardening covers the editor bindings, authentication through the identity provider, encryption of stored credentials, logging to the utility's own store and the restriction of default network exposure. Where the design needs it, the team also sets up queue mode or workers, and confirms the license and edition covering each feature, such as SSO or environments, is in place. Completion is a hardened baseline build with a configuration record that the utility can review.
Test flows, failures and integrations
Each flow is tested against the agreed design in a non-production environment that mirrors the production zones. Tests cover correct data mapping, credential handling, error paths, retries, alerting and what happens when a downstream system is unavailable. For any flow that reaches OT, DeployOpen also tests that the flow cannot send commands or change state beyond what the register permits. Test results are recorded per flow and open defects are tracked to closure with the utility's change owner. The step closes when every in-scope flow has a signed test record.
Prepare change control and assessment evidence
DeployOpen assembles the records an assessor will ask for: the flow register, zone and access designs, configuration baselines, change approvals for flow edits, test records, access reviews and audit logs of execution and credential use. The evidence is organized against the utility's chosen control set, and gaps are listed for the utility to resolve. DeployOpen does not issue audit reports, attestations or certifications; the utility's auditors and the relevant regulator or registered entity process make those determinations. The output is an evidence package the utility owns and can hand to its auditors.
Hand over, train and document operations
The utility's operators and flow owners are trained on editing, promoting and rolling back workflows through the agreed change process. DeployOpen delivers runbooks for monitoring, incident handling, credential rotation and platform upgrades, plus a list of the supported versions and the upgrade path. Handover is complete when the utility's staff demonstrate a supervised change through the full process without DeployOpen performing it for them. Ownership of each flow transfers to a named person in the utility.
Continue with an optional support retainer
After handover, the utility can add a retainer covering platform upgrades, security patches, continuous testing of changed flows and support for incidents. The retainer scope, response expectations and any service levels are written into the contract, and the utility should confirm them before signing. Upgrades are planned against vendor release notes and tested in a non-production environment first, so that changes to OT-adjacent flows follow the same review as the original build. The retainer ends when the utility decides to bring the platform in-house.
