You improve a security operations center by deciding what it must detect, collecting the logs those detections need, tuning detections against real threats, and measuring how fast it responds. More alerts do not help. Better-chosen logs and a clear operating model usually do.
What is a SOC for?
The UK NCSC's guidance on building a SOC says that while the primary goal of cyber security is to prevent attacks, this is not always possible. The role of a SOC is to limit damage by detecting and responding to attacks that get past preventive controls. It also says SOCs vary widely and there is no one-size-fits-all SOC, so the guidance helps you decide what type your organisation needs.
That makes the first question one of scope: what threats do you face, what assets do you hold, and what resources do you have? The NCSC calls the answer a target operating model, "the bedrock of a SOC".
Where do SOCs lose effectiveness?
Logs chosen by habit. Teams ingest what is easy, not what detects attacks. The NCSC's onboarding section introduces attack trees to decide log sources intelligently: start from how an attacker would reach a goal, then ask which logs would show each step.
Detections nobody tunes. A rule that fires hundreds of times a day, with no real incidents, teaches analysts to ignore it.
No map to threats. Without a reference such as MITRE ATT&CK, it is hard to say which behaviors you can see and which you cannot.
Slow, unclear response. NIST SP 800-61 Revision 3 places incident response inside the Cybersecurity Framework, so detection, response and recovery are planned together rather than as separate projects.
What does a constructed improvement look like?
Constructed example: a mid-sized firm's SOC receives 600 alerts a day. An analyst audit finds that 40 percent come from two rules. One flags every failed login, the other every port scan on the internet-facing range. Neither has produced an incident in a year. The team retires the first in favor of a rule on repeated failures followed by a success, and drops the second. Alert volume falls, and analysts have time to build a detection for a credential-theft path their attack tree shows is not logged at all.
What if you outsource part of it?
Many organisations buy monitoring from a provider and keep response in house. That can work, but the operating model still needs an owner on your side. Ask the provider which log sources it covers, how detections are chosen, and how quickly it contacts you. Agree what the provider may do on its own, such as isolating a host, and what needs your approval. The NCSC guidance is technology agnostic and focuses on operating model, so use its questions on a provider as well as on a team of your own.
How to improve it, step by step
- Write the target operating model: threats, assets, hours of cover, and who responds.
- Pick three likely attack goals, such as stealing credentials or deploying ransomware. Draw the path for each.
- For every step on the path, list the log that would show it. Mark what you do not collect.
- Onboard the missing logs, starting with identity, endpoints and the internet edge.
- Map each detection to ATT&CK techniques and note the gaps.
- Review every rule monthly: how often it fired, how often it led to action. Retire or tune the noise.
- Run an exercise from detection to containment, and record time at each step.
- Track a few measures: time to detect, time to contain and share of alerts that led to action.
Quick check
Does more log data make a SOC better?
No. Logs chosen from attack paths help. Large volumes of unrelated logs add cost and noise.
Should a small company build its own SOC?
It depends on threats, assets and resources. The NCSC says there is no one-size-fits-all SOC. Many smaller firms buy the service, and still need to own the operating model.
Sources
- NCSC, Building a security operations centre
- NIST SP 800-61 Rev. 3, Incident Response Recommendations
- MITRE ATT&CK, Command and Control (TA0011)
Last reviewed: 18 October 2026.
