Monitoring & SOC

A SIEM is the platform that ingests logs, correlates events and generates alerts, while a SOC is the staffed shift that decides what each alert means. The gap is organisational: a platform can be switched on without changing how your team works, whereas a SOC needs a named owner for every escalation and a mandate to stop an attack. Subscription offers bundle both, so confirm whether analyst time is included in the price.

Find out who actually staffs the shift: whether analysts are employed by the provider, whether night coverage is subcontracted, and which language escalation runs in after hours. Ask for references from an environment built on similar systems rather than from a company of similar headcount. Check whether a trial period is offered, so you can judge ticket quality against your own data before the service covers everything.

A small company usually connects a handful of sources, namely endpoints with EDR, the identity system and mail, and runs on the provider's standard detection content with light tuning. A large organisation adds in-house applications and several cloud tenants, so rules are written per system and part of the triage stays with an internal team. Splitting duties with your administrators then weighs more than the choice of platform.

Daytime monitoring is achievable in-house when someone knows the environment and maintains detection rules, but continuous coverage needs a shift roster that a mid-sized organisation rarely staffs. A middle path splits the clock: your team triages during business hours while a provider takes nights, weekends and public holidays. That model works only with one shared ticket queue and one agreed severity scale.

Detection rules need a review whenever something changes the shape of your event stream: a new application, a cloud migration, a different mail platform or a new administrative tool. Every incident and every alert closed as a false positive is another trigger, because both show that a rule is too narrow or too broad. Put that review into the contract as part of the service.

The clearest signal is where you learn about an incident from: the provider, or your users and business partners. Watch the direction of MTTD and MTTR across successive reports, and the share of alerts closed as false positives, which should fall once tuning settles. The strongest evidence comes from a controlled test, an agreed action in your environment that proves an alert fires and reaches you.

An SLA has to define severity classes and the moment the response clock starts, or each side measures it differently. Write down the scope of night and holiday coverage, the notification channel, and named contacts with deputies on both sides. Settle how far the provider may act on its own inside your estate, how new sources are added mid-contract, and which systems stay outside the service.

Logs handed to a monitoring provider carry personal data, account names and addresses, so the relationship needs a data processing agreement. Establish where the collection platform physically sits, how long it keeps events, and whether that retention matches your evidence needs. Ask which analysts open raw events, whether their access is recorded, and how data from higher-confidentiality systems is kept apart.

Buyers connect the sources that are easiest to wire up, the firewall and endpoint protection, while identity, mail and cloud consoles stay without logging. Monitoring then watches the network edge while an account takeover passes unseen. Handing over the environment without context costs as much: until the provider knows which administrative jobs are scheduled, it reports them as suspicious.

Onboarding lasts as long as it takes to prepare each source for event collection and to secure the change windows in which those systems may be touched. Sources are connected in waves, critical systems first, so the first incident tickets arrive before the whole estate is covered. Tuning then runs against production data until the false positive load becomes manageable.