Firewall change and rollback record

How to use this resource

Intended for Network administrators, security teams, service owners, change managers, and managed service providers. Typical completion time: 15 to 30 minutes for a routine change; longer for complex or high-risk work.

• Create one record per logically related change. Link related records rather than combining unrelated rules.
• Use the organization's standard change identifier and time zone.
• Write source, destination, service, direction, and action explicitly. Avoid broad terms such as any unless there is a documented reason.
• Do not paste passwords, private keys, pre-shared keys, tokens, or unredacted secrets into the record.
• Obtain approval before implementation. Record an emergency change as emergency, with retrospective review requirements.
• Close the record only after validation, monitoring, documentation updates, and evidence capture are complete.

1. Change identification

• FieldsChange IDRequiredUnique ticket or change number · Type: text
• FieldsTitleRequiredShort description of the intended network access · Type: text
• FieldsRequesterRequiredName, team, and contact · Type: text
• FieldsBusiness or service ownerRequiredPerson accountable for the service need · Type: text
• FieldsTechnical implementerRequiredPerson or provider making the change · Type: text
• FieldsFirewall or policy domainRequiredDevice, cluster, cloud policy, tenant, or management domain · Type: text
• FieldsEnvironmentRequiredType: select · Options: Production, Pre-production, Test, Development, Other
• FieldsChange classRequiredType: select · Options: Standard, Normal, Emergency
• FieldsPlanned windowRequiredInclude date, start, end, and time zone · Type: datetime_range
• FieldsRelated incident, problem, project, or vendor ticketReferences only; do not include secrets · Type: text

2. Business reason and expiry

• FieldsBusiness requirementRequiredWho needs to communicate, for what service, and why? · Type: long_text
• FieldsConsequence if not implementedRequiredOperational impact, deadline, and affected users or service · Type: long_text
• FieldsPermanent or temporaryRequiredType: select · Options: Permanent, Temporary, Time-bound pending review
• FieldsExpiry date and timeRequired for temporary access · Type: datetime
• FieldsReview dateRequiredWhen the continuing need will be confirmed · Type: date
• FieldsRule ownerRequiredNamed role responsible for future review · Type: text

3. Technical specification

• Repeatable groupOne row per rule or object change
• FieldsSequenceRequiredType: number
• FieldsSource zone or interfaceRequiredType: text
• FieldsSource address, object, or groupRequiredType: text
• FieldsDestination zone or interfaceRequiredType: text
• FieldsDestination address, object, or groupRequiredType: text
• FieldsProtocol and destination port or applicationRequiredType: text
• FieldsDirectionRequiredType: select · Options: Inbound, Outbound, Inter-zone, Site-to-site, Other
• FieldsActionRequiredType: select · Options: Allow, Deny, Reject, Inspect, Other
• FieldsNAT requirementRequiredNone, source NAT, destination NAT, or exact requirement · Type: text
• FieldsLoggingRequiredStart, end, deny, session, or platform-specific setting · Type: text
• FieldsSecurity profile or inspectionType: text
• FieldsRule position and interactionRequiredPlacement, shadowing, overlap, implicit rules, and policy route effects · Type: long_text
• FieldsRule commentRequiredInclude change ID, owner, purpose, and expiry where supported · Type: text

4. Risk and dependency review

• ChecklistSource and destination are as narrow as the requirement permits.
• ChecklistPorts, protocols, and applications are as narrow as the requirement permits.
• ChecklistThe rule does not unintentionally expose management interfaces.
• ChecklistInternet exposure and egress implications have been reviewed.
• ChecklistNAT, routing, VPN, DNS, load balancer, proxy, and cloud security-policy dependencies have been checked as applicable.
• ChecklistExisting rules were checked for duplication, overlap, shadowing, or conflict.
• ChecklistLogging and retention are suitable for validation and investigation.
• ChecklistRequired inspection profiles and exceptions are documented.
• ChecklistHigh availability or configuration synchronization has been considered.
• ChecklistA temporary rule has an expiry mechanism or scheduled removal task.
• FieldsRisk if implementedRequiredType: long_text
• FieldsRisk rating and methodRequiredUse the organization's rating scheme · Type: text
• FieldsCompensating controlsType: long_text
• FieldsKnown dependenciesRequiredType: long_text
• FieldsAffected monitoring or detectionType: long_text

5. Test and implementation plan

• FieldsPre-change checksRequiredHealth, backup/export, sessions, synchronization, monitoring, and baseline evidence · Type: long_text
• FieldsImplementation stepsRequiredExact, reviewable sequence; reference approved scripts or platform commands securely · Type: ordered_list
• FieldsExpected resultRequiredType: long_text
• FieldsPositive testRequiredAuthorized traffic that should succeed · Type: long_text
• FieldsNegative testRequiredTraffic that should remain blocked · Type: long_text
• FieldsMonitoring during and after changeRequiredType: long_text
• FieldsValidation ownerRequiredType: text
• FieldsObservation periodRequiredType: duration

6. Rollback and stop conditions

• FieldsRollback triggerRequiredSpecific failed tests, errors, performance conditions, or elapsed-time threshold · Type: long_text
• FieldsPoint of no returnRequiredState none if the change remains fully reversible · Type: text
• FieldsRollback stepsRequiredType: ordered_list
• FieldsEstimated rollback timeRequiredType: duration
• FieldsRollback decision authorityRequiredType: text
• FieldsPost-rollback validationRequiredType: long_text

7. Approval and closeout

• Approval rolesService owner
• Approval rolesSecurity or technical reviewer
• Approval rolesChange authority
• Approval rolesImplementer acknowledgement
• Closeout fieldsActual start and end time with time zone
• Closeout fieldsImplementation result: successful, partially successful, rolled back, or failed
• Closeout fieldsTest evidence references
• Closeout fieldsObserved errors or unexpected effects
• Closeout fieldsRollback performed and reason
• Closeout fieldsMonitoring result
• Closeout fieldsDocumentation, diagram, inventory, and rule-register updates
• Closeout fieldsTemporary-rule removal task
• Closeout fieldsFollow-up actions with owner and due date
• Closeout fieldsFinal reviewer and closure date

Important limitations

For general operational use only. These materials are not legal advice, compliance advice, a warranty, or a complete control framework. Using a template does not establish that a change, assessment, incident plan, or recovery capability is adequate. Obtain appropriate technical, legal, privacy, insurance, and regulatory advice for your circumstances.

• This template does not authorize a firewall change. Follow your organization's access, change, security, privacy, and vendor procedures.
• Do not place passwords, private keys, recovery codes, sensitive personal information, or unredacted secrets in forms, worksheets, tickets, or email. Use an approved secure channel for confidential material.
• Resource version 1.0. Suggested download filename: hai-firewall-change-template.html.