Incident procedure
This is the operational spine of a SOC. Every step names who does it, what it takes in, what it must produce, and when it is due. A step missing any of those four is a description of good intentions, not a procedure someone can execute at three in the morning.
Sequence
Note where the decisions sit. Steps 2, 4 and 5 are gates, and every gate has a written question — not a judgement call that varies by who is on shift.
Register the event in the incident management system, automatically or manually. Capture enough for later analysis: time observed, source, indicators, and the raw alert content.
Establish significance and truth. Determine whether the event is an obvious false positive, and whether it can be resolved under an existing playbook.
Gate: Is this an obvious false positive?
Where the event is unfounded, close it in the system — and record whether the detection rule needs improvement so the same false positive does not recur.
Gate: Does the detection rule need tuning?
Deeper assessment: examine the event context, likely threat vectors and impact on systems. Re-test the false-positive question where L1 could not answer it definitively.
Gate: Is this a genuine incident, and does it need escalation?
Unfounded incidents are closed with the tuning assessment recorded. Where scope, persistence or forensic depth exceed L2, escalate to L3 against the written trigger.
Gate: Does this exceed L2 capability or authority?
Inform the affected organisation through the channels its severity level mandates. Fix and record the awareness timestamp — this is what the statutory clock runs from.
Isolate affected systems or network segments, terminate malicious processes, block or restrict access, quarantine malicious files. Preserve evidence before destroying it.
Deep investigation and digital forensics: establish scope, root cause, dwell time, data affected and the full set of indicators. Maintain chain of custody throughout.
Submit the statutory notification and, for high and medium impact incidents, the investigation report. Whether the SOC or the organisation submits is set by the service agreement — settle it before you need it.
Coordinate restoration to normal operation, close the incident with a documented outcome, improve the detection rules that were involved, and assign owners and dates to the review actions.
Escalation
Escalation should never depend on how busy the analyst feels. Write the condition, and the escalation becomes a rule that can be audited rather than a habit that can drift.
In practice: Checks the alert against pre-prepared instructions, blocks a known malicious address, escalates when anything is unclear.
Escalates whenNo playbook covers the alert, the playbook's outcome is ambiguous, or the alert touches a system flagged as critical.
In practice: Performs memory analysis of the affected device, identifies the threat vector, coordinates containment actions.
Escalates whenScope crosses trust boundaries, the adversary shows persistence or evasion, forensic imaging or reverse engineering is needed, or legal or law-enforcement involvement becomes likely.
In practice: Performs full disk forensics, analyses complex malicious code, issues strategic recommendations for architecture improvement.
Escalates whenBeyond L3 the escalation is no longer technical — it goes to the SOC Officer, the CISO and the management body as a business decision.
Severity
Two things follow from a severity assignment, and both must be written down: how fast someone has to act, and how they are obliged to make contact. Critical is the level where email alone is not enough.
The service or a core function does not work, or repeatedly and regularly suffers problems that materially affect the ability to use and operate it.
Channel: Email and telephone — both, not either
Functionality is impaired, insufficient or difficult, so the service is hard but still possible to use; and/or there is uncertainty whether the data shown is accurate.
Channel: Email and/or telephone
Minor performance degradation, or minor issues requiring a check or a change of parameters.
Channel: Email and/or telephone
Demarcation
Half of a SOC's wasted capacity arrives as work that belongs elsewhere. Publish the routing table, and the argument only has to be had once.
| Request type | Goes to | Examples |
|---|---|---|
| Security incident | SOC | Malicious software, data leakage, unauthorised access, phishing attack, denial-of-service attack |
| Security request | SOC | Advice on secure software deployment, request to check a suspicious email, questions about security policy |
| IT problem / fault | IT service desk | Printer not working, software installation faults, network connectivity disruption, password reset |
| IT request / service | IT service desk | Ordering new software, granting access rights, preparing computer equipment |
Both severity scales are real, and they are not the same
The A/B/C scale above governs your service commitment — how quickly you respond and how you make contact. The statutory impact categories (high, medium, insignificant) govern your regulatory obligation — whether a report is owed at all. An incident can be severity C for the service and still be a high-impact incident for the regulator. Assign both, on every incident.
Where it breaks
An analyst decides an alert is nothing and moves on without writing it down. Later you cannot show the alert was seen, and cannot tell whether the rule fires 3 times a week or 300.
Fix: Every triage decision produces a record, including 'no action'.
An incident moves from L1 to L2 by a message in a chat channel. The handover is real but invisible, so ageing and MTTR are measured against the wrong timestamps.
Fix: Escalation happens in the incident record, with a reason and a time.
The same rule generates the same false positive every week. Nobody owns changing it, because closing the alert feels like completing the work.
Fix: A false positive closes with a tuning item or a dated, accepted exception.
The statutory clock runs from the moment the organisation became aware. If that moment is not deliberately recorded, you will be reconstructing it under pressure, in front of a regulator.
Fix: Awareness is a mandatory field, set once, never back-dated silently.