When a major incident hits, the immediate focus is on restoration: getting systems back online, containing the impact, notifying regulators, and demonstrating that the organisation is back in control. What follows in the days and weeks afterwards – the post-incident review – is where deeper resilience is put to the test.
Most large organisations have well-documented incident response processes. They have to. Reporting clocks are short, and regulators expect detail. In the wake of a breach, reviews get conducted, root causes filed, remediation plans tracked.
Yet according to IBM’s Cost of a Data Breach Report, the average cost of a data breach in India rose to INR 220 million in 2025, representing a 13% increase on the previous year. And while the mean time to identify and contain a breach reached a record low of 263 days, we’re still talking about organisations taking nearly nine months on average to notice something is wrong and make amends. This tells us that while the discipline is in place, the capability it is supposed to produce is not catching up at the same rate
Closing the gap means treating reviews not as an exercise in producing evidence for the auditor but as the mechanism by which the next incident might be detected earlier and contained more quickly. The five practices below will help.
1. Treat incident reviews as visibility audits
Every post-incident review should begin with this question: what didn’t we see in time?
Most disruptions trace back not to absence of action but to absence of visibility. A misconfigured rule, a forgotten exception, a dependency no one had documented. Artefacts like these can sit unnoticed for months until a bad actor brings them to light.
Reviews filed with regulators tend to just reconstruct the sequence of events, while reviews that actually strengthen resilience interrogate why the organisation didn’t see them coming in the first place. These are not the same exercise. Only the second one can prevent the next incident.
Closing the visibility gap requires a continuously maintained view of the rules, exceptions and access decisions that determine what the network is doing day to day. Policy is where security gets enforced, and policy is where it tends to drift. Without persistent visibility into that layer, “lessons learned” is just another phrase in a report, rather than a control the next reviewer can verify.
2. Replace reactive heroics with controlled change
In the heat of an incident, urgency overrides procedure. Temporary rules get added, emergency access is granted, approval steps are bypassed. After the event, those changes often remain in place – invisible until they crop up in the next audit or regulator query.
The pattern compounds itself in heavily regulated environments. Teams move from incident response into disclosure preparation, with little operational space to reconcile what changed in the emergency. Controls intended to be temporary become the baseline, and the rationale for each change is lost.
True resilience tightens control rather than relaxing it. Every change needs traceability and every exception an expiry. More than that, every change should be tested against intent before it goes live: not “did this change break something?” but “does this change still reflect what we meant the policy to do?” Validating intent before deployment is what stops emergency rules from becoming permanent ones, and what produces a credible audit trail when CERT-In, RBI or DPDP-aligned reviewers ask what was done and on whose authority.
3. Let real-time data decide what stays and what goes
After a disruption, teams typically move into cleanup mode: decommissioning emergency fixes, restoring baselines, reviewing firewall rules. In many organisations, this work is driven by instinct rather than evidence. Which changes are genuinely risky, and which are simply unfamiliar?
These decisions are better made with real-time traffic data and rule-usage analytics – evidence of which policies were actually exercised during the incident and which are creating exposure without serving any business need. Evidence-based reduction prevents well-intentioned rollback from breaking critical services and removes the clutter that tends to conceal genuine vulnerabilities.
There is a regulatory dimension to this as well. Reviewers increasingly ask not whether a control exists, but whether it is justified. Rule-usage evidence turns “we cleaned up after the incident” into “we can demonstrate which rules were exercised and why each remaining one is still in place.” One is operational hygiene. The other is provability, and audits in this environment increasingly demand it.
4. Pull third-party exposure into the review, not around it
Most post-incident reviews stop at the boundary of the organisation’s own estate. Vendor systems, partner integrations and outsourced infrastructure sit in a separate column, treated as someone else’s problem until forced into scope by a contract clause or a regulator question.
That separation is increasingly untenable. A meaningful share of recent breaches in regulated sectors trace back to a third party, and the regulatory position has tightened in response. RBI has reinforced that a vendor’s failure remains the regulated entity’s liability, and CERT-In’s reporting obligations apply regardless of which side of the contractual line the breach originated on.
Post-incident reviews need to treat the third-party perimeter as in-scope by default – understanding which vendors had access during the incident window, what that access permitted, and what the vendor’s own evidence trail can substantiate.
The harder, but even more important, version of this work is preventative. Vendor access paths should be evaluated continuously, not after an incident has already exercised them.
5. Embed lessons learned into systems, not slide decks
Every post-incident review produces useful insight. Too often, that insight lives in a debrief slide or a remediation tracker that loses momentum once immediate disclosure obligations are met. Three months later, the same incident plays out again, all because the lesson never made it into production logic.
The audit cycle deserves part of the blame. The artefact that satisfies the regulator is naturally where attention is diverted, but that artefact is backwards-looking. The control change in production is forward-looking, and it’s this which can prevent the next incident.
Resilient organisations capture what they learn and apply it as policy, replacing manual fixes with rules and constraints that prevent the same weakness from reappearing. Over time, those small corrections compound into fewer surprises and shorter recoveries.
A culture of evidence
The clearest measure of whether post-incident work is producing real capability is not the quality of the report filed afterwards. It is the distance between detection and containment in the next incident. Closing that distance is what the documented discipline exists to deliver. When it does not, the discipline has become an end in itself rather than a means of preventing the next incident.
What closes it, in practice, is the ability to see the policy environment as it actually behaves and validate every change against the intent behind it. Each well-handled incident should make the next one easier to contain. Resilience, in this view, is not measured by the absence of disruption or by the polish of the report that follows it. It is measured by how much faster the organisation moves from detection to containment next time, and by how much of that improvement can be evidenced when asked. That resilience is sustained only by governing policy continuously and coherently across the whole hybrid environment, so that intent, once validated, is stable even as the environment around it changes.
–Authored by Ashish Bali, Country Manager India, FireMon
