Guides
Firewall Change Management Report: A Template for Auditors and Management
A firewall change management report has two layers. The first is the per-change record: one entry per change, saying who asked for it, why, which rule changed on which device, who approved it and when, and whether verification passed. The second is the periodic report that rolls those records up into a few metrics for management and auditors. This post gives you a template for both, and maps each part to what PCI DSS v4.0.1, ISO/IEC 27001:2022 and NIS2 ask for.
How to run the change process itself (request, review, approval, implementation) is covered in our 7-step firewall change management guide. This post is about what that process has to leave behind: the document you hand over when an auditor, the CISO or the board asks for "the firewall change report".
What should a firewall change record contain?
A firewall change record should let someone who was not in the room reconstruct the change from the record alone: the request, the decision, the exact configuration delta and the proof it worked. Thirteen fields cover that. Five of them (3, 7, 8, 11 and 12) come straight from the wording of PCI DSS Requirement 6.5.1, and the rest are what an assessor needs to trace a change in both directions.
| # | Field | What goes in it | Why it matters at audit |
|---|---|---|---|
| 1 | Change ID | Unique ID from the change system, never reused | The key that links a device-side diff back to a record |
| 2 | Requester | Named person and team, not a shared mailbox | Someone has to own the business need later |
| 3 | Business justification | The reason in plain language, plus the application or service it serves | PCI DSS 6.5.1 asks for the reason for, and description of, the change |
| 4 | Ticket link | URL of the ITSM ticket or request | Holds the discussion the record summarises |
| 5 | Affected devices and rules | Hostnames, policy or rulebase name, rule IDs or names, objects touched | Defines the sample scope for the assessor |
| 6 | Before and after rule | The exact rule text before and after, or a configuration diff | Shows what changed on the box, not what was intended |
| 7 | Risk rating and security impact | Standard, normal, high or emergency, with one sentence on security impact | PCI DSS 6.5.1 asks for documentation of security impact |
| 8 | Approver and timestamp | Name, role, date and time of approval | Approval has to come before implementation, and the timestamp proves it |
| 9 | Implementation window | Planned start and end | Compared against the device log to spot changes made outside the window |
| 10 | Implementer | Named admin account that made the change | Shows separation between approver and implementer |
| 11 | Verification result | Test performed, result, evidence (log line, connection test, screenshot) | PCI DSS 6.5.1 asks for testing that the change does not hurt security |
| 12 | Rollback plan | Steps to revert, and whether they were used | PCI DSS 6.5.1 asks for procedures to address failures and return to a secure state |
| 13 | Expiry date for temporary rules | Removal date and owner, or "permanent" with a reason | Stops a temporary rule from becoming part of the baseline |
Which fields do teams fill in badly?
In our experience two fields fail far more often than the rest. Field 6 is the first: people paste what they intended ("allow app server to DB on 1433") instead of the rule as it now exists on the device, with its object names, zones and position in the rulebase. An auditor comparing that text to the live configuration finds a mismatch, and the record loses its value as evidence. Field 11 is the second, where "done" or "tested OK" stands in for a test. Write down what was tested and what the result was: "connection from 10.20.4.15 to 10.30.1.8 on TCP 1433 succeeded, hit count on rule 214 increased". That sentence takes thirty seconds to write and still matches the device when an auditor checks it.
Field 13 matters most for emergency changes. A rule opened during an incident with no expiry tends to outlive the incident by years, as we describe in the emergency change that never gets rolled back.
What goes into the monthly or quarterly management report?
The periodic firewall change report turns a pile of records into a handful of numbers that show whether the process works. Management reads it for trend and risk. Auditors read it as evidence that someone monitors the process instead of just running it. Seven metrics are enough. Each extra one makes the page harder to read.
| Metric | How to count it | What it tells you | Warning sign |
|---|---|---|---|
| Changes by type | Count per period: standard, normal, emergency; and add, modify, remove | Workload and the mix of work | A sudden jump with no project to explain it |
| Emergency share | Emergency changes divided by all changes | Whether planning works, or the emergency path has become the fast lane | Share rising while incident numbers stay flat |
| Failed or rolled-back changes | Changes whose verification failed or that were reverted | Quality of testing and peer review | Repeat failures on the same device or team |
| Rules added vs removed | Rules added, rules removed, net change | Whether the rulebase grows without control | Net growth in every period |
| Overdue recertifications | Rules past their review date | Whether periodic review keeps pace with the rulebase | The backlog growing period over period |
| Unauthorised changes detected | Configuration changes with no matching change ID | Whether the change process is the only route to the firewall | Any non-zero number without an explanation per item |
| Expired temporary rules still active | Rules past their field-13 expiry date | Whether temporary access really ends | The same rules appearing again next period |
Two of these carry most of the signal. The unauthorised changes line is the one auditors look at first, because it tests the whole process: if changes reach the firewall without a record, every other number in the report describes only part of reality. Our post on policy drift detection covers how to find them. The overdue recertifications line connects the change report to the periodic rule review in our rule recertification guide. PCI DSS Requirement 1.2.7 requires network security control configurations to be reviewed at least once every six months, so an overdue backlog is a finding waiting to happen.
We will not give you target values. We know of no credible industry benchmark for emergency share or failure rate, and a number copied from a vendor slide helps nobody. Set your own threshold after two or three periods, show the trend over the last four to six, and give every red number an owner and an action. The first question at the next review will be what happened to last quarter's red numbers.
What do PCI DSS, ISO 27001 and NIS2 auditors want to see?
All three frameworks want the same thing in different words: a defined change procedure, records showing each change followed it, and proof that someone checks the procedure works. The per-change record answers the first two. The periodic report answers the third.
| Framework | Reference | What it says | Where the template covers it |
|---|---|---|---|
| PCI DSS v4.0.1 | Req. 1.2.2 | All changes to network connections and NSC configurations are approved and managed per the change control process in 6.5.1 | One record per firewall change |
| PCI DSS v4.0.1 | Req. 6.5.1 | Reason and description, security impact, documented approval by authorised parties, testing, procedures to address failures | Fields 3, 7, 8, 11, 12 |
| PCI DSS v4.0.1 | Req. 1.2.7 | NSC configurations reviewed at least once every six months | Overdue recertifications metric |
| PCI DSS v4.0.1 | Req. 10.2.1.2 | Audit logs capture all actions by anyone with administrative access | Source data for the unauthorised-changes metric |
| ISO/IEC 27001:2022 | Annex A 8.32 | Change management control for information processing facilities and systems | Records as proof the procedure runs; report as monitoring |
| NIS2 | Art. 21(2)(e) and (f) | Security in maintenance of network and information systems; procedures to assess the effectiveness of risk-management measures | Records for (e); periodic report for (f) |
| Implementing Regulation (EU) 2024/2690 | Annex, 6.4 | Changes documented, tested and evaluated for impact based on risk; emergency changes documented with their result and the reason the normal procedure was not followed; procedures reviewed at planned intervals | Fields 6, 7, 11; emergency share; the report itself |
The PCI DSS wording comes from the v4.0.1 standard in the PCI SSC document library. Requirement 6.5.1 lists the reason for and description of the change, documentation of security impact, documented change approval by authorised parties, testing, and "procedures to address failures and return to a secure state". Our PCI DSS 4.0 firewall requirements post covers the rest of Requirement 1.
ISO/IEC 27001:2022 lists change management as Annex A control 8.32. The standard text is sold by ISO and does not prescribe fields, so the auditor judges whether your procedure and records are adequate. The template above gives them something concrete to judge.
The NIS2 Directive does not use the words "change report". Article 21(2)(e) covers "security in network and information systems acquisition, development and maintenance", and 21(2)(f) requires "policies and procedures to assess the effectiveness of cybersecurity risk-management measures". The detail sits in Implementing Regulation (EU) 2024/2690, whose Annex section 6.4 says the procedures "shall ensure that those changes are documented". That regulation binds a named list of digital providers: DNS and cloud providers, data centres, managed and managed security service providers, among others. Other essential and important entities answer to their national transposition. In our view, section 6.4 is still the most specific public benchmark an auditor in any NIS2 sector can reach for, so it is worth meeting.
In our experience, assessors test in both directions. They take changes visible on the device (a configuration diff, an admin log entry) and ask for the record. Then they take records and ask for the device-side evidence. A report that only works in one direction fails the other half of the sample.
Should you produce the report from tooling or a spreadsheet?
You can produce a firewall change report from a spreadsheet for a small estate, but a spreadsheet cannot produce the metric auditors trust most. It only knows what people typed into it, so it can never show a change nobody recorded. Tooling that reads the firewall configuration can.
| Report element | Spreadsheet | Change tooling connected to the firewalls |
|---|---|---|
| Record fields | Free text, columns get skipped | Mandatory fields enforced at submission |
| Before and after rule | Pasted by hand, often the intent | Pulled from the device as a diff |
| Approval timestamp | Typed in, editable later | Recorded by the system |
| Unauthorised changes | Not possible without a separate diff process | Configuration diff matched against change IDs |
| Monthly metrics | Pivot tables rebuilt by hand | A saved query |
| Tamper evidence | Any editor can rewrite history | Append-only history |
If you stay on a spreadsheet, three habits close most of the gap: protect the columns so records cannot be edited after approval, put the change ID into the rule comment or description field on the firewall, and export a configuration diff every month to reconcile against the sheet by hand. Our post on why spreadsheet tracking fails audits covers where that approach runs out.
How do you start if you have nothing today?
Start with the record, not the report. A report built on incomplete records only shows the gaps more neatly.
- Add the thirteen fields to the change form you already use. Make 6, 8 and 11 mandatory first.
- Tag every rule with its change ID in the firewall's comment or description field, so the device side can be traced back.
- Run one reconciliation: take last month's configuration diff and match each change to a record. Whatever is left over is your first unauthorised-changes number.
- Publish the first report as a baseline, without targets. Set thresholds once you have three periods of data.
Keep the records for as long as anyone might need to question a change. That can be longer than the audit cycle, as our post on firewall change records as legal evidence shows.
Could your team hand over a complete change report for last quarter by Friday? The free NIS2 Readiness Check shows which change evidence your firewall estate can produce today and where the gaps are.
