Support teams hear the same questions again and again, and the people who ask them are usually worried rather than curious. Over the past year, customers who run managed services have asked us a growing number of questions about monitoring for security problems: who watches, what counts as an emergency, how we know that someone looked. Behind those questions sits an area called SOC Ops. Below are our answers to the most frequent ones, drawing on the Ops Atlas as a reference and keeping the tone as plain as a phone call at the end of a shift.

What does SOC Ops actually mean?

It means running a security operations centre as an ongoing service, with people, procedures and measurements, instead of treating it as a set of tools. The entry we rely on, the Ops Atlas page that defines the discipline, is open about the name: the work is long established, but the label is the Atlas’s own and other sources use different terms. For a customer it comes down to something simpler. Alerts arrive; somebody decides what each one is; the decision is recorded; the next person can see it.

Is a SOC the same as the team that keeps my servers running?

No, and the confusion is common. The team that keeps services up works in an operations centre of its own, watching availability. The security team asks whether someone hostile is present. They share data and sometimes people, but they carry different urgency. If you ring us about a slow website, you want the first group. If you ring about a login from somewhere unexpected, you want the second.

How can you tell a real problem from a false alarm?

We rarely use the words “false alarm” any more. The Atlas recommends four outcomes for every alert: a confirmed problem, real activity that turned out harmless, a mistaken detection, or undetermined. The middle category surprises people. Research the Atlas cites suggests that much of what teams call false positives is actually legitimate activity needing context, such as an administrator working late. The fix for that is to improve our notes on your environment, not to switch the detection off.

How fast will someone respond?

Honest answer: it depends on severity and on which clock you mean. The Atlas separates the time until a human first acts from the time until a decision. As an example of targets, it sketches a top-priority case, a high-severity alert on a critical asset, triaged within fifteen minutes, decided within four hours, with pre-approved containment inside thirty. Your agreement may differ. We would rather commit to numbers we can show than to a vague promise of “immediate”.

Why do you report medians instead of averages?

One very old ticket can distort an average beyond use. The Atlas quotes an observation from MITRE that a single two-day-old email can wreck a mean response figure. We report a typical value and a slowest-tenth value for each shift, so a quiet Tuesday afternoon cannot mask a bad Sunday night.

Does somebody watch at night?

If you only ask one thing, ask this, of every provider, ours included. Round-the-clock cover is expensive: the Atlas gives a figure of roughly five full-time people to keep one seat occupied all day and all night, with at least two analysts on shift at any time. If a service claims overnight monitoring with a very small team, ask how it is possible and where the gaps are.

What happens when your shift ends?

We keep a shared handover record. The people leaving and the people arriving both sign it, and anything the incoming crew has not explicitly accepted stays with the person who is leaving. That rule comes from the Atlas, and it has saved us from more than one dropped ticket. Customers sometimes ask whether this is overkill. It takes minutes, and the alternative is a ticket that no one owns.

Can software handle all of this?

Software helps a great deal, and it also fails quietly. The Atlas is careful: tools that enrich and group alerts earn their place, but automatic actions should be limited to rules that have proved themselves and to low-importance devices, with a cap on how many can fire at once. Anything involving your critical systems waits for a human. A related caution is that dashboard figures counting automated touches as triage flatter the numbers without helping anyone.

Have missed alerts ever caused real harm?

Public reviews say yes. The Atlas cites the 2013 retail breach examined by a US Senate committee, where security tools raised warnings on the malware and the staff did not act on them. It also cites a 2023 government email case reviewed by the Cyber Safety Review Board, where a custom detection spotted the intrusion even though the same rule had produced false alarms before. The point for support is that an alert only has value when a person reads and decides.

How does this fit with the rest of our service?

Monitoring for security sits beside the practices described in our overview of delivery principles, and teams that treat infrastructure as code will find that the reasoning behind moving from code-defined infrastructure to reliability practice shares the same instincts: write it down, measure it, and make the next change safer than the last.

What should I ask my own provider?

• Do you record a reason with every closed alert?
• What are your times to first human action, by shift?
• Who is on duty at weekends, and how many?
• How do you hand work across shifts?
• If I outsource monitoring to you, who remains accountable for my systems? (The Atlas, quoting MITRE, says the owner does.)

Questions are welcome at any hour, and so are the awkward ones. The strongest support conversations we have had began with someone saying, “I don’t understand this, can you explain it?” That is exactly the attitude the discipline rewards.