Loading...
New
See what manual alert triage really costs your security team.
New
See what manual alert triage really costs your security team.
See what manual alert triage really costs your security team.
See what manual alert triage really costs your security team.
Loading...
MTTA usually means mean time to acknowledge, the average time between an alert firing and a responder taking ownership of it. You sum each interval and divide by the alerts acknowledged. Google's SRE book cites 5-minute paging targets for time-critical services. MTTA can also stand for mean time to adapt, or how fast defenses change after a threat does.
Take one hypothetical overnight shift with four alerts. That shift can come out at 13 minutes, 9.75 minutes, 6.3 minutes, or 10 seconds depending on which counting rule gets applied, and the work behind all four numbers is the same.
The documentation for PagerDuty, Atlassian, Rootly, Google SecOps, and Microsoft Sentinel shows how that happens: no two time first pickup the same way. A second metric now shares the acronym, and it counts days to months: mean time to adapt.
MTTA, or mean time to acknowledge, is the average time between an alert or incident being raised and a responder accepting ownership of it. It started in on-call work, where acknowledging a page stops it escalating to the next person in the rotation.
Google's Site Reliability Engineering book (O'Reilly, 2016) gives typical paging response targets of "5 minutes for user-facing or otherwise highly time-critical services, and 30 minutes for less time-sensitive systems." Security operations inherited the metric along with the paging tools, and it now sits on SOC dashboards and in managed-detection contracts.
In a SOC, the attacker's clock usually starts earlier than the alert does. CrowdStrike's 2026 Global Threat Report puts average eCrime breakout at 29 minutes from initial access to lateral movement, and your alert may not fire until well after initial access.
To calculate mean time to acknowledge, subtract each alert's creation time from its acknowledgment time, add up those intervals, and divide by the number of alerts acknowledged. Report the median next to the average, because one slow alert can drag it a long way.
MTTA = Σ (acknowledged time − alert time) ÷ number of alerts acknowledged
Back to that overnight shift. Three alerts get acknowledged after 2, 6, and 31 minutes, and the fourth, at 03:40, never gets picked up. That puts MTTA at (2 + 6 + 31) ÷ 3 = 13 minutes, with a median of 6.
A broken version of this formula is still going around. Atlassian's incident metrics guide lists "MTTA = Time of acknowledgment ÷ Number of incidents" in its summary, then gives the interval version further down the same page: "add up the time between alert and acknowledgement, then divide by the number of incidents." A clock reading divided by a count doesn't mean anything. Average the intervals.
MTTA hides three choices that change the number for identical work: where the clock starts, who's allowed to acknowledge, and whether alerts nobody acknowledged count at all. PagerDuty, Atlassian, Rootly, Google SecOps, and Microsoft Sentinel each document those choices differently.
| Tool | Clock starts | Clock stops | What the docs add |
|---|---|---|---|
| PagerDuty (Team MTTA) | Incident created | First responder acknowledges | "Excludes incidents that were not acknowledged" |
| Atlassian (guide) | Alert triggered | "when work begins on the issue" | Divides by "the number of incidents" |
| Rootly (incident level) | started_at | acknowledged_at | Timestamp "set by hand or by a workflow"; separate alert-level MTTA for on-call |
| Google SecOps (SOAR) | The detection that creates an alert | "acknowledged by an analyst for triage" | Suggests playbooks "for auto-assignment or enrichment" to cut the delay |
| Microsoft Sentinel (mean time to triage, not MTTA) | CreatedTime | FirstModifiedTime | Sample query only; doesn't say whether automation sets the field |
Say the shift's 31-minute alert fired in the SIEM at 02:00 and the ticket for it opened at 02:20. A clock that starts at ticket creation would record 11 minutes for that alert, and the MTTA for the whole shift would drop to 6.3. Rootly's guide warns about a version of this problem, where MTTA measured from page delivery "hides the time between the alert firing and the page going out." Pin the start to the earliest machine timestamp you have before you compare quarters.
PagerDuty is strict, and says "reassign, resolve, and escalation actions do not imply acknowledgement." Rootly and Sentinel leave more room. Run a test incident through your automation and see what your metric records.
A workflow that gets first touch at 10 seconds can put 10 seconds on the dashboard. The SANS 2026 SOC Report found 79% of SOCs use AI or ML tools and 36% have built them into a defined workflow, and a dashboard may not show which acknowledgments came from software.
PagerDuty's team metric "Excludes incidents that were not acknowledged." That default comes from on-call tooling, which keeps paging until someone answers. In a SOC, it drops the riskiest queue from the figure. The overnight shift's fourth alert never enters the average, and the number holds at a tidy 13 minutes.
Some formulas fail worse. Read literally, dividing by "the number of incidents" turns the shift's 39 minutes into 9.75, because the unacknowledged alert joins the divisor. Neither Atlassian nor Rootly tells you to do that, but a spreadsheet built from those words would reward ignoring an alert.
| Rule applied | Calculation | MTTA |
|---|---|---|
| Clock starts at the alert; acknowledged alerts only | (2 + 6 + 31) ÷ 3 | 13 minutes |
| Same intervals, divided by all four alerts | 39 ÷ 4 | 9.75 minutes |
| Clock starts at ticket creation for the 31-minute alert | (2 + 6 + 11) ÷ 3 | 6.3 minutes |
| An automation rule touches every alert first | 10 seconds each | 10 seconds |
If you're signing a managed-detection contract with an MTTA SLA, get three answers in writing: which timestamp starts the clock, whether automation counts as acknowledging, and whether unacknowledged alerts are excluded. A provider that can't answer all three hasn't defined its metric.
MTTA stops when a responder owns the alert, and MTTR (mean time to respond or resolve) ends when the incident is contained or closed, which makes MTTA an early segment of MTTR. The usual SOC metrics around them are MTTD (mean time to detect), MTTI (mean time to investigate), and MTTC (mean time to contain).
When an AI Agent picks up every alert the moment it fires, the acknowledge interval shrinks to a rounding error. Simbian's AI SOC Agent investigates and responds to every threat within minutes, on average under 4 minutes from detection to response, and acknowledgment barely registers inside that window.
At that point a falling MTTA mostly records which tool picks the alert up. That cuts against our own headline too: Simbian's under-4-minute figure is a speed, and on its own it won't show you whether your defenses changed afterward.
MTTA has a second meaning because some security leaders now use it for mean time to adapt. That metric runs in days to months, from the first dated notice of a threat change to a defensive change proven in production. JPMorganChase's global CISO, Pat Opet, put it in the title of an RSAC Conference 2026 fireside, and competing definitions have followed.
The two clocks meet in your acknowledge queue, where an alert acknowledged and closed for the fortieth time is a threat change nobody turned into a defensive change. Count recurring alerts as notice events, starting from the first in the series. Simbian uses the same recurrence as its signal to write a proposed improvement and submit it for your team's approval.
Take the Check Point VPN flaw CISA listed on June 8, 2026. The due date was three days later. A SOC could acknowledge its first related alert in 90 seconds and still be weeks from a tested detection. For start and stop events, the four sub-clocks, and that timeline in full, see how to measure mean time to adapt.
Mean time to acknowledge measures how fast someone picks up an alert, in seconds to minutes, while mean time to adapt measures how fast your defenses change after a threat does, in days to months.
| Dimension | MTTA: acknowledge | MTTA: adapt |
|---|---|---|
| Question it answers | Did someone pick up the alert? | Did your defense change after the threat did? |
| Unit | Seconds to minutes | Days to months |
| Clock starts | Alert or incident raised | First dated notice of a threat change (advisory, KEV entry, intel report, pentest finding, recurring alert) |
| Clock stops | A responder accepts ownership | A defensive change runs in production with proof |
| Closest public reference | Google SRE paging targets, 5 to 30 minutes | For patching, CISA KEV due dates, a median of 3 days in Q3 2026 by Simbian's count |
| Typical owner | SOC shift lead | CISO |
| What AI does to it | Drives it toward zero | Shortens the mechanical sub-clocks; the risk decision stays human |
Spell out the name on every slide. A board member who reads "MTTA: 90 seconds" will assume it covers the right-hand column, and nothing on the slide will correct them.
Mean time to adapt belongs on the board report, as a median and 90th percentile for each type of defensive change, with a trend across quarters, because it shows whether the program itself got faster. Leave mean time to acknowledge on the SOC dashboard, where a shift lead can act on a slow pickup.
Boards don't need more volume. The SANS 2026 SOC Report found incident count has been the top reported SOC metric for ten consecutive years, cited by 70% of respondents. Read beside rollbacks and failed changes, an adapt trend tells them more.
Keep acknowledge time where incidents page a person, like an outage or a ransomware note on a file server.
Q: What does MTTA stand for in cybersecurity? In most SOCs and incident-management tools, MTTA stands for mean time to acknowledge, the average time from an alert to a responder taking ownership of it. Some security leaders now also use MTTA for mean time to adapt, the time from a threat change to a proven change in your defenses. Spell out which one a report means.
Q: What is a good mean time to acknowledge? No widely adopted benchmark exists for mean time to acknowledge in security operations. Google's SRE book cites five minutes as a typical paging target for time-critical services and 30 minutes for less time-sensitive ones. Treat it as a health check on paging: Rootly warns that making it a personal target "mostly teaches people to acknowledge fast and start work later."
Q: What is the difference between MTTA and MTTR? MTTA ends when someone accepts an alert, while MTTR, mean time to respond or resolve, ends when the incident is contained or closed, so it includes investigation and response. Automation can cut MTTA to seconds. MTTR falls only if the work after the pickup gets faster too.
Q: Does automation make MTTA meaningless? Automation makes MTTA meaningless as a headline metric. When software picks up every alert the instant it fires, the interval falls to seconds whatever investigation follows. Keep it as a service-level check for incidents that page a person, and sample acknowledged alerts each week to confirm a real investigation followed.
Q: How do you reduce mean time to acknowledge? Route every alert to a queue with a named owner, cut duplicate and noisy alerts so responders trust the pager, and let software take first touch on routine alerts. Sample the results each week to confirm that a fast acknowledgment led to real investigation.
Q: Will mean time to adapt replace MTTA? No, mean time to adapt won't replace MTTA. Mean time to acknowledge tracks seconds to minutes for the SOC shift lead, and mean time to adapt tracks days to months for the CISO and the board. A report with both needs the full names, because the acronym hides two very different clocks.
Find the MTTA tile on your SOC dashboard and run last night's shift through the four rules above. If you get more than one number, fix the definition before the next report goes out. To see a defense that investigates every alert in minutes and proposes its own improvements for your team to approve, book a demo.
