Key Takeaways
- Severity tiers: most SOCs use P1 (critical) to P4 (informational) with mappings to safety, data, system and business impact dimensions.
- Classification criteria should be objective wherever possible: confirmed data exposure, business-critical system affected, regulator notification triggered, customer impact.
- Escalation paths per severity: who is paged, who is informed, who decides, what SLA applies. Documented in advance, not invented during the incident.
- Automated classification at the SIEM layer sets initial severity at alert creation; analyst can re-classify during triage based on new information.
- Review and calibration quarterly. Mis-classified incidents in either direction (over or under) become evidence to refine the matrix.
Why Classification Drives Everything Else
Severity classification is the single decision that cascades into every other aspect of incident response: who gets the page, how fast they respond, who is informed, what authority they have to take action, what notifications fire to regulators and customers, what evidence preservation level applies, and how the incident is closed out. Get classification right and the response is proportionate. Get it wrong in either direction and the cost is high: under-classification means real incidents get treated as routine and metastasize; over-classification means routine alerts wake the CISO at 3am and the team burns out.
Most Indian SOCs use a four-tier severity scale (P1 critical, P2 high, P3 medium, P4 low or informational). Some use five tiers; some use named severities (Sev 1 to Sev 5). The number of tiers matters less than the consistency of application. Pick a scale and stick with it across SOC, IR, communication and reporting.
Severity Tier Definitions (P1 to P4)
A workable starting point. Customise per your business context.
P1 (Critical)
Confirmed compromise of business-critical infrastructure, confirmed data exposure of regulated data (PII, payment card, health, financial), active ransomware encryption in progress, active denial of service against revenue-critical services, confirmed exposure of administrative credentials, or active insider threat with privileged access. Acknowledgement target: 15 minutes. Engagement target: 30 minutes. Escalation: CISO + Incident Commander + Legal Lead engaged immediately. Notifications: regulator clock starts (CERT-In 6 hour window in effect).
P2 (High)
Confirmed compromise of non-critical infrastructure with potential for escalation, suspected data exposure not yet confirmed, ransomware staging without active encryption, lateral movement detected, exposure of non-administrative credentials, targeted attack against the business (not opportunistic), or significant control failure (logging disabled, MFA bypassed). Acknowledgement target: 30 minutes. Engagement target: 1 hour. Escalation: IR lead engaged, CISO informed. Notifications: prepared in advance, fired if confirmation upgrades to P1.
P3 (Medium)
Suspicious activity warranting investigation but no confirmed compromise, malware quarantined by EDR without lateral movement, isolated phishing campaign without confirmed credential compromise, vulnerability exploitation attempted but failed, scanning activity from known-malicious source. Acknowledgement target: 2 hours during business hours. Engagement target: same business day. Escalation: SOC analyst handles, IR lead informed at shift handover.
P4 (Low / Informational)
Routine alert, expected behaviour requiring documentation, control validation events, false positives that nonetheless need closure, security awareness incidents (suspicious email reported but no compromise). Acknowledgement target: same business day. Engagement target: as workflow permits. Escalation: SOC analyst handles, weekly summary to IR lead.
Need Incident Response on Standby?
Codesecure offers retainer-based IR for Indian businesses: 24x7 on-call lead, named OSCP and GCFA consultants, evidence-preserving forensics, regulator-ready reporting and ISO/IEC 27001:2022 certified delivery. Available without retainer for active incidents on best-effort basis.
See IR Services →Classification Criteria: Objective Over Subjective
Each dimension maps to a severity contribution; the highest contribution sets the overall severity. A 'suspected data exposure of regulated data' is at minimum P2 even if no other dimension scores high. A 'confirmed administrative credential exposure on a business-critical system' is P1 regardless of whether exfiltration is confirmed.
- Data exposure: none (no data accessed) / suspected (access path open but no confirmed data taken) / confirmed (data confirmed accessed) / confirmed and exfiltrated (data taken outside the environment)
- System impact: none / single system / multiple systems / business-critical system / multi-tier including business-critical
- Business impact: none / minor (single workflow affected) / moderate (department affected) / significant (customer-facing service affected) / severe (revenue-critical outage)
- Regulatory trigger: none / DPDP triggered / sector-regulator triggered / multiple regulators triggered
- Customer notification: none / contract-only / public disclosure / regulatory public disclosure
Escalation Paths and SLAs by Severity
Each severity tier has a defined escalation path and SLA. The combination tells the analyst what to do, when, and whom to involve. Documented in the IRP, referenced from runbooks, drilled in tabletops.
Example escalation for P1: PagerDuty (or equivalent) pages SOC lead and on-call IR consultant within 15 minutes; SOC lead engages within 30 minutes and pages CISO, Incident Commander and Legal Lead; war room stood up within 60 minutes; CEO and Board sponsor informed within 90 minutes; CERT-In notification drafted within 4 hours (well inside the 6-hour window).
Example escalation for P3: SOC analyst handles, opens case in case management system, investigates per runbook, closes with summary, weekly summary aggregated for IR lead review at shift handover. CISO is not paged for P3; the weekly summary is the right communication cadence.
SLA Definitions: Acknowledgement, Engagement, Resolution
SLAs have three layers, often conflated: acknowledgement (someone has seen the alert and accepted it for handling), engagement (the analyst is actively working it), resolution (the incident is closed). Each has its own target by severity.
Acknowledgement SLA matters because it answers the question 'is anyone home'. For P1, 15 minutes from alert generation to acknowledgement is industry-norm for 24x7 SOCs; 30 minutes is acceptable for 16x5 with after-hours on-call. Engagement SLA measures whether the responder actually starts work; the gap between acknowledgement and engagement is often where slippage hides. Resolution SLA varies wildly by incident class; tracking it gives the trend rather than absolute deadlines.
Codesecure SOC clients receive a dashboard tracking SLA compliance per severity, with weekly reporting and quarterly trend analysis to feed back into runbook and staffing decisions.
Building an IR Programme From Scratch?
Whether you need an IR plan, a tabletop exercise, a SOAR rollout, or DFIR readiness for SOC 2 / ISO 27001 / DPDP, our IR lead is available for a 30-minute free scoping call. No obligation, no slideware.
Talk to an IR Lead →Automated Classification at the SIEM Layer
Modern SIEMs (Sentinel, Splunk ES, Elastic Security, Chronicle, QRadar) let detection rules set initial severity at alert creation. This is the leverage point: a well-designed rule library produces alerts that arrive pre-classified, with context, with suggested runbook, and routed to the right severity queue automatically.
Implementation: each detection rule is authored with a default severity tied to the dimensions above (data exposure dimension, system impact dimension, regulatory dimension). Enrichment automation adds asset-criticality context (this host is in PCI scope, this user is in the privileged tier) at alert generation. Severity calculated from rule default plus enrichment context. Analyst can re-classify during triage if the actual context differs.
Auto-classification reduces analyst cognitive load and produces more consistent severity application across the team. Without it, classification quality varies analyst-by-analyst and shift-by-shift, which makes the metrics noisy and the response inconsistent.
Review, Calibration and Ticketing Integration
Quarterly calibration: pull every P1 and P2 from the last quarter, review whether the classification was correct in retrospect, identify any P3s or P4s that should have been P2s or P1s based on new information, identify any P1s that were overclassified. The output feeds into rule tuning (some rules over-classify, some under-classify), runbook updates and SOC training.
Ticketing integration: every incident flows into the case management system (Jira, ServiceNow, Splunk SOAR Mission Control, Cortex XSOAR, Tines, dedicated IR platforms like Hive). Severity is a first-class field, drives ticket queue routing, drives SLA tracking, drives close-out approval requirements. The SOC and IR teams operate from the case management system, not from email or chat threads, so the audit trail is complete by construction.
Mature Indian SOCs also feed severity data back into business risk reporting. Number of P1s and P2s per quarter, trend over time, root-cause distribution, control gaps surfaced. Board-level cyber risk reporting is incomplete without this; Codesecure helps SOC leaders structure the report so it is decision-useful rather than dashboard theatre.
Frequently Asked Questions
How many severity tiers should we use?
Four is the most common (P1 to P4). Three (critical, high, low) is acceptable for small SOCs but loses granularity. Five or six tiers add complexity without much benefit unless the organisation is very large with very different incident handling per tier. Pick four and stay consistent.
Who decides the final severity?
Initial severity is set by the detection rule (automated). Triaging analyst can re-classify based on early investigation. Final severity is set by the IR lead at incident closure for any P1 or P2; analyst closes P3 and P4. All re-classifications are logged for the quarterly calibration review.
Can a P3 escalate to a P1?
Yes, frequently. The classification is point-in-time; new evidence (lateral movement confirmed, data exfiltration confirmed) upgrades severity and triggers the higher escalation. The IRP must explicitly support upgrade paths so the SOC does not get stuck at the original classification.
How do we handle severity for borderline incidents?
When in doubt, classify higher and downgrade later if appropriate. Cost of over-classification (waking the CISO at 3am for a false alarm) is one bad night. Cost of under-classification (treating a real P1 as a P3) is hours of attacker dwell time. The asymmetry favours over-classification at the margin.
How does this map to NIST SP 800-61?
NIST SP 800-61 r2 describes functional impact, information impact and recoverability impact, which map cleanly onto the data / system / business / regulatory dimensions described above. Our matrix is consistent with NIST and adds the Indian regulatory dimension (CERT-In, RBI, SEBI, DPDP) that NIST does not specifically address.
Can Codesecure help us build our classification matrix?
Yes. Codesecure delivers IR programme engagements that include classification matrix design, severity-tied SLA definition, runbook alignment, SIEM rule severity calibration, ticketing integration and quarterly calibration review. Typically 4 to 8 weeks for a mid-size Indian organisation.
Build A Classification Matrix Your SOC Will Actually Use
Codesecure helps Indian SOCs design and operate severity classification, SLA tracking and quarterly calibration as part of broader IR programme work. ISO/IEC 27001:2022 certified delivery, named GCIH consultants, integration with your SIEM and case management stack.
