24/7 multi-tenant SOC for a large services group

The service began with a classic scope: watching the group's own assets — dozens of companies, each with its own systems, websites and quirks. That was already a challenge of scale: a multi-sector group does not have one perimeter, it has many, and the SOC had to learn each company's fine print to tell the anomalous from the merely different.

The turning point came when the group put the other half of its business on the table: the digital services it delivers to its end clients, with hundreds of managed websites and assets. If the group was responsible for those platforms, who was watching their security? Nobody — not continuously. The natural answer was to extend the SOC: the group's clients' assets would join the same 24/7 monitoring, but as what they are — third-party assets, with their own escalation and with the group as the point of contact towards its client. That turned a dedicated SOC into a multi-tenant one.

1. Multi-tenant architecture from the design stage — telemetry, alerts and reporting segregated per client on the same platform. What belongs to the group and what belongs to each of its clients never mixes: every asset knows whose it is, which thresholds apply and through which channel it escalates.
2. Industrialised onboarding in waves — you do not onboard 200-plus websites and digital assets one at a time by hand. We defined onboarding templates per asset type, and assets joined in waves — each wave closing with alert verification and a confirmed escalation chain before any asset was marked operational.
3. Monitoring on three planes: availability, integrity and attacks — that the site responds; that nobody has altered its content (defacement); and that web attack patterns, brute force against login panels and anomalous spikes raise alerts. With certificate expiry and DNS changes as a supporting plane.
4. Playbooks per asset type, not per client — a corporate website, an online shop and an API call for different responses to the same symptom. By standardising the playbook per type, the quality of the response does not depend on which client is affected — and the service scales without degrading.
5. Differentiated escalation: the group on one channel, its clients on another — an incident on a group asset escalates straight to its team; an incident on a group client's asset escalates to the group as the point of contact, which decides how and when to communicate with its client. The SOC contains in both cases; the commercial relationship is never touched.
6. Recurring support on migrations and infrastructure — out of the trust built by the continuous service came projects that were never in the original contract: platform migrations, infrastructure changes and delicate deployments with the SOC watching before, during and after.

For the group, the most valuable result is not a detection metric: security stopped being a cost and became part of its proposition. Its clients get their websites watched around the clock without ever contracting a SOC — it comes with the digital service they were already paying for — and the group can state, with evidence, that what it manages is monitored. A defacement on a group client's website is detected within minutes and handled before the client finds out from a phone call.

And the pattern that sums up the case: when the continuous service works, the relationship grows on its own. The migrations and infrastructure projects did not come from a commercial proposal — they came from years of well-handled incidents. Operational trust is the best sales pipeline there is.