Severity Classification

Owner: Anchor MSP Operations Lead Last reviewed: 2026-05-24

Purpose

Define incident severity levels with clear criteria, response times, escalation rules, and communication requirements. This classification drives all incident response decisions.

Scope

All incidents affecting systems under Anchor managed production. This classification aligns with the Alert Severity Matrix used for monitoring alerts.

Severity Levels

Severity	Criteria	Response Time	Escalation	Client Communication
Critical	Complete system outage. Confirmed data breach. Active ransomware. Unauthorized root access. Active data exfiltration.	15 minutes	Immediate to Operations Lead + security team. SMS escalation.	Client notified within 1 hour of detection. Hourly updates until resolved.
High	Partial outage. Degraded performance affecting users. Backup failure. Monitoring gap on critical system. Single point of failure exposed.	1 hour	Operations Lead within 30 minutes.	Client notified within 4 hours if user-facing impact.
Medium	Non-critical component failure. Single monitoring check failing. Non-critical security alert. Elevated error rates below threshold.	4 hours	Raised at next standup.	Client notified only if impact persists beyond 24 hours.
Low	Cosmetic issue. Non-urgent maintenance needed. Documentation gap. Informational security finding.	Next business day	Tracked in incident log. No escalation required.	No client communication required.

Classification Guidelines

Critical Indicators

An incident is Critical when any of the following are true:

1. The production system is completely unreachable by end users.
2. A confirmed security breach has occurred (data accessed by unauthorized party).
3. Ransomware or destructive malware is active on a managed host.
4. An attacker has gained or is actively attempting to gain root/admin access.
5. Data integrity is compromised (database corruption, unauthorized modification).
6. The incident triggers BRB Protocol deployment.

High Indicators

An incident is High when any of the following are true:

1. The system is partially functional but with significant degradation visible to users.
2. A scheduled backup has failed and no successful backup exists within the RPO window.
3. Monitoring coverage has a gap on a critical system (blind spot).
4. A single point of failure has been exposed by the incident.
5. A security vulnerability is confirmed but not yet actively exploited.

Medium Indicators

An incident is Medium when any of the following are true:

1. A non-critical component has failed but the primary service remains operational.
2. A single monitoring check is failing but overall coverage is intact.
3. A non-critical security alert has fired (e.g., failed login attempts below brute-force threshold).
4. Error rates are elevated but below the alerting threshold.

Low Indicators

An incident is Low when any of the following are true:

1. A cosmetic or UI issue with no functional impact.
2. Maintenance is needed but not time-sensitive.
3. A documentation gap has been identified.
4. An informational security finding from a routine review.

Reclassification

Incident severity may be reclassified as new information emerges. The Incident Commander is responsible for reclassification decisions.

1. Upgrade: If an incident escalates (e.g., partial outage becomes full outage), the IC upgrades the severity and triggers the escalation path for the new level.
2. Downgrade: If initial assessment was overly cautious, the IC may downgrade. Downgrades are documented in the incident thread with justification.
3. Reclassification does not reset the response clock. The original detection time remains the baseline.

Exceptions

Severity classification overrides require approval from the Operations Lead. Override decisions and justification must be documented in the incident record.