How do you implement a managed SOC?

To implement a managed SOC, follow six steps: scope what needs monitoring, choose the SOC partner, gather the onboarding information, connect the data sources (EDR, Microsoft 365, firewalls), write the escalation procedure, then tune the alerts over the first few weeks. For an MSP, a commercial track runs alongside: building the offer and taking it to clients.

This article is the starting point of our series on implementing a managed SOC. Each step links to a dedicated article. For the basics, see What is a managed SOC? and SOC for MSP: what it is and how it works.

The six steps at a glance

Step	Goal	Owner	Dedicated article
1. Scope	Know what you monitor and why	MSP and client	Assessment first
2. Choose a partner	A SOC built for the MSP model	MSP	Choosing a provider
3. Prepare	Gather contacts, inventory, access	MSP	Onboarding information
4. Connect	Stream events to the SOC	MSP, with the SOC	Deployment time
5. Agree escalation	Who does what, and when	MSP, client, SOC	Escalation procedure
6. Tune	Cut the noise, keep the real alerts	SOC, with the MSP	False positives

Step 1: scope the perimeter

Before connecting anything, answer three questions: which systems to monitor, which threats matter most, and who decides during an incident. For a typical small business, the starting scope covers endpoints and servers (through the EDR), email and cloud identities (Microsoft 365 or Google Workspace) and the firewall.

Do you need a full assessment first? Not always. A light review is often enough to get going, with a deeper assessment later. We cover this trade-off in Do you need an assessment before a managed SOC?. To see what a SOC can observe, read What does a managed SOC monitor?.

If the client falls under NIS2, scoping can also take into account what the directive provides for: incident handling measures (Article 21) and reporting (Article 23 provides for an early warning within 24 hours, a notification within 72 hours and a final report within one month).

Step 2: choose the SOC partner

An MSP looking for a SOC needs something different from a large enterprise. It needs a provider that respects its client relationship, handles many clients from one console and delivers reports the MSP can pass on under its own brand. Selection criteria are covered in How to choose a SOC provider, and branding in White label SOC: how can an MSP resell one?.

In France, ANSSI’s PDIS framework sets out what is expected of a detection provider. Even where the qualification is not required, it is a useful benchmark wherever you operate. Cyna’s certifications and security documents are available on its Trust Center.

Step 3: gather the onboarding information

A SOC that does not know the environment it watches produces alerts of limited use. At onboarding, the MSP typically provides:

• contacts and call order, day and night;
• an inventory of critical assets (business servers, privileged accounts, executives);
• normal activity that might look suspicious (remote admin tools, scheduled scripts, logins from abroad);
• access to the consoles being connected.

The full checklist is in What information should you give a managed SOC at onboarding?.

Step 4: connect the data sources

This is the shortest step when the tools are standard. Cyna integrates natively with two EDRs, SentinelOne and Microsoft Defender, and has ready-made connectors for Microsoft 365, Google Workspace and Stormshield and Fortinet firewalls. Connecting an environment is quick when the tools are standard.

Two things to watch:

• Microsoft 365: according to Microsoft, auditing is not on by default for Business Basic, Business Standard and Business Premium licences. It must be turned on, which can take up to 60 minutes to take effect. See Managed SOC and Microsoft 365.
• Clocks and logs: ANSSI recommends synchronising device clocks and checking that the right logs are actually produced. Without this, rebuilding an incident timeline gets hard.

For the overall timeline, from signature to steady-state monitoring, see How long does it take to deploy a managed SOC?.

Step 5: write the escalation procedure

This step needs the most thought, and it is the one people most regret rushing. It answers simple questions:

• which actions the SOC takes straight away (isolating an endpoint through the EDR, disabling a compromised account);
• which actions need approval from the MSP or client (shutting down a production server);
• who to call, in what order, by severity and time of day.

The method is detailed in How to build a SOC escalation procedure. The split of roles is described in Managed SOC and MSP: who does what?.

Step 6: tune over the first weeks

In the first days, the SOC is learning the environment. Some legitimate activity triggers alerts: a remote support tool, an overnight backup, an admin script. Tuning means documenting these cases, adjusting the rules and making sure no real threat gets hidden along the way. See How to handle false positives when a SOC starts.

It is also the time to train the MSP’s team to read alerts and act on the SOC’s recommendations: How to train your team to work with a managed SOC.

The commercial track for MSPs

For an MSP, implementing a managed SOC also means launching a new service. Four workstreams run alongside the technical project:

1. Build the security offer: which services, in what order, for which clients. See MSP cybersecurity: how to offer security services to your clients.
2. Choose the branding model: reports under your name, SOC named as your partner. See White label SOC: how can an MSP resell one?.
3. Put it in the contract: contracts generally cover scope, service levels, responsibilities and data handling. See How to include a SOC in your MSP contracts.
4. Pitch the offer: talk about business risk and continuity rather than technology. See How do MSPs pitch a SOC offer to their clients?.

Cyna works through its partner MSPs, who own the relationship with their clients (contract, billing, reports). The Cyna Ignite partner programme supports these workstreams with platform onboarding, sales training, marketing kits and a Cyna expert who can join client meetings. See the partner programme.

The mistakes that derail a project

The same pitfalls come up again and again:

• connecting the EDR but forgetting cloud identities, even though many attacks start in the mailbox;
• signing without an escalation procedure, then finding at 3am that nobody answers;
• switching off detection rules too early to cut the noise;
• not deciding who reads the monthly reports and who acts on the vulnerabilities they flag.

We cover them, and how to avoid them, in Managed SOC implementation mistakes to avoid.

After go-live

Once monitoring has settled, the SOC runs continuously. The MSP receives triaged alerts and recommendations, carries out remediation on the systems it manages, and sends the client a monthly activity and vulnerability report. With Cyna, these reports export to CSV or PDF, white-labelled.

For serious incidents, Cyna’s CERT, a member of InterCERT France, works with the SOC teams and can be mobilised quickly. The incident response on-call team is available 24/7 from the Report an incident page. To see what happens during an attack, read What happens when a managed SOC detects an attack?.

The monthly report is also the natural moment to review the service with the client: incidents handled, vulnerabilities still open, changes coming up in the environment, and any adjustments to the monitored scope. A short, regular review keeps the SOC aligned with how the business actually works, and gives the MSP a concrete basis for recommending further improvements.

Review the escalation procedure and asset inventory regularly, and at the very least whenever a contact, a tool or the client’s organisation changes.

Talk to an expert

Planning a managed SOC for your organisation or your clients? If you already work with a Cyna partner, they are your first point of contact. Otherwise, get in touch.

Frequently asked questions

Do you need to change tools to implement a managed SOC?

Not necessarily. Cyna integrates natively with two EDRs, SentinelOne and Microsoft Defender. If the client has no EDR, the terms (scope, licences) are set out in the contract agreed with the partner MSP; if it runs another EDR, the question of migrating is looked at case by case. See Do you need an EDR for a managed SOC?.

Who leads the implementation project?

In the MSP model, the MSP does. It knows the client's environment, holds the admin access and owns the relationship. The SOC brings the method, the connectors and technical support.

Can you start with a single client?

Yes, and it is often the best approach for an MSP. A pilot client lets you refine the escalation procedure and the sales pitch before rolling out more widely. See How do MSPs pitch a SOC offer to their clients?.

Is a managed SOC enough for NIS2?

No. A SOC helps with incident handling and the Article 23 reporting deadlines, but the directive also provides for risk analysis, policies, training and governance. See Does a managed SOC help with NIS2?.

What does the client need to do during implementation?

Not much, but it matters: name a decision-maker who can approve disruptive actions, confirm which systems are business-critical and agree the out-of-hours contacts. The MSP handles the rest. See What information should you give a managed SOC at onboarding?.