Workflow Template

Firewall Change Request Workflow

Captures firewall rule change requests, routes them through security risk assessment and appropriate approval (owner or, for higher-risk changes, security manager), implements and tests approved changes, sets a review-by date for temporary changes, notifies the requester on implementation, and returns rejected requests with a reason.

Organisations subject to security governance frameworks and audit obligations require a defensible, consistent process for managing changes to network perimeter controls. This workflow captures firewall rule change requests and routes them through a structured security risk assessment, directing lower-risk changes to the resource owner and higher-risk changes to the security manager for approval. Security, IT operations, and requesting teams operate within a single record that tracks status from submission through implementation, testing, and review-by tracking for temporary changes.

Business Outcomes

Helps reduce unauthorised or undocumented firewall changes through consistent risk-based routing
Supports faster turnaround on low-risk changes by directing them to owner-level approval
Improves audit readiness with a full record of risk review, approvals, and rejection reasons
Reduces the risk of forgotten temporary rules through review-by date tracking
Streamlines requester communication with automated implementation and rejection notifications

Workflow Steps

Steps

1
Create Firewall Change Request Recordcreate record
Registers the submitted firewall change request as a record.
2
Set Status to Submittedupdate record
Marks the request as submitted and awaiting security review.
3
Security Risk Reviewcreate task
Security team reviews the requested change and assesses its risk level.
4
Set Status to Under Security Reviewupdate record
Persists the security team's risk assessment to the record.
5
Route Approval Based on Risk Level
High-risk changes require security manager approval; others go to the owner.
risk_level: "High"→Set Status to Pending Security Manager Approval
risk_level: "Medium"→Set Status to Pending Owner Approval
risk_level: "Low"→Set Status to Pending Owner Approval
Default→Set Status to Pending Owner Approval
6
Set Status to Pending Owner Approvalupdate record
Updates the record status ahead of owner approval.
7
Owner Approvalrequest approval
The system/network owner reviews and approves or rejects the change.
8
Route on Owner Approval Outcome
Proceeds to implementation if approved, or returns to requester if rejected.
approval_status: "approved"→Set Status to Approved - Implementing
approval_status: "rejected"→Capture Rejection Reason
Default→End
9
Set Status to Pending Security Manager Approvalupdate record
Updates the record status ahead of security manager approval for high-risk changes.
10
Security Manager Approvalrequest approval
High-risk changes require explicit security manager sign-off.
11
Route on Security Manager Approval Outcome
Proceeds to implementation if approved, or returns to requester if rejected.
approval_status: "approved"→Set Status to Approved - Implementing
approval_status: "rejected"→Capture Rejection Reason
Default→End
12
Capture Rejection Reasonupdate record
Records a standard rejection reason on the record before notifying the requester.
13
Notify Requester of Rejectionsend email
Returns the request to the requester with the reason it was rejected.
14
Set Status to Approved - Implementingupdate record
Marks the change as approved and moving into implementation.
15
Implement and Test Firewall Rulecreate task
Network/security engineer implements the approved rule and tests it works as intended.
16
Check if Change is Temporary
Temporary changes require a review-by date to be set for later removal.
change_duration: "Temporary"→Set Review-By Date
Default→Notify Requester of Implementation
17
Set Review-By Dateset due date
Sets a due date on the record and persists the review-by date to the record for reporting.
18
Persist Review-By Date to Recordupdate record
Writes the resolved review-by date onto the record so it is visible in table views and reports.
19
Notify Requester of Implementationsend email
Informs the requester that their firewall change has been implemented and tested.
20
Confirm Final Status as Implementedupdate record
Ensures the record is left in a final, non-mid-process status after the requester has been notified of implementation.

Fields

Requester Name*
Requester Email*
Requested Rule Description*
Source (IP/Range/Zone)*
Destination (IP/Range/Zone)*
Ports*
+9 more fields

Forms

Firewall Change Request

9 fields

Data Views

All Firewall Change Requests

requester_name, requested_rule, risk_level, request_status +2 more

Dashboard Widgets

Requests by StatusFirewall Change Requests OverviewRequests by Risk Level

Recommended integrations

Setup the following integrations to extend workflow capability.

Send email in the workflow
AWS SES

firewall change requestfirewall rule requestnetwork security changeport accesssecurity approval

Similar Workflows

it change management security exception privileged access request

Similar Categories

cybersecurity privacy information technology

FAQs

How is this audited within assess.one?

Every firewall change request record retains a complete history of status transitions, including submission, security risk review, approval routing, implementation, and testing outcomes. Rejection reasons and approver decisions are captured directly on the record, giving compliance and security teams a traceable audit trail without needing to reconstruct events from email or ticket threads.

Who has access to firewall change requests and approvals?

Access is configured within assess.one by role, so requesters, security reviewers, resource owners, and security managers each see only the steps and information relevant to their responsibilities. Administrators can adjust these permissions at any time to reflect changes in team structure or escalation paths.

How does this integrate with existing security and notification tools?

Notifications to requesters and reviewers, such as email or Slack alerts on implementation or rejection, are configured directly inside assess.one without third-party development work. This keeps the firewall change process connected to the communication channels teams already use for security operations.

Can the risk assessment and approval routing logic be customised?

Yes. The criteria used to classify a change as higher-risk, and the corresponding routing to owner or security manager approval, are configurable steps within the platform. Organisations can adjust thresholds, add additional approval tiers, or modify notification triggers to align with their internal security policy.

What happens when a change is rejected?

When an owner or security manager rejects a request, the workflow captures a rejection reason directly on the record before notifying the requester. This ensures rejected requests are documented with rationale rather than communicated informally, supporting a clearer resubmission process.

How are temporary firewall changes tracked for review?

During implementation, the workflow checks whether a change is temporary and, if so, sets and persists a review-by date to the record. This creates a visible marker for security teams to revisit and remove or re-approve temporary rules before they become permanent by default.

What approval considerations apply to higher-risk changes?

Higher-risk changes are routed to the security manager rather than the owner, reflecting the elevated potential impact on the network security posture. This tiered approval structure is designed to help ensure that more sensitive changes receive scrutiny appropriate to their risk level before implementation.

How long does it take to get this workflow live?

The Firewall Change Request Workflow is a ready-to-use template that can be published in minutes, with no separate implementation project required. Once published, teams can begin submitting and processing change requests immediately, and steps, roles, or approval logic can be refined as the process runs.

Who typically needs access to this workflow?

Typical participants include requesters submitting firewall change needs, security reviewers conducting the risk assessment, resource owners approving lower-risk changes, and security managers approving higher-risk changes. IT operations staff responsible for implementation and testing also interact with the record as it progresses.

Ready to use this workflow?

Create a free account and customise this workflow for your business.