What a SOC Actually Does

A discipline, not a dashboard

Ask a SOC analyst what the SOC does and you'll get a clear answer: "We monitor alerts, investigate incidents, and escalate threats." That answer is accurate the same way "a hospital treats patients" is accurate, it describes the function without explaining the system. It doesn't explain what the SOC monitors, what determines whether an alert gets investigated or closed, what the escalation criteria are, how investigation findings flow back to detection engineering, or how the SOC's performance is measured against the metrics that actually matter.

Security operations is the discipline of detecting threats, investigating incidents, and improving the organization's security posture over time. Not monitoring alerts, that's the input. Not watching dashboards, that's the visual. Not "24/7 coverage", that's a staffing metric that tells you nothing about detection quality. Security operations is the engineering discipline that turns a collection of security tools, detection rules, and analyst skills into a measured system that gets better every quarter.

The distinction between monitoring and operations is the distinction this course teaches. A team that triages alerts has security monitoring. A team that triages alerts using a documented methodology, measures triage accuracy, tracks detection coverage against ATT&CK, reviews false positive rates monthly, and reports quality metrics to leadership has security operations. The first team processes work. The second team runs a discipline.

The numbers tell the story. Mandiant's M-Trends 2026 report puts the global median dwell time, how long an attacker operates before detection, at 14 days. For ransomware specifically, the median dropped to 9 days. The IBM 2025 Cost of a Data Breach Report found organizations averaged 158 days to identify breaches at the macro level. The gap between SOC-level benchmarks measured in hours and breach-level statistics measured in months reflects the difference between detecting alerts that fire and discovering intrusions that evade detection entirely.

Fifty-two percent of organizations now detect malicious activity internally, up from 43% the year before. That improvement is real and meaningful, but it also means 48% of compromises are still discovered by external parties: a partner, a customer, a law enforcement notification, or a user who notices something wrong before the SOC does. When users detect attacks more reliably than the SOC, something fundamental is broken in the detection program, and no amount of speed optimization will fix it.

Estimated time: 40 minutes.

Layer 1: Visibility: what the SOC can see

Visibility is not a binary. The SOC doesn't simply "monitor the environment." It monitors what the detection rules are designed to catch, and everything else passes through undetected. An organization with 40 Sentinel analytics rules might have visibility into credential compromise, brute force authentication, and known malware signatures, and zero visibility into OAuth consent grant abuse, adversary-in-the-middle token theft, device code phishing, or living-off-the-land PowerShell techniques that use legitimate system tools to avoid endpoint detection.

This means every claim about SOC capability. "we have 24/7 monitoring," "we detect threats in real time", is bounded by the detection library. The SOC's actual capability is the intersection of what the detection rules cover and what the analysts can investigate. Everything outside that intersection is invisible regardless of how many analysts are on shift or how fast they triage.

What determines visibility

Three factors determine what the SOC can see. The first is data source coverage, which log tables are connected to Sentinel. If EmailEvents isn't ingested, the SOC can't detect email-based attacks regardless of how many email detection rules exist. If DeviceProcessEvents isn't flowing from Defender for Endpoint, endpoint detection rules are inert. Data source coverage is the foundation, without the telemetry, nothing else works.

The second factor is detection rule coverage, which attack techniques have at least one active analytics rule that queries the connected data. Data source coverage tells you what telemetry you have. Detection rule coverage tells you what you do with that telemetry. An organization that ingests SigninLogs but has no rule that queries for adversary-in-the-middle session token characteristics has the data to detect AiTM, and no mechanism to alert on it.

The third factor is detection rule quality, whether the rules that exist actually detect the techniques they claim to detect, at a false positive rate the SOC can sustain. A rule for "suspicious PowerShell execution" that fires on every encoded command line produces 200 false positives per day at an organization whose admin team uses encoded PowerShell for legitimate automation. That rule provides nominal coverage for T1059.001 in the ATT&CK matrix, but operational coverage is zero because the alert volume makes the rule unusable.

The visibility gap nobody measures

Most organizations know how many analytics rules they have. Almost no organization knows what percentage of relevant ATT&CK techniques those rules actually cover. The typical mid-size organization on the Microsoft stack has 20-40 analytics rules covering 10-15% of the techniques relevant to their threat landscape. The other 85-90% of relevant techniques produce telemetry in the Sentinel workspace, the data is collected, the ingestion cost is paid, but no rule examines it. Attacks using those techniques generate zero alerts.

This is the visibility gap. It's not a theoretical problem, it's the operational state of the majority of organizations. The SIEM deployment project enabled template rules, the SOC monitors the alerts those rules produce, and nobody ever measured what the rules actually cover. The gap between "we have detection" and "we know what we detect" is where the discipline of SOC operations begins.

Layer 2: Response: what the SOC does with what it sees

When an alert fires, something happens. In a SOC without operational discipline, what happens depends on who's on shift. One analyst checks the user's sign-in history, queries for related alerts, and makes an informed classification in 12 minutes. Another analyst reads the alert title, checks whether MFA is present, and closes it in 90 seconds. Both close the alert. One investigated. One didn't. The incident queue doesn't know the difference.

Response capability is the layer that defines what happens between alert and resolution. It includes triage methodology, the decision framework an analyst uses to classify an alert as true positive, false positive, or benign true positive. It includes investigation methodology, the process for determining the full scope of a confirmed or suspected compromise. It includes escalation paths, the criteria that determine when an alert exceeds one analyst's scope and moves to the next tier. And it includes containment authority, what actions the SOC can take independently and what requires approval.

The formalization gap

Most SOCs operate this layer informally. There's no documented triage decision framework. The quality of investigation depends on which analyst happens to be on shift. The escalation criteria are whatever each analyst feels is appropriate. Experienced analysts investigate thoroughly because they know what matters. New analysts close alerts faster because they don't know what to look for and there's no documented methodology telling them.

The result is inconsistent investigation quality. The same alert type gets 12 minutes of investigation from one analyst and 90 seconds from another. The experienced analyst finds the compromise. The new analyst closes it as benign. Neither knows the other's decision unless someone reviews closed incidents, and in most SOCs, nobody does.

The Tines 2025 Voice of the SOC Analyst report found that 71% of SOC analysts report burnout and 64% are considering leaving their roles within a year. The ISC2 2025 Cybersecurity Workforce Study identified 4.8 million unfilled cybersecurity roles globally, a 19% year-over-year increase. These numbers matter for response capability because they mean the SOC's institutional knowledge is walking out the door on a predictable timeline. When the experienced analyst who knows the environment, the users, and the investigation patterns leaves, the investigation quality they carried in their head leaves with them, unless the methodology is documented, repeatable, and transferable to the replacement.

What "documented" actually means

Documented doesn't mean a 40-page runbook in SharePoint that nobody reads. Documented means a triage decision framework the L1 analyst references during every shift, a structured set of criteria that tells the analyst what to check, what the results mean, and when to escalate. It means an investigation template the L2 analyst opens for every investigation, a consistent format that ensures evidence is preserved, timelines are reconstructed, and determinations are documented with supporting evidence. It means an escalation framework with defined triggers, not just severity levels, but criteria for handling the 30% of alerts that fall between obviously benign and obviously critical.

These are the operational documents that Module 1 of this course builds. They're not bureaucratic overhead. They're the infrastructure that makes investigation quality independent of which specific analyst is on shift, which is the definition of operational maturity.

Layer 3: The feedback loop: how the SOC improves

The feedback loop is the layer most SOCs lack entirely. It's also the layer that determines whether the SOC's detection capability improves, stagnates, or degrades over time.

What the feedback loop does

When an L2 investigation reveals that a phishing campaign bypassed email detection because the payload used HTML smuggling, someone needs to write a detection rule for HTML smuggling payloads. When a detection rule produces 30 false positives per week because the scoping condition matches a legitimate admin workflow, someone needs to tune it. When a post-incident review identifies that an AiTM attack was visible in SigninLogs for six days before an alert fired, someone needs to close the detection gap.

That "someone" is the feedback loop, the operational function that converts investigation findings into detection improvements. In organizations with a dedicated detection engineering function, the feedback loop is formalized: findings go to the detection engineer, who writes the rule, tests it, tunes it, and deploys it. In organizations without a dedicated function, which is the majority, the feedback loop either runs through the L3 analyst (if one exists) or doesn't happen at all.

What happens without it

Without the feedback loop, the SOC processes alerts generated by the same set of rules forever. The threat landscape evolves, new attack techniques emerge, adversaries adopt new tools, the organization's technology stack changes, but the detection rules don't evolve with it. The gap between what the rules detect and what attackers actually do grows wider every quarter.

False positive rates climb because the environment changes, new admin workflows, new applications, new service accounts, but the rules that fire on those changes are never tuned. Each false positive consumes analyst time that could be spent on real investigation. Alert fatigue sets in. Classification accuracy degrades. The SOC is running harder to stay in the same place, while the threat landscape moves away from it.

The M-Trends 2026 report documented a sharp rise in attacker "hand-offs", initial access brokers passing environment access to ransomware operators in under 30 seconds. Twenty-five percent of incidents saw data exfiltration in under five hours. The speed of sophisticated attacks means that detection gaps measured in techniques are survival gaps measured in hours. A SOC that discovers a technique wasn't detected after a breach, rather than discovering the gap during a proactive review and closing it before the attacker arrives, is a SOC operating without the feedback loop.

What the feedback loop requires

The feedback loop requires three things. First, a mechanism for investigation findings to reach the person who can write or modify detection rules. In most SOCs, this mechanism doesn't exist, investigation findings stay in closed ticket notes that nobody reviews.

Second, a tuning cadence, a scheduled, monthly review of false positive data that classifies each FP source by root cause and applies targeted fixes. Without a cadence, tuning happens only when the noise becomes unbearable, which means it happens too late.

Third, a coverage assessment cadence, a quarterly review of ATT&CK coverage that identifies which new techniques have entered the threat landscape since the last assessment and which detection gaps remain from the previous assessment. Without a coverage cadence, the detection library is evaluated only when an incident reveals a gap, which is the most expensive way to discover that a technique isn't detected.

This course builds all three. Module 1 establishes the operational foundation, including the metrics framework that makes the feedback loop measurable. Module 2 teaches the detection engineering methodology that the feedback loop feeds into. Modules 3-6 build the 28 detection rules that demonstrate the lifecycle. Modules 10-12 build the automation, metrics, and threat intelligence program that sustain the feedback loop long-term.

Why this matters now

SOC operations is not a new concept. Organizations have operated security monitoring functions since SIEMs existed. What's changed is the threat landscape's speed, the platform's capability, and the profession's expectations.

The speed change

Attackers exfiltrate data in under five hours in 25% of incidents. Attacker hand-offs, an initial access broker passing credentials to a ransomware operator, happen in under 30 seconds. Ransomware pre-encryption dwell times have dropped to a median of 9 days, with some campaigns executing encryption within hours of initial access. A SOC operating on habits, undocumented escalation, inconsistent investigation, no feedback loop, cannot respond to attacks that move this fast. The operational infrastructure has to be in place before the attack arrives. You can't build the escalation framework during the incident.

The platform opportunity

Microsoft Sentinel and Defender XDR place identity telemetry, endpoint telemetry, email telemetry, cloud application telemetry, and infrastructure telemetry in a single queryable workspace. For the first time, a detection rule can join a compromised authentication in SigninLogs with an inbox rule creation in OfficeActivity within 30 minutes, tracing two phases of an attack chain in one query. This cross-family correlation was impossible when identity data lived in one SIEM, email data in a separate gateway, and endpoint data in a different EDR with its own query language.

The organizations that benefit most from this unified data model are the ones that build cross-family detection rules and investigate across domains. The organizations that benefit least are the ones that enable templates and leave the cross-family data unexamined. This course teaches SOC operations on the Microsoft stack because the platform's capability exceeds what most organizations use, and the gap between capability and usage is where operational discipline creates the most value.

The professional shift

SOC operations is a career, not a waypoint. The average SOC analyst salary ranges from $75,000 to $137,000, with the median at $100,000-$103,000. The role has a defined career progression: L1 triage → L2 investigation → L3 deep analysis and detection feedback → SOC lead → security operations manager. The professionals who advance fastest are the ones who demonstrate operational maturity, not just "I can investigate an alert" but "I can design the escalation framework, build the metrics dashboard, write the board report, and prove the SOC is improving."

Every module in this course produces an operational artifact that demonstrates that maturity. The SOC charter. The escalation framework. The metrics dashboard. The investigation playbooks. The detection rules. The board report. These are not theoretical exercises, they're the artifacts that distinguish a SOC analyst who processes alerts from a security operations professional who runs a measured program.