As neededchange-management

Post-Change Checklist

16 items ·9 critical ·5 warn ·2 info

The post-change window is where an OPNsense change becomes either a successful operational change or a quiet regression that will be rediscovered at the next incident. This checklist forces the operator to validate, document, and close the change — and to keep the rollback plan in reach for at least a week in case the change is implicated later.

When to use

Use this checklist immediately after any planned change to an OPNsense firewall, including the post-change validation phase of every pre-change entry. Use it for both service-affecting and non-service-affecting changes; the validation criteria differ but the discipline does not.

How to use

Walk the list, run the explicit validation tests from the pre-change checklist, capture the rule-counter and log evidence, close the change in the ticketing system, and file the post-change artefacts against the change record. Anything with severity critical must pass before the change is closed.

Critical9 items

Configuration has been validated via the GUI (no red banners, no unsaved changes indicator) and via the API.
```
System > Configuration > History; `opnsense-configctl -c system check` from shell.
```
Validation tests from the change record have passed (the explicit pass conditions from the pre-change checklist).
Rule counters increment on changed rules as expected within the observation window.
```
Firewall > Log Files > Live View; filter by rule.
```
No unexpected errors in the system log for the change window; a focused review of `/var/log/system.log` has been performed.
Configuration backup has run successfully and is present at the remote destination.
```
System > Configuration > Backups; verify destination.
```
Monitoring / SIEM confirms that log shipping is healthy and not interrupted by the change.
Change is closed in the ticketing / change system with the operator, the change record ID, and the post-change artefact links.
HA state confirmed (if applicable): both nodes healthy, CARP VIPs on the expected master, sync clean.
```
Status > CARP; System > High Availability > Status.
```
External verification: a downstream user / service pinged through the firewall confirms reachability end to end.

Warning5 items

Documentation affected by the change has been updated: rule inventory, segmentation map, runbooks, topology diagrams.
Stakeholders have been notified of completion and any follow-up work that emerged during the change.
Rollback plan is retained in the change record for at least 7 days post-change in case the change is implicated in a later incident.
Drift scan: any drift between nodes is examined and reconciled via XMLRPC sync.
The rollback time budget was not consumed; if it was, a post-mortem item is opened.

Info2 items

Performance baseline (state table, CPU, memory, interface counters) is re-checked against the pre-change baseline.
```
pfctl -ss | wc -l; top -b -n 1; netstat -I.
```
Lessons learned are captured: surprises, slow steps, missing pre-checks, automation candidates.