Every organization will experience a cybersecurity incident — the question is whether it becomes a manageable event or a business-destroying crisis. The difference is almost entirely determined by preparation: having a documented Incident Response Plan, a trained team, pre-staged forensic tools, and tested communication procedures before the incident occurs.
Organizations that respond to incidents ad-hoc — deciding what to do as the incident unfolds — consistently make the same mistakes: they reboot infected systems (destroying forensic evidence), they notify too widely too early (tipping off insiders), they fail to contain lateral movement (allowing the attacker to persist), and they miss regulatory notification deadlines (adding legal liability to the technical damage).
1 IR Framework & Severity Levels
EnterWeb IT Firm follows the PICERL incident response lifecycle — Prepare, Identify, Contain, Eradicate, Recover, Lessons Learned — aligned with NIST SP 800-61r2 and adapted for Indian regulatory requirements including CERT-In reporting obligations.
The PICERL Lifecycle
🛡️ Phase 1 — PREPARE Ongoing
Build the capability to respond before incidents occur. Develop and maintain the IR Plan, train the IR team, establish detection tools (SIEM, EDR, SOAR), pre-stage forensic toolkits, create communication templates, conduct tabletop exercises quarterly, and maintain up-to-date asset inventory. Preparation is the phase that determines whether every other phase succeeds or fails.
🔍 Phase 2 — IDENTIFY Minutes–Hours
Detect that an incident has occurred, determine its scope and nature, and declare the appropriate severity level. Identification triggers from: SIEM alerts, EDR detections, user reports, threat intelligence feeds, external notification (ISP, law enforcement, security researcher). The key challenge is distinguishing real incidents from false positives quickly — without wasting response resources on noise while not missing real threats.
🚧 Phase 3 — CONTAIN First 1–4 Hours
Stop the spread of the incident — prevent the attacker from reaching additional systems, prevent data from leaving the organization, and preserve the ability to investigate. Containment has two phases: short-term (isolate affected systems immediately) and long-term (implement more durable controls while remediation is underway). The tension in containment is speed vs evidence preservation — contain fast enough to limit damage but carefully enough to preserve forensic integrity.
🔬 Phase 4 — ERADICATE Hours–Days
Remove the attacker's presence completely — malware, persistence mechanisms, compromised credentials, backdoors, and rogue accounts. Eradication without thorough investigation is dangerous — if you haven't identified how the attacker got in and what they did, you cannot confirm they are fully gone. Common eradication failures: removing malware but leaving the initial access vector open, resetting passwords but missing service accounts, reimaging endpoints but leaving compromised AD accounts active.
🔄 Phase 5 — RECOVER Days–Weeks
Restore systems to normal operation safely — verifying that restored systems are clean before reconnecting to the network, monitoring intensively for signs of re-infection, and phasing restoration by criticality. Recovery from the DR plan (tested backups) should already be underway during the Eradicate phase for critical systems. Do not rush recovery — reconnecting a system that still has remnants of attacker presence reinfects the environment.
📋 Phase 6 — LESSONS LEARNED Within 2 Weeks
Conduct a blameless post-incident review — what happened, what went well, what failed, what needs to change. Document the timeline, root cause, impact, and all action items with owners and due dates. Update the IR plan based on lessons learned. Every incident should make the organization harder to compromise and faster to respond next time. Skip this phase and you pay the same price twice.
Incident Severity Classification
P1
Critical
15 min
Active ransomware, confirmed data exfiltration, full network outage, payment system compromise. Immediate all-hands response.
P2
High
1 hour
Confirmed malware on critical system, BEC active, significant data loss suspected, major service degradation.
P3
Medium
4 hours
Malware on non-critical system, phishing campaign in progress, policy violation with data risk, suspicious insider activity.
P4
Low
24 hours
Isolated phishing email, failed attack attempt, minor policy violation, security tool alert with low confidence.
2 Incident Response Team Setup
An effective IR team is not assembled during an incident — it is pre-designated, trained, and contact-accessible at any hour before an incident occurs. Every role must have a primary and a backup person identified.
IR Team Roles & Responsibilities
| Role | Responsibilities | 24/7 Reachable? |
|---|
| Incident Commander (IC) |
Overall incident authority — makes all key decisions (contain vs investigate, when to notify leadership, when to engage external help). Keeps the team focused and prevents parallel uncoordinated actions. Typically IT Director or CISO. |
Yes — mobile + WhatsApp |
| Technical Lead |
Directs technical investigation and response — forensic analysis, malware analysis, containment execution, eradication. Must have deep knowledge of the organization's systems and security tools. |
Yes |
| Communications Lead |
Manages all internal and external communications — notifies leadership, prepares customer/regulator notifications, manages media inquiries. Critical to prevent premature or inaccurate disclosures. |
Business hours + on-call |
| Legal / Compliance |
Advises on regulatory notification obligations (CERT-In, DPDPA, RBI), legal privilege considerations, evidence preservation requirements, and contractual notification obligations to customers/partners. |
On-call for P1/P2 |
| IT Operations |
Executes technical containment actions — network isolation, account lockout, firewall rule changes, system shutdowns. Must be able to act quickly on IC direction without second-guessing. |
Yes — on-call rotation |
| External IR Retainer |
Pre-contracted cybersecurity firm for P1 incidents — provides forensic specialists, malware analysts, and negotiation support (for ransomware) that exceed internal capability. Engage within 2 hours of P1 declaration. |
24/7 SLA |
IR Contact List — Keep Offline Copy
3 Detection & Identification
Detection quality determines how quickly incidents are identified and how much damage is limited. The average dwell time for attackers in Indian enterprise networks — the time between initial compromise and detection — is 197 days. Improving detection capability directly reduces breach impact.
Detection Sources — Priority Order
- EDR alerts (Endpoint Detection & Response): Microsoft Defender for Endpoint, CrowdStrike Falcon, or SentinelOne — provides process-level visibility, behavioural detection, and attack chain visualization. The single highest-value detection investment for most organizations
- SIEM correlation rules: Microsoft Sentinel, Splunk, or ELK Stack — correlates events across multiple sources to detect patterns no single source can see. Key rules: impossible travel login, mass file access, lateral movement (new admin connections), data staging (large outbound transfers after hours)
- Firewall and network logs: FortiGate IPS/IDS alerts, DNS query logs (detecting C2 beaconing), NetFlow analysis (detecting large outbound data transfers), anomalous outbound connection alerts
- User reports: Users noticing ransomware notes, unexpected password resets, unusual account activity emails, or files that will not open. Train users to report to a dedicated security mailbox (security@enterweb.in) — not just to their manager
- External notification: ISP abuse desk, breach notification services (Have I Been Pwned Enterprise, SpyCloud), law enforcement, security researchers, customers reporting unusual emails from your domain
Initial Triage Checklist — First 15 Minutes
# INCIDENT TRIAGE — Execute within 15 minutes of alert
# Goal: Determine if this is a real incident and what severity
STEP 1 — GATHER INITIAL FACTS (do NOT touch affected systems yet)
□ What was the detection source? (SIEM alert / user report / EDR / external)
□ What systems/accounts are involved? (hostnames, IPs, usernames)
□ What is the timestamp of first observed activity?
□ Is this activity still ongoing or historical?
□ What data/systems could be at risk?
STEP 2 — QUICK SCOPE ASSESSMENT
□ Check SIEM: Any other systems showing similar indicators?
□ Check EDR: Is malware detected on multiple endpoints?
□ Check firewall logs: Unusual outbound connections from affected IPs?
□ Check AD: Any new admin accounts, unusual group membership changes?
□ Check email gateway: Mass phishing campaign or BEC indicators?
STEP 3 — CLASSIFY SEVERITY (use severity matrix above)
□ P1 — Critical: Activate full IR team immediately, bridge call within 15 min
□ P2 — High: Notify IC and Technical Lead, begin response within 1 hour
□ P3 — Medium: Assign to security team, respond within 4 hours
□ P4 — Low: Log and queue for next business day
STEP 4 — PRESERVE EVIDENCE (before any remediation)
□ Screenshot all alerts, logs, and indicators — timestamped
□ Export relevant logs to secure evidence storage (NOT the affected system)
□ Do NOT reboot, power off, or run antivirus scans yet (destroys forensics)
□ Start incident timeline document — log every action with timestamp
STEP 5 — NOTIFY IC
□ Call Incident Commander — verbal brief: "What happened, affected systems,
current severity assessment, what I've done so far, what I need"
□ IC activates appropriate IR team members based on severity
□ Open incident bridge/war room channel (dedicated Teams/Slack channel)
4 Containment Procedures
Containment stops ongoing damage while preserving the organization's ability to investigate. The containment decision is always a trade-off between speed and evidence preservation — and the right balance depends on whether the attacker is still active and how fast data loss is occurring.
Network Containment — FortiGate Isolation
# FortiGate — Emergency network isolation of compromised host
# Use when: Active malware spreading, ransomware encrypting, active C2 communication
# Option 1: Block specific host via quarantine (preserves connectivity for forensics)
config user quarantine
edit "QUARANTINE-INCIDENT-001"
set targets
edit 1
set entry-type ipv4-address
set ipv4-address 10.10.10.55 # Compromised host IP
next
end
next
end
# Host is now quarantined — blocked from all network except management VLAN
# Option 2: Block via firewall policy (explicit deny for specific host)
config firewall policy
edit 999
set name "INCIDENT-ISOLATE-HOST"
set srcintf "VLAN10-Users"
set dstintf "any"
set srcaddr "HOST-10.10.10.55" # Address object for compromised host
set dstaddr "all"
set action deny
set schedule "always"
set logtraffic all
set comments "IR-INCIDENT-2026-003 — Isolate compromised host — [date/engineer]"
next
end
# Move this policy ABOVE all permit policies for the VLAN
# Option 3: Block on FortiSwitch (layer 2 isolation — most complete)
# FortiGate → WiFi & Switch Controller → Managed FortiSwitch
# Click on switch → right-click affected port → Quarantine
# This blocks all traffic at the physical port level — host cannot communicate at all
# Verify isolation:
diagnose firewall iprope show 100004 10.10.10.55 # Check policy hit
# From compromised host: ping 8.8.8.8 should fail, ping gateway should fail
Active Directory Emergency Actions
# Active Directory — Emergency containment for compromised accounts
# Run from Domain Controller or admin workstation with AD tools
# Disable compromised user account immediately
Disable-ADAccount -Identity "jsmith"
# Verify:
Get-ADUser -Identity "jsmith" | Select Name, Enabled
# Reset password (force change on next logon — but disable first to prevent lockout)
Set-ADAccountPassword -Identity "jsmith" -Reset `
-NewPassword (ConvertTo-SecureString "Temp!P@ss9834#2026" -AsPlainText -Force)
Set-ADUser -Identity "jsmith" -ChangePasswordAtLogon $true
# Revoke all active sessions (Kerberos tickets)
# This forces re-authentication — attacker's stolen tokens become invalid
Get-ADUser -Identity "jsmith" | Set-ADUser -KerberosEncryptionType AES256
# More effective: reset krbtgt account password (nuclear option — use only in confirmed AD compromise)
# Check for suspicious admin account additions
Get-ADGroupMember -Identity "Domain Admins" | Select Name, SamAccountName, WhenCreated
Get-ADGroupMember -Identity "Enterprise Admins" | Select Name, SamAccountName
# Compare against known-good list — remove any unrecognized accounts immediately
# Find all accounts with admin privileges added in last 7 days
$since = (Get-Date).AddDays(-7)
Get-ADUser -Filter {WhenCreated -ge $since} -Properties MemberOf |
Where { $_.MemberOf -match "Admin" } |
Select Name, WhenCreated, MemberOf
# Block all logons for specific computer (isolate without disabling)
Set-ADComputer -Identity "WORKSTATION-055" -Enabled $false
5 Ransomware Response Playbook
Ransomware is the highest-severity cybersecurity incident most Indian organizations will face — it combines malware infection, lateral movement, data exfiltration (double extortion), and service disruption into a single devastating attack. Every minute of delay in the first hour increases encrypted system count and recovery cost.
1
Activate IR Team immediately — Call Incident Commander. Open a dedicated Teams/WhatsApp group "IR-RANSOMWARE-[DATE]". Do NOT use email (may be compromised). Alert all IT staff: "Stop all work, do not touch any systems until instructed."
T+0 to T+5 min
2
Network isolation — IMMEDIATELY — Physically disconnect affected segments from the network. Do NOT rely on firewall rules alone for active ransomware — pull network cables or shut switch ports. Isolate entire VLANs if individual host identification takes too long. Yes, this causes outages — it stops encryption spreading to more systems. Isolated encrypted systems are recoverable; fully-encrypted network is not.
T+5 to T+15 min
3
Do NOT reboot, do NOT run antivirus, do NOT wipe — Preserve memory state. Volatile memory (RAM) contains encryption keys, attacker tools, and C2 addresses that disappear on reboot. If forensics is planned (it should be), take memory dump FIRST using Magnet RAM Capture or WinPmem before any remediation action. Document which systems are powered on vs off.
T+5 min ongoing
4
Identify ransomware variant — Check ransom note filename and text. Upload sample encrypted file + ransom note to id-ransomware.malwarehunterteam.com — identifies the variant and whether a free decryptor exists. Check nomoreransom.org for available decryptors. Document ransom demand amount and deadline.
T+15 to T+30 min
5
Assess backup integrity — Are backups accessible and unencrypted? Check backup system from an isolated, clean management system. If cloud backups (AWS/Azure) — log in from a clean device not connected to the compromised network. Verify backup timestamps — determine RPO (how much data will be lost). If backups are also encrypted, this is now a ransomware + data loss incident — engage IR retainer immediately.
T+15 to T+60 min
6
Engage external IR retainer — P1 ransomware requires external forensic support. Call your pre-contracted IR firm within the first hour. They provide: forensic investigation of initial access vector, complete scope assessment (what was encrypted + what was exfiltrated), AD audit, remediation guidance, and ransom negotiation support if needed. Do not begin negotiation without legal and IR retainer guidance.
T+30 to T+60 min
7
Determine initial access vector — Common entry points: phishing email with malicious attachment (check email gateway logs), RDP exposed to internet (check firewall logs for external RDP connections), VPN credential compromise (check VPN authentication logs), vulnerable public-facing service (check IDS/IPS alerts). Closing the initial access vector is mandatory before recovery — otherwise attacker re-enters immediately after restore.
T+1 to T+4 hours
8
Begin recovery from clean backups — Restore in priority order from the system/data classification: (1) Domain Controllers from known-clean AD backup, (2) Email server, (3) ERP/core business systems, (4) File servers, (5) Workstations. Restore to isolated network segment — verify clean operation before reconnecting to production. Each restored system must pass EDR scan before reconnection.
T+4 to T+72 hours
9
CERT-In notification — Ransomware is a notifiable incident under CERT-In Directions 2022. Report to incident@cert-in.org.in within 6 hours of detection. Provide: incident type (ransomware), affected systems count, estimated data impact, and initial containment steps taken. CERT-In may provide threat intelligence support and will track the campaign for national-level response.
Within 6 hours
🚨 Ransom Payment Decision: Paying ransom does NOT guarantee data recovery — studies show 40% of organizations that paid ransom did not receive a working decryptor. Paying also funds criminal operations and may violate international sanctions if the ransomware group is on an OFAC list (US-based organizations) — which creates legal liability for the payer. The decision to pay should only be made after: (1) confirming backups are unrecoverable, (2) legal consultation, (3) IR retainer advises it as last resort, (4) board-level approval. Never pay without all four.
6 Phishing & BEC Playbook
Phishing and Business Email Compromise (BEC) are the most common initial access vectors for Indian enterprise attacks — BEC alone caused over ₹1,000 crore in losses to Indian organizations in 2024. Rapid identification of compromised accounts and revocation of attacker access is the critical success factor.
1
Receive report and assess — User reports suspicious email, unexpected password reset, or finance team receives unusual payment request. Determine: Did user click a link? Did user enter credentials? Was a payment made? Each answer changes the severity and response path dramatically.
T+0 to T+15 min
2
Investigate email headers and links — Pull email headers (X-Originating-IP, DKIM/SPF/DMARC pass/fail). Check link reputation via VirusTotal or URLScan.io. Check sender domain registration date — freshly registered domains (<30 days) are a strong BEC indicator. Forward phishing email as attachment to security@enterweb.in — do NOT click links in the analysis process.
T+15 to T+30 min
3
Check for account compromise (if credentials entered) — In Azure AD / Entra ID: Sign-in logs → filter by user → look for unfamiliar IP, country, or user agent. Check Unified Audit Log for mail forwarding rules, inbox rules, sent items, OAuth app grants. Run Identity Protection: Risky Users report. Impossible travel, TOR exit nodes, and unfamiliar device sign-ins are definitive compromise indicators.
T+15 to T+45 min
4
Revoke all sessions immediately (if compromised) — In Azure AD: User → Revoke Sessions. This invalidates all active tokens — attacker loses access within minutes. Also: Disable the account temporarily, reset password, remove any suspicious OAuth app grants, delete any attacker-created mail forwarding rules. Re-enable account only after full investigation confirms scope.
T+30 to T+60 min
5
Search and purge phishing emails organization-wide — Use Microsoft Purview Content Search to find all copies of the phishing email in all mailboxes (search by subject, sender, URL). Purge using: New-ComplianceSearchAction -SearchName "Phishing-Hunt-001" -Purge -PurgeType SoftDelete. Prevents other users from clicking the same link. Document all mailboxes where email was found.
T+45 to T+90 min
6
Investigate financial impact (BEC only) — If BEC involved a payment request: contact your bank immediately to initiate a payment recall. Time is critical — wire transfers that haven't cleared can often be recalled within 24–48 hours. File a cybercrime complaint at cybercrime.gov.in. Preserve all email evidence in original format (with headers) for law enforcement.
Immediate if payment made
7 Data Breach Playbook
A data breach — confirmed or suspected unauthorized access to personal or confidential data — triggers multiple parallel workstreams: technical containment, forensic scoping to determine exactly what data was accessed, legal assessment of notification obligations, and regulated notification to CERT-In, DPDPA Data Protection Board, and affected individuals.
1
Preserve evidence immediately — Before any containment action, capture: database access logs, file access logs, network flow data for the affected system, cloud storage access logs (AWS S3 access logs, Azure Blob Storage logs). Evidence preservation is legally required — destroying it (even inadvertently through system wipe) constitutes evidence tampering.
T+0 to T+30 min
2
Determine breach scope — What data was accessed? Personal data (PII), financial data (bank details, card numbers), health data, employee data, intellectual property? How many records? Which individuals? For how long was access possible? Database query logs, file access audit logs, and DLP alerts are the primary data sources for scope determination.
T+1 to T+12 hours
3
Contain the breach vector — Close the access path: revoke compromised credentials, patch the exploited vulnerability, remove the exfiltration channel (block C2 IP, remove backdoor, revoke API key). Verify containment by checking that the unauthorized access path no longer functions. Monitor for 24 hours post-containment for signs of re-access via alternate paths.
T+1 to T+4 hours
4
Legal assessment of notification obligations — Engage legal counsel immediately. Under DPDPA 2023: notify the Data Protection Board and affected Data Principals. Under CERT-In Directions 2022: notify CERT-In within 6 hours. Under RBI guidelines (if applicable): notify RBI CSITE within 6 hours. Under SEBI CSCRF (if applicable): notify SEBI. International notifications (GDPR for EU citizens data): 72 hours. Legal determines which apply and drafts notifications.
T+2 to T+6 hours
5
Customer/individual notification — Draft notification to affected individuals — describe: what happened, what data was involved, what EnterWeb has done to contain it, what individuals should do to protect themselves (monitor accounts, change passwords), and a dedicated contact point for questions. Notifications must be accurate — do not speculate. Do not minimize. Coordinate timing with legal to avoid prejudicing any ongoing investigation.
Within 72 hours
8 CERT-In Reporting & Post-Incident Review
India's CERT-In Directions 2022 mandate reporting of specific cybersecurity incidents within 6 hours of detection — this is one of the strictest reporting timelines globally. Missing the deadline adds regulatory liability to an already serious incident.
CERT-In Reportable Incidents (6-Hour Requirement)
- Targeted scanning/probing of critical networks
- Compromise of critical systems/information
- Unauthorised access to IT systems/data
- Defacement of websites or intrusion into website/server
- Malicious code attacks (ransomware, virus, worm, trojan)
- Attacks on servers (database, mail, DNS) and network devices
- Identity theft, spoofing, phishing attacks
- Denial of Service (DoS/DDoS) attacks
- DNS and BGP hijacking
- Attacks on critical infrastructure (power, banking, telecom)
- Data breaches and data leaks
CERT-In Notification Template
# Send to: incident@cert-in.org.in
# Subject: Cybersecurity Incident Report — [Organization Name] — [Date]
INCIDENT NOTIFICATION
Organization: EnterWeb IT Firm / [Client Organization Name]
Date of Detection: [DD/MM/YYYY HH:MM IST]
Date of Reporting: [DD/MM/YYYY HH:MM IST] (must be within 6 hours of detection)
Contact Person: [Name, Designation, Phone, Email]
INCIDENT DETAILS:
Type of Incident: [Ransomware / Data Breach / Phishing / DDoS / Unauthorized Access]
Affected Systems: [Number and type — e.g., "15 Windows workstations, 2 file servers"]
Affected Data: [Type and approximate volume — e.g., "Employee PII, ~500 records"]
Impact: [Service disruption, data exposure, financial impact]
INITIAL DESCRIPTION:
[2–3 paragraph description of what was detected, how it was detected,
initial scope assessment, and what containment steps have been taken]
INDICATORS OF COMPROMISE (if available):
Malicious IPs: [List]
Malicious domains: [List]
File hashes (MD5/SHA256): [List]
Malware name/family (if identified): [Name]
CONTAINMENT ACTIONS TAKEN:
[List actions: isolated systems, blocked IPs, disabled accounts, etc.]
CURRENT STATUS:
[Active/Contained/Under Investigation/Recovered]
# CERT-In may follow up with requests for:
# - Complete forensic report
# - Log files
# - Memory dumps
# - Additional IOCs
# Cooperate fully — CERT-In provides threat intelligence in return
Post-Incident Review Template
# POST-INCIDENT REVIEW REPORT
# Complete within 2 weeks of incident closure
# Blameless — focus on systems and processes, not individual failures
INCIDENT SUMMARY
Incident ID: IR-2026-003
Type: Ransomware (LockBit 3.0)
Detection Date: [Date/Time]
Containment: [Date/Time — X hours after detection]
Recovery: [Date/Time — X days after detection]
Total Duration: X days from detection to full recovery
IMPACT SUMMARY
Systems Affected: 23 workstations, 3 file servers
Data Loss: ~48 hours of work files (recovered from backup)
Downtime: 72 hours for file servers, 8 hours for workstations
Financial Impact: ₹X (IT costs, recovery labour, lost productivity)
ROOT CAUSE ANALYSIS
Initial Access: Phishing email → user entered VPN credentials on fake portal
Persistence: Attacker created local admin account on 3 servers
Lateral Movement: PsExec via compromised domain admin credentials
Impact: Ransomware deployed from domain admin context
Root Cause: 1. No phishing-resistant MFA on VPN
2. Domain admin credentials not protected with PAM/PIM
3. EDR not deployed on servers (only workstations)
WHAT WENT WELL
✅ Network isolation executed within 12 minutes of alert
✅ Backups were intact and recovery proceeded as planned
✅ CERT-In notified within 6 hours
✅ IR retainer responded within 45 minutes
WHAT NEEDS IMPROVEMENT
❌ Initial detection was 4 hours after first encryption event (SIEM alert missed)
❌ No playbook for ransom note discovery — first responder rebooted system
❌ Executive communication delayed 3 hours — leadership surprised
❌ Forensic toolkit not pre-staged — wasted 45 minutes sourcing tools
ACTION ITEMS
1. Deploy phishing-resistant MFA (FIDO2) for VPN — Owner: IT | Due: 30 days
2. Enroll all servers in EDR — Owner: Security | Due: 14 days
3. Implement PAM/Azure PIM for domain admin accounts — Owner: IT | Due: 45 days
4. Update SIEM rule: alert on 100+ file renames in 5 min — Owner: SOC | Due: 7 days
5. Add "do not reboot" to ransomware runbook prominently — Owner: IR Lead | Due: 3 days
6. Pre-stage forensic toolkit on management server — Owner: IT | Due: 14 days
NEXT TEST DATE: Tabletop ransomware exercise — [Date + 60 days]
Need Incident Response Support?
EnterWeb IT Firm provides Incident Response retainer services and IR readiness assessments — IR plan development, tabletop exercise facilitation, SIEM and EDR deployment, and 24/7 on-call incident response support for Indian enterprises. Be prepared before the incident, not during it.