Incident Response Planning: Building Your First Playbook

Most organizations do not discover the gaps in their incident response plan during a planning meeting. They discover them at 3 AM during an active breach, when the CISO is asking who to call, the IT team is debating whether to pull the network cable, and nobody knows who is supposed to talk to the press.

An incident response (IR) playbook eliminates that chaos. It is not a theoretical document gathering dust in a SharePoint folder -- it is an operational manual that your team reaches for when things go wrong. And like any operational manual, it only works if it is specific, tested, and maintained.

This guide walks you through building your first IR playbook from the ground up. We have kept it practical -- no frameworks for the sake of frameworks, just the elements that matter when an incident is unfolding.

Who Is This For?

This guide targets organizations that have little to no formal incident response capability. Maybe you have an IT team that handles security incidents ad hoc, or you have a written IR policy that nobody has ever practiced. If your organization has a mature SOC with established runbooks, you are past this stage -- but a review against these fundamentals never hurts.

Step 1: Define Your Incident Response Team

Before you write a single procedure, define who does what. An IR team needs clear roles with named individuals and backups.

Incident Commander (IC)

The IC owns the incident from declaration to closure. They coordinate resources, make containment decisions, manage communication, and ensure the response stays organized. This is typically the CISO, IT Director, or a senior security engineer.

The IC does not need to be the most technical person in the room. They need to be the most organized, the best communicator, and the person with authority to make decisions under pressure.

Technical Lead

The most senior technical responder. They direct the investigation, analyze evidence, and recommend containment and remediation actions. The IC decides; the Technical Lead advises.

Communications Lead

Manages all internal and external communication during the incident. This includes employee notifications, customer communication, regulatory notifications (CERT-In, DPDPA), and media statements. This is often someone from corporate communications or legal, not the security team.

Scribe / Documentarian

Records everything: decisions made, actions taken, timestamps, evidence collected, communications sent. This role is critical for post-incident review and regulatory compliance. During a fast-moving incident, if nobody is documenting, key details are lost.

Subject Matter Experts

Network engineers, system administrators, application owners, database administrators -- whoever has deep knowledge of the affected systems. They join the response when their expertise is needed and leave when it is not.

External Resources

Pre-identify external resources and have contact information and engagement procedures ready:

• Incident response firm (retainer in place)
• Cyber insurance carrier (policy number and claims process documented)
• Legal counsel (both internal and external, experienced in cyber incidents)
• Law enforcement contacts (CERT-In, local cybercrime cell)
• PR firm (if you do not have in-house communications capability)

Step 2: Establish Classification and Severity Levels

Not every security event is an incident, and not every incident requires the full IR team. Define clear classification criteria so your team knows when to escalate and how aggressively to respond.

Security Event vs. Incident

A security event is any observable occurrence related to security (a failed login, a firewall block, a malware detection by antivirus). Most events are routine.

An incident is a security event that actually compromises (or threatens to compromise) the confidentiality, integrity, or availability of your systems or data.

Severity Levels

Define three to four severity levels. Here is a model that works for most organizations:

Critical (Severity 1)

Active, confirmed compromise of critical systems. Indicators include: ransomware deployment, confirmed data exfiltration, domain controller compromise, active attacker on the network, compromise of customer-facing production systems.

Response: Full IR team activation, all-hands effort, executive notification, potential CERT-In notification.

High (Severity 2)

Confirmed security incident with significant potential impact, but the full scope is not yet clear. Indicators include: malware detected on multiple systems, unauthorized access to a server, targeted phishing campaign with confirmed credential theft, vulnerability exploitation detected.

Response: IR team activation, investigation to determine scope, executive awareness.

Medium (Severity 3)

Security incident contained to a limited scope with manageable impact. Indicators include: malware on a single workstation (contained by EDR), single account compromise (password changed, no evidence of further access), unauthorized access attempt blocked by controls.

Response: SOC / security team handles, no full IR team activation, documented and tracked.

Low (Severity 4)

Security event requiring investigation but unlikely to represent a significant threat. Indicators include: policy violation (unauthorized software installation), suspicious email reported by user (not clicked), vulnerability scan detection without exploitation evidence.

Response: SOC triage and investigation, tracked in ticketing system.

Step 3: Build Your Response Procedures

For each severity level, define the specific procedures. Use the NIST framework phases: Preparation, Detection & Analysis, Containment, Eradication, Recovery, Post-Incident Activity.

Detection and Initial Triage (First 30 Minutes)

When a potential incident is detected, the first responder should:

• Confirm the alert is not a false positive (check logs, correlate with other data sources)
• Classify the severity using the criteria above
• Notify the Incident Commander if Severity 1 or 2
• Begin documenting: what was detected, when, on which systems, by which detection method

Incident Declaration

The IC declares the incident and activates the response team:

• Send activation notification via out-of-band channel (not corporate email -- it may be compromised)
• Open a dedicated communication channel (Slack channel, Teams group, or conference bridge)
• Assign roles (Technical Lead, Communications Lead, Scribe)
• Set an initial check-in cadence (every 30 minutes for Severity 1, every hour for Severity 2)

Containment

Containment stops the bleeding. The goal is to limit the blast radius without destroying evidence. Containment decisions involve tradeoffs between business disruption and security risk -- the IC makes these calls.

Short-term containment (immediate actions):

• Isolate affected systems from the network (do not power off -- preserve memory forensics)
• Block known malicious IPs, domains, and hashes at firewalls and proxies
• Disable compromised user accounts
• Revoke compromised API keys and certificates
• If Active Directory is compromised: reset KRBTGT twice, disable compromised admin accounts

Long-term containment (bridge to recovery):

• Set up clean systems or network segments for business continuity
• Implement additional monitoring on contained and adjacent systems
• Patch the exploited vulnerability if identified

Eradication

Remove the threat from the environment completely:

• Identify and remove all malware, backdoors, and persistence mechanisms
• Reset credentials for all affected and potentially affected accounts
• Patch the vulnerability that allowed initial access
• Scan the environment for indicators of compromise associated with the threat

Recovery

Restore systems to normal operation:

• Rebuild compromised systems from clean images (do not just clean them)
• Restore data from verified clean backups
• Bring systems back online in priority order
• Monitor recovered systems closely for 48-72 hours for signs of reinfection
• Validate that business operations are functioning normally

Post-Incident Activity

Within two weeks of incident closure:

• Conduct an after-action review with all participants
• Document the incident timeline, root cause, impact, and response actions
• Identify what worked and what needs improvement
• Update the playbook based on lessons learned
• Track remediation actions to completion

Step 4: Communication Templates

During an incident, nobody has time to draft communications from scratch. Prepare templates in advance.

Internal Notification Template

Prepare a template for notifying employees about an incident. Include what happened (at an appropriate level of detail), what employees should do (change passwords, report suspicious activity), and what they should not do (speculate on social media, contact the press). Designate a point of contact for questions.

CERT-In Notification Template

Under CERT-In directives, certain incidents must be reported within 6 hours. Prepare a template that covers the incident type, affected systems, date and time of detection, initial assessment, and containment actions taken. Have the CERT-In reporting portal bookmarked and credentials accessible.

Customer / Partner Notification Template

If customer data is affected, prepare a notification template. Under DPDPA, you must notify affected Data Principals. This template should explain what happened, what data was affected, what you are doing about it, and what the customer should do (change passwords, monitor accounts).

Executive Briefing Template

CXOs need concise, business-focused updates: What is the business impact? What is the financial exposure? What is the expected recovery timeline? What decisions do you need from them? Avoid technical jargon.

Step 5: Test Your Playbook

A playbook that has never been tested is a wishful thinking document. Test it through tabletop exercises.

Tabletop Exercise Format

A tabletop exercise walks the IR team through a simulated incident scenario without touching real systems. A facilitator presents the scenario in stages, and the team discusses their response at each stage.

Example scenario flow:

• Stage 1: "The SOC receives an alert that a workstation in the finance department is communicating with a known command-and-control server." What do you do?
• Stage 2: "Investigation reveals that three additional workstations in the same department are also compromised. The malware appears to be exfiltrating files from a shared drive." What do you do?
• Stage 3: "The attacker has moved laterally to a domain controller. EDR shows Mimikatz execution 2 hours ago." What do you do?
• Stage 4: "A ransom note appears on 50 workstations across three departments." What do you do?

What to Evaluate

During the exercise, assess:

• Did the team follow the playbook? If not, why?
• Were role assignments clear? Did anyone struggle with their responsibilities?
• Were communication channels functional? Did information flow to the right people?
• Were containment decisions made quickly and decisively?
• Were regulatory notification requirements addressed?
• Were there gaps in the playbook that the scenario exposed?

Frequency

Conduct tabletop exercises at minimum twice a year. Vary the scenarios to cover different incident types: ransomware, data breach, insider threat, supply chain compromise, DDoS.

Maintaining the Playbook

An IR playbook is a living document. Update it when:

• Contact information changes (people leave, phone numbers change)
• Technology changes (new SIEM, new EDR, new cloud services)
• Lessons are learned from real incidents or tabletop exercises
• Regulatory requirements change (new CERT-In directives, DPDPA updates)
• Organizational structure changes (new CISO, team restructuring)

Review the playbook in full every six months, even if no specific changes are needed. Confirm that all contact information is current, all procedures reflect your current environment, and all team members know where to find the playbook when they need it.

Start Simple, Iterate

Your first playbook does not need to be comprehensive. Start with the essentials: who to call, how to classify, how to contain, and how to communicate. Then iterate based on exercises and real incidents.

The organization with a simple, tested playbook will outperform the organization with a complex, untested one every time.

At Zindagi Technologies, our incident response team helps organizations build IR playbooks, conducts tabletop exercises, and provides hands-on IR support during active incidents. Whether you are building your first playbook or stress-testing your existing one, we are here to help.