From Network Rule Chaos to Application Ownership

How DORA is forcing a shift in responsibility 
– and how we built a system to make it work.

With DORA – the EU’s Digital Operational Resilience Act – now in effect, financial entities are required to demonstrate a whole new level of operational control. It's not just about uptime or data protection anymore. We're talking about systematic, auditable processes for everything from risk management to infrastructure security.

In many organizations, firewall rules are created by network teams, requested by app teams, and occasionally reviewed by security. But when it comes to ownership – as in, who is responsible for this rule still existing? – the answer is often a shrug. This is where things get messy. Firewalls grow bloated, filled with legacy rules no one dares remove. Review processes, if they happen at all, are manual, inconsistent, and disconnected from the application context. Now DORA is asking us to fix that. Not theoretically – but operationally, with evidence

One clause in particular, Article 13(h), brings firewall management into the spotlight:

“Financial entities shall identify the roles and responsibilities and steps for the specification, implementation, approval, change, and review of firewall rules and connection filters…”

And it gets more specific:

“For ICT systems supporting critical or important functions, these rules must be reviewed at least every 6 months.”

If that sounds like a tall order – it is. Especially if your current process involves chasing down Excel files, reading outdated ticket descriptions, or just trusting that a rule must be needed… somehow.

So we built a system that answers the question: “What application is this firewall rule for, and is it still valid?”

We started by integrating multiple data sources: firewall configs and logs, CMDB data, LeanIX for application ownership, and F5 load balancer mappings. Instead of dumping it all into yet another spreadsheet, we modeled the relationships in a Neo4j graph database – because understanding firewall rules is all about relationships: source, destination, NAT, services, zones, applications. The result is a living map of which rules affect which apps, who owns them, and what traffic actually flows through them.

Image

Illustration: Graph-based view of infrastructure relationships – illustrating how a central object (like a firewall rule, IP address, or app ID) can be mapped to dozens of dependent entities in real-world network environments.

Making reviews meaningful

With this foundation in place, we focused on the part DORA actually cares about: reviewability. Application owners get targeted reports showing just the rules relevant to their systems. They don’t have to know firewall syntax – they simply validate whether a connection makes sense for their app. It’s a clear yes/no decision, backed by real traffic data. At the same time, the security team gets a complete view of rule usage and compliance. Are policies like “no any-any” enforced? Are logs active? Are there redundant or shadowed rules? Everything is traceable – and timestamped – for audit purposes.

Why this approach is different – and DORA-ready

What sets this apart isn’t just the data integration or the automation. It’s the shift in ownership. Instead of security or network teams carrying the entire burden of compliance, application teams become accountable for the adequacy of their own rules – but with the right tools and context to do it confidently. No more tribal knowledge. No more Excel archaeology. And no more guesswork in front of an auditor.

This is what operational resilience actually looks like: Data-driven, collaborative, and auditable.

What we learned

Yes, you can automate firewall rule reviews. But the real lesson? Once application teams see what’s running in their name, they care. There’s always a learning curve – not every application is perfectly modeled in LeanIX, and sometimes firewall configs are more myth than logic. But once visibility improves, so does ownership. And once the process runs regularly, it becomes just another control – not a crisis waiting to happen.

What’s next?

DORA isn’t just a regulation – it’s an opportunity to clean up old messes, align ownership, and make infrastructure reviews less painful and more powerful. If you’ve ever wondered what’s really hiding in your firewall rulebase – and who should care – now’s the time to find out. Curious what your rulebase looks like from an application point of view? We’d love to show you.

Let’s continue the conversation! But we're also curious:

• What challenges have you faced when trying to map firewall rules to applications?
• How do you handle outdated rules or zombie configs once they’re flagged?
• Do your app teams feel empowered – or overwhelmed – by ownership?
• How are you closing the loop between review and rule decommissioning?
• And how ready do you feel for a DORA audit, really?

We’d love to hear how others are tackling this – or to show you what this looks like in action.

>> Get in Touch with our Engineering Teams for a Lab Demo <<

We’re proud to develop this solution in close collaboration with NetworkedAssets - a Berlin‑ & Wrocław‑based software engineering firm recognized for their expertise in network automation, analytics and diagnostics. 
By combining our deep experience in connectivity, security and hybrid cloud architectures at Logicalis Connected with NetworkedAssets’ pragmatic, agile “software for complex systems” mindset, we’ve created a platform that doesn’t just tick boxes for compliance, but genuinely transforms how firewall rules are managed and owned.

Image