What mistakes should you avoid when implementing a managed SOC?
Partial coverage, vague escalation, unmanaged false positives, an uninformed client: the managed SOC implementation mistakes MSPs make, and how to avoid them.
The most common managed SOC implementation mistakes are organisational: incomplete coverage, a vague escalation procedure, on-call contacts who do not answer, false positives left unmanaged, and a client who has not been told what is changing. You avoid them by preparing the kick-off properly and scheduling a review after the first few weeks.
This article complements our guide How to implement a managed SOC, which walks through the process step by step.
Mistake 1: connecting part of the estate and forgetting the rest
A SOC only monitors what is connected to it. An old server, a director’s laptop still running a different antivirus, a secondary Microsoft 365 tenant: each gap becomes a blind spot, and often the first one an attacker finds.
How to avoid it: start from an up-to-date inventory, compare the number of reporting agents with the number of real devices, and chase the gap until it reaches zero. What to prepare is listed in What information should you give a managed SOC at onboarding?.
Mistake 2: watching endpoints only
The EDR is the foundation, but many attacks go through identities: stolen passwords, sign-ins from unusual countries, mail forwarding rules. Connecting endpoints only means ignoring part of the attacker’s path.
How to avoid it: connect email and the collaboration suite (Microsoft 365 or Google Workspace) from day one and, where possible, the firewall. Cyna has ready-made connectors for Microsoft 365, Google Workspace, and Stormshield and Fortinet firewalls. See also Do you need an EDR for a managed SOC?.
Mistake 3: a vague escalation procedure
The SOC spots an attack at 2am. Who does it call? Is it allowed to isolate the laptop? If those questions have no written answer, containment waits and the attack spreads.
How to avoid it: before go-live, write down severity levels, pre-approved actions and the contact chain, then test them. The method is set out in How do you build an escalation procedure with a SOC?.
Mistake 4: on-call contacts who never pick up
A generic number that goes to voicemail at night, a contact who has left the company, a list nobody updates: the procedure exists, but nobody answers.
How to avoid it: name a primary contact and a deputy, check the numbers during a drill, and make updating contacts mandatory whenever the team changes.
Mistake 5: ignoring early false positives
In the first weeks, the SOC is learning the environment: admin tools, internal scripts, niche business software. Some legitimate activity triggers alerts. If nobody deals with them, people get tired of the noise and stop reading alerts altogether.
How to avoid it: document normal tools and practices from the start and book a tuning review with the SOC. See How do you handle false positives when a SOC goes live?.
Mistake 6: not explaining the change to the client
The end client sees a laptop isolated or a session cut without warning, and calls the helpdesk about an “outage”. Or they assume nothing can go wrong now that there is a SOC.
How to avoid it: explain to the client what the SOC does, what it does not do, what can happen during an alert and who will tell them. A managed SOC replaces neither backups, nor patching, nor user awareness. For organisations in scope of NIS2, these sit within a wider set of measures laid down in Article 21 of the directive.
Mistake 7: never reading the reports
Monthly activity and vulnerability reports only help if someone reads them. Reported vulnerabilities stay open, and the client never sees the value of the service.
How to avoid it: hold a regular review, internally and then with the client, of incidents handled and vulnerabilities to fix. Cyna’s reports can be exported as CSV or PDF, white-labelled, so the MSP can present them to its clients.
At a glance
| Mistake | Fix |
|---|---|
| Partial coverage | Inventory and gap tracking |
| Endpoints only | Identities, email and firewall from day one |
| Vague escalation | Written, tested procedure |
| Unreachable contacts | Primary, deputy and a drill |
| Ignored false positives | Scheduled tuning review |
| Uninformed client | Clear explanation of the service and its limits |
| Unread reports | Regular review with the client |
Talk to an expert
Preparing a managed SOC rollout and want to avoid these pitfalls? If you work with a Cyna partner MSP, start the conversation with them. If you are an MSP, or do not have a partner yet, get in touch.
Frequently asked questions
Can you start a managed SOC on part of the estate only?
Yes, as a pilot. But treat it as one, with a date for extending to the rest of the estate, and tell the client: devices that are not covered are not monitored.
How long does the tuning phase last?
It depends on the size and variety of the estate. What matters is scheduling a review with the SOC after the first few weeks. See How do you handle false positives when a SOC goes live?.
Should the client's end users be told?
It helps to explain that a laptop may be isolated or a session cut during an alert, and who to call if it happens. That way, a containment action is not mistaken for an outage.
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.