Ørsted Firewall Automation: How Governance Made Speed Possible
How Ørsted reduced qualifying firewall changes to ten minutes—and what its approach teaches businesses about network automation and compliance.
At Ørsted, some firewall changes that once moved through days or weeks of coordination can now be completed in roughly ten minutes. The Danish energy company did not get there by dispensing with approvals. It built a process in which network data, eligibility rules, and human review work together.
As reported by Network World on October 12, 2026, about 60%–70% of Ørsted’s incoming firewall requests fit a lower-risk, preapproved category. Those requests still require peer review. Exceptions go to the Change Advisory Board (CAB).
The larger lesson is not that every company should automate its firewalls. It's that a faster technical task delivers limited value until the decisions surrounding it become easier to make.
The Delay Was Between Decisions, Not Devices
Previously, an internal customer submitted a request through ServiceNow. Engineers checked addresses, directory groups, and network context; some changes then required CAB approval before another team implemented them. Missing information could send the request back to its starting point.
The actual firewall configuration was only one step in the journey. A script that performed that step instantly would still leave the organization waiting for reliable inputs, a risk determination, and an accountable approver.
Ørsted addressed that upstream work by customizing Nautobot, an open-source network automation platform, to connect IP addresses with network zones and governing policies. Validation happens before a request advances, rather than being reconstructed across disconnected systems.
Multi-step coordination
Request submitted → engineers check addresses, groups, network context → CAB approval (if required) → separate team implements → missing info sends it back to start.
Governed automated process
Request data validated upfront → eligibility determined automatically → peer review or CAB approval → deployment with full traceability back to original request.
The Most Valuable Automation Was a Decision Boundary
The distinctive design choice was to make eligibility for the faster path explicit.
For a familiar, permitted traffic flow, the system can validate the request and enforce peer review. For a request outside those established conditions, CAB approval remains required. Logs and metadata link deployed rules to the original request and responsible team.
Lower-risk requests
Familiar, permitted traffic flows. The system validates the request and enforces peer review. About 60%–70% of incoming requests qualify.
CAB-required requests
Requests outside established conditions. Change Advisory Board approval remains required. Logs and metadata link deployed rules to the original request.
That distinction creates something more useful than a universal approval button: a repeatable division of responsibility between software and people.
It also changes the experience for internal customers. They need not understand every underlying firewall operation, but they do need to submit usable information and follow a defined approval path. Engineers and security teams remain responsible for maintaining the policies and systems behind those decisions.
This is compliance as an operating capability, rather than a separate documentation exercise. It doesn't make policies infallible; it makes their application more consistent and easier to trace.
→
Why the People Had to Help Redesign the Workflow
Ørsted also encountered a challenge that many technically sound automation initiatives face: stakeholders needed confidence that automated didn’t mean uncontrolled.
The company brought internal customers, network security engineers, IT security colleagues, and product owners into a design sprint to examine the existing process.
That collaboration addressed a question software alone cannot settle: who should be able to request, approve, change, and investigate an action?
The operational roles changed as well. Instead of manually maintaining most customer-facing firewall rules, some engineers moved toward developing the platform and others toward supporting its users. Firewall maintenance, patching, and oversight still require technical expertise.
The result is a positive example of automation redistributing engineering attention, not making engineers unnecessary.
Is Your Next IT Process Actually Ready for Automation?
Ørsted’s model is specific to its network and regulatory responsibilities. But the logic offers a useful way to assess other repetitive IT processes, from granting application access to provisioning a new site.
Consider three questions before choosing a tool.
Can the request be described using dependable data?
If ownership, system identifiers, or allowed connections are scattered across emails and spreadsheets, making the workflow faster may simply accelerate rework. Better records may deliver the first improvement.
Can ordinary requests be distinguished from exceptions?
A workflow is a better automation candidate when routine cases follow stable rules and unusual cases have a clear escalation path. The aim isn’t to avoid judgment; it’s to reserve judgment for decisions that actually need it.
Can someone reconstruct the decision afterward?
A successful deployment isn’t the same as a well-managed change. The request, validation, approval, and resulting action should form a coherent record that operations and compliance teams can use.
These tests are useful even if the conclusion is not to automate yet. Sometimes clearer request forms, current network documentation, and defined ownership eliminate the worst delays at much lower complexity.
Measure the Queue, Not Just the Command
A ten-minute result is compelling, but it only describes Ørsted’s qualifying requests. Other organizations should establish their own baseline rather than treating it as a target.
| Measure | What it reveals |
|---|---|
| Incomplete requests | Whether requesters have the information needed to submit usable requests |
| Requests returned for rework | How often missing or incorrect data sends a request back |
| Time waiting for review | Where queue time rather than task time dominates |
| Implementation accuracy | How often implementation differs from what was approved |
Those measures reveal whether work is becoming more predictable—not just whether individual commands execute faster.
At Infonaligy, we see this as a practical connection between Network Infrastructure, Managed IT, and Compliance: maintaining a network includes making routine changes understandable, supportable, and accountable.
Before investing in a larger automation platform, it’s worth asking a simpler question:
Which recurring change takes the most coordination relative to the work itself?
That is often where a process review can produce meaningful results. Infonaligy can help evaluate the network documentation and management practices behind those delays.
→
Sources
- Network World — Ørsted Builds Compliance Into Automation, Speeds Firewall Changes (October 12, 2026)
- TLDR IT — October 13, 2026
Frequently Asked Questions
Not necessarily. In Ørsted's implementation, preapproved lower-risk requests use enforced peer review, while changes outside that category still require CAB approval.
Network automation covers a broader range of infrastructure tasks, including configuration, validation, and change workflows. Firewall change automation specifically addresses the management and implementation of firewall rules and related approvals.
Infonaligy can help evaluate the network documentation and management practices behind those delays. Whether you're assessing automation readiness or tightening change management, we connect network operations with compliance so routine changes are understandable, supportable, and accountable.
Serving Businesses Across Texas & Oklahoma