Cyna
Detection and response · 5 min read

How do you train your team to work with a managed SOC?

Training a team to work with a managed SOC means learning to read alerts, follow escalation, act on SOC requests and use reports. Here is a practical programme.

MSP engineers trained to work alongside a managed SOC

Training your team to work with a managed SOC comes down to four skills: using the platform, following the escalation procedure, carrying out the first-response actions the SOC asks for, and making use of reports. The goal is not to turn engineers into analysts, but to make sure they can receive an alert, make a decision and act fast.

This article complements How to implement a managed SOC. It is written primarily for MSPs, whose teams are the day-to-day link between the SOC and their clients.

Who to train, and on what

RoleWhat they need to be able to do
Service desk and on-call engineersReceive an alert, judge urgency, carry out an action requested by the SOC
Technical leadApprove exclusions, decide on isolation, track vulnerabilities
Account managersWalk the client through monthly reports, explain what the service covers
LeadershipUnderstand their role in a serious incident and the decisions that are theirs

For leadership this is not just good practice: Article 20(2) of NIS2 provides that members of the management bodies of entities in scope follow cybersecurity training. Whether and how it applies to a given organisation is a question for its legal adviser.

Module 1: the platform

Start with the console. On the Cyna platform, a single console covers all of an MSP’s clients, with strict tenant separation and permissions set per user. Cover the following:

  • moving between clients and filtering alerts;
  • understanding severity levels and incident statuses;
  • reading the vulnerability dashboard;
  • exporting monthly reports as CSV or PDF, white-labelled.

The Cyna Ignite partner programme provides for platform onboarding and technical sessions; the details are set out in the partner programme.

Module 2: the escalation procedure

This is the heart of the training. Every engineer should know, without looking it up:

  1. Who the SOC calls, in what order and at what hours.
  2. What is expected of them by severity: information only, a check, or immediate action.
  3. Who they need to inform in turn, at the MSP and at the client.
  4. When a situation becomes incident response, with the CERT involved.

Write the procedure before the training, not during it. See How to build a SOC escalation procedure.

Module 3: first-response actions

When the SOC detects an attack, it may, depending on what has been agreed, act directly through the EDR (isolating a device, killing a process). Other actions sit with the MSP or the client: resetting a password, disabling an account, cutting VPN access, warning a user. Your team needs to know these actions and be able to carry them out at 3am as well as 3pm.

One caution: do not wipe the evidence. Reimaging a compromised machine before analysis destroys useful traces. See How to contain a system without destroying evidence and What happens when a managed SOC detects an attack?.

Module 4: reports and false positives

Your team should be able to read a monthly report and turn it into actions: accounts to disable, patches to apply, rules to tune. They should also know how to flag a false positive to the SOC with the right context (a legitimate scheduled task, a known admin tool) rather than simply ignoring the alert. See How to handle false positives when a SOC starts.

Learn by doing

A presentation is not enough. The most effective format is a simulated incident: the SOC sends a mock alert, the team runs the procedure, then everyone debriefs. NIST guidance (SP 800-61 Revision 3) stresses preparation and continuous improvement of incident response, and an exercise is exactly that.

These exercises quickly expose practical gaps: a wrong on-call number, an engineer without console access, an isolation decision nobody feels able to take. They are classic mistakes, covered in Managed SOC implementation mistakes to avoid.

Talk to an expert

Want to organise training so your team works smoothly with a managed SOC? If you already work with a Cyna partner, they are your first point of contact. Otherwise, get in touch.

Frequently asked questions

How many people at the MSP should be trained?

At least everyone who might take a call from the SOC, including on-call staff. A single trained person becomes a bottleneck at night, at weekends and during holidays.

Should sales staff be trained too?

Yes, on a different track: explaining the offer and what it covers. See How MSPs pitch a SOC offer.

Should the client's end users be trained?

Security awareness is still useful, but it is a separate topic. That said, the SOC may ask a user to confirm a sign-in or an email: users should know such a call is legitimate.

How often should training be repeated?

Whenever someone joins the team, and as a regular refresher, for example after a real incident or a change to the escalation procedure.

Sources & methodology
  1. Directive (EU) 2022/2555 (NIS2), Article 20(2) on management body training, EUR-Lex
  2. NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management, April 2025

This article provides general information for guidance only. It is neither legal advice nor a contractual commitment from Cyna: service terms are those of the contract agreed through your partner MSP. For any regulatory question, consult your legal adviser.

Ready to sign

The SOC your clients
will ask for tomorrow.

Let's plug in your first line in 30 minutes. Personalised demo, quote within 24h, end-to-end human support.

Reply within 24hISO 27001 certified24/7 managed SOC