Why most security alerts are never analysed

Monday, 8:05 a.m. An administrator opens the SIEM console and sees 426 alerts from the weekend. EDR reports unusual processes, Microsoft 365 flags suspicious sign-ins, and the firewall detects traffic anomalies. After an hour of reviewing the queue, more than 380 items remain. Does one of them mark the start of a real cyberattack? Nobody knows yet.

Modern tools can detect an increasing number of deviations. That does not mean an organisation can understand and handle each one. An alert is only a hypothesis requiring verification. Without an owner, priority, context and response path, even a correctly generated warning can remain another unopened entry in a console.

Useful insights

• More alerts do not automatically mean better security. More sources and rules improve visibility, but also increase the queue that needs attention.
• An alert is not an incident. Only analysis can establish whether the system detected legitimate activity, a false alarm or a real threat.
• Alert fatigue is a process problem, not an individual employee’s weakness. It arises when the volume and repetition of warnings exceed the team’s capacity for thorough triage.
• Technical priority alone is not enough. The same alert means something different on a test computer, a financial server or a domain administrator account.
• A 24/7 SOC turns a signal into a decision. It combines correlation, context, analysis, playbooks, escalation and response at any time of day.
• The goal is not to analyze every raw signal manually. A mature process deduplicates, groups and automatically enriches data so people can focus on cases that require judgment.

Introduction: 426 alerts and one unanswered question

A weekend backlog is not unique to one company. Every new source of telemetry—EDR, SIEM, firewalls, Microsoft 365, Active Directory, cloud services, applications and IDS/IPS—adds more signals. Some are valuable, some repetitive, and others result from routine administrative changes.

In a study of distributed SOC operations published in 2026, Microsoft cited estimates suggesting that 46% of alerts are false positives and 42% remain uninvestigated. These figures do not apply universally to every company, but they illustrate the tension between detection capabilities and analysis capacity. Risk therefore comes not only from what tools cannot see, but also from what they see and nobody has had time to assess. (Microsoft Security Blog)

The question „EDR alerts without analysis—what does that mean?” has a simple answer: the organization has the technical ability to spot anomalies, but does not yet know whether it can move from a signal to a controlled response.

Where do so many security alerts come from?

A security system does more than observe a single event. It compares activity against rules, behavioral models, threat indicators and policies. Several tools may therefore detect the same user action at once.

For example, opening a malicious attachment may trigger:

• an email alert about a suspicious message;
• an EDR alert about an office application launching a process;
• an identity system alert about an unusual sign-in;
• a firewall alert about a connection to a new domain;
• a SIEM rule correlating some of these events;
• another warning when the account starts downloading an unusual number of files.

Each signal can be useful, but without deduplication and correlation, an analyst sees several separate items instead of one case. Volumes also increase because of:

• overly broad or poorly tuned rules;
• outdated exceptions following infrastructure changes;
• repetitive administrative activities without the right context;
• duplicate detections from overlapping products;
• missing asset inventories and criticality ratings;
• automated scanners, service accounts and maintenance processes;
• configuration errors that repeatedly generate the same pattern.

The problem is not that SIEM or EDR is „working too well.” The tool is doing what it was configured to do. The operating model should determine which signals to combine, which to enrich automatically and which to send to a person.

Are all alerts equally important?

No. In practice, two different dimensions are often confused: verdict and severity. The verdict describes what analysis established about an event. Severity indicates how urgently it needs investigation based on the available evidence.

Classification	What it means	Typical action	Important caveat
False positive	legitimate activity incorrectly flagged as suspicious	close with a rationale, investigate the cause and tune if appropriate	do not suppress an entire rule after a single case
Benign positive	correctly detected activity that is authorized in the specific context	confirm with the owner and document the exception	exceptions should be narrow, controlled and reviewed periodically
True positive	confirmed malicious or unauthorized activity	escalation, containment and further incident response	the incident may extend beyond the initial alert
Low	a weak or low-risk signal	automated enrichment, grouping or queued analysis	several Low alerts together may indicate a significant incident
Medium	suspicious activity requiring context	triage within a defined timeframe and correlation	asset criticality can raise the priority
High / Critical	high confidence or potentially significant impact	immediate triage, escalation and a response decision	high severity still does not replace verification of business impact

What is alert fatigue, and why is it dangerous?

Alert fatigue occurs when the number, frequency and repetition of warnings exceed a team’s capacity to handle them thoroughly. It is not simply physical tiredness. It is a predictable consequence of a poorly designed work queue.

The pattern usually develops in stages:

1. Tools generate more alerts than the team can analyze.
2. The easiest items are closed quickly, while harder cases are deferred.
3. Repetitive false positives create an assumption that the next similar item will also be harmless.
4. The unresolved queue grows, and intuition increasingly replaces full analysis.
5. A critical signal may be treated as familiar noise or noticed only after business consequences emerge.

„Alert fatigue does not mean an analyst has stopped paying attention. It means the organization is producing more unresolved hypotheses than its process can turn into decisions. The answer is not to demand greater vigilance, but to reduce noise, improve context, clarify priorities and make escalation predictable.”

The most dangerous consequence is becoming accustomed to warnings. If a rule has reported legitimate events for weeks, the team may stop treating it as urgent. When an attacker uses a similar pattern, the signal will be technically visible but operationally invisible.

Why can’t an administrator analyze everything?

An IT administrator usually handles service availability, accounts, updates, deployments, backups, helpdesk requests and projects. Alert analysis is only one responsibility. During an outage or migration, it loses out to tasks whose effects users can see immediately.

Continuity is another challenge. One person cannot provide round-the-clock coverage, retain the full context of every change and conduct in-depth investigations simultaneously. A holiday, illness, project meeting or simply nighttime can leave a critical alert waiting.

IT administrator	SOC team
maintains environment availability and implements changes	focuses on threat detection, triage and analysis
supports users, helpdesk operations and projects	works through security event and incident queues
understands the organization’s architecture and operational dependencies	correlates telemetry from multiple sources and analyzes the attack path
usually works during business hours or provides limited on-call coverage	maintains continuous analysis around the clock in a 24/7 SOC model
can make changes to the client’s systems	classifies, escalates and initiates agreed playbooks
also responds to outages unrelated to security	measures triage, escalation and incident response times

This is not a comparison of a „better” and a „worse” role. Administrators and SOC teams solve different problems. An effective model combines the administrator’s knowledge of the environment with continuous analysis and the security team’s specialist expertise. The division of responsibilities is explored in more detail in A day in the life of a SOC analyst.

Case study: a critical alert hidden in the queue

The following is an illustrative editorial scenario. It does not describe a specific client or an actual VigilHorizon incident.

A manufacturing company used EDR, SIEM, email security and a firewall. Its environment generated several hundred alerts a day on average. Most involved repetitive administrative scripts, blocked sign-in attempts and tools used by IT. However, there was no formal tuning process informed by triage outcomes, and High alerts went to a shared mailbox.

At 10:17 p.m. on Friday, EDR detected an office application launching an encoded command. The alert was rated Medium because the process terminated quickly. A few minutes later, the identity system recorded a sign-in from an unusual location, and the firewall logged a connection to a new domain. Each event entered a different queue and, individually, did not look like a confirmed attack.

The administrator was busy with maintenance and returned to the alerts on Monday. By then, a mail forwarding rule had been created on the user’s account and the attacker had conducted asset reconnaissance. The tools had not been silent. The process failed: there was no cross-source correlation, queue owner, account-aware prioritization or after-hours coverage.

After the event, the organization did not buy another system. First, it:

• combined EDR, identity and email alerts into a single correlation scenario;
• identified critical accounts and assets;
• set risk-based triage times;
• prepared a playbook for suspected account compromise;
• defined permissions for revoking sessions and blocking accounts;
• introduced 24/7 SOC analysis of the queue;
• started using closed-case findings to tune rules.

The lesson is not to treat every Medium alert as a crisis. It is to assess an alert in the context of other signals and the asset’s importance before deciding it is harmless.

How does a SOC separate threats from noise?

A SOC does not depend on manually opening every raw event. A mature process reduces the number of cases through grouping, deduplication and correlation. Microsoft Defender describes an incident as a collection of related alerts that gives an analyst a unified view of the attack sequence. This distinction matters: a single low-confidence signal can become meaningful when combined with account, host and network activity. (Microsoft Learn)

Typical triage includes:

1. checking the user, host, timestamp and alert source;
2. assessing asset criticality and account privileges;
3. collecting related events from EDR/XDR, SIEM, identity, email and network systems;
4. comparing activity with normal behavior and known changes;
5. determining whether the alert is a false positive, benign positive or true positive;
6. assessing scope, impact and urgency;
7. closing with a rationale or escalating to an incident;
8. running the agreed playbook and verifying the outcome.

In VigilHorizon’s approach, analysis does not end with sending the client a screenshot. The goal is to provide the context needed for a decision: what was detected, which facts were confirmed, what is at risk, what has already been done and what the organization needs to do next. This operating model is explored further in Inside a modern 24/7 SOC

A reference model for alert handling

Effective alert handling is a closed loop. Incident response produces information that improves rules, priorities and playbooks.

Stage	What happens	Required outcome before moving on	Risk of omitting the stage
Event sources	EDR/XDR, SIEM, identity, email, network, cloud and applications provide telemetry	complete, current data with accurate timestamps	blind spots or an inaccurate incident picture
Normalization and deduplication	repetitive signals are organized and grouped	fewer technical duplicates	several queues describe the same activity
Correlation and enrichment	the alert gains context about the user, asset and related events	a single case with a clear sequence	the analyst assesses events in isolation
Prioritization	detection confidence is combined with business risk	a defined priority and triage timeframe	an important alert gets lost behind hundreds of less significant ones
SOC analysis	the analyst determines the verdict, scope and potential impact	a decision: close the case or declare an incident	the alert remains an unresolved hypothesis
Escalation and response	the playbook, containment and communications are initiated	controlled action and an incident owner	the threat develops despite successful detection
Lessons learned and tuning	the team improves rules, exceptions, sources and procedures	less noise and better detection of future events	the same problems return to the queue

Automation is particularly valuable for gathering context, checking reputation, grouping duplicates and performing safe, repeatable steps. However, not every decision should be automated. Isolating a critical server may contain an attack but also halt production or sales. The scope of automation must therefore follow tested playbooks and authorizations.

Find out how many alerts have no owner

The key question is not „How many alerts do our tools generate?” It is „What proportion receives a verdict within the required time, and what happens after an incident is confirmed?”

A basic review should cover the past 30 days of queues, arrival times, the age of unresolved cases, false-positive rates, prioritization rules and the availability of people authorized to respond. It should also trace several alerts from source to closure: did they have an owner, context, a decision, a documented outcome and an influence on tuning?

If High alerts wait until morning, tools create separate queues and the administrator has no backup, VigilHorizon SOC 24/7 can complement existing systems with continuous analysis, correlation, escalation and response using agreed playbooks. The starting point is not replacing every technology, but assessing the path from signal to action.

Deduplicate and group events

If several sources describe the same activity, they should form one case or incident. This reduces manual work and enables assessment of the full sequence.

Enrich alerts automatically

Queue items should include information about the user, host criticality, system owner, previous activity, domain reputation and administrative changes. Analysts should not need to search several consoles manually for basic context.

Prioritize by risk, not severity alone

An alert’s technical severity must be combined with the asset’s value and potential impact. A Low alert on a privileged account may need faster triage than a High alert on an isolated test device.

Base tuning on analysis outcomes

Every false positive should answer four questions: why did the rule trigger, will the event recur, what exception is safe, and could it weaken another detection scenario? Exceptions should be reviewed periodically.

Create playbooks for recurring situations

A playbook reduces the time needed to decide what to check, whom to notify and which actions are permitted. It should cover scenarios such as account compromise, malware, ransomware, suspicious PowerShell, unusual mail rules and threats to backups.

Automate safe steps

SOAR or platform capabilities can retrieve data, check indicators, create cases and carry out pre-approved actions. Automation still requires testing, error controls and clear limits on actions that affect the business.

Maintain a continuous improvement process

New applications, accounts, integrations and working practices change the profile of normal activity. Rules and exceptions must be updated after changes, incidents and tests. Why didn’t SIEM detect ransomware? explains why simply having data and alerts does not guarantee effective detection.

How can you tell if your organization has a problem?

One „no” does not mean the entire program is ineffective, but several negative answers indicate an operational gap.

Question	Answer
Does every High or Critical alert have an owner and a defined triage timeframe?	YES / NO
Are alerts analyzed at night, on weekends and on public holidays?	YES / NO
Do you know how many cases remain unresolved beyond the intended SLA?	YES / NO
Are alerts from EDR, SIEM, email, identity and network systems correlated?	YES / NO
Does prioritization consider system criticality and user privileges?	YES / NO
Does the team distinguish false positives, benign positives and true positives?	YES / NO
Does every closure include a verdict and a brief rationale?	YES / NO
Do recurring false positives lead to controlled tuning?	YES / NO
Are playbooks and escalation contacts up to date?	YES / NO
Is it clear who can block an account or isolate a device outside business hours?	YES / NO
Does full incident response begin when an incident is confirmed?	YES / NO
Does management receive information on time, impact and trends, rather than just alert counts?	YES / NO

Particularly concerning signs include administrators disabling notifications, ownerless queues, alerts closed in bulk without verdicts, or nobody being able to identify the oldest unresolved case.

How do you measure the effectiveness of alert analysis?

Counting handled alerts alone can reward quickly closing easy cases. Metrics should reflect time, quality and outcomes.

• Time to acknowledge an alert —the time from generation to assignment to an owner.
• Triage time —the time from acknowledgment to an initial verdict and escalation decision.
• MTTD —time to detect or recognize an incident; the definition must be used consistently throughout the organization.
• MTTR —time to respond, contain impact or restore operations; the acronym has several meanings, so reports should specify the exact endpoint.
• Percentage of alerts with a verdict —the proportion of the queue that ends in a documented decision.
• Backlog size and age —how many cases remain open and for how long.
• False positive rate —the proportion of analyzed alerts that do not indicate a threat, and the rules producing the most noise.
• Reopening and misclassification rates —whether quality suffers under pressure to work faster.
• Time to containment —the time from incident confirmation to effective threat containment.
• Source and use-case coverage —whether critical systems provide the data needed to detect the most important scenarios.

VigilHorizon considers the entire path from first signal to decision, not just the time to generate a notification. Fast detection offers little help if an alert waits hours for analysis. Likewise, rapid closure is not a success if it lacks context and a rationale.

Summary

Organizations do not need the maximum possible number of alerts. They need visibility they can act on: complete data, correlation, risk-based priority, an owner, analysis and an agreed response.

SIEM, EDR and XDR are essential sources of signals, but do not replace an operating model. An alert without a verdict remains a hypothesis. A confirmed alert without permissions and a playbook remains information. Analysis coupled with a decision and action is what reduces business risk.

VigilHorizon treats monitoring as an end-to-end process: from defining priorities and data sources through 24/7 SOC analysis to escalation, incident response, reporting and continuous tuning. If you do not know how many alerts lack an owner, which sources produce the most noise or how long containment takes, start by reviewing the current model. Talk to VigilHorizon about assessing your alert handling process and SOC 24/7 tailored to your organization’s risk.

Frequently asked questions (FAQ)

What is a security alert?​

A security alert indicates that a system detected activity matching a rule, an anomaly model or a known threat pattern. It is the starting point for analysis, not automatic confirmation of a cyberattack.

How does an alert differ from a security incident?​

An alert describes a suspicious signal. An incident is a confirmed or sufficiently credible event requiring management, escalation or response. Several alerts may form one incident, while some alerts are closed as legitimate activity after analysis.

What is alert fatigue?​

Alert fatigue is a decline in analysis effectiveness caused by excessive, repetitive and low-quality warnings. The team works under backlog pressure, postpones harder cases and may miss an important signal among familiar noise.

Does every alert require manual analysis?​

Not every raw signal should reach a person as a separate case. Deduplication, correlation, enrichment and safe automation can discard duplicates or combine them into incidents. However, every alert covered by the process should have a defined handling method and outcome.

Does SIEM analyze alerts on its own?​

SIEM collects and correlates data and can automate parts of classification. However, it does not know the full business context, establish accountability or make every response decision. Configuration, tuning and analysis still need a process owner.

Why does EDR generate so many alerts?​

EDR observes many behaviors on workstations and servers, and some legitimate administrative tools resemble attacker techniques. Alert volumes depend on policies, device coverage, exceptions, configuration and the organization’s activity profile. Persistent noise usually calls for controlled tuning.

What is the difference between a false positive and a benign positive?​

A false positive means a detection incorrectly identified a threat. A benign positive is activity correctly detected by a rule but permitted in the specific context, such as an approved administrator script. This distinction helps improve detection tuning.

How does a SOC reduce false alarms?​

A SOC reviews triage outcomes, identifies recurring causes, enriches alerts with context and tunes rules or exceptions. The aim is not to suppress warnings mechanically, but to reduce noise without losing the ability to detect a similar attack.

Can automation replace SOC analysts?​

Automation handles repetitive steps well: gathering context, grouping events, checking indicators and running approved actions. It does not replace a full assessment of ambiguous situations, business impact or decisions that might stop a critical service.

How quickly should a High or Critical alert be analyzed?​

No single timeframe suits every organization. It should reflect risk, system criticality, available response mechanisms and the agreed SLA. What matters is defining and measuring it outside business hours too, and connecting it to real escalation.

Who should be responsible for alert analysis?​

An internal SOC, security team, MDR provider or external 24/7 SOC can take responsibility. Accountability must be clear, staff must be available when required, and analysts need data, context and agreed escalation permissions.

How can you check whether security monitoring really works?​

Generate a controlled signal and trace the full path: data capture, correlation, priority, acknowledgment time, verdict, escalation, playbook execution and documentation. An alert appearing in a console confirms detection, but not readiness to handle an incident.

Does a 24/7 SOC mean a person analyzes every event?​

No. A 24/7 SOC uses rules, automation, grouping and prioritization so analysts can focus on cases requiring judgment. The key is continuous ability to recognize and handle threats, not manually reading every log.

Learn more

• Inside a modern 24/7 SOC
• A day in the life of a SOC analyst: inside 24/7 security monitoring
• Why didn’t SIEM detect ransomware?
• The alert appeared at 2:13 a.m. The administrator saw it at 8:04 a.m.
• EDR, XDR and MDR—how they differ and when they actually protect a business
• The first 60 minutes of a cyberattack
• The VigilHorizon SOC 24/7 plan