I got this story from one of our new onboard clients.
One of the IT team members called the IT Manager and Director at 2:30 in the morning.
Ransomware attacked, and it’s spreading across the server environment. The IT team had detected it eighteen minutes earlier. Two servers were already encrypted. Three more were showing signs.
IT Manager’s first question was not about containment. It was: “Where is our incident response plan?”
It took eleven minutes to find the document. It was saved in a shared folder on a server that was now encrypted.
When they finally opened it from a personal email backup, they found the following: the emergency contact tree had four phone numbers, two of which were disconnected. The CERT-In portal login credentials were written inside the plan document they had just spent eleven minutes locating. The person listed as the primary incident coordinator had resigned eight months earlier. The external cybersecurity vendor number in the plan was a general sales line that went to voicemail at 2:30 AM.
The plan existed. The capability did not.
The organisation had spent money on a firewall, renewed their antivirus licenses, commissioned a VAPT, and had the document audited by their compliance team. They had done everything that looked like incident preparedness. They had done almost nothing that actually was.
This is not an unusual situation in India. It is, based on my experience across dozens of conversations with IT heads, CISOs, and CTOs over the past three years, the standard situation.
Why India Has a Detection Problem Before It Has a Response Problem
Before discussing response, it is worth establishing where India sits on the detection side. Because you cannot respond to what you have not found.
India’s data breach detection time runs 20 to 30 days above the global average. The gap comes from limited XDR and MDR adoption in SMEs, lower penetration of advanced detection tooling outside large enterprises, and a smaller pool of certified incident responders relative to the attack surface being defended.
Ransomware median dwell time is five to six days overall. The attacker is inside your environment, mapping it, exfiltrating data, and positioning for encryption for nearly a week on average before you know they are there.
CERT-In handled 29.44 lakh cybersecurity incidents in 2025 alone. That is roughly 2.9 million events across Indian organisations, each of which required or should have required some form of incident response.
Across those millions of incidents, a consistent pattern repeats. The organisation discovers the problem. Someone escalates. There is a conversation about who is responsible. Someone looks for the incident response plan. The plan, if it exists, was written by a consultant two years ago and has not been reviewed since. The clock is running.
CERT-In gives you six hours from detection to notification for significant cyber incidents. That six-hour window does not pause while you locate the document.
The Plan Nobody Has Read
Most organisations that have an incident response plan have one of the following four things, none of which is an actual incident response capability.
- A consultant-authored document from a compliance exercise. Written to satisfy an audit requirement. Approved by the board. Filed in a shared drive. Never read by the people who would need to use it. The document describes a process. The people who work there have never been through it.
- A copy of a template from the internet, customised with company letterhead. The roles and responsibilities section lists positions rather than names. The contact tree has placeholder numbers. The containment steps are generic enough to apply to any incident at any organisation, which means they are specific enough for none.
- A plan written for a threat environment that no longer exists. Written in 2021 when the primary threat was email phishing and endpoint malware. The organisation has since moved to hybrid cloud, connected three SaaS platforms to their core systems, onboarded twelve new vendors, and deployed IoT devices on the factory floor. None of these appear in the plan.
- A plan that nobody in the current team was around to write. The IT head who commissioned it left. The vendor who wrote it is no longer engaged. The team that would use it in a crisis learned about its existence from the compliance checklist, not from participating in its creation.
The average cybersecurity maturity score for Indian organisations is 6.37 out of 10. Incident response is consistently identified as one of the most significant gaps, with organisations investing more heavily in prevention tools than in response capability.
The Five Things That Always Fail in an Untested Plan
These are not theoretical failure modes. They are what I have seen, repeatedly, when a real incident tests a plan that has only ever existed on paper.
- Contact trees with wrong numbers. Personnel change. Vendors change. External cybersecurity firm contacts change. A contact tree that was accurate when written becomes less accurate every month it is not reviewed. In the organisation I described above, two of four emergency numbers were disconnected. At 2:30 AM, those two numbers represented 45 minutes of wasted time.
- Credentials stored in the document itself. The CERT-In portal, the cloud console, the security monitoring tool, the external SOC ticketing system: all of these require login credentials during a crisis. Plans frequently store these credentials inside the document for convenience. If the incident involves encryption of the document’s storage location, the credentials are inaccessible at the moment they are most needed.
- Roles assigned to titles rather than people. An IR plan that says “the IT head escalates to the CISO” is useless if nobody has clarified who fills each role when the primary occupant is unavailable. Real incidents happen at 2:30 AM, on Diwali, during summer leave. The plan needs names, alternates, and personal contact numbers. It needs to work when the most senior person available is a junior analyst who just started three months ago.
- Steps that assume tools that are offline. Many IR plans include steps like “log into the SIEM and identify affected systems” or “check the endpoint management console.” If the incident has encrypted the infrastructure those tools run on, the steps are impossible. The plan needs offline alternatives for every tool-dependent step.
- No decision authority defined. Who has authority to isolate a server at 3 AM without waiting for the IT head to respond? Who can engage the external incident response vendor without a purchase order? Who calls the RBI supervisory team or the Data Protection Board if the IT head is unreachable? An untested plan rarely answers these questions. When they are not answered in advance, they get argued during a crisis, while the incident continues.
What the Law Has Already Decided About Your Response Timeline
The regulatory framework for incident response in India has become significantly more specific since 2022. The timelines are not aspirational. They are mandatory.
- CERT-In: 6 hours. From the moment of detection of a significant cyber incident, covered entities have six hours to report to CERT-In through the CIMS portal. This includes ransomware attacks, data breaches, and unauthorised access to sensitive systems. The report must include the type of incident, systems affected, initial impact assessment, and actions taken. Bajaj Auto met this requirement when ransomware was detected at 8 AM on June 23, 2026. They disclosed the same day.
- DPDP Act: prescribed timeline. For personal data breaches, the Data Protection Board must be notified within the prescribed period following confirmation of a breach. Affected individuals must also be notified. The obligation applies to personal data of customers and employees. A ransomware attack that encrypts systems holding customer or employee data is a personal data breach by definition.
- SEBI: 24 hours. Listed companies must disclose material cybersecurity incidents to stock exchanges within 24 hours. The materiality threshold includes incidents that affect critical systems, data, or operations. Bajaj Auto’s regulatory filing the day of the incident and the resulting 2% share price drop illustrated exactly what SEBI disclosure looks like in practice.
- RBI: 6 hours for banks and NBFCs, with additional reporting through the CIMS portal as specified in the IT Governance Master Directions we published in detail last week.
These timelines run from detection, not from investigation completion. An organisation that says “we need to finish the investigation before we can report” is already non-compliant with at least the CERT-In timeline. The notification requirements are triggered by detection of a suspected incident, not confirmation of its full scope.
The Difference Between a Plan and a Capability
This is the distinction that separates organisations that respond effectively from those that fumble.
A plan is a document. It describes what should happen. It lists who does what. It specifies how each step is carried out. A plan has value. Having no plan is worse than having a plan.
A capability is what happens when the people who need to act have practiced acting under conditions that approximate a real incident. A capability is built through repetition, simulation, and deliberate review of what went wrong.
When you have to guess who has authority to isolate a server while an attacker moves laterally inside your network, your response will be hampered by indecision and procedural delays. Time is the enemy during a breach.
The organisations that responded best to incidents this year, and Bajaj Auto’s same-day disclosure is one example, did not succeed because they had better plan documents. They succeeded because the team had practiced the process often enough that the decisions were automatic, the contacts were known, and the authority was clear.
Five Exercises Every Indian Organisation Must Run Before the Next Incident
These are the specific exercises that build capability from a document. Run them in this order over six months.
- Exercise 1: The Document Accessibility Test
Without advance notice, ask someone on the IT team to retrieve the incident response plan and the CERT-In portal login credentials within ten minutes. Time them. If they cannot do it, the plan fails the most basic test. Fix the access and storage before anything else.
- Exercise 2: The Contact Verification Run
Call every number in the emergency contact tree. Send a test message to every email address. Confirm that every external vendor contact is still active and reaches someone with actual authority. Do this quarterly, not annually.
- Exercise 3: The Tabletop Exercise
Gather the IT team, the compliance officer, a senior business representative, and ideally a board member or CFO for a 90-minute scenario walkthrough. Present a realistic incident scenario: ransomware detected at 9 PM on a Friday. Walk through every decision. Who is notified first? Who authorises isolation of affected systems? Who contacts CERT-In? Who drafts the SEBI disclosure? Who calls the external IR vendor? Do not resolve ambiguities during the exercise. Document them and resolve them afterward, then update the plan.
Run this tabletop exercise at minimum twice a year. For NBFCs and banks, the RBI IT Governance Master Directions effectively require it.
- Exercise 4: The Isolated Recovery Test
Test whether your organisation can restore critical systems from backup without using any of the infrastructure that might be compromised during a real incident. This means offline backups, an isolated recovery environment, and a documented restoration process that does not depend on the systems that might be encrypted. Organisations need to validate whether recovery can be executed effectively under pressure, not just whether backups exist.
- Exercise 5: The Regulatory Notification Drill
Practice the actual process of notifying CERT-In through the CIMS portal, drafting a DPDP breach notification, and preparing a SEBI disclosure. Do it once with real logins and real templates, without the pressure of an actual incident. Find out how long it actually takes. Find out what information is required that you do not have readily available. Fix the gaps before the six-hour clock is running.
The First Six Hours — What Actually Needs to Happen
This is a practical reference for the specific actions that must occur in sequence during the first six hours of a confirmed cyber incident. It is not a complete IR playbook. It is the minimum viable response that covers the mandatory regulatory requirements while containing the incident.
- Minutes 0 to 15: Confirm and escalate
Confirm the incident is real and not a false positive. Activate the IR team via offline communication, meaning phone calls, not company email if email may be compromised. Notify the IT head, CISO, and whoever in senior management is designated as the incident authority. Do not post about the incident on internal messaging platforms until you know the scope of compromise.
- Minutes 15 to 45: Contain without destroying evidence
Isolate affected systems from the network to stop lateral movement and exfiltration. This is where EasyNAC provides a specific capability: real-time visibility into every connected device means the IT team knows immediately which devices are affected and which are clean, rather than guessing. Isolation decisions made on partial information can both miss compromised devices and unnecessarily take down clean systems that operations depend on.
Do not wipe or reimage affected systems yet. Forensic preservation matters. Wiping removes the evidence needed to determine how the attacker got in, what they accessed, and how to prevent recurrence.
- Minutes 45 to 90: Assess and document
Identify which systems are affected and which data categories they hold. This determines whether CERT-In, DPDP, RBI, or SEBI notification is required, and on what timeline. A ransomware attack on a server holding customer PAN data is a different regulatory event from a ransomware attack on a development environment with no personal data.
- Minutes 90 to 180: Engage external support
If the organisation does not have internal incident response capability for the specific incident type, engage the external IR vendor now, not after the initial chaos has resolved. External IR teams are most useful when brought in early. They are significantly less useful when brought in after internal actions have contaminated the forensic environment.
- Minutes 180 to 360: Notify CERT-In
Submit the incident notification through the CIMS portal before the six-hour window closes. The notification requires: incident type, affected systems, approximate impact assessment, and initial containment actions taken. It does not require the complete investigation. File what you know. Update as more is confirmed.
Why Detection Speed Determines Everything Else
All of this, the plan, the exercises, the six-hour window, the regulatory notifications, depends on one prior capability: knowing that something is happening before it becomes a disaster.
India’s data breach detection time runs 20 to 30 days above the global average. Ransomware median dwell time is five to six days. The gap between those two numbers is the window during which the attacker has already established persistence, mapped the environment, exfiltrated data, and positioned for maximum damage. The better your detection, the less damage you are containing.
Detection at the network level is the layer most often missing in Indian organisations. Endpoint protection tools cover devices with agents. SIEM systems correlate logs from known sources. But a device that connects to the network without an agent, a vendor laptop, a personal device, an IoT sensor, generates no endpoint signal and may not appear in any log source the SIEM watches.
EasyNAC addresses the detection gap at the network layer. By identifying every device on the network in real time, including unmanaged and unknown devices, it gives the IR team an accurate picture of what is connected at the moment of incident declaration. Without that picture, isolation decisions are guesswork.
What Bajaj Got Right and What Most Indian Companies Will Not
When ransomware was detected at 8 AM on June 23, 2026, Bajaj Auto’s response was fast, professional, and compliant. Detection at 8 AM. CERT-In notified. SEBI disclosure filed the same business day. External experts engaged immediately.
Bajaj Auto is a large, well-resourced organisation with a security team that had practiced this scenario. The speed of their response was not accidental. It was the result of having a team that knew what to do without spending forty-five minutes finding the plan document.
Check Point recorded 3,195 attacks a week per Indian organisation in 2025. CERT-In handled 2.9 million incidents that year. Most of those organisations did not have Bajaj Auto’s resources. Most of them did not respond as well. Most of them spent the critical first hours in confusion about who was in charge, what the regulatory requirements were, and where the recovery backups were stored.
The difference between Bajaj’s response and the 2:30 AM call I described at the start of this blog is not budget. It is preparation. And preparation is a decision that can be made before the incident, not during it.
Building IR Capability Into the Organisation, Not Just the Document
The practical path from where most Indian organisations are today to where they need to be is not another policy document. It is a structured programme that runs alongside the organisation’s normal operations.
Assign ownership. The IR plan should have a named owner, not a job title, who is responsible for keeping it current and for ensuring exercises are run on schedule.
Build offline access into the design. Every critical credential, every emergency contact, every external vendor number should exist in a printed document kept physically offsite and in a password-protected file stored outside the corporate network. When the network is down is not the time to discover that all your recovery instructions are on the network.
Integrate IR readiness into the annual audit cycle. IR plan review, contact verification, and at minimum one tabletop exercise should be standard items on the annual IT governance calendar. For NBFCs and banks, the RBI IT Governance Master Directions require this as part of the cybersecurity framework.
Brief senior management and the board once a year on the IR plan. Board members should know what the regulatory reporting obligations are before they are activated. A board that hears about CERT-In’s six-hour requirement for the first time during an active incident is a board that cannot make good decisions quickly. FacctorX gives leadership the real-time visibility into IT risk and incident status that allows informed decisions during a live incident rather than hourly phone calls from the CISO.
Test the external vendor relationship before you need it. The external IR firm’s weekend contact should be a number that has been called before. The engagement terms should be clear. The scope of authority, what they can do and what requires approval, should be documented in the retainer before the 2:30 AM call, not negotiated during it.
Final Thought
The client who called me at 2:30 AM contained the ransomware. It took longer than it should have. The six-hour CERT-In window came and went during the hunt for the plan document and the argument about who had authority to isolate the affected servers. The regulatory notification was late.
They are working on their IR capability now. Not their plan document. Their capability.
The exercises are scheduled. The contact tree has been verified. The CIMS portal credentials are stored offline and in a physical document in the IT head’s safe at home. The external IR vendor has been briefed on the environment. The tabletop exercise ran last month, and three gaps were found and fixed before a real incident could expose them.
Basic cybersecurity prevention, including a tested incident response plan, costs between $5,000 and $15,000 per year for a small or mid-sized business. The average breach cost for companies under 500 employees is $3.31 million. Downtime alone costs approximately $53,000 per hour.
The arithmetic is clear. The question is only whether the organisation makes the investment before the 2:30 AM call or after it.
Almost every organisation that calls us during an incident wishes they had called us a year earlier.
At Skeletos IT Services, we help Indian organisations build incident response capability through IR plan development, tabletop exercises, CERT-In notification readiness, and ongoing managed security monitoring. EasyNAC provides the real-time network visibility that is the foundation of effective incident detection and containment. If you want to test whether your current IR plan would hold up in a real incident before you find out under pressure, we can help you find out.
