NexusSec.In an incident, people lose time looking for phone numbers, switch off the wrong things, wipe evidence or make expensive decisions in a panic. A short written plan prevents most of that.
1. Roles
- An incident lead and a deputy, who decide what happens next.
- Who can approve spending, such as bringing in outside responders, and who can authorise shutting systems down.
- Who speaks to staff, customers and, if needed, the press.
2. Contacts, kept offline
Keep a printed list and a copy outside your network: your IT team or provider, your security provider, your cyber insurer with the policy number, your bank's fraud line, a lawyer, your internet provider and key software vendors. Many cyber insurance policies require prompt notice, and some require you to use their approved responders, so check yours. See what insurers ask for.
3. What counts as an incident
Write down examples so staff know when to raise the alarm: a suspicious login, a mailbox sending mail nobody wrote, files that will not open, a ransom note, a lost laptop, a request to change bank details, or a customer reporting strange mail from you.
4. First steps for common incidents
- Compromised mailbox: reset the password, sign the account out everywhere, check forwarding and inbox rules, confirm MFA, and warn contacts if mail was sent. See the first hour after a phishing click.
- Ransomware: disconnect affected machines from the network, do not wipe or rebuild them yet, protect your backups, and call your security provider and insurer before deciding anything else. See backups that survive ransomware.
- Lost or stolen laptop: wipe or lock it remotely if you can, and reset the passwords that were used on it.
- Payment fraud: call your bank immediately to try to stop or recall the payment, and report it on the national cybercrime helpline 1930 or at cybercrime.gov.in. See invoice fraud and changed bank details.
5. Reporting
- CERT-In: under its directions of April 2022, organisations in India must report specified types of cyber incident to CERT-In within six hours of noticing them. Note in the plan who files the report and how.
- Sector regulators: regulated businesses may have their own reporting timelines.
- Personal data: if personal data is involved, check your duties under the DPDP Act; see our DPDP Act guide.
- Customers: some contracts require you to tell customers within a set time.
6. Evidence
Keep logs, do not rebuild machines before evidence is collected, and keep a simple timeline of what was noticed, when, and what was done. The CERT-In directions also require logs to be kept for 180 days; see CERT-In log retention.
7. Recovery and lessons learned
Restore from known-good backups, change the credentials involved, watch closely for the attacker returning, and hold a short review afterwards: what happened, what worked, and what to change.
Test it once a year
Run a one-hour tabletop exercise: walk the people named in the plan through a scenario, such as "the finance mailbox is sending invoices we did not write", and see where the plan is unclear. Our managed security service covers incident response and response playbooks.
