How do you choose a SOC provider?

To choose a SOC provider, check five things: genuine 24/7 monitoring by the provider’s own analysts, a scope that matches your IT estate, the ability to handle incidents rather than just flag them, written service commitments, and hard evidence (certifications, sample reports, a pilot). Price comes next, and only on a like-for-like scope.

This guide is the starting point of our series on choosing a managed SOC. Each criterion links to an article that goes deeper. If you are new to the subject, start with What is a managed SOC?.

Before comparing: define what you need

Offers are hard to compare when the need is unclear. Three questions first:

1. Should you outsource at all? An in-house SOC means hiring, training and rostering a team around the clock. For most organisations, outsourcing is the realistic option. See Should you outsource your SOC?.
2. What size, what risks? An SME has different needs from a large group, but faces the same attacks. See Do SMEs need a SOC? and, more broadly, Cyber security for small business.
3. What obligations? If NIS2 applies to you, incident handling and fast reporting (an early warning within 24 hours, Article 23) become requirements. See Does a managed SOC help with NIS2?.

If you are looking for a wider security partner rather than just a SOC, see How to choose a cybersecurity service provider.

Eight criteria for choosing a SOC provider

1. Real 24/7 coverage

Attacks ignore office hours: many start at night, at weekends or during holidays. “24/7” can hide an on-call phone line overnight, or automated detection with no analyst behind it. Ask who looks at alerts at 3am and what they are allowed to do. See 24/7 SOC vs business hours monitoring.

2. Named teams and a clear location

Who are the analysts? Are they the provider’s employees or a subcontractor’s? Where are they based, and where is collected data stored? These questions affect service quality, confidentiality and data sovereignty. See Why choose a European SOC provider?.

3. The right monitoring scope

A SOC is only useful for what it can see. Check which sources are covered: endpoints and servers (through an EDR), email and identities (Microsoft 365, Google Workspace), firewalls, cloud. Ask which tools are natively integrated, what connecting a new source takes and what stays out of scope. See What does a managed SOC monitor? and Do you need an EDR for a managed SOC?.

4. Genuine incident response capability

This is the most underrated criterion. Some providers detect, send an email and leave the client on their own. Others isolate the machine, block the account and bring in an investigation team. Ask what is included, how fast, and whether incident response needs a separate quote in the middle of a crisis. See Assessing a SOC provider’s incident response.

5. Written service commitments

Response, triage and notification times for a critical alert belong in the contract, along with how they are measured. A vague promise (“as soon as possible”) protects nobody. See What SLAs should you expect from a managed SOC?.

6. Relevant certifications

ISO 27001 certification shows the provider manages its own security in a structured way. Some countries run their own schemes: in France, ANSSI qualifies security incident detection providers (PDIS), a qualification required in specific contexts such as French operators of vital importance. NIS2 does not require it. See Should you require a PDIS-qualified detection provider?.

7. Useful reporting

A good monthly report says what was detected, what was handled and what still needs fixing. Management should be able to read it, not just engineers. Ask for anonymised samples. Reports also serve as evidence in audits and regulatory checks.

8. The right relationship model

Who signs the contract, who invoices, who calls the client during an incident? For a business that already works with an MSP, it is often simpler for the SOC to come through them. See Managed SOC and MSP: who does what?.

Summary table

Criterion	Question to ask	Answer that should worry you
Coverage	Who handles a critical alert at night or at weekends?	”It will be picked up next morning”
Teams	Are your analysts your own staff? Where are they?	Vague answer or undisclosed subcontracting
Scope	Which sources do you integrate natively?	”Everything is compatible”, with no list
Incident response	What do you do after detection?	”We send you an alert”
SLAs	Which response times are in the contract?	No figures at all
Certifications	Which certifications, covering what scope?	Certification with no stated scope
Reporting	Can you show a sample?	Refusal, or a purely technical dump
Exit	How do we get logs and reports back at the end?	No reversibility clause

For a fuller list, see Questions to ask a SOC provider and Red flags in a managed SOC offer.

Extra criteria for MSPs

An MSP choosing a SOC provider for its clients has further needs:

• A multi-tenant console: one interface for all clients, strict separation between them and per-user permissions. See Why MSPs need a multi-tenant SOC.
• White-label reports: the MSP hands them to clients under its own brand.
• Fast onboarding: each new client should connect without a heavy project.
• Respect for the client relationship: check how the provider organises the relationship with the MSP’s clients, and who owns it.
• Enablement: technical and sales training, and support in client meetings.

See also SOC for MSP: what it is and how it works and What is an MSSP?.

What drives the price

Comparing prices without comparing scope is meaningless. The main factors:

• the number of endpoints, servers and users monitored;
• the sources connected (EDR, email, firewalls, cloud);
• whether EDR licences are included;
• hours of coverage;
• whether incident response is included or billed by the hour;
• the level of reporting and support.

A cheap offer that excludes incident response can turn expensive on the day of an attack.

A five-step selection process

1. Write down the need: scope, regulatory constraints, in-house resources.
2. Shortlist two or three providers against the criteria above.
3. Ask each one the same questions, in writing, to compare like for like.
4. Run a pilot on a limited scope: alert quality, responsiveness, clarity of communication.
5. Read the contract closely: SLAs, incident response, reversibility, data location.

Common mistakes

• Choosing on price per endpoint alone, without checking what that price actually covers.
• Confusing a tool with a service: an EDR console nobody watches at night is not a SOC.
• Ignoring the first weeks: a SOC needs tuning to cut false positives, and the provider should explain how it handles that phase.
• Forgetting the exit: without a reversibility clause, changing provider later becomes painful.

What Cyna offers

Cyna is a 24/7 managed SOC run from France by in-house teams, and certified to ISO 27001. Cyna’s certifications and security documents are available on its Trust Center. Its 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. Human analysts review every alert.

Cyna integrates natively with two EDRs, SentinelOne and Microsoft Defender. Connectors are ready for Microsoft 365, Google Workspace and Stormshield and Fortinet firewalls, and connecting an environment is quick. The multi-tenant platform produces exportable white-label reports. The terms (scope, licences) are set out in the contract agreed with your partner MSP.

Cyna works through its partner MSPs, which own the relationship with their clients: contract, invoicing and reporting. Its Cyna Ignite partner programme supports them with, among other things, training, marketing kits and help in client meetings.

Talk to an expert

Comparing SOC providers? If you work with a Cyna partner MSP, they are your first point of contact. Are you an MSP looking for a SOC for your clients? Get in touch.

Frequently asked questions

What is the difference between a SOC provider and an MSSP?

An MSSP offers a range of managed security services, often including a SOC. A SOC provider specialises in detection and response. See What is an MSSP?.

Should we run a trial before signing?

It is a good idea. A pilot on a limited scope shows alert quality, responsiveness and report clarity far better than a sales deck.

Can a SOC provider work with our current EDR?

That depends on the integrations it supports. Ask for the exact list of natively integrated tools and what happens if yours is not on it: migration, licences, lead time.

How long is a typical SOC contract?

Terms vary between offers. Focus on exit conditions: handover of logs and reports, notice period and support during transition.