Ashish Bali
Country Manager India, FireMon
India’s enterprise technology sector has expanded at a pace that few markets can match. In banking and financial services, digital infrastructure that took other markets decades to build has been assembled in years – payment rails processing billions of transactions monthly, cloud environments layered onto legacy core banking systems, new digital services extended to hundreds of millions of customers.
When you build that quickly, firewall rules rarely keep up. Access gets opened to support a new service and never closed. Exceptions get granted to keep a project moving and become permanent. Boundaries that made sense at design time get redrawn by operational pressure. For large organisations, including the Global Capability Centres now running significant security operations for global enterprises from Indian soil, the result is a divergence between access as it exists and access as it was intended.
The pattern shows up reliably in firewall audits. FireMon’s benchmarking work shows that across large enterprise estates, close to 60% of firewalls fail at least one high-severity check. In environments that have expanded rapidly, that figure rarely surprises anyone. That it no longer surprises is precisely the problem.
Nothing in day-to-day operations flags this. Indicators look stable, services run, and nothing breaks in a way that demands attention. Rules stay open and access stays excessive. And it accumulates that way until an audit makes it visible.
The failure mode nobody plans for
It is tempting to call these findings misconfigurations. That label implies a discrete mistake, something identifiable, correctable, closed. What audits actually uncover is different. The rules that fail high-severity checks are rarely the result of careless work. They are the residue of reasonable decisions – access granted because a project needed it, an exception created because something urgent could not wait, a rule that made sense in context and has simply never been revisited.
Over time, policy stops reflecting decisions and starts reflecting history. The rule-base accumulates. Shadowed rules sit beneath active ones, creating the appearance of control while leaving effective access unchanged. Segmentation that looked defensible on paper does not hold under real traffic patterns.
The result is a policy surface – every rule, exception, and inherited access decision across the estate – that no longer reflects deliberate decisions. This, as reflected in audit findings, is not an outcome anyone ever plans for. In almost every case, it happens because the environment kept changing and the governance around it did not keep up.
Compliance evidence is not the same as governance
Most large enterprises are responding to a significantly tightened regulatory environment. CERT-In requires organisations to retain ICT logs, including firewall logs, for 180 days and to report qualifying incidents within six hours of detection, one of the strictest windows anywhere in the world. SEBI’s Cybersecurity and Cyber Resilience Framework requires documented access policies, network segmentation controls, and mandatory audit submissions. The RBI places equivalent obligations on banks and NBFCs around continuous monitoring and independent audit.
That investment in compliance tooling is necessary. But log retention and audit reporting answer a different question to the one that produces recurring firewall failures. Retaining firewall logs tells a regulator what happened. It does not tell you whether your policy reflects what you actually intended to permit. Similarly, a SIEM captures events; it does not govern the rules that determine what those events mean.
Recurring high-severity audit findings are rarely a failure of logging. They are a failure of policy management. The organisation was capturing evidence of a problem it had not diagnosed. Security teams can usually describe architectural intent – where boundaries should sit, which flows should not exist. What they cannot consistently show is that enforced policy reflects that intent today, across data centres, cloud environments, and the legacy infrastructure running core operations. When regulators examine that gap, the audit does not create the problem. It simply makes it visible.
Policy stops being a control when it loses its meaning
A firewall rule-base can be technically operational and still not express a coherent access model. When it reflects years of exceptions and inherited decisions rather than current intent, teams lose confidence in their ability to test the impact of changes. Change control becomes conservative because nobody can reliably say what a given change will affect. The firewall becomes something that must not be disturbed.
From there, the deterioration is predictable. Rationalisation gets deferred and access widens because tightening it feels riskier than leaving it alone. Audits become reconstruction exercises – explaining after the fact what findings mean – rather than evidence of a security posture that is understood and in control.
A periodic review can describe that state. It cannot fix it, because the problem is produced every day by ordinary operational change.
What continuous oversight actually looks like
Network Security Policy Management addresses this by connecting intent, enforced policy, and observed dependencies in a single, continuously updated view. Used as an operational discipline rather than a reporting layer, it gives teams the means to see where access has expanded beyond what is justified, where segmentation has softened, and where exceptions have become the default. Crucially, it also allows teams to test changes before deployment, rather than discover their impact afterwards.
What security teams need is a current, accurate picture of what their policy actually permits – not the intended state, but the enforced one – across firewalls, cloud controls, and the on-premise infrastructure that continues to run core operations. When a change is proposed, it can be tested before deployment – what it will affect, whether it complies, whether it stays within the intended access model. When drift occurs – and in any active environment, it will – it is surfaced before it becomes a finding rather than after.
Our tech, for example, maintains the audit evidence trail that regulators ask for – what policy was in place at any point, what changed, and whether those changes remained aligned to stated business intent. That is the difference between compliance as a reporting exercise and compliance as a reflection of how the environment is actually run.
That capability matters directly for the compliance posture that CERT-In and SEBI CSCRF now require. The six-hour incident reporting window requires knowing what changed, when it changed, and whether that change introduced risk. Without continuous policy visibility, answering that question means going back through logs after the fact – reconstructing what the policy state was at the moment an incident occurred. By continuously tracking policy state, teams are better positioned to understand what changed, when it changed, and whether it introduced risk.
The question audits can’t answer for you
A high-severity finding in an audit report is easy to treat as a defect to close. The more useful interpretation is that it is a signal – the organisation cannot currently explain, with confidence, how enforced policy reflects intent across its estate.
For organisations managing hybrid environments spanning legacy infrastructure and cloud, carrying both domestic and global regulatory obligations, that gap does not close by running a better audit. It closes when policy governance becomes continuous rather than periodic.
