Depends on industry and organization size. Generally: - < 24 hours — good level for most companies - < 4 hours — very good, requires mature SOC - < 1 hour — elite, requires automation and ML

SOC metrics — MTTD, MTTR and security KPIs explained [2026]

SOC metrics exist to answer one question a board actually asks: are we getting better or only busier? That makes the definitions matter more than the numbers — two organisations reporting the same mean time to detect can be measuring from entirely different moments. What follows is the set of metrics worth reporting and how to define them so the comparison holds.

What Are SOC Metrics?

SOC (Security Operations Center) metrics are measurable indicators of security operations effectiveness, such as MTTD (Mean Time to Detect), MTTR (Mean Time to Respond), alert volume, and false positive rate, used to evaluate the efficiency of threat detection and response capabilities.

Metric	Definition	Benchmark (as of 2026)
MTTD	Mean time to detect a threat	< 24 hours
MTTR	Mean time to respond/remediate	< 4 hours
MTTC	Mean time to contain an incident	< 72 hours
False Positive Rate	% of false alarms	< 30%
Dwell Time	Time attacker remains undetected	< 21 days

Measuring SOC effectiveness isn’t a “nice to have” — it’s the foundation of a mature security program. Without metrics, you can’t know whether your SOC is actually protecting the organization or just generating reports.

Why Measuring SOC Performance Matters

Budget justification — concrete numbers for CFO and executives
Identify weak points — where you’re losing time, what needs improvement
Industry comparison — are you better or worse than competitors
Compliance — NIS2 requires “assessment of security measure effectiveness”
Team motivation — visible progress motivates analysts

Operational vs Business Metrics

Operational Metrics	Business Metrics
MTTD, MTTR, MTTC	Cost per incident
Alert volume	ROI on SOC investment
False positive rate	Downtime
Coverage %	Avoided financial losses

Executives don’t want to know that MTTR dropped by 15 minutes. They want to know how much money that saved.

📚 Read the complete guide: SOC: Security Operations Center - what it is, how it works, how to choose

MTTD - Mean Time to Detect

MTTD (Mean Time to Detect) is the average time from when a threat occurs to when the SOC team detects it. This is one of the most critical metrics — the faster you detect an attack, the smaller the damage.

This article defines MTTD and shows how to calculate and report it. What to do so that the number actually falls — breaking detection time into four segments and applying the right lever to each — is the subject of a separate article on how to reduce mean time to detect (MTTD).

MTTD Calculation Formula

MTTD = Σ (Detection Time - Occurrence Time) / Number of Incidents

Example:

Incident 1: detected after 2 hours
Incident 2: detected after 8 hours
Incident 3: detected after 4 hours

MTTD = (2 + 8 + 4) / 3 = 4.67 hours

MTTD Benchmarks

Maturity Level	MTTD	Characteristics
Initial	> 72h	No SIEM, reactive detection
Developing	24-72h	SIEM without tuning, few analysts
Mature	4-24h	SIEM with correlation, 24/7 SOC
Advanced	1-4h	ML/AI, threat hunting, automation
Elite	< 1h	Real-time detection, SOAR

Factors Affecting MTTD

Factors that reduce MTTD:

Comprehensive monitoring (endpoint, network, cloud, identity)
Well-configured SIEM with event correlation
Machine learning and anomaly detection
Threat intelligence (IoC feeds)
Sufficient 24/7 analyst coverage
Regular threat hunting

Factors that increase MTTD:

Coverage gaps (unmonitored systems)
Alert fatigue — analysts ignore alerts
Poorly configured detection rules
Lack of business context
Manual analysis without automation

How to Improve MTTD

Increase coverage — monitor 100% of critical systems
Tune SIEM rules — less noise, more signal
Deploy EDR/XDR — endpoint visibility
Integrate threat intelligence — detect known IoCs immediately
Automate triage — use SOAR for initial analysis
Threat hunting — don’t wait for alerts, search proactively

MTTR - Mean Time to Respond

MTTR (Mean Time to Respond) is the average time from threat detection to taking the first containment action. Some organizations define MTTR as time to full resolution — that’s why establishing a clear definition matters.

Different Definitions of “R” in MTTR

Acronym	Meaning	Measures
MTTR (Respond)	Time to first response	SOC speed
MTTR (Remediate)	Time to fix	Remediation effectiveness
MTTR (Recover)	Time to full restoration	Resilience
MTTC (Contain)	Time to isolate threat	Containment

In this article, we use MTTR as Mean Time to Respond — time from detection to first action.

MTTR Calculation Formula

MTTR = Σ (First Action Time - Detection Time) / Number of Incidents

MTTR Benchmarks

Incident Priority	Target MTTR	Example
Critical (P1)	< 15 minutes	Active ransomware, data breach
High (P2)	< 1 hour	Admin account compromise
Medium (P3)	< 4 hours	Workstation malware
Low (P4)	< 24 hours	Policy violation, shadow IT

Automation as the Key to Low MTTR

Humans can’t beat machines in response speed. That’s why the best SOCs use SOAR (Security Orchestration, Automation and Response) for automation:

Automation examples:

Automatic isolation of infected endpoints
Blocking suspicious IPs on firewall
Password reset on suspected compromise
Alert enrichment with context (CMDB, threat intel)
Automatic ticket creation and notification

Organizations with SOAR achieve MTTR significantly lower than those without automation.

Other Key SOC Metrics

MTTC - Mean Time to Contain

Time from detection to isolating the threat and stopping attack spread.

Example target: < 1 hour for critical incidents

Why it matters: Ransomware can encrypt an entire network in a very short time. Every second counts.

False Positive Rate

Percentage of alerts that turned out to be false alarms.

FP Rate = Number of False Positives / Total Alerts × 100%

FP Rate	Rating	Implication
< 20%	Excellent	Analysts trust alerts
20-40%	Good	Acceptable noise level
40-60%	Average	Alert fatigue emerging
> 60%	Poor	Analysts ignore alerts

Note: Too low FP rate may indicate overly conservative rules that miss real threats (false negatives).

Alert Volume and Alert Fatigue Index

Alert Volume — daily alerts per analyst.

Alerts/analyst/day	Rating
< 50	Comfortable level
50-100	High but manageable
100-200	Alert fatigue
> 200	Impossible to handle

Alert Fatigue Index = Alert Volume × FP Rate

The higher it is, the greater the risk that analysts miss real threats.

Coverage - Monitoring Coverage

Percentage of infrastructure covered by SOC monitoring.

Coverage = Monitored Assets / Total Assets × 100%

Target: 100% of critical assets, > 80% of all assets

Typical coverage gaps:

Cloud (shadow IT, new accounts)
OT/ICS (industrial systems)
Mobile devices
SaaS applications
Dev/test environments

Dwell Time

Time an attacker remains undetected in the network.

Benchmarks 2025/2026:

Global average: markedly shorter than a few years ago
Best performers: < 7 days
Ransomware: often very short (fast attack)
APT: months or years

Business Metrics for Executives

Executives don’t operate in MTTD and MTTR language. They need business metrics.

Cost per Incident

Cost per Incident = Total Incident Costs / Number of Incidents

Cost components:

IR team work time
System downtime
Lost revenue
Regulatory fines
Forensics and legal costs
Customer compensation
Reputation damage (hard to measure)

ROI on SOC Investment

ROI = (Avoided Losses - SOC Cost) / SOC Cost × 100%

Example:

SOC cost: about €470,000/year (lower bound of the nFlo estimate for an in-house 24/7 SOC, Polish market; converted from PLN at the nFlo reference rate of 4.25 PLN/EUR)
Assumed cost of one incident without a SOC: €470,000 (illustrative value)
Incidents stopped/mitigated: 5
Avoided losses: 5 × €470,000 = €2.35 million
ROI = (€2.35 million - €470,000) / €470,000 = 400%

Risk Score Trend

Aggregated organizational risk indicator over time. Should decrease as the security program matures.

Components:

Number of critical vulnerabilities
MTTD/MTTR trend
Number of incidents
Coverage %
Compliance score

How to Report SOC Metrics to Executives

Reporting Principles

Less is more — 5-7 key metrics, not 50
Trends, not snapshots — show change over time
Business context — “MTTR dropped” → “We stop attacks faster, fewer losses”
Benchmarks — compare with industry
Actions — what we’re doing to improve

Monthly Executive Report Template

Executive Summary (1 page):

SECURITY - MONTHLY REPORT [Month 2026]

OVERALL STATUS: 🟢 Good (improvement vs previous month)

KEY METRICS:
┌─────────────────┬──────────┬──────────┬─────────┐
│ Metric          │ Target   │ Current  │ Trend   │
├─────────────────┼──────────┼──────────┼─────────┤
│ MTTD            │ < 24h    │ 18h      │ ↓ 15%   │
│ MTTR            │ < 4h     │ 2.5h     │ ↓ 20%   │
│ P1/P2 Incidents │ < 5      │ 3        │ ↓ 40%   │
│ Coverage        │ > 95%    │ 97%      │ ↑ 2%    │
│ FP Rate         │ < 30%    │ 28%      │ ↓ 5%    │
└─────────────────┴──────────┴──────────┴─────────┘

HIGHLIGHTS:
• Stopped 2 ransomware attempts (estimated avoided losses: ~€700K)
• Deployed AWS cloud monitoring - coverage increased by 5%
• 0 data breaches (streak: 18 months)

RISKS AND PLANS:
• OT environment still without full monitoring (plan: Q2)
• Need 2 additional SOC FTEs (budget request)

SOC Metrics and NIS2 Requirements

The NIS2 Directive requires essential and important entities to conduct “assessment of the effectiveness of cybersecurity risk management measures” (Art. 21).

Which Metrics to Document for NIS2?

NIS2 Requirement	Metrics to Report
Incident management	MTTD, MTTR, incident count
Business continuity	RTO, RPO, downtime
Supply chain security	Supplier-related incidents
Effectiveness assessment	Risk score trend, coverage
Incident reporting	Time to report to CSIRT (requirement: 24h)

NIS2 Audit - What to Prepare?

Historical metrics data (min. 12 months)
Evidence of improvement process (action plans)
Comparison with industry benchmarks
Incident documentation and lessons learned

FAQ

What is a good MTTD?

Depends on industry and organization size. Generally:

< 24 hours — good level for most companies
< 4 hours — very good, requires mature SOC
< 1 hour — elite, requires automation and ML

How do I calculate MTTR when I don’t have exact timestamps?

Use data from ticketing systems (ServiceNow, Jira) — ticket creation time vs first action time. If you don’t have a ticketing system, start using one — without data, there are no metrics.

Is low false positive rate always good?

Not always. FP rate = 0% may indicate overly conservative detection rules that miss real threats (false negatives). In practice, the optimal balance is an FP rate of 15-30%.

How often should I report metrics?

Operationally: Daily standup with key metrics
Tactically: Weekly report for security manager
Strategically: Monthly report for CISO/executives
Governance: Quarterly review for board/audit committee

Which metrics are most important?

If you can only track 5 metrics, choose:

MTTD — how fast you detect
MTTR — how fast you respond
P1/P2 Incidents — number of serious events
Coverage — how much you see
Risk trend — is it getting better or worse

Summary

MTTD and MTTR are the two most important operational SOC metrics — measure them consistently
MTTD benchmark: < 24 hours, best performers < 4 hours
Example MTTR target: < 4 hours for critical incidents
Automation (SOAR) drastically reduces MTTR
False positive rate above 40% leads in practice to alert fatigue
Executives need business metrics — ROI, incident cost, avoided losses
NIS2 requires documenting security measure effectiveness
Measure trends, not snapshots — what matters is whether you’re improving

Need a SOC that delivers transparent metrics and reporting? Check out our SOC as a Service or contact us.

A metric without a defined start time is not comparable

Mean time to detect is the metric most often quoted and least often defined. Does the clock start when the attacker first touched the estate, when the first related log entry was written, or when an alert reached a human? Each definition produces a number several orders of magnitude apart, and all three are reported as MTTD. The same applies to response: acknowledged, contained and resolved are three different events.

Whichever definition you choose, write it down next to the number — and require the same of a provider. That is part of how service levels are agreed in managed detection and response.

Learn key terms related to this article in our cybersecurity glossary:

Security Operations Center (SOC) — Security Operations Center (SOC) is a central location where a team of security…
SOC as a Service — SOC as a Service (Security Operations Center as a Service), also known as…
Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
Incident Response — Incident Response (IR) is an organized process of detecting, analyzing, and…
Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…

Learn More

Explore related articles in our knowledge base:

Explore Our Services

Need cybersecurity support? Check out:

Security Audits - comprehensive security assessment
Penetration Testing - identify vulnerabilities in your infrastructure
SOC as a Service - 24/7 security monitoring