Incident Response: The First 24 Hours

Hour 0–1: Confirm and contain

• Assign an incident lead. One person coordinates; everyone else reports to them.
• Open a log. Record every action with time and name — a shared document is fine.
• Contain without destroying evidence. Isolate affected machines from the network (unplug or disable Wi-Fi) rather than wiping or rebooting them.
• Reset exposed credentials, starting with admin accounts and anything with remote access.

Hour 1–4: Understand

• What systems and data are affected? Who are the users?
• How did it start — phishing, exposed service, stolen password, vendor?
• Is it still happening? Look for new accounts, scheduled tasks, unusual outbound traffic.
• Preserve logs: export authentication, firewall and application logs before they roll over.

Hour 4–12: Communicate

• Inform management with facts, not guesses: what you know, what you don't, what you are doing.
• If personal data may be affected, note the time of discovery — notification obligations (for example under India's DPDP Act and CERT-In directions) are time-bound.
• Prepare a short holding statement for staff and students if services are down.

Hour 12–24: Recover safely

• Rebuild from known-good images or backups; do not just "clean" a compromised machine.
• Re-enable services in order of importance, watching logs as each comes back.
• Keep the incident lead and log running until you are confident the attacker has no access.

What not to do

• Do not pay a ransom before taking advice.
• Do not communicate with the attacker from an affected account.
• Do not delete anything that could be evidence.

Afterwards

Hold a blameless review within two weeks: timeline, root cause, what worked, what to change. Turn the actions into tracked tasks with owners and dates.