Qutzl LLC LogoQutzl Insights

Tutorial

Document firewall changes on one page

A single change record template so every rule edit has a name, a reason, and a rollback path.

3 min readBy Michael NarehoodNetworking

Firewall consoles remember every rule you ever added. Humans do not. Six months later, “TEMP_VENDOR” is production, and nobody recalls which ticket authorized it. A one-page change record fixes most of that without a heavyweight ITIL rollout.

Use the same template for every edit—new allow rule, NAT tweak, VPN phase-2 adjustment, object rename. One page, stored with the ticket or in your wiki. If it does not fit on one page, the change is probably too big for a single maintenance window.

1. Copy a template you will actually fill out

Create a doc or ticket section with these fields:

Field Example
Change ID / ticket NET-4821
Date & owner 2026-03-24, M. Narehood
Device(s) HQ-FW01 (FortiGate 60F)
Summary Allow vendor VPN to app server
Business reason Payroll vendor support session Tuesday
Rules/objects touched VENDOR_VPN → APP-SRV TCP/443
Before state No path from VPN pool to 10.10.5.20
After state Allow as above; logged
Rollback Disable rule VENDOR_VPN-APP-443
Test plan Vendor connects; staff VLAN still blocked
Expiry / review Remove 2026-04-30 unless renewed

Paste the table into every firewall ticket. Empty fields mean the change is not ready to implement.

2. Write the reason in plain language

“User asked” is not a reason. “Accounting needs vendor RDP for month-end support per approval from [name/role]” is. You are not writing a novel—you are giving the next admin enough context to defend or delete the rule.

If the reason is emergency incident response, say so and schedule a follow-up review date. Emergency rules become permanent by accident more often than by design.

3. Snapshot before you click Apply

Minimum:

  • Export the relevant rule section or full config (vendor-dependent)
  • Note rule numbers/names and hit counts if the UI shows them
  • Screenshot the policy pane if export is awkward

Store the export in the ticket. Rollback is “re-import snippet” or “disable rule X,” not “guess what changed.”

4. Implement with naming discipline

When you add objects and rules:

  • Use names that describe purpose (PAYROLL-VENDOR-VPN), not rule47
  • Avoid TEMP unless the expiry field is filled and calendared
  • Prefer narrow sources and destinations over any-any shortcuts “we will tighten later”

Log the exact object and rule identifiers in the Rules/objects touched field. Console search should match the document word for word.

5. Test and record results

Run the Test plan immediately after apply:

  1. Confirm the new path works (vendor reaches the app; user reaches the internet)
  2. Confirm adjacent paths still fail as expected (guest Wi-Fi cannot reach the server; rule is not any-any)
  3. Note pass/fail in the ticket with timestamp

Failed tests trigger rollback first, analysis second. Do not “fix forward” silently on a production edge device at 4:45 p.m. unless you enjoy evening calls.

6. Schedule review for temporary access

If the change is time-bound, put a calendar reminder on the Expiry / review date. Review means disable, confirm nothing broke, delete objects, update the ticket closed. Vendor access that persists unreviewed is how flat networks happen.

Bottom line

Every firewall change deserves one page: why, what, before/after, rollback, test, and expiry. Fill the template before you apply, export proof, test like an attacker would, and delete temporary rules on schedule. Your future self—and anyone covering PTO—will treat you like a hero instead of an archaeologist.