A NOC (Network Operations Center) is the team that makes sure the infrastructure works: the network, the links, the servers, the cloud services, capacity, backups and everything that has to be running for the company to work. Its daily question is just one: is everything up? A SOC watches something very different within that same infrastructure: whether someone is doing something they shouldn’t.
Put more briefly: the NOC makes sure the network works and the SOC makes sure no one breaks into it.
Confusing them costs nothing until the day it costs a great deal. It almost always goes the same way: the company contracts monitoring, sees green charts for months and assumes it is covered. What it bought watches for outages. An attack is not an outage.
What exactly does a NOC do?
A NOC operates availability. It is the permanent shift that watches the infrastructure dashboards and acts when something degrades or stops. In practice, it takes care of the following:
- Availability of servers, applications, internet links and links between sites.
- Capacity and performance: disks filling up, memory at its limit, rising latency, a link saturated at peak hours.
- Scheduled jobs that fail silently, starting with backups, the classic one nobody notices until a restore is needed.
- Hardware with symptoms: a redundant power supply that died, a disk with errors, a switch running at an unusual temperature.
- Certificates and licenses that expire, updates and maintenance windows.
- Escalation with providers: when the problem lies with the telecom carrier, someone has to open the ticket and chase it.
The reference framework most of these processes come from is not a cybersecurity framework; it is an IT service management framework. It is ITIL, with its vocabulary of incidents, problems, changes and service levels. It’s worth knowing, because it explains why a NOC and a SOC speak differently even when they look at the same machines.
And what does a SOC do that a NOC doesn’t?
The SOC starts from an uncomfortable assumption that the NOC doesn’t need to make: that there is someone on the other side. Not a component that failed, but a person with a goal, who hides, who learns from what you block and who prefers that everything look normal.
That’s why the SOC doesn’t check whether the server responds. It looks at who got in, from where, at what time, with which account, whether that account usually does that, and whether the volume of data that left makes sense. For that it uses SIEM, EDR, threat intelligence and threat hunting, and it is measured by its own metrics: MTTD and MTTR, how long it took to detect and how long to respond.
There is a fundamental difference between the two alarms. The NOC’s says “something broke.” The SOC’s says “someone may have broken it on purpose, and they may still be inside.”
What is the difference between a NOC and a SOC?
Side by side, it’s easier to see. They share screens, schedules and even providers, but little else:
| NOC | SOC | |
|---|---|---|
| What it watches | That the infrastructure is available and performing | That no one does anything improper inside it |
| What it is up against | Failures, saturation, human error, provider outages | An adversary who decides, adapts and hides |
| What it asks when an alert fires | What broke and how do I bring it back up? | Who did this, since when and how far did they get? |
| Typical tools | Network monitoring, ticket management, remote administration tools | SIEM, EDR and XDR, SOAR, threat intelligence |
| Primary metric | Availability and service restoration time | Incident detection and response time |
| First reflex | Restore service as soon as possible | Contain without destroying the evidence |
| When the work ends | When the service is back up | When it is confirmed that the attacker no longer has any access |
| Team profile | Network, systems and cloud engineers | Security analysts, forensic specialists, threat hunters |
The last two rows are the ones that cause the most arguments inside companies, and they are the ones worth discussing.
Why can both see the same alert and do opposite things?
Imagine a server that at 3:14 a.m. becomes extremely slow and starts consuming CPU for no apparent reason.
The NOC does the right thing according to its trade: it isolates the symptom, restarts the service and, if that doesn’t work, restarts the server. At 3:31 the dashboard is green again, the ticket is closed with the note “resolved, service restarted,” and no one loses sleep. It’s a good night’s work.
The SOC would have done the opposite. Before touching anything, it would have captured the machine’s memory and looked at which process triggered the consumption, which account launched it and which internet address it was talking to. Because that strange consumption is also what an encryption process looks like when it starts, or a cryptominer, or a data exfiltration channel.
When the service is restarted, the service comes back and the evidence disappears. And if what was there was persistent access, it comes back too, only now with no trace of how it got in. Incident response guides insist on that order for a reason: the NIST SP 800-61 places evidence preservation within containment, not afterward.
Neither team made a mistake. Each one followed its procedure. The problem is that the company had only one procedure, and it was the availability one.
Can the two be combined into a single team?
It can be done, and more and more companies are doing it. Convergence has real advantages: a single asset inventory, a single on-call team to phone in the middle of the night and, above all, the end of that “that’s a network issue” versus “that’s a security issue” argument while the clock is running.
But putting the two desks together is not the same as putting the two functions together. To make it work you need three things: separate processes for availability and for security incidents, a clear criterion for when an alert stops being treated as a failure and starts being treated as an attack, and people trained in both, or at least a bridge between the two shifts.
What doesn’t work, and is seen often, is putting a security tool on top of the NOC and renaming it. The tool generates alerts that no one is trained to investigate, the queue grows, and within a month the noisy alerts get filtered out so people can work. That is exactly the alert that later shows up underlined in the forensic report.
Which of the two are you missing?
Signs that you are missing a NOC: you learn about outages because a user calls, you don’t know how long you were down last month, no one checks that backups complete successfully, and the links always saturate at the same time of day and no one has measured it.
Signs that you are missing a SOC: no one looks at the access logs unless there is a problem, you couldn’t say whether an administrator account was used last night, antivirus alerts are reviewed by whoever has time, and if someone asked you today how long it would take you to detect an intruder, the honest answer would be that it depends on luck.
Which one does my company need first?
It depends on what hurts you more, and it’s worth answering without the heroics.
If your operation stops when the network stops, if you sell or produce with systems that have to be up during business hours, the NOC comes first. Without availability, there is no business to defend.
If you handle personal data, financial information or anything regulated, if you have already had an incident, or if a large customer has started asking about your controls, the SOC stops being optional. And there is a nuance almost no one sees: most mid-size companies already have an informal NOC, which is their own IT team fixing outages all day. What almost none of them have is someone watching in the middle of the night with the SOC’s question in mind. That gap is the one that gets expensive, because it goes unnoticed until it has already happened.
Frequently asked questions
Can a NOC detect a cyberattack?
Is a NOC the same as a help desk?
What Is NOC as a Service?
Can my IT team act as both NOC and SOC at the same time?
What should I require in writing from each one?
Two centers, two different questions
The fastest way to tell which of the two you are looking at is to listen to the question it asks when something happens. If it asks how long it will take us to bring it back up, it’s a NOC. If it asks how long it had been there, it’s a SOC. Both questions are necessary, and neither answers the other.
At ZetTateK we manage both layers: the network infrastructure, with continuous monitoring, segmentation and managed firewalls, and the managed 24/7 SOC that watches what happens inside it. If you’re not sure which of the two you are missing today, the free security assessment is the quickest way to find out. The other terms in this article are explained in our cybersecurity glossary.
Everything being up doesn’t mean everything is fine. They are two questions, and you need both.
