What evidence should a firewall provider supply after configuration changes?

Adequate evidence should allow an independent person to understand, verify and, if necessary, challenge a firewall change. It is more than a notification that an update was completed. The provider should supply enough information to connect the change with its business purpose, security impact, authorisation, validation and ongoing ownership.

In addition to the technical record, request the following supporting evidence:

• Change classification and risk assessment: The record should identify whether the change was routine, significant or emergency, together with the risks considered. This should explain possible effects on confidentiality, integrity, availability, remote access, site-to-site connections and dependent services.
• Scope and dependency information: Evidence should show which networks, users, applications, locations, interfaces or third-party connections could be affected. Dependencies are particularly important where a firewall change interacts with cloud services, DNS, identity systems, virtual networks or several business sites.
• Approval and accountability: The documentation should identify who requested, reviewed, authorised and implemented the work. Where separation of duties is appropriate, the person approving a high-risk change should not be the only person checking its implementation.
• Implementation notes: The provider should record the sequence of material actions, any prerequisites, and any deviations from the intended plan. This helps distinguish the approved design from what was actually carried out and supports a later investigation.
• Security-impact assessment: Ask for an explanation of how the change affects the attack surface. For example, a new inbound service, wider source range, altered administrative access or changed inspection policy should be explicitly assessed rather than treated as an ordinary connectivity adjustment.
• Exception and residual-risk records: If a control could not be applied, a test could not be completed, or a temporary exception was required, the evidence should state why, who accepted the risk, what compensating control exists and when the exception is due for review.
• Administrative access records: For sensitive changes, retain appropriate audit information showing which privileged account performed each action. Access should be attributable to an individual or approved service identity, rather than an untraceable shared administrator account.
• Configuration integrity information: Where configuration files or exports are supplied, the provider should identify their source, creation time and format. Integrity checks or a secure document trail can help show that the supplied files have not been altered after collection.
• Operational handover: The final pack should identify any new rule owner, monitoring requirement, service dependency or maintenance task. It should also state whether documentation, network diagrams, asset records or incident procedures need updating.

The evidence should be proportionate to the change. A minor modification to an existing, tightly scoped policy may need a concise record, whereas a change affecting internet-facing services, privileged access, remote workers or several sites warrants a fuller assessment and review trail. The important point is that the level of evidence reflects the potential business and security impact.

Evidence should also be usable by someone who was not involved in the work. Avoid accepting unexplained screenshots, informal messages or a single line stating that a change was successful. A reviewer should be able to identify the intended control, the people accountable for it, any limitations and the actions required next. Technical terms should be accompanied by enough context to show what they mean for the organisation’s systems and risks.

For governance purposes, retain the evidence with the organisation’s change-management records rather than leaving it solely in a provider’s ticketing system. Access should be restricted appropriately, and retention should align with the business’s contractual, regulatory and incident-investigation requirements. Periodic review can then identify repeated exceptions, undocumented ownership or changes that have become unnecessary.

Before closing the change, a business should ask:

• Can another administrator understand what was intended and what was actually done?
• Is the security impact clear, including any new exposure or reduced control?
• Are approvals, responsibilities and exceptions attributable to named roles or individuals?
• Are outstanding actions, review dates and ownership recorded?
• Could the evidence support an internal audit, customer query or security investigation?

If the answer to these questions is no, the provider should be asked to improve the record before the change is treated as fully documented. A managed IT partner such as S2 Technology Group can help businesses establish consistent firewall change records and review processes, but the organisation should retain sufficient evidence to understand and govern its own security controls.