How To Monitor Multiple Sites From One Security Operations Centre

Running security operations for one site is hard. Running it for ten sites, sixty sites, or two hundred sites from a single control room — without exploding headcount and without losing operational fidelity at each site — is a different problem entirely.

The good news is that the multi-site SOC pattern is well-established. The same architectural and operational principles that work for a mall chain in Lagos, a bank branch network in Nairobi, an estate-management portfolio in Johannesburg, or a hotel group across Egypt and the UAE. This article walks through them.

The multi-site problem, precisely

A single-site operation is simple by comparison: cameras live on-site, the VMS lives on-site, operators sit in a room watching them. When something happens, response is immediate because everyone is co-located.

Multi-site adds five dimensions of complexity:

• Network. Footage and events need to traverse the public internet, often across multiple network providers, often with intermittent uplink at each site.
• Awareness. Operators in a central SOC have no physical presence at any individual site. Situational awareness has to be reconstructed from data.
• Response. Physical response has to be dispatched to whichever site the incident is at — usually local guards, sometimes external responders.
• Heterogeneity. Different sites have different camera estates, different incident profiles, different operational rhythms.
• Governance. Each site may have local management, local stakeholders, and local compliance requirements that all need to be honoured from the central SOC.

The naive solution is to stand up a dedicated monitoring room at each site. This doesn't scale: at twenty sites you have twenty rooms, twenty teams, twenty cost centres, no cross-site learning, and twenty different operational standards. The right solution is a single SOC that monitors everything centrally — using technology and operating discipline to compensate for the loss of co-location.

Architecture that scales

The architectural pattern that works for multi-site monitoring has three layers.

Layer 1 — Edge processing at each site. A small compute node at each site (or a server in the site's existing IT closet) runs the AI inference on camera feeds locally. This means real-time detection happens at the site itself, not over a remote link. It also means detection continues through brief uplink failures — the alerts queue locally and sync when connectivity returns.

Layer 2 — Cloud aggregation and dashboard. Events, metadata and incident clips flow upstream to a central cloud platform. This is what the SOC operators see: a unified dashboard across every site, every camera, every event. Cross-site analytics, watchlist distribution, and configuration management live here.

Layer 3 — Storage tier. Raw footage stays at the site (or replicated to a regional NVR for redundancy). Only event metadata and flagged incident clips travel to central storage. This dramatically reduces bandwidth requirements and keeps footage residency aligned with whatever jurisdiction each site sits in.

The bandwidth profile of this architecture is modest. A 50-camera site streaming everything to the cloud would need somewhere around 50–100 Mbps continuous. The same site running edge processing with only events and incident clips travelling upstream needs typically 2–10 Mbps — well within standard business broadband or even reasonable LTE/5G fixed-wireless. This is the architectural pattern that makes African multi-site deployments work.

The operating model

The operating model in a well-functioning multi-site SOC is event-driven. Operators don't watch screens; they handle a queue of triaged events that the AI layer has surfaced as worth attention.

The lifecycle of a typical event:

1. AI detects an event at a remote site — say, perimeter intrusion after hours.
2. Event surfaces in the central dashboard with the camera feed, event type, location, confidence score, and any historical context.
3. Tier-1 operator triages: verifies the event is real (not a false positive), categorises it, and either resolves or escalates.
4. If escalated, tier-2 operator coordinates response — dispatching site security, calling on-site management, or escalating externally per the site's playbook.
5. Response completes; outcome is logged; event closes.

Every step is timestamped, every action is logged, every operator decision is traceable.

Staffing and tiering

A common mistake is to assume multi-site means "more operators of the same type". The right model is tiered, with each tier handling a different category of work.

Tier 1 — Triage operators. Handle high-volume, lower-complexity event verification. Confirm real vs false positive. Categorise and route. Typical throughput: 30–80 events per shift in a well-tuned deployment. Skill profile: rapid pattern recognition, clear procedural execution, calm under pressure.

Tier 2 — Response coordinators. Handle escalated events. Coordinate physical response. Liaise with site management and external responders. Manage incident lifecycle. Typical workload: 10–25 escalations per shift. Skill profile: judgement, communication, multi-stakeholder management.

Tier 3 — Investigators / supervisors. Handle complex investigations, post-incident review, pattern analysis across sites, watchlist governance. Lower volume, higher seniority.

On-call site teams. Each site has local security or facility staff who execute physical response under SOC direction.

A typical ratio for a 30-site SOC with moderate incident profile: 3–4 tier-1 operators per shift, 1 tier-2 coordinator per shift, 1 tier-3 supervisor on day shift, with on-call rotation overnight. Total SOC headcount across all shifts: typically 12–18 people for 24/7 coverage of 30 sites. The same workload under traditional manual monitoring would require 40–80.

The tooling stack

What the SOC actually needs to operate:

• Unified video intelligence platform. The core — a single pane of glass for all sites with AI-driven event surfacing. Sorveo and equivalents.
• Incident management / ticketing. Each event becomes a record with state transitions, assignment, and resolution notes. Can be embedded in the VI platform or integrated externally.
• Communications. Channels for talking to each site's on-call team — typically a mix of structured radio, mobile messaging, and voice. Discord, Slack, dedicated PTT platforms each have their place.
• Site documentation. Each site has a playbook: who to call, escalation thresholds, response SLA, local restrictions. Accessible from the event detail page.
• SIEM/PSIM integration. For mature operations, events flow into a central security information platform alongside cyber and access-control signals.
• Audit and reporting. Per-site and cross-site reporting on metrics — MTTD, MTTR, incident counts, false-positive rates.
• Identity and access management. SSO, MFA, role-based access for operators. Especially important when operators have access to footage and events across many customer sites.

Escalation rules that work

Escalation rules are where multi-site SOCs succeed or fail. Get them right and the operation runs smoothly. Get them wrong and either operators get overloaded with non-events or real events fall through the cracks.

The principles:

• Confidence-based gating. Below a confidence threshold, events are logged but don't surface to operators. Above the threshold, they enter the triage queue.
• Time-of-day rules. The same camera in the same zone has different escalation rules at 14:00 and at 02:00.
• Repeat-event collapsing. Three motion events from the same camera within 60 seconds are one incident, not three. The platform should collapse them automatically.
• Site-specific playbooks. A perimeter event at a bank goes to a different response chain than a perimeter event at a residential estate.
• Escalation timers. If tier-1 doesn't acknowledge an event within X minutes, it auto-escalates to tier-2. If tier-2 doesn't respond within Y minutes, it auto-escalates to supervisor.
• Quarterly review and re-tuning. Escalation rules are not set-and-forget. Review false-positive rates and outcome data quarterly; re-tune.

Metrics that matter

The metrics for measuring multi-site SOC effectiveness:

• Mean time to detect (MTTD). Event onset to operator awareness. Target: under 30 seconds for tier-1 alerts.
• Mean time to respond (MTTR). Operator awareness to operational response. Target: under 5 minutes for critical events.
• Per-site incident rate. Per-site, per-week, by category. Used to identify outlier sites needing attention.
• False positive rate by alert source. Tracked per camera, per rule. Used to drive escalation-rule retuning.
• Operator handle rate. Events handled per operator per shift. Used to balance staffing.
• Camera-health uptime by site. Percentage of cameras operational per site. Used to drive maintenance prioritisation.
• Cost per monitored camera. Total SOC operating cost divided by camera count. Used to benchmark efficiency over time.

More on the alert-to-outcome flow that drives these metrics.

Common multi-site SOC mistakes

Six failure modes that consistently appear in multi-site operations:

1. Centralising too aggressively. Trying to do every action from the SOC, including ones that need local presence. Result: response times suffer and local teams disengage.
2. Centralising too cautiously. Treating each site as autonomous and only using the SOC for backup. Result: no cross-site value, duplicated headcount.
3. Standardising too rigidly. Forcing every site onto identical playbooks regardless of local context. Result: rules that don't fit edge cases.
4. Customising too freely. Letting every site have unique procedures. Result: operators can't move between sites and learnings don't propagate.
5. Underweighting camera-health. Letting dark cameras accumulate because they're at remote sites that nobody visits. Result: invisible coverage gaps.
6. Not measuring per-site outcomes. Reporting only aggregate numbers. Result: bad sites hide behind good sites.

FAQ

Sorveo powers multi-site SOCs across Africa, including mall chains, residential portfolios, and corporate networks. Book a demo to see the unified dashboard.