Multi-Tenant SOC Architecture and 24x7 Coverage at Litware
Litware has completed two acquisitions in twelve months and now operates three Microsoft Entra tenants: HQ (5,000 users, contractual EU data residency commitments to customers, Microsoft Sentinel workspace in West Europe), North America (1,800 users, no Sentinel), and APAC (900 users, no Sentinel). All three use Microsoft 365 E5 with the Defender XDR suite. The security operations team is four analysts working 09:00 to 17:00 CET with no weekend cover. The board has mandated 24x7 monitoring within two quarters, and the CISO has budget for either four additional hires or an MSSP contract, not both. Legal has imposed twelve-month retention on security logs for a subset of systems, while the current workspace keeps 90 days of analytics-tier data and ingestion cost is already 40 percent over forecast.
1. Design the log and incident architecture across the three tenants. How many Sentinel workspaces, where does cross-tenant detection live, and how does that survive both the residency commitment and a four-person team?
Read the worked answer
Workspaces follow data-residency boundaries, not org charts; detection content is centralised as code.
- EU logs stay in an EU workspace. The residency commitment is contractual and the workspace region determines storage location. Do not copy EU telemetry into a US workspace to save one pane of glass.
- Consolidate where nothing forbids it. If North America and APAC have no residency constraint, one additional workspace serving both is defensible; choose its region deliberately for latency and any state-level requirement. Two workspaces is the practical target, not three.
- Cross-workspace triage: use Sentinel's multi-workspace incident view combined with Defender XDR incidents, which are tenant-scoped and fan into a single analyst queue. Grant analysts and any MSSP access through Azure Lighthouse delegated resource management rather than duplicate accounts per tenant.
- Detection as code, deployed identically to every workspace, versioned in Git. Three drifting rule sets means three tuning burdens and three blind spots - the single biggest threat to a four-analyst team.
Be explicit that per-tenant Defender XDR cannot itself correlate an incident spanning tenants; if that becomes a requirement, raise it as a separate design problem rather than assuming the portal does it.
2. With budget for either four hires or an MSSP, how do you deliver 24x7, and what contract terms matter most?
Read the worked answer
Recommendation: hybrid - MSSP for tier-one triage, in-house for tier two/three and detection engineering.
Reasoning: genuine 24x7 coverage of a single seat needs roughly five FTE to absorb leave, sickness and weekends. Four hires does not deliver 24x7 either, and recruitment plus ramp-up takes three to six months - which alone misses the two-quarter mandate.
- Outsource tier one: alert triage, enrichment, ticket creation, execution of pre-approved runbooks, around the clock, under scoped Lighthouse RBAC and defined escalation SLAs.
- Retain in-house: detection engineering, threat hunting, incident command, and ownership of identity and cloud controls. This is institutional knowledge and the part that cannot be outsourced without hollowing out the team.
- Contract terms that actually matter: fifteen-minute acknowledgement, named escalation contacts with authority, monthly false-positive and false-negative reporting, the right to audit, data-handling and sub-processor commitments consistent with the EU residency promise, and a clean exit clause for detection content.
- Automate before you buy: automation rules and playbooks to auto-close known-benign patterns and auto-enrich the rest. Paying MSSP rates to triage your own noise is the most common way this model fails financially.
3. Legal wants twelve months of retention for a subset of systems, and ingestion is already 40 percent over forecast. How do you meet both without simply increasing the budget?
Read the worked answer
Separate the questions of where data lives, how long it lives, and how much of it you ingest at all.
- Tiering: keep the interactive analytics tier short (30 to 90 days) for the tables analysts actually query, and move the legally-mandated subset to a long-term data lake tier where retention is cheap and data is retrieved with search or KQL jobs on demand. Do not extend analytics-tier retention across the board to satisfy a legal requirement affecting a handful of systems.
- Scope the obligation: get legal to name the systems and tables, not 'security logs'. A twelve-month requirement on sign-in, audit and endpoint telemetry is a very different bill from one covering every firewall flow record.
- Cut at ingestion, not after: use data collection rule transformations to drop verbose fields, filter known-noise events before they are billed, and route high-volume low-value tables to a low-cost plan rather than the analytics tier. Sampling is acceptable for some flow data and never for audit logs.
- Summarise: scheduled summary rules can preserve the analytic value of high-volume tables - counts, first-seen, unique tuples - at a fraction of the volume.
- Then forecast honestly: present the residual cost of the legal requirement as a compliance cost, attributable to the systems legal named, so the overrun discussion is about scope rather than about the SOC being wasteful.