I’ve spent years working in a Cybersecurity Operations Center, much of that time in a 24/7/365, follow-the-sun model. There is always someone watching, always someone available, and always someone expected to respond.
That availability is essential to the mission. It also makes the SOC a convenient destination for work nobody else has figured out how to own.
A new alert needs monitoring? Send it to the SOC. A process needs coverage after hours? Send it to the SOC. Nobody knows who should review the notification, but someone probably should?
You can guess where it ends up.
Over time, “the SOC is always here” becomes the justification for an expanding collection of tasks, processes, and responsibilities. Some belong there. Others arrive because the SOC has capable people, answers the phone, and has historically been willing to help.
Eventually, being helpful turns into permanent ownership.
And that is how a security team becomes the catch-all for everyone else’s unresolved operating model.
Being available does not automatically make the SOC the right owner.
Before handing another process to the SOC, we need to ask a few basic questions:
- What is the security concern, and what makes it a cybersecurity responsibility?
- What decision or action do we expect the analyst to take?
- Does the SOC have the access, context, training, and authority to do that?
- Who owns the underlying system, service, or process?
- Who can the SOC call in the middle of the night when it needs help?
- What actually requires immediate attention, and what can wait until morning?
These questions should be answered before the first notification lands in the queue — not improvised by an analyst at 2 a.m.
If a task is important enough for the SOC to triage overnight, the team that owns the issue needs to be prepared to support that triage. That means a usable escalation path, clear expectations, and someone who can make a decision or take action.
“Have the SOC look at it” is not much of a response plan if the next step is “wait until the person who understands it gets to work.”
The SOC cannot be the only team expected to treat something as urgent.
There are legitimate reasons for a SOC to perform initial checks on an issue that ultimately turns out to be operational. We do not always know whether an outage, unusual behavior, or service disruption is cyber-related until someone investigates.
But that initial check needs a defined purpose and a clear handoff. It should not quietly become indefinite ownership of an operational problem.
If there is no meaningful cybersecurity decision to make, no useful action for the analyst to take, and no reason the work cannot wait until business hours, we should question why it is sitting with the SOC at all.
Every task we accept consumes attention that could be spent somewhere else.
A notification may take only a few minutes to review. Multiply that across shifts, systems, and years of accumulated responsibilities, and those minutes become a real demand on the team.
Analysts spend time opening tickets, looking up context, chasing contacts, and documenting that there was nothing they could do. Meanwhile, the work we actually need them focused on is still arriving.
We cannot keep adding responsibilities and act surprised when the team has less time for investigations, improvement, or training.
We also need to revisit the work that is already there.
Some processes landed with the SOC because it was the best option at the time. Maybe the organization was smaller. Maybe another team lacked coverage. Maybe someone agreed to help temporarily, and “temporarily” has now survived three managers and a platform migration.
That history explains how the work got there. It does not prove it should stay.
Periodically, we should ask whether those responsibilities still provide value to cybersecurity, whether another team is better equipped to handle them, and whether the process needs a different escalation path or automation.
This requires SOC leadership to push back constructively. Simply saying “not our problem” does not fix a broken process. Neither does accepting every piece of dumb shit because we happen to be awake.
The goal is to get the work to the right team, with the right expectations and the right support.
Sometimes that means the SOC owns it. Sometimes the SOC performs a specific initial check and hands it off. Sometimes the right answer is to help establish a process that never needs to touch the SOC.
We should be willing to help figure that out. We should also be willing to challenge arrangements that consume analyst time without improving security outcomes.
“Send it to the SOC” can be one step in a well-defined process.
It cannot be the entire operating model.
Originally published on Medium.