Security Incident Severity Classification Template one multi-dimensional rubric for activation, reclassification, response posture, and audit defensibility
A free, copy-ready security incident severity classification rubric. Twelve structured sections covering rubric header and version control, five-band Sev0 through Sev4 definitions with response posture and paging behaviour, nine scoring dimensions (confidentiality, integrity, availability, data subject exposure, regulatory clock exposure, customer-facing visibility, reputational risk, financial exposure, recovery time pressure) plus sector overlays, per-dimension band definitions with anchored examples, composition rule with worked hybrid example, named activation authority and time budget, reclassification authority and named upward and downward triggers, severity-banded response posture for pager fan-out and executive engagement and communications, edge-case decision tree for unknown scope and suspected versus confirmed and third-party scope and multi-tenant blast radius, framework crosswalk, three worked examples, and rubric governance with cadence and revision triggers. Aligned with ISO/IEC 27001 Annex A 5.25, A 5.26, A 5.27, SOC 2 CC7.3 and CC7.4, PCI DSS Requirement 12.10.1, 12.10.5, 12.10.6, NIST SP 800-61 Rev. 2 Section 3.2, NIST SP 800-53 IR-4 through IR-8, NIS2 Article 21 significant-incident criteria, DORA Article 17, HIPAA 164.308(a)(6)(ii), and the SEC cybersecurity disclosure rule material-incident determination.
Run the rubric against the live incident record, not against a guess on the bridge
SecPortal carries the per-dimension scores, the composed band, the activation declaration, the reclassification trail, and the framework expectations the rubric evidences on one workspace so the audit committee read of incident classification discipline and the operational read are the same record. Free plan available.
No credit card required. Free plan available forever.
Twelve sections that turn a severity scale into a defensible classification rubric
A security incident severity classification rubric is the named, multi-dimensional decision tool a programme uses to assign a severity band to an incident at activation, to reclassify the band as scope confirms, and to leave a defensible record of the decision on the response artefact the audit reads after. It sits at a different layer than the incident response plan (the policy document that names authority, escalation, regulatory clocks, and the cadence of testing) and the per-scenario runbook (the procedural document the responder reads during the incident for one scenario class). The rubric is what makes severity a calibrated decision rather than a guess.
The twelve sections below cover the durable shape of one enterprise rubric against ISO/IEC 27001 Annex A 5.25, A 5.26, A 5.27, SOC 2 CC7.3 and CC7.4, PCI DSS Requirement 12.10.1, 12.10.5, 12.10.6, NIST SP 800-61 Rev. 2 Section 3.2, NIST SP 800-53 IR-4 through IR-8, NIS2 Article 21 significant-incident criteria, DORA Article 17 ICT-related incident classification, HIPAA 164.308(a)(6)(ii), and the SEC cybersecurity disclosure rule material-incident determination. The package pairs with the incident response plan guide for the underlying plan structure, the per-scenario runbook template for the procedural layer activated at each band, the tabletop exercise template for the cadence vehicle that tests the rubric under simulated pressure, the audit evidence retention policy for the classification that governs incident artefacts, and the incident response workflow for the operational layer that runs incidents day to day. Copy the section that fits your stage and paste the rest as you go.
Copy the full rubric package (all twelve sections) as one block.
1. Rubric header and version control
Open the rubric with the boundary, the version, and the authority. A reviewer should be able to read in the first lines which programme owns the rubric, when it was last revised, and which framework expectations the classification scheme evidences. ISO/IEC 27001 Clause 7.5 expects documented information for the management system with controlled identification, format, and review; this opening block makes the rubric traceable to the rest of the programme rather than a loose decision aid.
Rubric title: {{RUBRIC_TITLE}}
Rubric identifier: {{RUBRIC_IDENTIFIER}}
Scope (the parts of the organisation the rubric applies to: enterprise-wide, business unit, region, tenant, or service line):
- {{RUBRIC_SCOPE}}
Version: {{RUBRIC_VERSION}}
Effective date: {{EFFECTIVE_DATE}}
Next scheduled review date: {{NEXT_REVIEW_DATE}}
Revision trigger that produced this version (one of: scheduled annual review, post-incident lesson, tabletop after-action item, regulator interaction, audit observation, material estate change, new sector overlay):
- {{REVISION_TRIGGER}}
Owner (the role that maintains the rubric and signs it at publication):
- Role: {{OWNER_ROLE}}
- Named person at time of publication: {{OWNER_NAME}}
- Signature: {{OWNER_SIGNATURE}}
- Signature date: {{OWNER_SIGNATURE_DATE}}
Co-owners (roles that share authority for sections of the rubric):
- Privacy or data protection co-owner (data subject and personal data dimensions): {{PRIVACY_CO_OWNER_ROLE}}
- Legal co-owner (regulatory clock dimension, materiality posture): {{LEGAL_CO_OWNER_ROLE}}
- Communications co-owner (customer-facing visibility and reputational risk dimensions): {{COMMUNICATIONS_CO_OWNER_ROLE}}
- Engineering co-owner (availability and recovery time pressure dimensions): {{ENGINEERING_CO_OWNER_ROLE}}
Framework expectations evidenced by this rubric (ISO/IEC 27001 Annex A 5.25, A 5.26, A 5.27; SOC 2 CC7.3 and CC7.4; PCI DSS Requirement 12.10.1, 12.10.5, 12.10.6; NIST SP 800-61 Rev. 2 Section 3.2; NIST SP 800-53 IR-4, IR-5, IR-6, IR-8; NIS2 Article 21 significant incident criteria; DORA Article 17; HIPAA 164.308(a)(6); SEC cybersecurity disclosure material incident determination; sector-specific notification clocks):
- {{FRAMEWORK_EXPECTATIONS_LIST}}
Cross-references:
- Parent incident response plan version: {{IR_PLAN_VERSION}}
- Per-scenario runbook portfolio version: {{RUNBOOK_PORTFOLIO_VERSION}}
- Tabletop exercise programme reference: {{TABLETOP_PROGRAMME_REFERENCE}}
- Vulnerability severity policy version (related but distinct rubric): {{VULNERABILITY_SEVERITY_POLICY_VERSION}}
- Audit evidence retention policy version: {{RETENTION_POLICY_VERSION}}
- Compliance tracking record identifier: {{COMPLIANCE_RECORD_IDENTIFIER}}
Revision history (each entry: version, effective date, trigger, owner, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, owner {{PRIOR_OWNER_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, owner {{PRIOR_OWNER_2}}, signed {{PRIOR_SIGNATORY_2}}
2. Severity bands defined
Name the bands the programme operates against, then anchor each band with a descriptive narrative, the response posture the band triggers, and the operational signals the audit reads when reviewing per-band incident composition over time. The bands carry the meaning; without them the dimension scoring in Section 4 has nowhere to compose to.
Sev0 (rare existential event; the firm pages everyone and starts disclosure clocks):
- Narrative: confirmed material customer data exposure, active ransomware encryption in production, full control plane compromise, regulator-grade compromise of payment data or protected health information at scope, or an incident the SEC or equivalent material-disclosure rule will read.
- Expected response posture: pager fan-out to the full response roster, executive bridge opening with the named board contact, communications lead opening the customer-facing message draft, privacy officer starting the regulatory clock assessment, legal counsel reviewing for legal hold, customer success representative starting the affected-account list, destructive containment authorised under incident commander authority without further consultation.
- Expected paging behaviour: page everyone on the response tree without exception.
- Expected leadership engagement: board notification trigger fires; executive bridge runs continuously until containment holds.
- Expected customer-facing communication: customer-facing message drafted within the first hour and released after privacy officer and legal counsel sign-off.
- Expected regulatory notification posture: clock assessment opens at activation; notification fires per the shortest applicable clock.
Sev1 (confirmed critical incident with bounded but significant blast radius):
- Narrative: a single high-impact customer affected, a confirmed but contained data exposure, a critical service offline, a credential compromise at scope, a confirmed exploitation of a critical vulnerability in production.
- Expected response posture: pager to the response team, executive escalation contact engaged for critical severity, privacy officer engaged for scope determination, legal counsel reviewing for legal hold, internal communications opening, customer-facing communications drafted for release on confirmed customer-facing impact.
- Expected paging behaviour: page the response team and the IC; the executive bridge opens on confirmed customer-facing impact.
- Expected leadership engagement: executive escalation contact engaged on activation; board contact informed on confirmed customer-facing impact.
- Expected customer-facing communication: drafted at activation; released after privacy officer and legal counsel sign-off on confirmed customer-facing impact.
- Expected regulatory notification posture: clock assessment opens at activation; notification fires on confirmed in-scope data exposure.
Sev2 (high-impact event with significant operational disruption):
- Narrative: a non-customer-facing data exposure, a high-risk vulnerability under active exploitation in scope, a third-party breach with potential downstream effect, an operational service degradation affecting multiple internal users.
- Expected response posture: pager to the response team, leadership chain engaged on the next business-day briefing, internal communications opening, privacy officer review on confirmed personal data scope, no executive bridge by default.
- Expected paging behaviour: page the response team and the IC; no executive bridge.
- Expected leadership engagement: leadership chain informed on the next business-day reporting cycle.
- Expected customer-facing communication: drafted only on confirmed customer-facing visibility.
- Expected regulatory notification posture: clock assessment opens on confirmed in-scope data; no preemptive notification.
Sev3 (contained issue worth tracking through formal incident discipline):
- Narrative: a suspected compromise under investigation, an isolated misuse event, a recoverable service degradation, a third-party advisory worth a structured response, a confirmed low-impact event the firm wants on the incident ledger.
- Expected response posture: on-call engagement, incident commander assigned, runbook activation captured on the engagement record, leadership chain informed on the standard reporting cycle.
- Expected paging behaviour: engage the on-call role; no after-hours paging unless scope escalates.
- Expected leadership engagement: informed on the standard reporting cycle.
- Expected customer-facing communication: not drafted unless reclassified up.
- Expected regulatory notification posture: not opened unless reclassified up.
Sev4 (watch-and-track band):
- Narrative: a confirmed low-risk event that the firm still wants on the incident ledger so the post-incident review can read the cumulative posture.
- Expected response posture: routes to standard ticketing with an incident record cross-reference.
- Expected paging behaviour: no paging.
- Expected leadership engagement: rolled up into the weekly batch report.
- Expected customer-facing communication: not drafted.
- Expected regulatory notification posture: not opened.
3. Scoring dimensions
Name the axes the rubric scores against so the on-call role does not collapse the decision into a single guess. Nine dimensions cover most enterprise programmes; sector overlays add dimensions where the regulatory environment or the estate requires them. Each dimension is scored independently before the composition rule in Section 5 combines them.
Dimension 1 - Confidentiality:
- Definition: the volume and sensitivity of data exposed or potentially exposed in the event.
- Use: scored from the captured evidence of data access, exfiltration, or exposure surface.
Dimension 2 - Integrity:
- Definition: whether trusted systems, code, records, or transactions have been modified or potentially modified.
- Use: scored from the captured evidence of unauthorised writes, code changes, or pipeline tampering.
Dimension 3 - Availability:
- Definition: the customer-facing or operational service impact, measured in user reach and degradation magnitude.
- Use: scored from telemetry on affected service health and from customer-success input on the customer-facing impact.
Dimension 4 - Data subject exposure:
- Definition: the count, geography, and category of natural persons whose personal data is in scope.
- Use: scored from privacy officer review of the scope record; updates as scope confirms.
Dimension 5 - Regulatory clock exposure:
- Definition: which notification clocks the event activates and how short the shortest clock is.
- Use: scored from legal counsel review against the firm's regulatory map; updates as scope confirms.
Dimension 6 - Customer-facing visibility:
- Definition: whether customers can see the event from the outside (service degradation, public disclosure, third-party reporting).
- Use: scored from customer-success input and public-monitoring inputs.
Dimension 7 - Reputational risk:
- Definition: the press, social, analyst, and industry visibility likelihood of the event.
- Use: scored from communications lead review of the event characteristics and the public visibility risk.
Dimension 8 - Financial exposure:
- Definition: direct loss, recovery cost, contract-penalty risk, and material-disclosure threshold proximity.
- Use: scored from finance input and from legal counsel review of contractual exposure.
Dimension 9 - Recovery time pressure:
- Definition: how long until service has to return to meet contractual, operational, or regulatory expectations.
- Use: scored against the firm's RTO commitments per service tier and the customer-facing SLA where applicable.
Sector overlays (added where the estate requires):
- Operational technology exposure (industrial estates): scored against the OT scope and the safety-impact lens.
- Payment card scope (PCI estates): scored against the PCI DSS event criteria.
- Protected health information scope (HIPAA estates): scored against the HIPAA breach notification rule.
- Critical infrastructure designation (NIS2, DORA, sector-specific): scored against the regulator's significant-incident threshold.
Scoring scale (each dimension scored on a five-point scale):
- 0: no impact on this dimension.
- 1: low impact on this dimension.
- 2: moderate impact on this dimension.
- 3: high impact on this dimension.
- 4: critical impact on this dimension.
Per-dimension scoring discipline:
- The on-call role scores each dimension independently at activation against the evidence available in the first ten minutes.
- The incident commander revises the per-dimension scores as scope confirms or new evidence arrives.
- Every score change lands on the activity log with the named actor, the timestamp, the dimension, the prior score, the new score, and the trigger reason.
4. Per-dimension band definitions with anchored examples
Anchor each dimension to recognisable examples from the estate the firm operates. The anchored examples turn the scoring scale from an opinion into a calibrated decision and let multiple on-call operators score the same event the same way. Customise the examples to match the firm; the scale stays constant.
Confidentiality:
- 0: no data accessed or exposed.
- 1: internal-only metadata accessed; no customer or employee data.
- 2: small volume of internal employee or operational data accessed; no customer data.
- 3: customer data accessed in confirmed but bounded volume (single account, single tenant, single data category).
- 4: large-volume customer data accessed, exfiltrated, or exposed; or a single-record event involving highly sensitive data (financial, health, or special-category personal data at scope).
Integrity:
- 0: no unauthorised writes or modifications confirmed.
- 1: minor configuration drift; no business-relevant data affected.
- 2: confirmed unauthorised configuration change in non-production environment, or unauthorised access to a write path without confirmed writes.
- 3: confirmed unauthorised write to a business-relevant system; bounded scope.
- 4: confirmed unauthorised modification of customer-facing data, transaction records, source code in production, build pipeline artefacts, or cryptographic material.
Availability:
- 0: no service impact.
- 1: minor degradation affecting internal users only.
- 2: significant degradation affecting internal users; customer-facing services unaffected.
- 3: confirmed customer-facing degradation; partial outage of one service.
- 4: full outage of a customer-facing service, or partial outage of a critical service for an extended window.
Data subject exposure:
- 0: no personal data in scope.
- 1: small volume of employee personal data; no special category.
- 2: small volume of customer personal data; no special category; no cross-border scope.
- 3: large volume of customer personal data, or any volume of special-category personal data, or cross-border scope.
- 4: very large volume of customer personal data, or large volume of special-category personal data, or scope across multiple regulator jurisdictions.
Regulatory clock exposure:
- 0: no notification clock activated.
- 1: notification clock with a window longer than thirty days, or contractual notification only.
- 2: notification clock between fourteen and thirty days.
- 3: notification clock between seventy-two hours and fourteen days.
- 4: notification clock of seventy-two hours or shorter (GDPR seventy-two-hour rule, NIS2 early warning, DORA major incident initial notification, SEC four-business-day material incident disclosure).
Customer-facing visibility:
- 0: no customer-facing visibility.
- 1: visibility limited to internal users.
- 2: visibility limited to a small subset of customers.
- 3: visibility to a significant subset of customers; potential for public reporting.
- 4: public visibility confirmed (press, social, status page, third-party advisory).
Reputational risk:
- 0: no public visibility likelihood.
- 1: low likelihood of press or social visibility.
- 2: moderate likelihood; limited industry visibility.
- 3: high likelihood of press, social, or analyst visibility; potential for sustained coverage.
- 4: confirmed press, social, analyst, or industry coverage; sustained reputational exposure expected.
Financial exposure:
- 0: no financial exposure expected.
- 1: low recovery cost; no contract penalties expected.
- 2: moderate recovery cost; contained contract-penalty exposure.
- 3: significant recovery cost; multiple contracts in penalty scope.
- 4: very high recovery cost, broad contract-penalty exposure, or material-disclosure threshold proximity.
Recovery time pressure:
- 0: no time pressure; recovery on a discretionary schedule.
- 1: low time pressure; recovery within normal operating hours.
- 2: moderate time pressure; recovery within business-day SLA.
- 3: high time pressure; recovery within hours-level SLA.
- 4: critical time pressure; recovery within minutes-level SLA or against a regulatory deadline.
Sector overlay examples (customise per estate):
- OT exposure 4: safety-of-life impact confirmed or possible.
- Payment card scope 4: confirmed primary account number exposure at volume.
- PHI scope 4: confirmed PHI exposure triggering breach notification rule.
- Critical infrastructure 4: regulator-defined significant incident threshold crossed.
5. Composition rule
Name the explicit logic the rubric uses to combine per-dimension scores into the final severity band. The composition rule has to be written down so the on-call role applies it without improvisation and the audit can re-derive the decision. Three patterns are common; the hybrid rule below is what most mature enterprise programmes use.
Composition rule selected: {{COMPOSITION_RULE_SELECTED}}
(One of: highest-dimension-wins, weighted-sum-with-threshold, two-of-N-trigger, hybrid)
Hybrid rule definition (example):
- Highest-dimension-wins applies to: confidentiality, regulatory clock exposure, customer-facing visibility, data subject exposure.
- Weighted-sum-with-threshold applies to: integrity, availability, reputational risk, financial exposure, recovery time pressure.
- Weights (publish on the rubric): integrity = 1.0, availability = 1.0, reputational risk = 0.8, financial exposure = 1.0, recovery time pressure = 0.7.
- Weighted-sum thresholds: total below 2.0 -> Sev4; 2.0 to 3.9 -> Sev3; 4.0 to 5.9 -> Sev2; 6.0 to 7.9 -> Sev1; 8.0 and above -> Sev0.
- Final severity = max(highest-dimension-wins severity from the first dimension group, weighted-sum-banded severity from the second dimension group).
- Sector overlay uplift: if any sector overlay scores 3 or higher, apply a one-band uplift to the final severity.
- Unknown scope uplift: if the on-call role cannot bound the scope at activation, apply a one-band uplift until scope is confirmed.
Mapping table (highest-dimension-wins group):
- Highest score of 4 on any dimension in the first group -> Sev0.
- Highest score of 3 on any dimension in the first group -> Sev1.
- Highest score of 2 on any dimension in the first group -> Sev2.
- Highest score of 1 on any dimension in the first group -> Sev3.
- All scores of 0 in the first group -> defer to the weighted-sum-banded severity from the second group.
Worked composition example:
- Confidentiality: 3 (customer data accessed in bounded volume).
- Integrity: 0.
- Availability: 1 (minor internal degradation).
- Data subject exposure: 2 (small volume of customer personal data; no special category).
- Regulatory clock exposure: 3 (seventy-two hours to fourteen days).
- Customer-facing visibility: 1 (internal users only).
- Reputational risk: 2 (moderate).
- Financial exposure: 1 (low recovery cost).
- Recovery time pressure: 1 (normal operating hours).
- First-group severity (highest of confidentiality, regulatory clock, customer-facing visibility, data subject exposure): 3 -> Sev1.
- Second-group weighted sum: (0 * 1.0) + (1 * 1.0) + (2 * 0.8) + (1 * 1.0) + (1 * 0.7) = 4.3 -> Sev2.
- Final severity = max(Sev1, Sev2) = Sev1.
- Sector overlay uplift: none active.
- Final published severity: Sev1.
Discipline at composition:
- The composition rule is applied verbatim at activation and at every reclassification.
- The activity log captures the per-dimension scores, the rule applied, the intermediate severities from each group, and the final composed severity.
- The audit can re-derive the decision from the activity log without asking the responder.
6. Activation authority and time budget
Name the role authorised to declare the initial severity at activation and the time budget on the declaration. Activation declaration is a tight-window decision that fires before the response team has fully gathered; without named authority it defaults to whoever is on the bridge first.
Initial declarant role (the role authorised to declare the first severity at activation):
- Primary: {{INITIAL_DECLARANT_PRIMARY_ROLE}}
- Backup: {{INITIAL_DECLARANT_BACKUP_ROLE}}
- Escalation when both unavailable: {{INITIAL_DECLARANT_ESCALATION_PATH}}
Time budget on the initial declaration:
- Target: within {{INITIAL_DECLARATION_TIME_BUDGET_MINUTES}} minutes of activation page acknowledgement.
- The declaration fires before the response team has fully gathered; the rest of the response posture cannot wait for the IC to be online to know which pager fan-out to fire.
Activation channel and capture discipline:
- The declaration lands on the engagement record as the activation severity field.
- The per-dimension scores supporting the declaration land on the engagement record as the initial scoring record.
- The activity log captures the declaration with named actor, timestamp, per-dimension scores, composition rule applied, and final severity.
- The notification dispatcher reads the activation severity field and fires the per-band response posture from Section 8.
Suspected-only declaration (where the activation signal does not yet confirm a security incident):
- The declarant labels the initial severity as suspected-only.
- The response posture runs at the suspected severity band per Section 8 until evidence confirms or excludes.
- Reclassification from suspected to confirmed is a tracked transition on the activity log.
Stand-down on false-positive determination:
- If the activation signal proves to be a false positive within the first thirty minutes, the declarant authorises stand-down per the runbook activation criteria.
- Stand-down lands on the activity log with the false-positive evidence reference.
- The engagement record is retained at Sev4 with a stand-down note rather than deleted, so the post-incident review can read the cumulative false-positive trend.
7. Reclassification authority and triggers
Name the role authorised to reclassify the severity once the IC is engaged and the trigger criteria that force re-evaluation. Reclassification authority sits with the IC and is explicit about both upward and downward movement so the rubric does not have an upward-only ratchet that traps the response in a higher band than the confirmed scope justifies.
Reclassification authority role:
- Primary: incident commander once engaged on the response.
- Backup: backup incident commander on incident commander unavailability.
- Override path (for cases where the IC is conflicted or unavailable for an extended window): {{RECLASSIFICATION_OVERRIDE_PATH}}
Upward reclassification triggers (the named conditions that force re-evaluation toward a higher band):
- New scope evidence: additional affected accounts, services, customers, or assets confirmed beyond the initial scope record.
- New data category evidence: the privacy officer confirms personal data exposure that was not initially scored, or confirms special-category personal data scope.
- New regulatory clock evidence: legal counsel confirms a regulator-grade notification requirement that activates a shorter clock than initially assessed.
- Confirmed customer-facing visibility: the event becomes visible to customers from the outside, including via press, social, status page, or third-party reporting.
- Material new financial exposure: finance input or contractual review surfaces exposure that crosses a material-disclosure threshold candidate.
- Sector overlay activation: a sector-specific notification clock or significant-incident threshold is confirmed.
- Containment failure: containment in the runbook does not hold and the spread widens beyond the initial scope record.
Downward reclassification triggers (the named conditions that authorise re-evaluation toward a lower band):
- Confirmed scope is materially smaller than the initial estimate.
- Confirmed false-positive on a dimension that previously drove a higher band (e.g. the suspected data exposure proves not to have occurred).
- Containment is confirmed to have held and recovery has completed without revealing wider scope.
- Privacy officer confirms no personal data in scope after initial scope assessment.
- Legal counsel confirms no regulatory clock activated after initial clock assessment.
Reclassification discipline:
- Every reclassification produces an activity log entry with the named actor, the timestamp, the trigger criterion, the prior severity, the new severity, the prior per-dimension scores, and the new per-dimension scores.
- The communications lead reads the reclassification and adjusts the briefing cadence per Section 8.
- The response team reads the reclassification and adjusts the response posture per Section 8.
- The post-incident review reads the reclassification trail against the actual incident trajectory.
Time discipline on reclassification:
- Reclassification fires as soon as the trigger evidence is confirmed; the IC does not batch reclassifications to the next briefing.
- The activity log timestamp distinguishes between the trigger event timestamp and the reclassification decision timestamp so the audit can read the responsiveness of the rubric application.
8. Severity-banded response posture
Publish the response posture each band triggers so the on-call role does not have to compose the posture under pressure. The audit reads the posture map; the responder reads the same map. Without this section the rubric stops at the band and the team improvises the response.
Sev0 response posture:
- Pager fan-out to the full response roster including the named board contact and external counsel.
- Executive bridge opening with continuous attendance until containment holds.
- Communications lead opens customer-facing draft within the first hour.
- Privacy officer starts regulatory clock assessment at activation.
- Legal counsel reviews for legal hold at activation; invokes legal hold by default on Sev0.
- Customer success representative starts the affected-account list at activation.
- Destructive containment authorised under IC authority without further consultation.
- Internal incident-progress briefing cadence: every fifteen minutes for the first hour, every thirty minutes for the next four hours, every ninety minutes thereafter.
- Board notification fires at activation; sponsor decision required on external disclosure timing.
Sev1 response posture:
- Pager to the response team and the IC.
- Executive escalation contact for critical severity engaged at activation.
- Privacy officer engaged for scope determination at activation.
- Legal counsel reviews for legal hold; decision per IC and counsel judgement.
- Internal communications opens at activation.
- Customer-facing communications drafted at activation; released after privacy officer and legal counsel sign-off on confirmed customer-facing impact.
- Executive bridge opens on confirmed customer-facing impact.
- Internal incident-progress briefing cadence: every thirty minutes for the first two hours, every sixty minutes thereafter.
Sev2 response posture:
- Pager to the response team and the IC.
- Leadership chain engaged on the next business-day briefing.
- Internal communications opens at activation.
- Privacy officer review on confirmed personal data scope.
- Customer-facing communications drafted only on confirmed customer-facing visibility.
- No executive bridge by default.
- Internal incident-progress briefing cadence: every sixty minutes during business hours.
Sev3 response posture:
- On-call role engagement; IC assigned.
- Runbook activation captured on the engagement record.
- Leadership chain informed on the standard reporting cycle (typically end of business day or next business day).
- No paging unless reclassified up.
- Internal communications cadence: end-of-day status note.
Sev4 response posture:
- Routes to standard ticketing with an incident record cross-reference.
- No paging.
- Weekly batch report rolls up Sev4 events alongside Sev3 closures for the leadership reporting cycle.
Posture discipline:
- Every posture action fires from the activation severity field on the engagement record without manual intervention by the on-call role wherever automation supports it.
- Posture actions that require human judgement (legal hold invocation, customer-facing release, executive bridge opening) are named on the rubric so the on-call role knows which decisions to escalate immediately and which to batch.
- The activity log captures the posture action firings with named actor and timestamp.
9. Edge-case decision tree
Ambiguity at the classification step is one of the most common failure modes of incident response programmes. Publish the named edge-case patterns with named resolutions so the responder reads a decision rather than improvising under pressure.
Edge case 1 - Unknown scope at activation:
- Pattern: the activation signal confirms an incident is in progress but the scope cannot be bounded in the first ten minutes.
- Resolution: apply a one-band uplift from the apparent severity until the scope is bounded; reclassify down once evidence confirms the bounded scope.
Edge case 2 - Multi-tenant blast radius:
- Pattern: the incident affects multiple customers or business units with varying impact.
- Resolution: default to highest-affected-tenant classification with a programme-wide rollup posture; do not average across tenants.
Edge case 3 - Suspected versus confirmed compromise:
- Pattern: the activation signal suggests but does not confirm a compromise.
- Resolution: declare suspected-only at the apparent band; run the response at the suspected band per Section 8 until evidence confirms or excludes; capture the suspected-to-confirmed transition on the activity log.
Edge case 4 - Insider versus external threat:
- Pattern: the event involves an internal actor whose access was authorised but whose actions exceed authorised use.
- Resolution: run the same dimension scoring with the same composition rule; add the HR coordination path and the internal legal counsel path to the response posture.
Edge case 5 - Third-party scope:
- Pattern: the event originates at a vendor or third-party platform with potential downstream effect on the firm.
- Resolution: score the firm-side impact rather than the third-party-side impact; add the vendor management coordination path to the response posture; capture the vendor-side advisory reference on the engagement record.
Edge case 6 - Sector-specific clock-triggered events:
- Pattern: a sector overlay activates a notification clock shorter than the firm-side recovery clock.
- Resolution: apply the one-band uplift rule from Section 5; the regulatory clock dimension drives the final severity regardless of operational impact.
Edge case 7 - Composite events spanning multiple scenario classes:
- Pattern: the incident involves multiple scenario classes (a ransomware event that also exposes customer data, an account takeover that pivots to source code repository compromise).
- Resolution: score the composite event on the rubric as one classification decision; activate the runbook for each scenario class with the IC coordinating across runbooks.
Edge case 8 - Reopened incident from a prior closure:
- Pattern: a previously closed incident reopens because the underlying cause was not fully remediated.
- Resolution: reactivate the engagement record rather than create a new one; reclassify per the current evidence; capture the reopen reason on the activity log; treat the reopen as a runbook revision trigger.
Edge case 9 - Materiality threshold proximity:
- Pattern: the financial exposure dimension scores at the boundary of the firm's material-disclosure threshold.
- Resolution: escalate to legal counsel for materiality determination before publishing the final severity; do not delay activation while the materiality determination runs; the activation severity reads at the upper boundary until materiality is determined.
Edge case 10 - Disputed reclassification:
- Pattern: a responder, leader, or stakeholder disputes a reclassification decision.
- Resolution: capture the dispute on the activity log; the IC's reclassification holds unless the override path in Section 7 invokes; the dispute and resolution become inputs to the post-incident review and the next rubric revision.
10. Framework crosswalk
Map the rubric to the framework expectations it evidences so the audit reads one consistent classification discipline rather than reverse-engineering it from a folder of incident records. The crosswalk is published on the rubric and referenced from the compliance tracking record on the workspace.
ISO/IEC 27001:2022 Annex A 5.25 (assessment and decision on information security events):
- Rubric evidences: the named assessment mechanism that produces a defensible classification decision per event.
- Evidence pack: rubric document, per-event classification record on activity log, reclassification trail on activity log.
ISO/IEC 27001:2022 Annex A 5.26 (response to information security incidents):
- Rubric evidences: severity-banded response posture from Section 8 drives the response.
- Evidence pack: per-band response posture map, runbook activation records, communications release records.
ISO/IEC 27001:2022 Annex A 5.27 (learning from information security incidents):
- Rubric evidences: post-incident review reads classification decisions against actual incident behaviour; revisions feed the next rubric version.
- Evidence pack: rubric revision history, post-incident review records, after-action item ledger.
SOC 2 CC7.3 (identification and assessment of security events):
- Rubric evidences: defensible identification and assessment per the dimensions and composition rule.
- Evidence pack: rubric document, per-event classification records.
SOC 2 CC7.4 (incident response procedures tested):
- Rubric evidences: rubric included in tabletop exercise scope; tabletop after-action records feed rubric revisions.
- Evidence pack: tabletop programme records, rubric revision history.
PCI DSS Requirement 12.10.1 (incident response plan includes event classification):
- Rubric evidences: the named classification mechanism the IR plan authorises.
- Evidence pack: IR plan referencing the rubric version, rubric document.
PCI DSS Requirement 12.10.5 (response procedure operates against the classification):
- Rubric evidences: severity-banded response posture drives the procedural response.
- Evidence pack: response procedure records per incident.
PCI DSS Requirement 12.10.6 (plan evolves per lessons):
- Rubric evidences: rubric revision triggered by post-incident review.
- Evidence pack: rubric revision history.
NIST SP 800-61 Rev. 2 Section 3.2 (incident categorisation and prioritisation):
- Rubric evidences: the named categorisation and prioritisation procedure.
- Evidence pack: rubric document, per-event classification records.
NIST SP 800-53 IR-4 (incident handling capability including classification), IR-5 (incident monitoring), IR-6 (incident reporting that uses the classification), IR-8 (incident response plan including the classification scheme):
- Rubric evidences: classification scheme; monitoring against the classification; reporting against the classification.
- Evidence pack: rubric document, IR plan referencing rubric, per-event classification records, reporting records.
NIS2 Article 21 (significant incident criteria):
- Rubric evidences: Sev0 and Sev1 bands define the significant-incident threshold for the firm.
- Evidence pack: rubric document, per-event classification records, regulator notification records.
DORA Article 17 (ICT-related incident classification):
- Rubric evidences: classification consistent with the Commission Delegated Regulation criteria for major incidents.
- Evidence pack: rubric document, per-event classification records, regulator notification records.
HIPAA 164.308(a)(6)(ii) (identification and response to suspected or known security incidents):
- Rubric evidences: identification and response procedure including the suspected-only band path.
- Evidence pack: rubric document, per-event classification records.
SEC cybersecurity disclosure rule (material incident determination):
- Rubric evidences: financial exposure and customer-facing visibility dimensions surface materiality candidates for legal counsel review.
- Evidence pack: rubric document, per-event classification records, legal counsel materiality determinations.
11. Worked examples
Walk three anonymised incidents through the rubric end to end so the on-call role reads how it works rather than only what it says. The worked examples are a training aid and an audit aid; they let a new operator calibrate against the rubric before facing a live activation.
Example 1 - Customer data exposure via misconfigured cloud storage bucket:
- Confidentiality: 4 (large-volume customer data accessed by external party).
- Integrity: 0.
- Availability: 0.
- Data subject exposure: 4 (very large volume of customer personal data; no special category).
- Regulatory clock exposure: 4 (GDPR seventy-two-hour notification clock activated).
- Customer-facing visibility: 2 (visibility limited to a subset of customers initially).
- Reputational risk: 3 (high likelihood of press coverage given volume).
- Financial exposure: 3 (significant recovery cost; multiple contracts in penalty scope).
- Recovery time pressure: 2 (moderate; bucket reconfiguration is fast but disclosure cadence is short).
- First-group severity (max of confidentiality, regulatory clock, customer-facing visibility, data subject exposure): 4 -> Sev0.
- Second-group weighted sum: (0 * 1.0) + (0 * 1.0) + (3 * 0.8) + (3 * 1.0) + (2 * 0.7) = 6.8 -> Sev1.
- Final severity: max(Sev0, Sev1) = Sev0.
- Final published severity: Sev0.
- Response posture activated: full Sev0 posture from Section 8.
Example 2 - Active ransomware encryption in non-production environment:
- Confidentiality: 1 (internal-only metadata accessed; no customer data).
- Integrity: 4 (confirmed unauthorised modification of build pipeline artefacts).
- Availability: 2 (significant degradation affecting internal users; customer-facing services unaffected).
- Data subject exposure: 0.
- Regulatory clock exposure: 0.
- Customer-facing visibility: 0.
- Reputational risk: 2 (moderate; potential for industry visibility if scope widens).
- Financial exposure: 2 (moderate recovery cost; contained contract-penalty exposure).
- Recovery time pressure: 3 (high; build pipeline outage prevents deploys).
- First-group severity (max of confidentiality, regulatory clock, customer-facing visibility, data subject exposure): 1 -> Sev3.
- Second-group weighted sum: (4 * 1.0) + (2 * 1.0) + (2 * 0.8) + (2 * 1.0) + (3 * 0.7) = 11.7 -> Sev0.
- Final severity: max(Sev3, Sev0) = Sev0.
- Unknown scope uplift: applied at activation pending scope confirmation; reclassified down to Sev1 once scope is confirmed bounded to non-production environment.
- Final published severity at activation: Sev0.
- Final published severity post-scope-confirmation: Sev1.
Example 3 - Credential leak in public repository:
- Confidentiality: 2 (internal employee operational data accessible; no confirmed customer access).
- Integrity: 0.
- Availability: 0.
- Data subject exposure: 1 (small volume of employee personal data; no special category).
- Regulatory clock exposure: 0.
- Customer-facing visibility: 0.
- Reputational risk: 1 (low likelihood of press or social visibility).
- Financial exposure: 1 (low recovery cost).
- Recovery time pressure: 2 (moderate; credential rotation is fast but exposure window matters).
- First-group severity: 2 -> Sev2.
- Second-group weighted sum: (0 * 1.0) + (0 * 1.0) + (1 * 0.8) + (1 * 1.0) + (2 * 0.7) = 3.2 -> Sev3.
- Final severity: max(Sev2, Sev3) = Sev2.
- Final published severity: Sev2.
- Response posture activated: Sev2 posture from Section 8.
12. Rubric governance and review cadence
Close the rubric with the governance shape that keeps it current. Without explicit revision triggers and ownership the rubric drifts as the estate, the regulatory environment, and the team change, and the responder reads a classification scheme that no longer matches the world.
Ownership:
- The rubric owner role: {{RUBRIC_OWNER_ROLE}} (typically the security operations leader or CISO).
- Co-owner roles: privacy officer (data subject and personal data dimensions), legal counsel (regulatory clock dimension, materiality posture), communications lead (customer-facing visibility and reputational risk dimensions), engineering leader (availability and recovery time pressure dimensions).
- The owner signs the rubric at every revision; co-owners co-sign on revisions affecting their dimensions.
Revision triggers (event-driven; the rubric does not wait for the calendar):
- Every actual incident produces a revision pass: did the rubric classify defensibly under live conditions, did any dimension prove ambiguous, did the composition rule produce an unexpected result, did the response posture match the band.
- Every tabletop exercise produces a revision pass: did the rubric classify the scenario the same way the IC and the leadership chain expected.
- Every regulator interaction or audit observation that touches incident classification produces a revision pass.
- Every material estate change (new business unit, new sector exposure, new regulator scope, new sector overlay activation, significant technology change) produces a revision pass.
- Every change to the parent IR plan or the per-scenario runbook portfolio triggers a rubric review for consistency.
Scheduled review cadence:
- Annual structured review even when no event-driven revisions have fired in the period.
- Quarterly governance review reads the rubric application against actual incident composition by band, by dimension, and by reclassification frequency.
- The audit committee receives the rubric revision log on the quarterly governance cycle.
Training cadence:
- New on-call role onboarded against the rubric within the first thirty days; calibration exercise against the worked examples in Section 11.
- Annual rubric refresher for every role with classification authority.
- Post-revision briefing for every classification-authorised role within thirty days of revision publication.
Exercise rotation:
- The rubric is included in the tabletop exercise programme at least annually; at least once across each major scenario class in the runbook portfolio.
- Tabletop after-action reports drive the next rubric revision pass.
Cumulative observation reading (read at the quarterly governance review):
- Per-band incident composition over the rolling twelve months: does the firm's incident profile match the band distribution the rubric design expected.
- Reclassification frequency: are reclassifications running at a rate that suggests the activation declaration is consistently wrong, the composition rule is producing fragile results, or scope is consistently slow to bound.
- Per-dimension scoring drift: are any dimensions consistently scored at the extreme bands across many incidents in a way that suggests a calibration issue.
- Edge-case invocation: which edge-case decision tree entries are firing repeatedly and whether the resolution remains right.
- Cross-rubric consistency: does the incident severity rubric remain consistent with the vulnerability severity policy, the breach notification rubric, and the financial materiality framework.
Seven failure modes the rubric has to design against
The classification rubric fails the audit read and the live-incident read in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before you customise the rubric so the customisation does not weaken the discipline that makes the classification defensible.
Single-axis severity that collapses multi-dimensional events
The rubric scores only impact or only urgency and assigns the same band to a confidentiality-only event and an availability-only event, even when the response posture should differ. The fix is the multi-dimensional scoring in Section 3 with the composition rule in Section 5 that distinguishes the dimensions before composing the band.
Severity declared by whoever is on the bridge first
The activation declaration defaults to the first responder online because the rubric does not name the authority. The first declaration is whatever feels reasonable and the response posture fires from a guess. The fix is the named activation authority in Section 6 with the explicit time budget.
Upward-only ratchet that traps the response in an over-classified band
The rubric does not authorise downward reclassification, so initial conservative declarations stay at the inflated band even when scope confirms a narrower scope. The response runs at higher posture than the confirmed scope justifies, consuming resources and leadership attention disproportionately. The fix is the explicit downward reclassification triggers in Section 7 with the same activity log discipline as upward reclassification.
Ambiguity resolved by improvisation rather than by named resolution
The rubric stops at the bands and dimensions and leaves the responder to improvise edge cases under pressure. The improvisations drift toward under-classification because the responder defaults to the lower-effort response posture. The fix is the edge-case decision tree in Section 9 with named resolutions for the recurring edge patterns.
No published response posture per band
The rubric assigns the band and stops; the responder has to compose the response posture under pressure from memory or from the IR plan in a separate document. Pager fan-out, executive engagement, customer-facing communications, and regulator clock starts run inconsistently. The fix is the severity-banded response posture in Section 8 published on the rubric itself.
Rubric frozen at first publication
The rubric is published at programme launch and never revised. The estate, the regulatory environment, the sector overlays, and the team change underneath, and the responder reads a classification scheme that no longer matches the world. The fix is the event-driven revision triggers in Section 12 with the captured revision history.
No quarterly observation reading of cumulative classification behaviour
The rubric is treated as a static document rather than as a programme artefact whose application is monitored. The leadership and the audit do not read per-band composition over time, reclassification frequency, per-dimension scoring drift, or edge-case invocation patterns. Drift accumulates invisibly until a real incident reveals the gap. The fix is the cumulative observation reading at the quarterly governance review in Section 12.
Ten questions the quarterly governance review has to answer
Operational review keeps the rubric current. Governance review answers whether the rubric is delivering durable classification discipline or accumulating drift the audit will read as procedure-on-paper. Run these ten questions at every quarterly review and capture the answers in the governance record on the workspace.
1.What is the rubric application rate against activated incidents in the rolling twelve months and how does it compare to the prior twelve months.
2.What is the per-band incident composition in the rolling twelve months and does it match the band distribution the rubric design expected.
3.What is the reclassification frequency and how does the upward-to-downward ratio compare to the prior period.
4.Which dimensions are consistently scored at the extreme bands in a way that suggests a calibration issue rather than a real signal.
5.Which edge-case decision tree entries are firing repeatedly and is the resolution still right.
6.How many activations in the rolling twelve months had a suspected-only declaration that proved out as confirmed, and how many proved out as false-positive.
7.How many activations had an unknown-scope uplift applied at declaration and how many were reclassified down once scope was confirmed.
8.How many reclassifications in the rolling twelve months were triggered by privacy officer scope determination, legal counsel clock determination, customer-facing visibility confirmation, or sector overlay activation.
9.Which rubric revisions in the period were triggered by a real incident, by a tabletop after-action item, by a regulator interaction, or by a material estate change.
10.Does the incident severity rubric remain consistent with the vulnerability severity policy, the breach notification rubric, the financial materiality framework, and the per-scenario runbook activation criteria.
How the package pairs with SecPortal
The template above is copy-ready as a standalone artefact. If your team already runs incident records, document custody, and severity reporting on a workspace, the rubric application becomes a byproduct of the work rather than a separate evidence project. SecPortal pairs every rubric application to a versioned engagement record through engagement management, so the per-dimension scores, the composed band, the activation declaration, the reclassification trail, and the framework expectations the rubric evidences live alongside the rest of the engagement record rather than scattered across a chat channel, a wiki page, and a shared drive.
The document management feature holds the rubric itself, the worked examples, and every prior rubric version retained per the audit evidence retention policy. Access to the rubric is gated by role-based access control through team management and protected by multi-factor authentication. The activity log captures the timestamped chain of state changes by user with 30, 90, or 365-day retention windows depending on the plan, so the initial declaration, every reclassification, the per-dimension score updates, and the trigger reasons are all observable rather than asserted. The notifications and alerts feature dispatches the severity-banded pager fan-out and escalation per Section 8 with the same audit trail.
Action items emerging from rubric application (post-incident review action items, rubric revision candidates, dimension-calibration adjustments) live alongside vulnerability findings on the same workspace through findings management, each carrying a CVSS-aligned severity, a named owner, a target close date, and an evidence-of-closure requirement. The compliance tracking feature maps the rubric application to ISO 27001, SOC 2, Cyber Essentials, PCI DSS, and NIST frameworks with CSV export, so when an auditor asks how the firm classifies a ransomware event, a customer data breach, or a third-party compromise, the rubric version, the per-dimension scores, the composed band, and the reclassification trail are one query against the same data. The AI report generation workflow produces a draft post-incident report and a leadership summary from the same engagement data so the audit committee read of incident classification discipline and the operational read are the same record rather than two independently edited documents that diverge between reporting cycles.