Microsoft ISOC: what changes for Defender and Sentinel

A different starting point

After working through the public documentation, I think the significant change in Microsoft’s Integrated Security Operations Center is where a security team can begin its work. Defender has traditionally been the place for Microsoft-native detection, investigation, and response, while Sentinel extends operations across broader telemetry and SIEM use cases. ISOC brings more of those workflows into one experience.

This is a historical adaptation of my September article. ISOC remains a preview in the documentation reviewed for this edition, so availability and capabilities should be checked before designing around them.

Supporting reference: Integrated Security Operations Center (ISOC) in Microsoft Defender - Microsoft Defender XDR ↗

Start in Defender, add a workspace where needed

Eligible Microsoft Defender Suite, Microsoft 365 E5, and Microsoft 365 E7 customers can begin with case management, workbooks, and natural-language playbook generation. During this phase of the preview, eligibility is limited to organizations without an active Sentinel workspace. Existing Sentinel customers should continue their current experience, rather than disconnect production workspaces to qualify.

An ISOC workspace becomes relevant when the team needs additional Microsoft or non-Microsoft ingestion, UEBA, Content hub connectors, repositories, threat intelligence, and other workspace-dependent capabilities. That distinction should drive the architecture. A useful feature in the Defender portal does not mean the data plane, retention requirements, or ingestion charges have disappeared.

The operating model is the harder work

Enabling capabilities is easier than deciding where analysts should investigate, who owns containment, and which evidence an incident requires. I would start by tracing one investigation the team already performs. Identify the signals available natively in Defender, then record the missing telemetry, analytics, retention, and workflow requirements that justify a workspace.

That exercise also exposes unnecessary duplication. Sending every available data set into a SIEM because the previous design did so is an architectural habit, rather than evidence that each copy improves response. Keep the data needed to answer a specific operational question and make its cost and retention deliberate.

Automation needs an accountable owner

An automated response needs a defined trigger, a permitted action, and someone responsible for the result. Isolating an endpoint, disabling an identity, and changing a production integration have different consequences. The approval and recovery paths should reflect those consequences.

ISOC is a product experience, not a managed response service. Portal integration does not supply staffing, escalation authority, or an incident commander. Automatic attack disruption also has its own supported scenarios and prerequisites. Test those boundaries before assuming that a consolidated interface means a complete operating model.

The question I would bring to the next review

Ask which parts of the SOC still require workspace-backed SIEM capabilities, which can now operate directly in Defender, and whether the change simplifies the work of investigation and response. Have the team demonstrate one incident from first signal to closure, including the handoffs and any automated actions. That gives the adoption decision a practical basis without turning a preview announcement into a migration mandate.