EVOLV Deployment Controls Checklist

This page translates the EVOLV architecture into deployment controls that can be checked during implementation, review, FAT/SAT, and audit preparation.

It is not a legal compliance certificate. It is the operational checklist that helps turn the architecture into demonstrable control.

How To Use This Page

For each deployment:

mark whether the control is implemented
record the evidence location
record the responsible owner
track open gaps before production release

Control Checklist

Control Area	Required Control	Why It Matters	Evidence To Keep
Network segmentation	Edge, site, and central layers are separated by defined network boundaries.	Supports OT/IT separation and reduces blast radius.	Network diagrams, firewall rules, VLAN or conduit definitions.
No direct field exposure	PLCs and field-edge runtimes are not exposed as public or enterprise-facing endpoints.	Protects lower operational layers from unnecessary attack surface.	Access matrix, ingress configuration, API gateway design.
Central ingress only	External APIs terminate centrally and are mediated before any downward action.	Enforces policy, logging, and safer integration boundaries.	API gateway config, reverse-proxy config, architecture review notes.
IAM and access control	Human and service access is authenticated and role-scoped.	Required for controlled operations and traceability.	IAM configuration, role matrix, account review records.
Secret handling	Secrets are not stored in tracked manifests; env files or secret-injection mechanisms are used.	Prevents credential leakage and supports safer rotation.	Secret inventory, compose/env config, rotation procedure.
Patch and update process	There is a documented process for platform, OS, Node-RED, and dependency updates.	Required for lifecycle security and operational hygiene.	Patch policy, maintenance log, release records.
Release traceability	Runtime deployments map to versioned source, commits, and release artifacts.	Supports auditability and controlled rollback.	Git commit references, build artifacts, deployment records.
Local resilience	Local Node-RED and local InfluxDB remain usable during central outage.	Supports essential-service continuity and digital-twin/local monitoring use cases.	Outage test results, failover procedure, site acceptance records.
Site resilience	Site layer can continue plant-local operation when central connectivity is lost.	Avoids central single-point dependence.	Network-loss test evidence, continuity plan, site operating procedure.
Backup and recovery	Backups exist for config, telemetry where required, and critical platform state.	Supports recovery and resilience obligations.	Backup policy, restore test logs, retention schedule.
Logging and audit	Security-relevant and operationally critical actions are logged with retention rules.	Supports incident response, review, and accountability.	Logging policy, sample logs, SIEM or retention config.
Incident response	Operators know how to detect, escalate, contain, and recover from incidents.	Needed to translate architecture into operational resilience.	Incident runbook, contact tree, exercise records.
Data retention	Retention is defined for raw, reconstructed, and summarized telemetry by signal class.	Prevents ambiguity around smart storage and regulatory evidence.	Retention policy, telemetry class matrix, Influx retention config.
Reconstruction policy	Smart-storage signals have explicit fidelity and reconstruction rules.	Prevents opaque analytics and compliance disputes.	Signal policy document, reconstruction thresholds, validation results.
Config authority	`tagcodering` or approved configuration services are identified as the source of truth.	Prevents uncontrolled config drift across flows and sites.	Config ownership record, schema documentation, API contract.
Change governance	Config and runtime changes require approval, versioning, and rollback path.	Reduces unsafe ad hoc plant changes.	Change tickets, deployment approvals, rollback notes.
Site commissioning evidence	FAT/SAT and commissioning checks include security and resilience controls, not only functionality.	Confirms architecture is implemented, not just described.	FAT/SAT reports, commissioning checklist, defect log.

Minimum Pre-Go-Live Gate

Before a site goes live, the minimum gate should confirm:

segmentation is implemented
field assets are not directly exposed
central ingress and IAM are configured
local/site outage behavior is tested
secret handling is clean
backup and restore have been tested
retention and smart-storage policy are documented
configuration authority is identified

Suggested Status Model

Use one of these statuses per control:

implemented
partially implemented
planned
not started
not applicable

EVOLV Deployment Controls Checklist

How To Use This Page

Control Checklist

Minimum Pre-Go-Live Gate

Suggested Status Model

Related Pages