What a Security Operations Centre Actually Monitors and Responds To

TL;DR — A security operations centre (SOC) does not "watch your company" in a magical way; it collects security-relevant events from your devices, cloud services, apps, and identity systems, looks for suspicious patterns, and then investigates and responds. The key takeaway for most companies is this: a SOC is only as useful as the logs, alerts, and response actions you have actually connected to it, so the first decision is not "Do we want monitoring?" but "What systems will send evidence, and who will act on it?" Reading time: ~7 min

What it is and where it sits

A security operations centre (SOC) is the team and process that monitors security signals across your company and decides whether something is normal, suspicious, or an active incident. In an Extended Detection & Response (XDR) setup, the SOC is usually the human layer sitting on top of tools that pull together signals from endpoints (employee laptops and servers), identity providers (login systems such as Microsoft Entra ID or Okta), cloud platforms, email, firewalls, and application logs.

Think of it as an operations desk for security events. It does not replace your firewall, antivirus, backups, or developers. It sits above them, consuming their alerts and telemetry (machine-generated activity data), then coordinating response.

In a typical architecture, these systems talk to the SOC or to the SOC's tooling:

• Endpoint agents on laptops and servers
• Identity systems: sign-in logs, MFA (multi-factor authentication) events, password resets
• Cloud audit logs: who created a VM, changed a storage bucket, altered a security group
• Email security tools: suspicious attachments, phishing clicks
• Network devices: VPN, firewall, DNS, proxy logs
• Application and server logs: nginx, Windows Event Log, Linux auth logs, database access logs
• Ticketing/chat tools where incidents are handed off

What it replaces: usually manual spot-checking and fragmented alert inboxes. Without a SOC, companies often have alerts scattered across cloud dashboards, antivirus consoles, and email notifications that nobody consistently triages.

Where it lives in the flow: usually off to the side of normal business traffic. Your customer request still goes from browser to CDN to app to database. Separately, those systems emit logs and alerts to a central platform where the SOC works.

[Customer Browser] ---- 1. HTTPS request ----> [Web App]
[Web App] ---- 2. query/write ----> [Database]
[Web App] ---- 3. app logs ----> [Log Platform]
[Database] ---- 4. audit logs ----> [Log Platform]
[Identity Provider] ---- 5. sign-in logs ----> [Log Platform]
[Employee Laptop] ---- 6. endpoint alerts ----> [XDR Platform]
[Log Platform] ---- 7. detections ----> [SOC Analysts]
[XDR Platform] ---- 8. detections ----> [SOC Analysts]
[SOC Analysts] ---- 9. ticket/chat/call ----> [Your IT or Dev Team]

The important architecture point: the SOC usually does not sit inline in the request path like a load balancer or reverse proxy. It is mostly observing and coordinating. Some response actions can become inline later — for example, disabling a user account or isolating a laptop from the network — but monitoring itself is usually out-of-band (not directly in the request path).

How it actually works

Here is one realistic end-to-end example: an employee's Microsoft 365 account is taken over through phishing, and the attacker starts reading email and setting up forwarding rules.

Step 1: Data arrives from connected systems

The SOC's tools ingest several streams:

• Identity sign-in logs from your identity provider
• Email audit logs from Microsoft 365 or Google Workspace
• Endpoint telemetry from the employee's laptop
• VPN or geo-location context from network logs

In a dashboard, this usually starts with enabling log export or API connections in each provider's admin area. Typical paths are:

• In your identity provider's admin dashboard: Security → Reports / Sign-in logs → Export / Stream logs
• In Microsoft 365 admin areas: Compliance / Audit → Audit search / Export or connector setup in your SIEM (security information and event management system)
• In your cloud provider: Monitoring / Logging → Create sink / Export

Step 2: A detection rule fires

The SOC does not read every line manually. Detection rules look for combinations such as:

• Successful login from a country the user has never used
• MFA fatigue pattern (many push prompts in a short time)
• Creation of an inbox forwarding rule right after a suspicious login
• Impossible travel (two logins too far apart to be physically plausible)

A single strange login may be harmless. A strange login plus a forwarding rule plus mailbox access from a new device is much more serious.

Step 3: An analyst triages the alert

The analyst checks context before waking anyone up:

• Is the user traveling?
• Was the login through the normal corporate device?
• Did the same IP address hit other accounts?
• Did the user recently reset their password?
• Are there endpoint alerts on the laptop too?

This is where SOC value shows up. Good SOC work is not just "an alert happened." It is deciding whether this is a real incident, a false positive (benign alert), or something to watch.

Step 4: The SOC investigates scope

If the alert looks real, the SOC asks: how bad is it, and what else is touched?

For this example, they would check:

• Other successful logins from the same IP
• Whether mailbox rules were added, deleted, or hidden
• Whether OAuth app consent (granting an app access to mail) was created
• Whether the user sent phishing emails internally
• Whether the same credentials were used on VPN, Slack, GitHub, or cloud consoles

This is why XDR matters. A SOC limited to one tool may see only the mailbox event. A SOC with XDR can pivot across identity, endpoint, email, and cloud activity.

Step 5: Response actions happen

Common response actions for this scenario are concrete and fast:

• Disable the user session in the identity provider
• Force password reset
• Revoke active tokens (log out existing sessions)
• Remove malicious mailbox forwarding rules
• Block the source IP if appropriate
• Check whether the laptop needs endpoint isolation
• Open an incident ticket for IT and management

In a provider dashboard, this is usually done in places like:

• Identity provider dashboard → Users → [user] → Revoke sessions / Reset password / Block sign-in
• Email admin dashboard → Mailboxes → [user] → Mail flow rules / Forwarding → Remove rule
• Endpoint security console → Devices → [device] → Isolate device

Step 6: The SOC documents and improves detections

After containment, the SOC should record:

• What happened
• What evidence confirmed it
• What actions were taken
• How long detection and response took
• What rule or process should be improved

That last part matters. A mature SOC gets better over time. If every phishing incident requires manual mailbox-rule hunting, the SOC should add a detection for "new forwarding rule after risky login."

When to use it (and when not to)

You probably want a SOC, or a managed SOC service, when your business has enough systems and risk that security alerts cannot be handled ad hoc by whoever notices an email.

You probably do not need this yet if:

• You have almost no central logging
• You cannot name who will approve account lockouts or emergency response actions
• Your bigger problem is basic hygiene: no MFA, no patching, no backups, shared admin accounts

In those cases, spending on SOC before fixing basics often creates noise instead of protection.

Trade-offs

Every SOC benefit comes with a cost.

• Benefit: faster detection of real attacks
  Cost: you must connect many log sources, tune rules, and pay for storage, tooling, and analyst time.

• Benefit: someone is watching after hours
  Cost: 24/7 coverage is expensive, and handoffs can be messy if your internal team is unavailable or unclear on authority.

• Benefit: better visibility across identity, endpoint, cloud, and email
  Cost: integration complexity. Different systems log differently, keep data for different periods, and may need API permissions that your admins are uncomfortable granting.

• Benefit: quicker containment actions
  Cost: response automation can disrupt the business. Disabling the wrong account or isolating the wrong device can stop real work.

• Benefit: evidence for audits and incident reviews
  Cost: retaining logs costs money and may raise privacy and data residency questions.

• Benefit: one place to triage alerts
  Cost: platform lock-in can creep in if detections, dashboards, and workflows become tied to one vendor's ecosystem.

A useful buying question is: "What response actions are included, and who is allowed to approve them?" Monitoring without authority often means the SOC can only email you while the attacker keeps working.

In practice

Below are two concrete examples of the kind of plumbing a SOC depends on. These are not "the SOC" by themselves; they are examples of feeding useful evidence into it.

Example 1: Forward nginx access and error logs with Filebeat

filebeat.inputs:
  - type: filestream
    id: nginx-access
    paths:
      - /var/log/nginx/access.log
    fields:
      service: web
      log_type: nginx_access

  - type: filestream
    id: nginx-error
    paths:
      - /var/log/nginx/error.log
    fields:
      service: web
      log_type: nginx_error

output.elasticsearch:
  hosts: ["https://logs.example.com:9200"]
  username: "filebeat_writer"
  password: "REPLACE_ME"

This ships web server logs to a central log platform so the SOC can correlate suspicious requests, admin logins, or attack patterns with other events. Gotcha: log shipping without time sync is painful; check your server clock and timezone first or your investigation timeline will be wrong.

Example 2: Send Linux authentication logs with rsyslog

module(load="imfile")

input(type="imfile"
      File="/var/log/auth.log"
      Tag="authlog"
      Severity="info"
      Facility="local6")

action(type="omfwd"
       Target="siem.example.com"
       Port="514"
       Protocol="tcp"
       TCP_Framing="octet-counted")

This forwards login-related events such as SSH attempts and sudo usage to a central collector. Gotcha: plain syslog over TCP may still be unencrypted depending on your setup; use your provider's documented TLS method if logs cross the public internet.

Example 3: Useful local commands during an investigation

⚠️ Running response actions like disabling accounts or killing sessions can interrupt real users. Confirm the identity of the affected user and record the reason in your ticket before doing it.

sudo last -a | head -20
sudo grep "Failed password" /var/log/auth.log | tail -20
sudo journalctl -u ssh --since "2 hours ago"

These commands help confirm whether a Linux server saw unusual login activity around the time of an alert. Gotcha: log retention may be short on small servers, so if you only keep a few days locally, central collection is not optional.

Further reading

• NIST Computer Security Incident Handling Guide (SP 800-61)
• MITRE ATT&CK
• The "Logging" and "Audit Logs" sections of your cloud provider's security documentation
• Microsoft 365 Unified Audit Log documentation
• Google Cloud Architecture Framework: Security and Logging

This article was written by an AI system and published pending human review. Verify anything you intend to act on.