Give firewall, Wi-Fi, and VPN requests the same written lane as everything else.
Network changes touch security policy more directly than a license assignment does. That is a reason to write this lane precisely before the first firewall-rule request arrives — not a reason to leave it undefined.
What enters the network lane.
Useful when routine firewall, Wi-Fi, and VPN requests are currently absorbed informally instead of following a written procedure.
Firewall rule and object changes within an approved change model, Wi-Fi configuration — SSID, guest-network separation, access-point provisioning and health checks — VPN administration for user access grants and site-to-site tunnel monitoring, triage of the alerts an existing network-monitoring tool already generates, and carrier or ISP coordination for an outage the client has already reported.
An authorized change is applied and logged against the documented standard, or returns as an exception naming the security or availability question it raises.
A device and circuit inventory, the administrative method and access path for each platform, the change-approval rule for anything touching inbound access or network segmentation, and the monitoring tool already generating alerts.
A firewall change is a security decision wearing a network hat.
- New or widened inbound accessReturns for approval before it is applied — this is a security-policy decision, not a configuration task.
- VPN access grantsFollow the same authorization check as any other account request; urgency is not authorization.
- Guest/corporate wireless separation changesReturn to the named owner, since they can quietly widen what a guest device can reach.
- SD-WAN, new circuits, or a network redesignAre project work, scoped and estimated on their own — not a lane request.
These examples do not name a specific vendor or platform; the actual device list and change-approval rule belong in the written lane definition.
Who decides, once a network request stops being routine.
| Approved low-risk configuration change | Delivery applies it against the documented standard. |
|---|---|
| New inbound rule or segmentation change | Named security or network owner, per the escalation matrix. |
| New site, circuit, or redesign | Separately scoped project, estimated on its own. |
| Monitoring alert | Delivery triages against agreed thresholds; escalates anything with a security signal immediately. |
Ask these before treating network work as included.
- Does the lane name which devices and vendors are actually covered?"The network" is not a scope until the hardware is listed.
- Is remote administrative access to the firewall or controller itself defined?Confirm the method and who can audit it, not just who has a password.
- What happens to a request that would open access from outside the office network?That should trigger the same exception path every time, not just when someone remembers to ask.
- Who is called when the client's own ISP is the actual problem?Delivery can coordinate; it cannot fix a circuit it does not own.
Network work rarely stops at the network.
Client groups still running on-prem hosts usually need the infrastructure lane too; call-quality problems on a phone system sometimes turn out to be network problems in disguise.