How do you build an escalation procedure with a SOC?

To build an escalation procedure with a SOC, define a handful of severity levels, then for each one set who gets contacted, through which channel, how quickly, and which actions the SOC may take without waiting. Add on-call contacts and a rule for when nobody answers, then test the whole thing before go-live.

This article is part of our series on rolling out a managed SOC. For the full approach, see How to implement a managed SOC.

Step 1: agree severity levels

Everything starts with a simple scale shared by the SOC, the MSP and the client. Three or four levels are enough:

Level	Example	Expected response
Informational	Vulnerability to patch, configuration to review	Report or ticket, scheduled fix
Moderate	Suspicious software blocked by the EDR on one laptop	Ticket and check within the working day
High	Compromised Microsoft 365 account, infected endpoint	Call the on-call engineer, contain immediately
Critical	Encryption under way, several machines affected	Immediate call, CERT engaged

Use examples your engineers recognise. A scale with too many shades of grey leads to debate exactly when you need action.

Step 2: pre-approve actions

This is the heart of the procedure. For each level, decide upfront:

• what the SOC does on its own: isolate a device, disable a compromised account, force a sign-out;
• what needs the MSP’s sign-off: block a network flow, isolate a server;
• what needs the client’s sign-off: stop a business application or a production line.

The clearer the list of autonomous actions, the faster containment happens at night and at weekends. The wider split of responsibilities is covered in Managed SOC and MSP: who does what?.

Step 3: set up the contact chain

For each client, list the people to call, in order:

1. the MSP’s on-call number, one that actually rings at night;
2. a deputy, if the first contact does not answer within the agreed time;
3. a decision-maker at the end client, for heavy actions;
4. where relevant, the person in charge of personal data at the client (for example its data protection officer), if a data breach is possible.

Match the channel to the level: a ticket or email is fine for informational items, a phone call is a must for high or critical incidents. Set an expected response time and a default rule if nobody picks up: next contact, then the action agreed in advance.

Step 4: plan what happens next

A critical incident does not end with containment. The procedure states who decides to bring in an incident response team, who briefs the client’s leadership and who prepares any regulatory reports.

Those deadlines are tight. For organisations in scope of NIS2, Article 23 of the directive provides, for a significant incident, for an early warning within 24 hours, an incident notification within 72 hours and a final report within one month. For a personal data breach, Article 33 of the GDPR provides for notification to the supervisory authority within 72 hours of becoming aware of it. The SOC supplies the facts; these texts place the report on the organisation concerned, and its legal adviser can confirm what applies to it. See What happens when a managed SOC detects an attack?.

At Cyna, the CERT, a member of InterCERT France, works with the SOC teams and can be engaged quickly; it takes over from the SOC when an incident goes beyond containment. Cyna’s incident response on-call team is available 24/7 from the Report an incident page.

Step 5: test it and keep it current

A procedure that has never been used usually hides a flaw: a wrong number, a contact who has left, a pre-approved action nobody actually signed off. Before go-live, run a simple drill: the SOC simulates a high-severity alert and checks that the contact chain responds within the agreed time.

After that, review the procedure whenever a contact, supplier or critical system changes, and at least at each periodic review with the SOC. The information to gather at kick-off is listed in What information should you give a managed SOC at onboarding?.

Common pitfalls

• A single contact with no deputy: the incident lands during their holiday.
• No autonomous actions for the SOC: it detects the threat, then waits for a reply before isolating a laptop.
• Vague severity levels, read differently by each party.
• An untested procedure, discovered on the day of the incident.

Talk to an expert

Want to build or review your clients’ escalation procedures? If you work with a Cyna partner MSP, they are your first point of contact. If you are an MSP, or do not have a partner yet, get in touch.

Frequently asked questions

Who belongs on the escalation contact list?

At least an on-call contact at the MSP, a deputy, and a decision-maker at the end client who can approve a heavy action such as shutting down a production server.

Do you need a separate procedure for each client?

The template can be shared across all of an MSP's clients. Contacts, critical systems and pre-approved actions are specific to each client.

What happens if nobody answers at night?

The procedure must say: next contact on the list, then a default action agreed in advance. Without that rule, the SOC can be stuck at the very moment it needs to act.

Does the escalation procedure cover regulatory reporting?

It prepares for it. The SOC provides the timeline and facts; the texts (NIS2, GDPR) place reporting to the authority on the organisation concerned. See Is incident response mandatory?.