How should an MSP pitch a SOC offer to its clients?
Start from the client's priorities, show what the SOC does in practice, be clear about its limits and add it to the contract: how MSPs pitch a SOC offer.
When an MSP pitches a SOC offer, the starting point is the client’s own priorities (keeping the business running, questions from their customers, regulation). Then show what the SOC actually does day to day and during an alert, be upfront about what it does not do, and fold it into the existing managed services contract. The conversation stays the MSP’s, because the MSP keeps the relationship.
This article is part of our series on rolling out a managed SOC. For the full approach, see How to implement a managed SOC. For the wider picture of an MSP’s security portfolio, see How can an MSP build a cybersecurity offering?.
Start with the client’s priorities, not the technology
A small business owner does not buy “detection rules”. They want the business to keep running, their data to stay theirs and their customers to keep trusting them. Three questions open the conversation:
- What happens if your laptops or email are down for several days?
- Are your customers asking you about your security?
- Are you subject to regulation, directly or through your customers?
On that last point, Article 21 of NIS2 provides that organisations in scope address supply chain security, taking into account their suppliers’ cybersecurity practices. A supplier can therefore receive questions even if NIS2 does not apply to it directly. See Does NIS2 apply to me if my client is in scope?.
Show the service in action
A short scenario works best. For example:
- At 3am on a Saturday, a mailbox signs in from an unusual country and creates a forwarding rule.
- The SOC spots the anomaly, triages the alert and ends the session, as agreed in the pre-approved actions.
- The MSP’s on-call engineer is notified and resets the credentials.
- On Monday, the client receives a clear account of what happened.
This shows the value of 24/7 monitoring without drama. It also shows that the MSP stays at the centre: the MSP acts on the client’s systems and keeps the client informed.
Show what the client receives
The service must be visible outside incidents too. Bring a sample monthly report: monitored activity, alerts handled, vulnerabilities to fix. Cyna’s reports can be exported as CSV or PDF, white-labelled, and the MSP presents them under its own name. They also anchor the regular review with the client.
Be clear about the limits
A well-pitched offer says what it does not cover. A managed SOC does not replace backups, patching or user awareness, and no service guarantees that nothing will ever happen. Saying so does not weaken the pitch: it makes it credible, and it prevents misunderstandings after an incident.
| What the SOC provides | What still needs doing |
|---|---|
| 24/7 monitoring of connected sources | Backups and restore tests |
| Alert triage and first containment actions | Patching and updates |
| Incident response support | User awareness |
| Activity and vulnerability reports | Security policy and governance |
Fold it into the existing contract
For the client, the simplest option is for the SOC to sit inside the managed services contract they already know, with one point of contact and one invoice. What to cover (scope, escalation, personal data, exit) is set out in How do you include a SOC in a managed services contract?.
That is Cyna’s model: Cyna works through its partner MSPs, who own the relationship with their clients (contract, billing, reporting).
Get support for the first meetings
The first pitches are the hardest. Cyna’s Ignite partner programme offers sales training, marketing kits and the possibility of a Cyna expert joining client meetings to handle technical questions while the MSP leads the relationship.
Talk to an expert
Are you a client of a Cyna partner MSP? They are your first point of contact to find out more. Are you an MSP building your SOC offer? Explore the partner programme or get in touch.
Frequently asked questions
Should you offer the SOC to every client?
You do not have to, but a SOC presented as a natural step up in the contract, rather than an extra for a few accounts, is easier to explain and to run.
What do you say to a client who already has antivirus?
Explain the difference between a tool that blocks known threats and human monitoring that analyses behaviour and responds. See Antivirus vs EDR: what is the difference?.
How do you talk about price without downplaying or inflating it?
Tie it to what drives it: number of devices and accounts, connected sources, service level, support during incidents. The client then compares a described service, not a number on its own.
Will the client know the SOC is run by a partner?
With Cyna, reports are white-labelled and the MSP owns the whole relationship, but Cyna is named in the offer as the MSP's SOC. See How can an MSP resell a white label SOC?.
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.