What Is a Network Operations Center (NOC)? Daily Work, Shift Routine and a Handover Note Template

The short version: A network operations center (NOC) is the team and tooling that watch your network and infrastructure around a defined schedule, detect faults, fix or escalate them, and keep a record. A NOC protects availability and performance; a security operations center (SOC) protects against attacks. Both can exist in one organisation, and they need a clear route between them.

This is for IT managers deciding whether they need a NOC, and for anyone evaluating a provider's NOC service. You will get what a NOC watches, how a shift runs, a handover note template, escalation triggers to start from, and the differences between a NOC and a SOC.

What is a NOC?

Wikipedia's article on the network operations center (read 28 October 2026) describes it as one or more locations from which network monitoring and control is exercised over a computer, telecommunication or satellite network. NOC engineers deal with network failures, power outages and attacks that affect availability, configure equipment such as firewalls and routers, monitor activity, and keep the core network stable. Most work rotating shifts.

For a small or mid-sized organisation, "a NOC" usually means a service: a provider's team, tools and process that monitor your network and servers, handle alerts, and escalate to engineers. You do not need a room with large screens. You need coverage, a defined scope, and a process that works at 2 a.m.

What does a NOC do every day?

1. Monitor the health of network devices, internet lines, servers, key services and backups.
2. Triage alerts: decide which are real faults, which are noise, and which need action now.
3. Diagnose and fix what can be fixed remotely: restart a service, fail over a line, clear a stuck interface, apply a configuration change under an approved procedure.
4. Escalate faults that need a higher level, a vendor or an on-site visit, with a clear handover. See L1, L2 and L3 support levels.
5. Communicate with affected users and the service owner at the agreed intervals.
6. Record every alert, action and result in a ticket so the history is searchable.
7. Handle planned work: maintenance windows, change checks before and after, and capacity watching.
8. Report on availability, incidents and trends.

What does a NOC monitor?

Agree the scope in writing. A typical scope list:

1. Network devices: firewalls, routers, switches, wireless controllers and access points, VPN gateways. Availability, interface status, utilisation, errors.
2. Internet and WAN links: up/down, latency, packet loss, failover state.
3. Servers and virtual hosts: online status, CPU, memory, disk, key services.
4. Core services: DNS, DHCP, directory services, time sync.
5. Backup jobs: success, age of last good backup.
6. Power and environment: UPS state, room temperature where sensors exist.
7. Cloud and application checks: website or login page responding, mail flow, Microsoft 365 service health (Microsoft 365 admin center > Health > Service health).
8. Expiries: certificates, domains, support contracts.

For the threshold values to start from, read what to monitor and which alert thresholds to start with.

A shift routine you can copy

Adapt the times to your coverage hours.

Start of shift

1. Read the previous shift's handover note (template below).
2. Check the open ticket queue and any work waiting for a vendor or user.
3. Check the monitoring tool itself: are all collectors and agents reporting?
4. Check the planned maintenance and change calendar for today.

During the shift

1. Work alerts in priority order. Acknowledge each one, so everyone knows it is being handled.
2. For each alert, decide: false alarm (tune it later), event to record, or incident to work.
3. For incidents, set the priority using your agreed rules; see severity vs priority in IT incidents.
4. Update the ticket when you act, not afterward from memory.
5. Escalate on the triggers below without waiting to be sure.
6. Before and after any planned change, check the affected device and its neighbours.

Hourly or at set intervals

1. Review the dashboard for amber items that are drifting toward red.
2. Check the backup and job status for the period.
3. Send the agreed updates on open incidents.

End of shift

1. Close what is finished, with a short summary of cause and fix.
2. Write the handover note.
3. Hand over by message or call for anything critical; a note alone is not enough for a live incident.

Handover note template

Copy this into your ticket tool or shared document. Keep each line short.

1. Shift and author: date, hours, who wrote it, who is receiving it.
2. Open incidents: ticket number, one-line symptom, priority, current status, next action, and next update due.
3. Alerts being watched: what, why it is not yet an incident, and the condition that would escalate it.
4. Planned work: maintenance windows and changes in the next shift, with approver and rollback plan.
5. Waiting on others: vendor case numbers, user replies, parts, with who chases and when.
6. Changes made this shift: what changed, on which device, and who approved it.
7. Known issues and workarounds: anything the next shift will otherwise rediscover.
8. Monitoring health: tool or collector problems, silenced alerts and when the silence ends.
9. Contacts in use: on-call engineers, vendor contacts, customer contacts for open items.
10. Anything else the next shift must know: one line each.

Escalation triggers to start from

These are starting points to tune, not standards. Tie them to your SLA and escalation matrix; see the IT escalation matrix template.

1. Time: an incident has no owner after 5 minutes, or no progress after 30 minutes for a critical one.
2. Impact: more than one site or department is affected, or a core service (internet, authentication, mail) is down.
3. Risk: any sign of an attack, data loss or unexpected configuration change goes to security immediately.
4. Skill: the NOC has no documented procedure for the fault.
5. Vendor: hardware fault or a bug that needs the maker.
6. Major incident: meets your major incident criteria; switch to the major incident management process.

NOC vs SOC

Wikipedia's article on the security operations center (read 28 October 2026) says a SOC monitors an organisation's network, investigates potential security incidents, and takes the steps needed to remediate threats. It also notes a SOC can be internal or run by an outsourced security service provider. The practical differences:

Main question: NOC asks "is it up and performing?" SOC asks "is it safe, and is anyone attacking it?"

Typical alerts: NOC handles link down, high utilisation, failed backup, service stopped. SOC handles suspicious sign-ins, malware detections, unusual data movement, alerts from security tools.

Typical actions: NOC restarts, fails over, reconfigures, dispatches an engineer. SOC isolates a device, blocks an account, investigates, hunts for further activity.

Speciality skills: NOC needs networking and infrastructure skills. SOC needs security analysis and incident response skills.

Where they meet: an outage can be an attack, and an attack can look like an outage. Agree how each team hands cases to the other. For our security monitoring service, see security operations center.

How to tell whether a NOC service is any good

1. Scope in writing: a list of monitored systems and the checks on each.
2. Coverage hours: business hours or around the clock, and what happens outside them.
3. Response targets: first response by priority; ours are published on the SLA page, and any provider's should be too.
4. Escalation path: who is called, in what order, and by when.
5. Reports: availability, incidents, alert volume, mean time to acknowledge and resolve; see MTTA, MTTR and MTBF.
6. Change control: who may change what, and how changes are approved and recorded.
7. Handover quality: ask to see a redacted example of a handover note.

Common mistakes

1. Watching devices, not services. Everything is up and users still cannot work. Add service and login checks.
2. No shared scope. Nobody knows whether the printer, the VPN or the Wi-Fi is in or out. Write it down.
3. Alert fatigue. Too many low-value alerts hide the real one. Review alert volume monthly.
4. Handover by memory. Verbal handover loses detail. Use the template.
5. Fixing without recording. If a fix is not in the ticket, it will be repeated or contradicted.
6. No route to security. Treat a suspected attack as a security case, not another network fault.
7. Unmonitored monitoring. A silent collector looks like a quiet network.

How to check it worked

1. Pick a monitored device and take it out of service in a maintenance window. Confirm the alert, acknowledgement and ticket arrive within your target.
2. Read the last three handover notes. Could a stranger start the shift from them?
3. Check that every incident in the last month has a cause, fix and owner recorded.
4. Compare the alert count with the incident count. A large gap means tuning is overdue.
5. Practise one escalation to a vendor or security so the contacts are known to work.

FAQ

What does a network operations center do?

It monitors networks and infrastructure, triages alerts, fixes or escalates faults, communicates with affected users, handles planned maintenance and records everything in tickets.

What is the difference between a NOC and a SOC?

A NOC keeps systems available and performing; a SOC detects and responds to security threats. They share data and need an agreed handover route.

What is the role of a NOC?

Its role is to keep services running by finding problems early, restoring service quickly and learning from repeat faults. It acts as the central point where alerts become tickets and tickets reach the right engineer. Day to day that means monitoring, alert triage, incident handling and escalation, change checks, communication, handover and reporting on availability and trends.

What do you need to run a NOC?

A defined scope, monitoring and ticketing tools, trained staff on a schedule that matches your coverage hours, written procedures, an escalation matrix, and handover and reporting routines. Small organisations usually buy this as a service instead of building it.

Next step

If you would rather have a team run this for you, start with the Brocent operation center page.

Sources checked 28 October 2026: Wikipedia, "Network operations center" and "Security operations center". Thresholds are starting points to tune.

Brocent publishes its managed IT support plans with per-user monthly prices for Hong Kong, Singapore, mainland China and the United States, so you can compare before you talk to anyone: see the plans and pricing.