SIEM and SOC for a midsize business: who acts on the alert?
An alert reports unusual administrator activity at midnight. The monitoring platform collected it correctly, but the notification goes to an unattended mailbox and nobody has authority to suspend the account. Security monitoring succeeds when useful evidence reaches a person who can investigate and act, within the coverage your business actually needs.
A SIEM, or security information and event management system, helps collect and analyze security events. A SOC, or security operations center, is an operating capability involving people, processes, and technology for detection, investigation, and response. Buying the first does not automatically provide the second.
For a midsize company, begin with important systems and plausible incidents. Decide what evidence you need, who reviews it, and what action is permitted. Then choose an internal, managed, or hybrid arrangement that can operate those responsibilities reliably.
01Separate the platform from the operating service
A SIEM can combine events from identities, endpoints, networks, applications, and cloud services. Microsoft Sentinel's overview illustrates collection, analysis, investigation, and response capabilities. The value still depends on the data supplied, configured detections, business context, and people handling the result.
Endpoint detection and response focuses on endpoint activity and response. A SIEM can use its alerts alongside other sources. A managed detection and response service may provide monitoring and investigation with a defined scope. These labels overlap in commercial offers, so ask exactly which systems, hours, and actions are covered.
| Operating model | What it can provide | What your company must clarify |
|---|---|---|
| Internal security operation | Direct knowledge and control with your own analysts | Staffing, coverage, skills, tooling, leave, escalation and ongoing maintenance |
| Managed monitoring or SOC service | Supplier analysts and agreed investigation capability | Included sources, response authority, service hours, evidence access and handover |
| Hybrid operation | External monitoring with internal system and business owners | Who handles each stage, what waits for approval, and how teams coordinate |
| Limited monitoring pilot | A smaller set of detections operated within explicit hours | The gaps and risks accepted while capability is being proved |
Avoid treating a staffed dashboard as proof of complete coverage. A supplier may monitor only selected endpoints, escalate findings without taking action, or depend on your team for application context. Record those boundaries before comparing proposals.
02Choose detection questions around real business risks
Start with the workflows whose compromise would matter most: identity administration, customer records, payments, production systems, or important intellectual property. Ask what suspicious behavior you want to recognize and what legitimate activity can look similar. An unexpected export during a migration is different from an unexplained export by a new account.
- An administrator role is added without an expected change request.
- A suspicious sign-in is followed by a new mailbox forwarding rule.
- An account performs unusual access or export on a sensitive data set.
- Endpoint protection or an important audit source stops reporting.
- A cloud access policy changes in a way that exposes an important resource.
These are illustrative detection questions, not ready-to-run rules or proof that every event is malicious. For each, specify the data, relevant fields, business context, analyst check, likely benign explanations, and authorized response. Some sources or licenses may not expose the evidence you expect.
Use MITRE ATT&CK as a vocabulary for adversary behavior and threat modeling. Mapping a rule to a technique does not prove it detects every instance of that behavior. Prioritize scenarios relevant to your environment and verify them with safe, authorized tests.
Begin with a set your team can maintain and investigate. A large imported rule library may generate more work without increasing useful visibility. Expand when you can explain the coverage and gaps of the current detections.
03Treat log quality and collection health as controls
Confirm the source actually records the operation, then verify delivery and interpretation. Check timestamps, identities, event types, resource identifiers, parsing, duplication, and delays. Keep a known test event you can trace from its source to the analyst's view. A connected status alone does not prove the fields required by a detection arrive correctly.
CIS Control 8 addresses collecting, reviewing, alerting on, and retaining useful audit events. Choose logs that support detection, investigation, or recovery, with access and retention suited to their purpose and applicable requirements. Avoid sending passwords, tokens, or unnecessary sensitive content into the monitoring system.
Plan for changes in formats, licenses, connectors, and APIs. Sentinel's connector documentation distinguishes Microsoft, partner, and community support. A connector in the catalog can have a different maintenance and escalation route from the platform itself. Check the specific source and its current supported ingestion method.
Monitor missing or delayed data as well as suspicious events. A quiet dashboard can mean normal activity, a disconnected source, or a broken parser. Name who repairs collection failures, how the gap is recorded, and what temporary visibility is available while repair happens.
Review data location, supplier access, deletion options, and retention costs for the actual storage tier. These are service-specific and jurisdiction-dependent choices. Do not assume deleting a source record automatically deletes every ingested copy.
04Tune alerts into an investigation process
An analyst needs more than an alert title. Include the account or asset, time, relevant activity, confidence and limitations, known business context, and the next check. Link the investigation to evidence the reviewer can access. A screenshot without the underlying event can make follow-up unnecessarily difficult.
Group related activity when that helps the investigation, while preserving the events needed to understand the sequence. Document suppressions and allowlists, with a reason, owner, scope, and review. A broad permanent exception for a noisy account can hide the very activity you wanted to detect.
Review common benign explanations with operations staff. A new region, backup process, or support account can create unusual behavior. Tune from actual evidence rather than disabling a rule after the first inconvenience. Test that the adjusted rule still detects its intended scenario.
Track alert volume, useful escalations, investigation delays, false positives, and detections that failed a test. Interpret them together. Fewer alerts may reflect better tuning or reduced visibility; more closed tickets may reflect hurried dismissal rather than effective work.
05Agree on response authority before an incident
Define severity in terms of affected systems, evidence, and business impact. Specify who receives an escalation, the contact method, backup contacts, and expected handling during nights, weekends, and leave. Distinguish a notification promise from an investigation or containment commitment.
List actions the analyst or supplier may take immediately, actions requiring approval, and actions reserved for a system owner. Isolating an endpoint, disabling an identity, blocking a connection, or stopping an application can have different operational consequences. Agree on safeguards and recovery, especially for critical services.
Sentinel playbooks can run response workflows manually or through configured automation. Start with bounded tasks such as attaching evidence or opening an incident record. Automated containment needs tested permissions, reliable conditions, and a response when the workflow itself fails.
NIST's current incident-response guidance integrates response into cybersecurity risk management. Prepare beyond the initial alert: evidence handling, communication, recovery, and learning. Notification duties and deadlines depend on the incident, contracts, and applicable law, so use the relevant process for your business.
Rehearse a realistic scenario with the supplier and internal owners. Confirm the contact works, the investigator can obtain evidence, the approver understands the decision, and the team can restore the affected workflow. A tabletop discussion can expose missing authority before a disruptive technical test.
06Compare total cost and the service you can operate
Include ingestion, storage, queries, retention tiers, connectors, response automation, analyst time, engineering maintenance, and incident support. Ask how increased volume or another data source changes the quote. Use a representative sample of your logs rather than a generic employee-count estimate.
Compare services on the same detection and response scenarios. Ask for a demonstration of how an incident reaches your team and what the supplier does when evidence is missing. Clarify whether proactive tuning, collection-health monitoring, and incident investigation are included or separately charged.
Check reporting, evidence access, export, configuration ownership, and exit. Your company should understand what it receives if the provider changes. Document who owns the tenant, accounts, rules, connectors, and incident records, and how a replacement team can continue operating.
Be explicit about accepted gaps. Office-hours monitoring may be a conscious initial choice for one environment, while a critical around-the-clock workflow needs different coverage. A small team does not need to copy a large enterprise SOC, but it does need honest service boundaries and an actionable escalation route.
Our cloud security overview covers preventive and infrastructure controls. Monitoring complements that work; it still depends on appropriate access, reliable systems, and a recovery plan.
07Pilot the alert-to-action path
- Select the scenarios. Choose important systems and plausible incidents. Define the evidence, limits, owners, and desired response.
- Validate the data. Trace safe test events through collection, timestamps, parsing, detections, and collection-health checks.
- Rehearse operation. Test analyst access, escalation, approval, permitted containment, communication, and recovery.
- Review and expand. Assess useful findings, missed tests, noise, delays, costs, and remaining gaps before adding scope.
Keep the pilot's findings in the operating agreement. A source gap, slow approval, or unclear contact can matter more than another dashboard. Expand when the people responsible can demonstrate the process and maintain it through normal system changes.
08Questions about SIEM and SOC for midsize companies
Does buying a SIEM give us a SOC?
No. The platform provides capabilities, while the operating service needs people, maintained detections, investigation, escalation, and response. Clarify who handles each stage and during which hours.
Do we need our own analysts around the clock?
Choose internal, managed, or hybrid coverage from your risk and operating needs. Verify what the supplier investigates and may do, and what still depends on your internal contacts. A service label alone does not prove complete coverage.
Should we collect every available log?
Choose sources around useful detection and investigation, with appropriate privacy, retention, and cost. Also test collection health. Large volume does not compensate for missing fields or evidence from an important source.
Does ATT&CK mapping prove we are protected?
It helps describe intended coverage, but a mapped rule still needs relevant data and a meaningful test. It does not guarantee detection of every variation or replace the investigation and response process.
Can we automate account suspension?
Where the platform supports it, review authority, evidence, conditions, permissions, impact, and recovery. Test safely and keep approval for actions that require it. The automated workflow also needs monitoring and failure handling.
What should we ask a managed provider?
Ask about sources, coverage hours, collection health, tuning, investigations, response authority, contacts, costs, evidence access, and exit. Compare a real scenario from event to action instead of only comparing dashboards.
What shows the pilot is useful?
Known test events are detected and investigated, owners receive actionable escalation, and permitted response works. Review gaps, noise, delays, operating costs, and the evidence preserved for follow-up.