Incident Response Plan Template for Indian Companies (CERT-In Compliant)
On April 28, 2022, CERT-In issued directions mandating all organizations report cybersecurity incidents within 6 hours of detection. Not 6 business days. Not 6 working hours. Six clock hours. The DPDP Act adds another mandate: notify the Data Protection Board within 72 hours of a personal data breach.
Most Indian companies I've spoken to have no formal incident response plan. They think "we'll figure it out when it happens." That's like not having a fire escape plan because you've never had a fire.
This article provides a complete, ready-to-use incident response plan template that meets both CERT-In and DPDP Act requirements. Copy it, customize it, and hopefully never need it.
- 6 hours — CERT-In mandatory incident reporting timeline
- 72 hours — DPDP Act breach notification to Data Protection Board
- 280 days — average time to identify and contain a breach in India (IBM 2025)
- 73% of Indian companies have no formal incident response plan
- ₹1.27 crore — cost savings from having an IR plan vs. not having one (per incident)
CERT-In Reportable Incidents
CERT-In requires reporting of these incident types within 6 hours:
| Incident Type | Examples | Priority |
|---|---|---|
| Targeted scanning/probing | Port scans against critical systems | P3 |
| Compromise of critical systems | Server takeover, admin access breach | P1 |
| Unauthorized access to data | Database breach, file exfiltration | P1 |
| Website defacement | Homepage modified by attacker | P2 |
| Malware deployment | Ransomware, cryptominer, trojan | P1 |
| Identity theft/phishing | Spoofed emails, fake domains | P2 |
| DDoS attacks | Service disruption from traffic flood | P2 |
| Attacks on critical infrastructure | Power, telecom, banking systems | P1 |
| Data breaches affecting citizens | Any PII/financial data leak | P1 |
| Attacks on cloud infrastructure | AWS/Azure/GCP compromise | P1 |
WARNING
Many Indian companies don't realize that even a targeted port scan against critical systems is a CERT-In reportable incident. The threshold for reporting is much lower than most businesses assume.
The Incident Response Lifecycle
flowchart LR
A[1. Preparation] --> B[2. Detection]
B --> C[3. Containment]
C --> D[4. Eradication]
D --> E[5. Recovery]
E --> F[6. Post-Incident]
F --> A
style A fill:#3b82f6,color:#fff
style B fill:#eab308,color:#000
style C fill:#ef4444,color:#fff
style D fill:#f97316,color:#fff
style E fill:#22c55e,color:#fff
style F fill:#8b5cf6,color:#fffPhase 1: Preparation (Before Any Incident)
1.1 Incident Response Team (IRT)
| Role | Primary | Backup | Contact |
|---|---|---|---|
| Incident Commander | CTO/CISO | VP Engineering | +91-XXXXXXXXXX |
| Technical Lead | Senior DevOps | Senior Backend | +91-XXXXXXXXXX |
| Communications Lead | Head of Marketing | CEO | +91-XXXXXXXXXX |
| Legal Advisor | General Counsel | External Law Firm | +91-XXXXXXXXXX |
| CERT-In Liaison | CISO | CTO | +91-XXXXXXXXXX |
| DPO (DPDP) | Data Protection Officer | Legal | +91-XXXXXXXXXX |
1.2 Communication Channels
bash
# Primary: Dedicated Slack/Teams channel (#incident-response)
# Secondary: WhatsApp group (Incident Response Team)
# Tertiary: Phone tree (in order of IRT table above)
# External: incident-report@cert-in.org.in
# CERT-In reporting portal: https://www.cert-in.org.in/
# CERT-In helpdesk: 1800-11-4949 (toll-free)
# CERT-In email: incident@cert-in.org.in1.3 Tool Kit
Prepare these tools in advance (don't scramble during an incident):
| Tool | Purpose | Access |
|---|---|---|
| AWS CloudTrail | Audit log analysis | IAM role: IR-Analyst |
| CloudWatch Logs | Application log analysis | IAM role: IR-Analyst |
| Prisma/DB Admin | Database forensics | Emergency access credentials |
| Wireshark/tcpdump | Network packet capture | Installed on bastion host |
| YARA | Malware scanning | Installed on bastion host |
| Backup System | Data restoration | Documented restore procedures |
| ntfy.sh / PagerDuty | Alerting | Team subscribed |
TIP
Create a sealed "break glass" document with emergency credentials (AWS root, database admin, DNS registrar, domain registrar) stored securely. During a crisis, you don't want to discover that only the person on vacation knows the admin password.
Know your vulnerabilities before attackers do
Run a free VAPT scan — takes 5 minutes, no signup required.
Book Your Free ScanPhase 2: Detection & Classification
2.1 Detection Sources
flowchart TD
A[Incident Detection Sources] --> B[Automated]
A --> C[Human]
A --> D[External]
B --> B1[SIEM Alerts]
B --> B2[WAF Blocks]
B --> B3[CloudTrail Anomalies]
B --> B4[Application Error Spikes]
B --> B5[Billing Anomalies]
C --> C1[Employee Reports]
C --> C2[Customer Complaints]
C --> C3[IT Support Tickets]
D --> D1[CERT-In Advisory]
D --> D2[Security Researcher]
D --> D3[Media Report]
D --> D4[Dark Web Alert]
D --> D5[Law Enforcement]2.2 Severity Classification
| Severity | Definition | Response Time | Escalation |
|---|---|---|---|
| P1 — Critical | Active breach, data exfiltration, ransomware, production down | Immediate (within 15 min) | CEO + Board |
| P2 — High | Attempted breach, vulnerability being exploited, partial compromise | Within 1 hour | CTO + Legal |
| P3 — Medium | Suspicious activity, scanning, failed attack attempts | Within 4 hours | Security Team |
| P4 — Low | Policy violation, minor misconfiguration, informational | Within 24 hours | IT Manager |
2.3 Incident Classification Form
INCIDENT CLASSIFICATION FORM
━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Date/Time Detected: _____________________ (IST)
Detected By: ___________________________
Detection Method: ☐ Automated ☐ Human ☐ External
Incident Type:
☐ Unauthorized Access ☐ Malware/Ransomware
☐ Data Breach ☐ DDoS Attack
☐ Website Defacement ☐ Phishing/Social Engineering
☐ Insider Threat ☐ Supply Chain Compromise
☐ Cloud Misconfiguration ☐ Other: _____________
Severity: ☐ P1-Critical ☐ P2-High ☐ P3-Medium ☐ P4-Low
Affected Systems:
☐ Production Servers ☐ Database
☐ Customer Data ☐ Employee Data
☐ Financial Systems ☐ Email/Communication
☐ Cloud Infrastructure ☐ Third-party Services
Estimated Impact:
- Records potentially affected: _______
- Systems compromised: _______
- Business operations affected: ☐ Yes ☐ No
- Customer-facing impact: ☐ Yes ☐ NoPhase 3: Containment
3.1 Short-Term Containment (First 2 Hours)
bash
# 1. Isolate affected systems (DON'T shut down — preserve evidence)
# For EC2 instances:
aws ec2 modify-instance-attribute --instance-id i-xxxx --groups sg-quarantine
# 2. Block attacker IP (if identified)
# WAF rule:
aws wafv2 update-ip-set --name "blocked-ips" --addresses "ATTACKER_IP/32" ...
# Security group rule:
aws ec2 revoke-security-group-ingress --group-id sg-xxxx --protocol tcp --port 0-65535 --cidr ATTACKER_IP/32
# 3. Revoke compromised credentials
aws iam update-access-key --user-name compromised-user --access-key-id AKIAXXXXX --status Inactive
aws iam delete-login-profile --user-name compromised-user
# 4. Rotate secrets
aws secretsmanager rotate-secret --secret-id production/database
aws secretsmanager rotate-secret --secret-id production/api-keys
# 5. Enable enhanced logging
aws cloudtrail update-trail --name main-trail --enable-log-file-validationSECURITY
NEVER shut down a compromised server. Power off destroys volatile memory evidence (running processes, network connections, encryption keys). Instead, isolate it by changing security groups to deny all traffic, then take a forensic memory dump and disk snapshot.
3.2 Evidence Preservation
bash
# 1. Snapshot affected EBS volumes
aws ec2 create-snapshot --volume-id vol-xxxx --description "IR-Evidence-$(date +%Y%m%d)"
# 2. Capture memory dump (on the instance)
sudo dd if=/dev/mem of=/tmp/memory-dump.raw bs=1M
# 3. Capture network state
netstat -tulpn > /tmp/network-connections.txt
ss -tulpn >> /tmp/network-connections.txt
# 4. Capture running processes
ps auxf > /tmp/running-processes.txt
# 5. Copy CloudTrail logs to separate secure bucket
aws s3 sync s3://cloudtrail-bucket/AWSLogs/ s3://ir-evidence-bucket/incident-$(date +%Y%m%d)/
# 6. Calculate hashes of all evidence files
sha256sum /tmp/*.txt /tmp/*.raw > /tmp/evidence-hashes.txtPhase 4: CERT-In Notification (Within 6 Hours)
4.1 CERT-In Report Template
TO: incident@cert-in.org.in
SUBJECT: Cybersecurity Incident Report — [Company Name] — [Date]
1. ORGANIZATION DETAILS
Organization Name: _______________
Sector: _______________
Contact Person: _______________
Designation: _______________
Email: _______________
Phone: _______________
2. INCIDENT DETAILS
Date/Time of Detection: _______________ IST
Date/Time of Occurrence (estimated): _______________ IST
Incident Type: _______________
Severity: _______________
3. AFFECTED SYSTEMS
IP Addresses: _______________
Domain Names: _______________
Services Affected: _______________
Geographic Location: _______________
4. IMPACT ASSESSMENT
Data Records Affected: _______________
Systems Compromised: _______________
Business Impact: _______________
Customer Impact: _______________
5. CONTAINMENT ACTIONS TAKEN
[List all containment measures implemented]
6. INDICATORS OF COMPROMISE (IOCs)
Attacker IP(s): _______________
Malware Hashes: _______________
Malicious URLs: _______________
C2 Domains: _______________
7. ADDITIONAL INFORMATION
[Any other relevant details]sequenceDiagram
participant Team as IR Team
participant CERT as CERT-In
participant DPBI as Data Protection Board
participant Users as Affected Users
participant Media as Media/Public
Note over Team: T+0: Incident Detected
Team->>Team: T+15min: Classify & Assign Severity
Team->>Team: T+1h: Containment Actions
Team->>CERT: T+6h MAX: Submit Incident Report
CERT-->>Team: Acknowledge & Assign Ticket
Note over Team: If Personal Data Affected:
Team->>DPBI: T+72h MAX: Breach Notification
DPBI-->>Team: Acknowledge
Team->>Users: T+72h: Notify Affected Individuals
Note over Media: Only after legal review
Team->>Media: If required: Public statementPhase 5: DPDP Act Notification (Within 72 Hours)
If personal data is affected, you must also notify the Data Protection Board of India:
5.1 DPDP Breach Notification Template
NOTIFICATION OF PERSONAL DATA BREACH
Under Section 8(6) of the Digital Personal Data Protection Act, 2023
1. DATA FIDUCIARY DETAILS
Organization: _______________
DPO Name: _______________
DPO Contact: _______________
2. NATURE OF BREACH
Date of Breach: _______________
Date of Discovery: _______________
Type: ☐ Unauthorized Access ☐ Data Exfiltration ☐ Ransomware
☐ Accidental Disclosure ☐ Other: _______
Description: _______________
3. DATA AFFECTED
Categories of Data: ☐ Name ☐ Email ☐ Phone ☐ Aadhaar ☐ PAN
☐ Financial ☐ Health ☐ Biometric ☐ Location
Number of Records: _______________
Number of Data Principals: _______________
4. LIKELY CONSEQUENCES
[Assessment of risk to Data Principals]
5. MEASURES TAKEN
Containment: _______________
Mitigation: _______________
Preventive (future): _______________
6. DATA PRINCIPAL NOTIFICATION
Method: ☐ Email ☐ SMS ☐ In-App ☐ Website
Date Notified: _______________Phase 6: Eradication & Recovery
6.1 Eradication Checklist
bash
# 1. Remove malware/backdoors
# Scan all affected systems
clamscan -r /var/www/ --infected --remove
# 2. Patch the vulnerability that was exploited
# Document: What was the entry point?
# Apply: Security patch or configuration fix
# 3. Reset ALL credentials
# - Database passwords
# - API keys
# - SSH keys
# - OAuth tokens
# - Service account passwords
# 4. Rebuild compromised systems from known-good images
# NEVER just "clean" a compromised server — rebuild it
# 5. Verify clean state
# Run VAPT scan on rebuilt systems
# Verify no persistence mechanisms remain6.2 Recovery Checklist
| Step | Action | Verified By | Date |
|---|---|---|---|
| 1 | Restore from verified clean backups | DevOps | |
| 2 | Verify data integrity | DBA | |
| 3 | Test all application functionality | QA | |
| 4 | Monitor for re-compromise (48 hours) | Security | |
| 5 | Gradually restore user access | IT Admin | |
| 6 | Lift containment measures | Incident Commander | |
| 7 | Confirm normal operations | CTO |
Phase 7: Post-Incident Review
7.1 Post-Incident Report Template
POST-INCIDENT REVIEW REPORT
━━━━━━━━━━━━━━━━━━━━━━━━━━━
Incident ID: IR-YYYY-NNN
Date of Incident: _______________
Date of Report: _______________
Author: _______________
Classification: _______________
EXECUTIVE SUMMARY
[2-3 paragraph summary for leadership]
TIMELINE
[Detailed chronological timeline of events]
ROOT CAUSE ANALYSIS
[What was the root cause? Use 5 Whys method]
IMPACT ASSESSMENT
- Data records affected: _______
- Systems compromised: _______
- Downtime duration: _______
- Financial impact (estimated): ₹_______
- Reputational impact: _______
WHAT WENT WELL
[List effective responses]
WHAT NEEDS IMPROVEMENT
[List gaps and failures]
ACTION ITEMS
| # | Action | Owner | Deadline | Status |
|---|--------|-------|----------|--------|
| 1 | | | | |
| 2 | | | | |
| 3 | | | | |
LESSONS LEARNED
[Key takeaways for the organization]7.2 Mandatory Post-Incident Actions
flowchart TD
A[Post-Incident Actions] --> B[Technical]
A --> C[Process]
A --> D[People]
A --> E[Compliance]
B --> B1[Patch vulnerability]
B --> B2[Enhanced monitoring]
B --> B3[Architecture review]
C --> C1[Update IR plan]
C --> C2[Improve detection rules]
C --> C3[Review access controls]
D --> D1[Team debrief]
D --> D2[Training gaps identified]
D --> D3[Update contact list]
E --> E1[CERT-In follow-up report]
E --> E2[DPDP documentation]
E --> E3[Audit trail preservation]Quick Reference Card
Print this and keep it at every engineer's desk:
╔══════════════════════════════════════════════════╗
║ INCIDENT RESPONSE QUICK REFERENCE ║
╠══════════════════════════════════════════════════╣
║ ║
║ 1. DON'T PANIC. DON'T SHUT DOWN SERVERS. ║
║ ║
║ 2. NOTIFY: Incident Commander immediately ║
║ → Slack: #incident-response ║
║ → Phone: [IC Phone Number] ║
║ ║
║ 3. CLASSIFY: P1/P2/P3/P4 ║
║ ║
║ 4. CONTAIN: Isolate, don't destroy ║
║ → Change security groups ║
║ → Block attacker IP ║
║ → Revoke compromised creds ║
║ ║
║ 5. PRESERVE: Evidence first, cleanup later ║
║ → Snapshot EBS volumes ║
║ → Save CloudTrail logs ║
║ → Document everything ║
║ ║
║ 6. REPORT: ║
║ → CERT-In: 6 hours (incident@cert-in.org.in)║
║ → DPBI: 72 hours (if personal data) ║
║ ║
║ 7. NEVER: Delete logs, modify evidence, ║
║ communicate on compromised channels, ║
║ or make public statements without legal ║
║ ║
╚══════════════════════════════════════════════════╝Key Takeaway
Key Takeaways:
- CERT-In mandates 6-hour incident reporting — have your templates ready BEFORE an incident
- DPDP Act requires 72-hour breach notification to DPBI for personal data incidents
- Never shut down compromised servers — isolate them and preserve evidence
- Your IR plan is only as good as your last drill — test it quarterly
- The "break glass" document with emergency credentials is critical — create it today
- 73% of Indian companies have no IR plan — having one gives you a significant advantage
- Post-incident review is mandatory — every incident should make your organization stronger
Need help building your incident response capability? Start with a Bachao.AI security assessment — we identify the vulnerabilities that could lead to incidents in the first place.