Service
Change-control and rollback audit
A clean audit of today’s configuration is worth little if tomorrow’s update can rewrite it without a record. We examine the path from a proposed change to a running control application.
This audit covers application releases, rule-engine edits, dashboard writes that alter setpoints in bulk, and firmware campaigns to gateways and controllers.
We read the ticket trail (or note its absence), who can promote a build, whether staging uses the same broker as production, and what “rollback” actually means when retained MQTT messages and device flash disagree.
We also look at vendor remote sessions: who authorises them, whether they are watched, and whether the session can push a new flow without a local countersignature.
The deliverable is a change-path description, gaps against the site’s own permit-to-work or MOC procedure, and a minimum record set we recommend keeping for the next twelve months of control-application edits.