8 mins

SOC Monitoring & Incident Response: How to Stay Ahead of Cyber Threats

Last Updated

September 24, 2026

Key Takeaways

SOC monitoring is the round-the-clock review of identity, email, endpoint and cloud telemetry by analysts who decide which alerts are real incidents.
SOC incident response starts when triage confirms an incident and runs through severity, escalation, containment and closure.
Microsoft Entra keeps sign-in and audit logs for 7 days on Entra ID Free and 30 days on P1 or P2, while the Microsoft 365 audit log keeps 180 days on Audit (Standard).
Advanced hunting and six months of data retention sit in Defender for Endpoint Plan 2 and Defender for Office 365 Plan 2, so tenants below E5 extend their look-back by streaming logs into Microsoft Sentinel.
Status, severity, owner, classification and tags are the case management fields that turn alert noise into accountable incidents.
Microsoft-specialised monitoring wins on native correlation, while a general-purpose SOC fits better when much of your estate runs outside Microsoft.

SOC monitoring is the continuous review of security logs and alerts inside a security operations center (SOC) so analysts catch attacks early, and SOC incident response is what the same team does once an alert is confirmed as real. This guide covers what a SOC watches in Microsoft 365, how far back it can see, and how alerts become incidents. On default retention, a SOC can catch today's attack but cannot trace one that started months ago, which is how a compromised mailbox survives a password reset.

‍

What Is SOC Monitoring?

SOC monitoring is the continuous collection, correlation and review of security logs and alerts by security operations center analysts, so real attacks are identified and escalated as early as possible.

Monitoring is a process, not a product. A SIEM (security information and event management) platform and Microsoft Defender XDR (extended detection and response) collect the signals. Analysts decide which alerts describe a real attack and close the rest with a reason.

In a Microsoft 365 estate, that means identity, email, endpoint and cloud signals landing in one incident queue, watched by analysts on shift rather than read the next working morning. That difference is the whole argument for what round-the-clock monitoring includes.

SOC Monitoring vs SOC Incident Response: What's the Difference?

Monitoring and incident response are two halves of one team's job, split by a single event: confirmation. Monitoring decides whether an alert is real. Incident response takes over once it is.

	SOC monitoring	SOC incident response
Trigger	A log event or alert arrives	Triage confirms an alert is a real incident
Goal	Decide what is real, as early as possible	Limit the damage and restore normal operations
Main activities	Log collection, correlation, alert triage, threat hunting	Severity assignment, escalation, containment, eradication, recovery
Output	A closed alert or a declared incident	A contained incident and a closed case record
Typical owner	Tier 1 and Tier 2 SOC analysts	An incident responder, working with customer IT and leadership
Ends when	The alert is closed or escalated	The incident is closed with a classification

Providers differ on where they stop. Some sell monitoring and hand you the alert; others own the response. That distinction is worth understanding before you sign anything, and it's covered in monitoring-only vs response-driven SOC models.

‍

What Does a SOC Monitor in a Microsoft 365 Environment?

A Microsoft 365 SOC monitors sign-ins and identity changes, mailbox and SharePoint activity, endpoint behaviour, app consents, and the correlated alerts Defender XDR raises, ideally in one incident queue.

Which of those you can actually watch depends on what you send to Microsoft Sentinel, and some of it costs money to send.

Log source	What it shows the SOC	Where it lives	Cost to send to Sentinel
Microsoft Entra ID sign-in logs	Who signed in, from where, with which method, and whether the sign-in was risky	Microsoft Entra admin center	Paid
Microsoft Entra ID audit logs	Directory changes: role assignments, app consents, MFA method changes	Microsoft Entra admin center	Paid
Office 365 audit logs (SharePoint activity, Exchange admin activity, Teams)	File access and sharing, admin actions, Teams activity	Microsoft Purview	Free
Defender XDR alerts and incidents	Correlated attack stories across endpoint, identity, email and cloud apps	Microsoft Defender portal	Free
Defender advanced hunting raw events (DeviceFileEvents, EmailEvents and similar)	Raw endpoint and email telemetry for hunting	Microsoft Defender portal	Paid
Azure Activity logs	Subscription-level changes to Azure resources	Azure portal	Free

Microsoft's free list covers Azure Activity logs, Microsoft Sentinel Health, Office 365 audit logs including all SharePoint activity, Exchange admin activity and Teams, and security alerts from Defender XDR, Defender for Cloud, Defender for Office 365, Defender for Identity, Defender for Cloud Apps and Defender for Endpoint. Raw logs from those same products, and from Microsoft Entra ID, are charged. Microsoft's wording says Exchange admin activity, so check mailbox-level audit events against your own bill rather than assuming they are free.

Two paid rows get cheaper on E5. Microsoft 365 E5, A5, F5 and G5 customers, and the matching Security SKUs, receive a data grant of up to 5 MB per user per day for Microsoft 365 data ingested into Sentinel. Business Premium isn't on that list, so those tenants pay full rate for Entra sign-in logs.

Two documented gaps are worth knowing before you design around them. Defender Vulnerability Management tables such as DeviceTvmSoftwareInventory appear in the Sentinel schema, but the data isn't ingested, so queries return nothing in Sentinel while working fine in Defender. And Defender for Cloud incidents arrive without their alerts and entities unless you also enable the Defender for Cloud connector.

Getting the order right matters more than getting everything connected, and which log sources to connect first covers how that sequencing usually runs.

‍

How Far Back Can Your SOC See? Log Retention and the Look-Back Window

Your SOC can only investigate as far back as your logs are kept. By default that means 7 days of Entra sign-in history on Entra ID Free, 30 days on P1 or P2, 30 days of Defender hunting data, and 180 days in the Microsoft 365 audit log.

Retention doesn't stop a SOC detecting a new attack. Today's malicious sign-in raises an alert today, whatever your licence. What retention limits is the investigation afterwards: how far back analysts can trace initial access, find persistence the attacker left behind, and work out what was actually taken.

Default Retention by Microsoft 365 Log Source

Log source	Default retention
Entra sign-in and audit logs	7 days (Free), 30 days (P1), 30 days (P2)
Entra risky sign-ins	7 days (Free), 30 days (P1), 90 days (P2)
Entra risky users	Kept until the risk is remediated
Defender XDR advanced hunting (raw data)	30 days
Microsoft 365 audit log, Audit (Standard)	180 days (90 days for logs created before 17 Oct 2023)
Microsoft 365 audit log, Audit (Premium)	1 year for Entra, Exchange, OneDrive and SharePoint records, 180 days for other records, up to 10 years with a paid add-on
Microsoft Sentinel, analytics tier	First 90 days included

What a Microsoft 365 Business Premium Tenant Sees by Default

Capability	Business Premium default
Entra sign-in and audit logs	30 days (Entra ID P1 is included)
Microsoft 365 audit log	180 days (Audit Standard)
Advanced hunting	A Defender for Endpoint Plan 2 capability, along with six months of data retention. It isn't in Microsoft's Defender for Business capability list
Adding E5 Security to some users	The tenant stays on the Defender for Business experience until every user is licensed for Plan 2 and Microsoft Support switches it
Sentinel E5 data grant	Not included

For most 50 to 300 seat tenants, practical identity look-back is 30 days unless the logs are streamed somewhere else.

The Arithmetic: What a Months-Long BEC Campaign Demands

CyberQuell's four-month BEC case study shows what that means in practice. A professional services firm of about 50 people saw a fraudulent payment request in October 2025, reset passwords and revoked sessions, then saw a second request in January 2026, with hidden Outlook rules still in place. Access had likely persisted through a malicious OAuth application, which a password reset doesn't remove.

Work the windows backwards from each investigation:

January: understanding the second request meant reaching back about 90 days to October. That is 3 times a 30-day Entra P1 or Defender hunting window, and roughly 13 times Entra ID Free's 7 days.
February: the forensic review spanned about 120 days, 4 times a 30-day window and roughly 17 times a 7-day window. It sits inside Audit (Standard)'s 180 days.
Upgrading late doesn't help much. Microsoft documents that moving from Entra ID Free to a premium licence shows up to 7 days of earlier activity. Retention isn't retroactive.

How to Extend Your SOC's Look-Back

Connect the free sources to Sentinel first: Office 365 audit logs, Defender XDR alerts and incidents, and Azure Activity.
Stream Entra sign-in and audit logs to Sentinel or Azure storage. This is billable, and the E5 data grant offsets it.
Stream Defender advanced hunting tables to Sentinel, then set workspace or per-table retention beyond 30 days.
Move to Audit (Premium) for 1-year records. It requires Microsoft 365 E5, Office 365 E5, Microsoft Purview Suite, or the E5 eDiscovery and Audit add-on.

Not sure how far back your own tenant can actually see?

Book a call with CyberQuell to map your licence mix against your real look-back window, and find out what your SOC could investigate today if an attack turned out to be four months old.

‍

How Does SOC Monitoring Work? From Alert to Incident

SOC monitoring turns raw alerts into a small number of accountable incidents. Analysts triage each alert, group related ones into an incident, and manage that incident as a case until it's closed with a classification.

Alerts vs Incidents

	What it is	Who creates it
Alert	A single signal from one detection source, such as a suspicious sign-in or a blocked file	A detection rule in Defender, Sentinel or a connected product
Incident	A collection of correlated alerts that make up the story of one attack, across devices, users and mailboxes	Defender XDR correlation, which also names the incident from alert attributes such as how many users or endpoints are affected

The Five Alert Triage Steps

Validate. Is the signal real, or a known-good pattern? Most alerts die here.
Enrich. Add context the alert doesn't carry: who the user is, what the device does, whether the indicator is known-bad. This is where enriching alerts with threat intelligence in Sentinel earns its keep.
Correlate. Group the alert with related signals so one attack becomes one incident, not nine tickets.
Prioritise. Rank by severity and by what the affected asset actually does for the business.
Escalate or close. Either it becomes an incident someone owns, or it closes with a reason.

Alert fatigue is a triage problem, not a tooling problem. Teams drown when every alert gets the same treatment, which is why automating alert triage is usually the first thing a SOC automates.

SOC Case Management: What Every Incident Record Needs

Field	What it does in the Defender portal
Status	Incidents start as Active, move to In progress while someone works them, and end as Resolved
Severity	High, Medium, Low or Informational, which is what escalation keys on
Owner	Assigning an incident takes ownership of every alert inside it
Classification	True positive, Informational expected activity, or False positive, each with a Determination that records why
Tags	The correlation engine generates incident names, so automation should key on tags rather than titles
Comments and activity log	The handoff trail between shifts and the evidence record afterwards
Merges	Related incidents merge into one, but a closed incident isn't reopened by a merge

Microsoft now has a native layer above this. Case management in the Defender portal is generally available, and it lets a SOC define custom status values, assign tasks with due dates, and link several incidents to a single case, with access controlled by role. It requires a connected Microsoft Sentinel workspace, and cases are visible only in the Defender portal, not the Azure portal.

One transitional note: if you still run Sentinel in the Azure portal, supported until 31 March 2027, the values differ across the sync. Active shows as New, Not set shows as Undetermined, Sentinel incidents cap at 150 alerts, and a merged incident closes with a "redirected" tag.

‍

How Does SOC Incident Response Work?

SOC incident response begins when triage confirms a real incident. The SOC assigns severity, escalates to the right people within agreed times, coordinates containment, and keeps the case current until closure.

What follows in a mature process maps to the six incident response phases. The two things that decide whether it runs well are the same two things most contracts leave vague: what each severity level triggers, and who is allowed to act.

Severity-Based Escalation

Use this as a starting template and adjust it to your environment. The severity levels match the ones Defender assigns.

Severity	Microsoft 365 example	Who's engaged	What to agree in writing
High	Confirmed business email compromise with a hidden forwarding rule, or a stolen token with an active session	SOC analyst and incident responder, customer IT brought in immediately	Notification method and time, and whether the SOC can disable an account without asking
Medium	A risky sign-in that passed MFA from an unusual location, or malware contained automatically on one device	SOC analyst, customer IT notified	Whether the SOC can isolate a device on its own authority
Low	A phishing message delivered to a single mailbox and blocked, or repeated failed sign-ins with no success	SOC analyst only	How these reach you: ticket, daily digest or monthly report
Informational	Expected admin activity, or sanctioned penetration testing	SOC analyst, closed as informational expected activity	How to register planned testing so it isn't escalated as an attack

CyberQuell's commitment is 15 minutes from a confirmed threat to an analyst actively working on containment, at any hour, tracked and reported monthly. Lower-severity events are handled by the SOC and logged in the monthly report rather than escalated.

Who Does What During a SOC-Led Incident

A RACI (responsible, accountable, consulted, informed) split removes the pause where everyone waits for someone else to act. This is a template, not a contract.

Activity	SOC analyst	Incident responder	Customer IT	Leadership
Alert triage	R, A	C	I
Incident declaration	R	A	C	I
Containment in Microsoft 365	R	A	C	I
Stakeholder updates	C	R	C	A
Remediation and rebuild	C	C	R, A	I
Closure and classification	R	A	C	I

The split shifts depending on what you've actually signed, which is the point of understanding who owns each decision when a provider runs your SOC before an incident rather than during one.

‍

Specialised Microsoft 365 Monitoring vs a General-Purpose SOC

A Microsoft-specialised SOC catches identity, email and endpoint attacks inside Microsoft 365 with less integration work, because Defender XDR already correlates those signals. A general-purpose SOC fits better when much of your estate runs outside Microsoft.

Side-by-Side Comparison

	Microsoft-specialised SOC	General-purpose SOC
Signal correlation	Defender XDR correlates endpoint, identity, email and cloud app alerts into one incident before a human sees it	Correlation is built in the SIEM, using rules the provider writes and maintains
Microsoft-specific detections	Hidden inbox rules, OAuth app consents, risky sign-ins and token theft are native detections	Depends on which Microsoft logs the provider ingests and what they've written rules for
Non-Microsoft coverage	Needs connectors and custom rules for anything outside the stack	Usually the stronger side, with existing parsers for common third-party tools
Data cost model	Alerts and incidents stream free, raw Entra and hunting tables are billable	Often billed on total ingestion, so Microsoft logs are charged like any other source
Response integration	Containment runs through Defender actions on the same incident record	Response may mean a ticket to your team unless the provider holds permissions
Setup effort	Lower inside Microsoft 365, since the correlation already exists	Higher, but the work buys breadth across mixed environments
Vendor dependence	Concentrated in one vendor's roadmap and portal changes	Spread across tools, at the cost of more integration to maintain
Best fit	Estates where identity, email and endpoints are Microsoft	Estates where much of the risk sits outside Microsoft

If the question is really which managed plan to buy on top of that, when a third-party MDR beats Microsoft-native coverage covers the licensing side of the decision, and how MDR and a SOC fit a Microsoft estate covers where the two service models differ.

Microsoft Integration Limits to Check Before You Decide

Microsoft Sentinel won't be supported in the Azure portal after 31 March 2027 and runs only in the Defender portal.
Workspaces first onboarded after 1 July 2025 by a subscription Owner or User Access Administrator go to the Defender portal automatically.
Connecting Defender XDR turns off Microsoft incident creation rules, which the Defender portal doesn't support, and the correlation engine renames incidents, so automation should key on tags rather than incident titles.
Defender Vulnerability Management tables appear in the Sentinel schema but the data isn't ingested, so those queries return nothing there.
Defender for Cloud incidents arrive without their alerts and entities unless the Defender for Cloud connector is enabled.
A tenant running Business Premium alongside E5 Security stays on the Defender for Business experience until every user is licensed for Plan 2.

When a General-Purpose SOC Is the Better Choice

A non-Microsoft EDR is your primary endpoint tool
Significant workloads run in AWS or Google Cloud
Identity runs on Okta or another non-Microsoft provider
You have OT or IoT environments to monitor
Most of your telemetry is on-premises network traffic

‍

What SOC Monitoring Looks Like in Practice: Six Months of Incidents

In its first six months, a CyberQuell white-label SOC serving an MSP's small-business portfolio, which grew from 38 to 43 clients, detected and contained 127 incidents, with a reported average response time of 8 minutes.

The arithmetic is worth doing, because volume is what most buyers guess wrong:

127 incidents over 6 months is about 21 a month
Across 43 clients, roughly 0.49 incidents per client per month, approximate because the portfolio grew during the period
Cross-check against the first 30 days: 18 incidents across 38 clients is about 0.47 per client, which is consistent

Three incidents from that period, with what actually triggered detection:

Incident	What triggered detection	Response time	Outcome
Business email compromise	A suspicious inbox rule in an executive mailbox	4 min	Contained before a wire request went out
Credential stuffing	2,400 failed sign-ins across three tenants in two hours	6 min	No accounts compromised
Ransomware precursor	A Cobalt Strike beacon flagged by Defender for Endpoint	11 min	One device affected, no encryption

The stack behind it was a Microsoft Sentinel workspace per client, accessed through Azure Lighthouse, ingesting Microsoft 365 audit logs, Defender for Endpoint telemetry and Microsoft Entra ID sign-in events. The inbox rule in the first row is exactly the signal the four-month BEC campaign turned on, which is the retention argument stated a different way.

Three things to be clear about before anyone quotes these numbers. They are self-reported from one MSP's portfolio, not an industry benchmark. The case study doesn't define where response time starts and stops, so treat the minute figures as reported rather than measured against a standard. And they aren't the same metric as the 15-minute SLA, which runs from a confirmed threat to an analyst working on containment.

Ask any provider for the same three things: the incident count, the client count behind it, and the definition of the clock they're quoting. The full white-label SOC case study has the rest of the detail, and what true 24/7 monitoring and response should include covers how to score a provider's answer.

‍

Final Thoughts

Staying ahead of an attack depends less on which dashboard your SOC monitoring runs on than on two things you can check today. The first is how far back your logs actually reach, because a tenant on default retention keeps 7 or 30 days of Entra sign-in history while a business email compromise can run for months. The second is what happens after an alert is confirmed: who assigns severity, who is allowed to contain, and how quickly a human is on it.

Those two answers decide whether a SOC finds the whole attack or only its latest symptom. Run the check in this order. Work out which log sources you send to Microsoft Sentinel and what each one costs. Confirm your real look-back window against your licence mix rather than the default you inherited. Then get the escalation path and the response clock defined in writing, with the start and end points named, before you need either.

Book a call with CyberQuell to map your Microsoft 365 log sources and retention windows, agree an escalation path for each severity, and scope a 30-day pilot with 24/7 monitoring and a 15-minute response commitment on confirmed threats.

Last Updated:

September 24, 2026

FAQs

Find answers to commonly asked questions about our cybersecurity solutions and services.

What tools does a SOC use for monitoring?

A SOC runs on a SIEM for log collection and correlation, an XDR platform for endpoint, identity and email detection, automation rules or playbooks for repetitive actions, an incident queue for case management, and threat intelligence for enrichment. In a Microsoft environment that usually means Microsoft Sentinel and Microsoft Defender XDR feeding one incident queue. Tools alone don't make a SOC; analysts reviewing what those tools produce do.

‍

Is SOC monitoring the same as a SIEM?

No. A SIEM is a tool that collects, correlates and stores security logs. SOC monitoring is the people and process deciding which of those correlated events represent a real attack, which is why a SIEM with nobody watching it produces alerts rather than security.

‍

How long does Microsoft 365 keep security logs?

It depends on licence. Microsoft Entra keeps sign-in and audit logs for 7 days on Entra ID Free and 30 days on P1 or P2, Defender advanced hunting holds 30 days of raw data, and the Microsoft 365 audit log retains 180 days on Audit (Standard) or one year for Entra, Exchange, OneDrive and SharePoint records on Audit (Premium). Retention changes are not retroactive, so upgrading a licence after an incident does not recover the earlier history.

What is SOC case management?

SOC case management is the discipline of tracking each incident as a record with a status, a severity, an owner, a classification and tags, so incidents get resolved accountably rather than informally. In the Microsoft Defender portal it is also a named feature, letting a SOC define custom status values, assign tasks with due dates, and link several incidents to one case. It requires a connected Microsoft Sentinel workspace and is available only in the Defender portal.

Does 24/7 monitoring mean a human reviews every alert?

No, and no provider does this at scale. Automation handles triage and closure for high-volume, low-risk alerts, while analysts review what escalates past those rules. Ask a provider what proportion of alerts a human actually sees, and what automation closes without review, because that ratio is the real difference between two services that both advertise 24/7 coverage

How fast should a SOC respond to a confirmed threat?

There is no universal standard, and published provider figures rarely say where the clock starts or stops. Ask for the start and end points in writing, because alert generated, threat confirmed, analyst engaged and threat contained are four different measurements. CyberQuell's commitment is 15 minutes from a confirmed threat to an analyst actively working on containment, at any hour, tracked and reported monthly.

How do you measure SOC monitoring effectiveness?

Track time to detect, time to respond, true-positive rate and coverage, meaning how much of your estate is actually monitored. Coverage is the one most often skipped, because a fast response across 60% of your log sources is worse than it looks. Ask for these monthly rather than on request.

Can small businesses get SOC monitoring?

Yes. Small businesses typically access it through a managed SOC, or through an MSP reselling a white-label SOC, rather than building in-house, which requires enough analysts to cover 168 hours a week. The practical question is not availability but which log sources your licence lets you send, and when a managed SOC is the right choice for your size of team.

Latest