Let’s talk about SOC Ops without the jargon. If you work anywhere near a hospital, clinic or digital health service, you have probably heard someone say “we have a SOC” with the same confidence as “we have a fire exit”. This friendly explainer unpacks what that room does, how it should be run, and which questions are worth asking. It deals with computer systems and administration only; there is no medical content here.
The switchboard picture of SOC Ops
Imagine the hospital’s old telephone switchboard. Calls arrive, a person decides who needs to hear about each one, and a log notes what happened. A security operations centre works in a similar spirit, except the calls are automated warnings from computers, accounts and networks. SOC Ops is simply the craft of running that switchboard so it is dependable: warnings get looked at promptly, decisions are written down, and the next shift knows what the last one did.
The Ops Atlas, a reference site we lean on for definitions, describes its SOC Ops entry in exactly these terms: a service, not a gadget. We like that framing because it keeps attention on habits rather than on shiny tools.
Three things it is not
Names cause confusion, so here are the common mix-ups the Atlas helps untangle.
- It is not a network operations room. That team keeps links and servers running; the security desk asks whether something suspicious is happening on them.
- It is not the audit report with a similar number on it. That is an assurance document about a company’s controls, produced by accountants, and has nothing to do with a staffed room.
- It is not the same thing as the wider working arrangement between security and IT. That arrangement decides who patches what; the desk watches and decides what each alert means.
What happens to a warning
In a well-run centre, a warning is first enriched, meaning someone or something attaches background such as which department the device belongs to. Then a person decides one of four things: this is a real problem, this is real activity but harmless, the detector got it wrong, or we cannot tell yet. The decision and a short reason are recorded. If it is a real problem, it moves up to a more experienced colleague.
The four-way choice is the clever bit. If you only have “real” and “false”, the harmless-but-genuine cases pile up in the wrong bucket and people assume the detectors are broken when what is missing is context. The Atlas cites research from several operations centres suggesting that this is common.
How fast is fast enough?
Speed targets depend on how important the thing at risk is. The Atlas gives an example matrix where the most serious alerts on the most important systems get looked at within a quarter of an hour, receive a decision within a few hours, and have pre-approved protective steps ready within half an hour. Lesser alerts get longer. The point is not the exact numbers, which are examples, but that the targets are written down in advance so nobody improvises at night.
A related rule: declare an incident when events meet criteria that were agreed on paper beforehand. This stops a debate in the middle of the crisis about whether it counts.
Who works there, and when?
People. Round-the-clock cover needs far more than one person per seat; the sources the Atlas summarises put it at about five full-time staff for a single seat watched continuously, with at least two on duty at any time. Staff are often organised in tiers, with first-line triage, deeper investigation and a few specialists. The Atlas insists the first tier should be a place people want to grow from, because tired, undervalued staff make poor calls.
If you are a smaller organisation, you may buy this as a service instead. That is perfectly sensible, but the accountability does not travel with the contract. Executives and system owners remain answerable, so ask for the same outputs you would expect in-house: recorded decisions, fair measures and clean handovers.
A tiny made-up example
Suppose, purely as an illustration, that a records system reports a login from an unusual place at an odd hour. The first-line person checks the enrichment: the account belongs to an administrator who is travelling, and a leave calendar confirms it. The case is closed as genuine-but-harmless with the reason written beside it. Next month, someone sorting closures by reason notices that travel alerts are a big slice of the pile, and a simple feed of approved trips is arranged. Nothing dramatic happened, yet the desk got quicker and quieter, which is the entire point.
The life of a new desk
The Atlas describes three phases. On day zero you design it to suit the real risks of your organisation, because there is no one-size-fits-all. Day one is the stand-up, where you gather a baseline of normal behaviour, which cannot be built in a day. On day two you run it: weekly numbers, a regular tuning loop and practice exercises. Treat it as a living service and it will improve; treat it as a project that ends and it will decay.
Things to watch for
A good habit for any non-technical reader is to ask to see one ordinary day. Not the calmest day, not the worst, just last Tuesday: how many alerts arrived, how each was closed, who handed over to whom. A team that can show this calmly, with reasons attached, is usually in better shape than one with an impressive dashboard and no records behind it.
Warning signs the Atlas lists include queues nobody triages, closures with no reason, unwatched nights and contracts that pay for speed alone. A target focused purely on closing quickly encourages shortcuts, and counting automatic tagging as a human look inflates the picture. Keep metrics at the team level and report the typical wait together with the slow tail rather than a single average.
We wrote about the broader digital side of a modern organisation in how engineering discipline shapes an organisation’s digital ecosystem, and the same mindset applies here. Our plain-definition style, seen in entries such as our reference-style cardiology definition pages, is what we are borrowing for this subject: short, careful and honest about limits.
That is the whole idea in a few minutes. This is general information on how monitoring services are organised and is not technical guidance for a specific system or any health advice.
