Updated on November 5, 2026
Consider a hypothetical scenario in which a legitimate administrative credential starts accessing network folders it has never touched. The detection tool does exactly what it was bought to do: it flags the anomalous behavior, classifies the event as critical, sends an email and turns a dashboard red. What nobody defined in advance is who decides, how quickly and with what authority, and while that question circulates among three people, a manageable technical problem grows into a problem of revenue, contracts and reputation.
The scene is uncomfortable because any organization that has already invested in advanced antivirus, EDR (Endpoint Detection and Response), MFA (Multi-Factor Authentication) and centralized cloud logging can recognize itself in it. For these companies, detection stopped being the bottleneck, and the critical point became the interval between the alert firing and a person with authority deciding how to contain the damage. That interval needs an owner, a number and a target, and this article proposes a roadmap to build all three.
A company's response capacity needs to be measured with the same precision it applies to detection. That distance between the attacker's pace and the pace of the decision is the risk leadership should be looking at, long before debating which software brand is installed.
Detection is just one of six security functions
The NIST Cybersecurity Framework 2.0, published in 2024, organizes security into six functions: Govern, Identify, Protect, Detect, Respond and Recover. Each has its own processes, owners and metrics, and Detect sits alongside Respond and Recover as distinct stages of one cycle. Protect and Detect are the functions that can be bought with a purchase order, whereas Respond and Recover require available people, delegated authority and rehearsal, three items no vendor ships in a box.
Cisco's 2025 Cybersecurity Readiness Index indicates that only 4% of the organizations assessed reach the maturity level considered adequate for today's threat landscape. The figure separates owning technology from having the operational capacity to act on what it produces.
The cause-and-effect mechanism is well known: every new tool added to the environment multiplies the volume of signals generated, while human triage capacity stays the same, and the result is alert fatigue, a phenomenon in which professionals exposed to a large volume of notifications, most of them irrelevant, develop the organizational habit of ignoring them. When the real signal arrives, it looks just like the false positives of recent weeks.
Time also compounds the cost: IBM's Cost of a Data Breach Report 2025 measured the average cycle to identify and contain a data breach at 241 days, and the 2024 edition of the same study found the highest average cost, USD 5.46 million, in breaches with a lifecycle exceeding 200 days. Response latency thus becomes a management variable with a direct effect on the company's financial results.
The contractual and regulatory dimension reinforces the point. The GDPR in Europe sets 72 hours, where feasible, for notifying the supervisory authority of a personal data breach that poses a risk to individuals, and Brazil's LGPD requires incidents that may cause relevant risk or harm to be reported to the national authority and to the data subjects, within a deadline set by that authority. Contracts with service level clauses turn hours of downtime into measurable penalties, and response latency later shows up on the income statement.
How to treat incident response as a business process
1. Give the process an owner, a deadline and a cost
The first move is to treat response as a business process, on the same level as the accounting close or a logistics delivery. That means naming a responsible person, defining an internal SLA (Service Level Agreement) for containing critical events and reviewing that indicator in the same meeting where sales and margin are reviewed. A containment time that leadership never discusses tends to be managed by no one.
2. Write the decision tree before the crisis
Define which actions are pre-authorized without consultation: isolating a device, blocking an account, terminating active sessions, cutting a network link. Without written delegation, the responsible professional tends to do the one thing that protects them, which is to escalate and wait, and waiting is the most expensive decision in the playbook. An unnecessary isolation costs one user or one server some productivity for a while, whereas waiting for approval can cost the entire operation.
3. Rehearse without notice
A tabletop exercise in which everyone knows the script proves little about real response time. The same exercise run without advance notice, with the primary manager unavailable, reveals the true number and tends to expose cheap fixes such as outdated phone numbers and emergency credentials nobody knows how to find.
4. Decide on economic grounds what stays in-house and what needs backup
The in-house team is irreplaceable in everything that depends on business context: knowing which system sustains revenue, which customer cannot tolerate downtime, which decision requires the president on the line. Continuous automated monitoring of systems and first-level triage are functions of scale, and scale is what a specialized backstop in monitoring (NOC) and incident response (SOC) adds to the team, without taking away its authority over the business. When the volume of events exceeds the team's triage capacity, it is worth evaluating a managed security operation as an extension of the internal team.
The pre-authorized actions matrix: the minimum model
The matrix is a short, one-page table that the IT team and leadership sign together. Each row describes a containment action and answers five questions, which you can copy into your incident response document:
- What the action is (isolate a device, block an account, terminate sessions, cut a network link) and which type of event it applies to.
- Who can execute it without consulting anyone, with name and phone number.
- Who replaces that person when they do not answer, and what the alternative contact channel is.
- Which decisions require executive approval, so that nobody hesitates over doubts about scope.
- How the action is recorded, with the time of the alert, the time of the reading and the time of containment.
Keep the matrix outside systems that may become unavailable, in a printed copy or in a repository independent of the main environment, because a plan stored only in the compromised environment is out of reach exactly when it is needed, and review it every quarter so it keeps up with team changes.
What leadership should track every month
Five indicators are enough to turn response latency into a management topic, and all of them come from recording three timestamps per critical event:
- Average time between the alert and the first reading by a professional.
- Average time between the reading and the containment action.
- Percentage of critical events handled by an action that was already pre-authorized.
- Number of gaps found in the last rehearsal and how many have been fixed.
- Estimated cost of each hour of downtime in your business.
Each indicator needs an owner and a target set by the company itself, because the right value depends on the sector, the contracts and the risk tolerance of each organization.
Five questions to bring to your IT team
The answers you cannot give show where to start, and three of the questions receive a comment below.
- What is the average time between a critical alert and the first containment action in your company, and can anyone prove that number with data?
- Who, by name and phone number, has the authority to isolate a server or block a user without waiting for approval?
- How much does each additional hour of response latency cost in your sector, in stalled revenue, idle payroll and contractual penalties?
- Why does adding detection tools tend to worsen the problem when triage capacity does not grow along with them?
- What can your company do on its own, what needs specialized backup and how do you decide that on economic grounds?
1. What is the time between the critical alert and the first containment action?
The answer most managers give tends to be an optimistic estimate built on the best case ever observed. The number that matters comes from the record of the last twelve months, with three timestamps per critical event: when the alert was generated, when a human being read it and when the containment action actually took place. Two indicators are enough to start, MTTD (Mean Time To Detect) and MTTR (Mean Time To Respond), segmented by severity and by system.
If the data simply does not exist, the honest answer is that the time is unknown, and in risk management unknown and unlimited mean the same thing.
3. How much does each additional hour of latency cost?
The calculation is simpler than it looks and changes the conversation with finance. Add up the gross revenue generated per operating hour, the hourly cost of the payroll that cannot produce, the contractual penalties provided for unavailability and the estimated cost of recovery and communication with customers. With that number in hand, the investment in response capacity becomes comparable to the cost of the outage, and the decision leaves the field of opinion. An objective estimate of the hourly cost of downtime is the first artifact that should exist before any new tool purchase.
4. Why can more detection tools worsen the problem?
Detection and response scale in different ways: tools scale with licenses, in a practically linear fashion, while triage scales with trained people, more slowly and at a higher cost. By adding a new source of alerts without expanding analysis capacity, the company lowers the percentage of alerts actually investigated. Before approving the next purchase, ask what percentage of critical alerts in the last ninety days was analyzed by a professional within the limit your business considers acceptable.
Frequently asked questions
What is the practical difference between detection and incident response?
Detection is the ability to identify anomalous behavior and generate an alert, a function usually performed by automated tools. Response is the decision that contains the damage, such as isolating a device or blocking a compromised account. NIST Cybersecurity Framework 2.0 treats Detect and Respond as separate functions, with their own owners and metrics, because investing in one does not produce the other.
How do you measure incident response time?
Record three timestamps for every critical event: the alert generation, the first reading by a professional and the effective containment action. Segment the data by severity, system and team, and track MTTD and MTTR every month. A large gap between events of similar severity indicates a lack of process standardization.
When does it make sense to add specialized backup to the internal team?
When alert volume exceeds the team's triage capacity, when the response process has not yet been rehearsed or when the cost of expanding internal capacity exceeds the cost of the backup plus the gain in containment time. The backup adds to the IT team and leaves with it the decisions that depend on business context.
If the interval between the alert and the decision still has no proven number in your company, a no-obligation Strategic IT Assessment is the most direct way to find it before a crisis reveals it.