Pre-change checklist — the discipline that turns a risky change into a reversible one · OPNsense

A rule change is not a click in a GUI. A rule change is a deliberate sequence of decisions made before, during, and after the click. The pre-change checklist is the discipline that catches the decisions the operator did not know they were making — the worst-case effect they did not think through, the recovery path they did not test, the backup they did not take.

This lesson covers the pre-change checklist: the seven checkpoints the operator walks through before any firewall modification, and the trap each checkpoint catches.

The seven checkpoints

The pre-change checklist has seven checkpoints. Every checkpoint produces an explicit answer. An answer like “I will figure it out” or “should be fine” is not an answer; it is a hole in the checklist. The operator stops, fills the hole, and only then proceeds.

What is the change? The rule (or alias, or NAT, or interface setting) being added, modified, or removed. State it in one sentence.
Why is the change being made? The incident, the request, the ticket, the requirement. The reason that put this change on the schedule.
What is the expected effect? The traffic pattern that will change after the change. Include the interface, the source, the destination, the port, and the action.
What is the worst-case effect? The most damaging thing the change could do if applied incorrectly. Name the failure mode, not just “the firewall breaks”.
Is the backup current? A configuration backup exists, was taken recently, is stored off the firewall, and is restorable.
Is the recovery path tested? Console access works. Break-glass SSH works. The backup can be restored.
Is this a maintenance window? A planned change window with a rollback deadline, or an emergency change with a separate approval.

Each checkpoint produces evidence. The evidence is written down in the change ticket — not in the operator’s memory, not in a chat message, not in a Slack thread that scrolls away. The written evidence is the audit trail.

The worst-case effect is the checkpoint that catches most lockouts

Most operators can state what the change is and why it is being made. Most operators can describe the expected effect. The checkpoint most operators skip is the worst-case effect — the explicit statement of what breaks if the change is wrong. The operator who skips this checkpoint is the operator who applies a change, sees the GUI go unreachable, and has to think on the spot about what to do next. The operator who fills in this checkpoint has already thought through the recovery, knows which session to use, and has the rollback procedure written before the change is applied. The worst-case-effect checkpoint is also the checkpoint the peer reviewer reads first — the reviewer reads the worst case, decides whether the procedure is sufficient for that worst case, and either signs off or sends the change back.

Filling in each checkpoint

The operator who is honest about the worst case catches mistakes before they happen. The operator who fills in the expected effect and skips the worst case finds the worst case at 03:00.

Checkpoint 1 — What is the change?

State the change as a single sentence in plain language. “Add a rule on LAN that blocks 192.0.2.0/24 from reaching 198.51.100.50:443.” Not “improve egress filtering.” Not “tighten the rules.” The single sentence is the change; everything else is the rationale.

Checkpoint 2 — Why?

The reason. The incident. The ticket number. “INC-2026-0814-0042 — 198.51.100.50 was compromised, block egress to that destination.” The reason is the audit trail; the next operator who looks at the rule will read the reason to decide whether the rule is still needed.

Checkpoint 3 — Expected effect

The traffic pattern after the change. “Hosts on 192.0.2.0/24 cannot reach 198.51.100.50:443. Other destinations on 198.51.100.50 are unaffected. Other LAN traffic is unaffected.” The expected effect is what the operator verifies after the change. If the change does not produce the expected effect, the change did not work.

Checkpoint 4 — Worst-case effect

The most damaging thing the change could do. “If the source is mistyped as 0.0.0.0/0, all LAN traffic is blocked. The GUI is on the LAN; the operator would be locked out. Recovery: console restore from backup.” The worst-case effect is what the peer reviewer reads; the reviewer decides whether the procedure is sufficient for that worst case.

Checkpoint 5 — Backup current

A backup exists, was taken recently, is stored off the firewall, and is restorable. The operator takes the backup immediately before the change, downloads it to the operator’s workstation or to the configuration management system, and confirms the file is readable.

Read-only / SafeBackup and copy off the firewall— configctl config backup writes a timestamped backup to /conf/backup/. The operator then copies the backup off the firewall to a workstation or to a configuration management system. A backup stored on the firewall is recoverable only if the firewall is reachable — which is the very case the operator may be trying to recover from.

$ configctl config backup && cp /conf/backup/config-*.xml ~/backups/

Writing backup to /conf/backup/...
-rw-------  1 root  wheel  14523 Aug 14 02:14 config-2026-08-14-0214.xml
drwxr-xr-x  2 root  wheel    512 Aug 14 02:14 backups

Illustrative output

Checkpoint 6 — Recovery path tested

Console access works. Break-glass SSH works. The backup can be restored. The operator tests each path before applying the change. The recovery path that is not tested does not exist.

Checkpoint 7 — Maintenance window

A planned change window with a rollback deadline (typically 30-60 minutes), or an emergency change with a separate approval chain. The change window is the time the operator has to verify the change; if verification fails within the window, the operator rolls back.

Risk classification

Not all changes carry the same risk. The pre-change checklist produces a risk classification:

Low risk. Change affects a test network, a non-production alias, or an interface the operator does not use. Two-session test optional. Peer review optional. Backup current required.
Medium risk. Change affects production traffic but not the operator’s path to the firewall. Two-session test required. Peer review recommended. Backup current required.
High risk. Change affects the operator’s path to the firewall (GUI, SSH, console-via-IPMI), affects a default-deny boundary, or affects stateful filtering on a high-volume interface. Two-session test required. Peer review required. Backup current and restore-tested required.

The risk classification drives the procedure. High-risk changes require additional precautions: peer review by a senior operator, rollback procedure documented before the change, change window with a rollback deadline, and a second operator on standby during the change window.

Summary

The pre-change checklist has seven checkpoints: what, why, expected, worst-case, backup, recovery, window.
Each checkpoint produces an explicit answer. The holes in the checklist become the holes in the recovery.
The worst-case effect checkpoint is the one that catches most lockouts. Name the failure mode, not just “the firewall breaks”.
Risk classification (low/medium/high) drives the procedure. High-risk changes require peer review, tested recovery path, and rollback procedure documented before applying.