It's 3:12 a.m. on a Sunday during a long holiday weekend. At a mid-sized company, a legitimate administrative credential begins accessing network folders it had never touched before. The detection tool does exactly what it was purchased to do: it identifies the anomalous behavior, classifies the event as critical, fires off an email, and lights up a dashboard in red. The alert is actually read at 9:40 a.m. on Monday. In that thirty-four-hour interval, what was a manageable technical problem became a billing problem, a contractual problem, and a reputational problem.
The scene is unsettling because it's so ordinary. Most organizations have already invested in advanced antivirus, EDR (Endpoint Detection and Response), MFA (Multi-Factor Authentication), and centralized cloud log collection. Detection is no longer the bottleneck. The bottleneck is now the interval between an alert firing and someone with authority making the decision that contains the damage. Almost no company measures that interval, and practically none measure it outside business hours, on holidays, or while the team is on vacation.
According to the Microsoft Digital Defense Report, the average time for an attacker to begin moving laterally within the environment after the initial compromise is roughly 72 minutes. The effective response window, therefore, is measured in minutes. Most companies' response capability is measured in shifts, business days, and office hours. That asymmetry, not the brand of software installed, is the real risk the board should be seeing.
The budget is concentrated in one function out of six
The NIST Cybersecurity Framework 2.0, published in 2024, organizes security into six functions: Govern, Identify, Protect, Detect, Respond, and Recover. Detect is only one of them. Respond and Recover are distinct functions, with their own processes, owners, and metrics. In companies' actual budget practice, however, the overwhelming majority of investment goes to Protect and Detect, because those are the functions you can buy with a purchase order. Respond and Recover require available people, delegated authority, and rehearsal, three things no vendor delivers in a box.
The 2025 Cisco Cybersecurity Readiness Index shows that only 4% of the organizations assessed reach the maturity level considered adequate for today's threat landscape, even among companies that report growing investment in security. The figure is revealing because it separates two things managers tend to confuse: having technology and having operational capability. Technology is distributed fairly democratically across the market. The capability to act on what it produces, at 3 a.m., is not.
The cause-and-effect mechanism is more perverse than it appears. Every new tool added to the environment multiplies the volume of signals generated, but human triage capacity stays constant. The result is alert fatigue, the phenomenon in which professionals exposed to hundreds of daily notifications, most of them irrelevant, develop the organizational habit of ignoring them. When the true signal finally appears, it arrives dressed exactly like the false positives of the last six weeks. Buying more detection without expanding response capability does not reduce risk. It increases the noise the real incident will hide in.
There is also the compounding effect of time. In a ransomware attack, the interval between initial access and large-scale encryption is usually a matter of hours, not seconds. Containing it within the first ninety minutes normally means losing one server. Containing it after thirty hours normally means restoring the entire environment, renegotiating deadlines with clients, and explaining what happened to partners and regulators. IBM's annual report on the cost of data breaches indicates that the average cycle between identifying and containing an incident exceeds two hundred and forty days in organizations without continuous monitoring operations, and that the cost grows consistently with the length of that cycle.
Add to that the contractual and regulatory dimension. Regimes such as the GDPR in Europe and the LGPD in Brazil set short deadlines, typically 72 hours, for notifying authorities of significant incidents. Corporate contracts with service level and availability clauses turn hours of downtime into measurable penalties. Response latency, which looks like an operational detail, later shows up in the income statement as lost revenue, idle payroll, penalties, and discounts at contract renewal.
How to treat incident response as a business process
The first move is to stop treating response as a technical matter and start treating it as a process with an owner, a deadline, and a cost, exactly like the accounting close or a logistics delivery. That means naming a process owner, defining an internal SLA (Service Level Agreement) for containing critical events, and reviewing that metric in the same meeting where sales and margin are reviewed. If containment time isn't discussed by the leadership team, it isn't being managed by anyone.
The second move is to write the decision tree before the crisis. It isn't enough to know who owns the topic; you need to define which actions are pre-authorized without consultation: isolating an endpoint, blocking an account, terminating active sessions, cutting a link. Without written delegation, the on-call professional will do the one thing that protects their career, which is to escalate and wait. Waiting is the most expensive decision in the repertoire. The cost of an unnecessary isolation is one morning of productivity. The cost of waiting thirty hours for authorization is weeks of operations.
O terceiro movimento é testar fora do horário comercial. Um exercício de mesa realizado em uma terça-feira às 15h prova muito pouco. O mesmo exercício conduzido em um domingo, sem aviso, com o gestor titular de férias, revela o número verdadeiro. Empresas que fazem isso descobrem coisas desconfortáveis e baratas de corrigir: telefones desatualizados, listas de contato armazenadas apenas dentro do sistema que ficou indisponível, credenciais de emergência que ninguém sabe onde estão. Vale ancorar essa decisão em a managed security operation when the volume of events exceeds the capacity of the internal team.
The fourth move is to decide, on economic criteria, what stays in-house and what requires external backup. Maintaining genuine 24-hour, 7-day-a-week monitoring, with coverage for vacations, holidays and leaves of absence, requires roughly six dedicated professionals working in shifts. Few organizations below a few thousand employees can justify that fixed cost for a function that, under normal conditions, sits idle. This is a business calculation, not a question of the internal team's competence.
1. What is the average time between a critical alert and the first containment action at your company, and can anyone prove that number with data? 2. Who, by name and phone number, has the authority to isolate a server or block a user at 3 a.m. on a Sunday, without waiting for approval? 3. How much does each additional hour of response latency cost in your industry, in lost revenue, idle payroll and contractual penalties? 4. Why does buying more detection tools tend to make the problem worse when there is no human capacity for continuous triage? 5. What can your company handle on its own, what requires specialized backup, and how do you decide that on economic criteria?
What is the average time between a critical alert and the first containment action at your company, and can anyone prove that number with data?
The answer most managers give is an optimistic estimate built on the best case ever observed. The number that matters is not the one from business hours with the full team on hand. It is the one from the early hours of a Saturday morning, with the lead on vacation and the backup in another time zone. Ask for 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 get started: MTTD (Mean Time To Detect) and MTTR (Mean Time To Respond). Segment both by time of day and by day of the week. If the difference between the business shift and the overnight hours is an order of magnitude, the problem is not technology, it is operational scale. And if the data simply does not exist, the honest answer is that the time is unknown. In risk management, unknown and unlimited mean the same thing.
Who, by name and phone number, has the authority to isolate a server or block a user at 3 a.m. on a Sunday, without waiting for approval?
That question tends to produce a revealing silence in board meetings. There is almost always someone formally responsible for the topic, but there is rarely a written delegation of authority to act without consulting anyone. In its absence, the chain of command turns into a chain of waiting, and every additional link costs minutes that the attacker is using to spread.
The mature practice is to build a short matrix of pre-authorized actions, with names, phone numbers and designated backups, plus an alternative path that does not depend on a single person answering their cell phone. Document the inverse as well: which decisions require executive approval, so that no one hesitates out of uncertainty about scope. Store that matrix outside the systems that may become unavailable. A response plan stored only in the compromised environment is not a plan, it is a hope.
How much does each additional hour of response latency cost in your industry, in lost revenue, idle payroll and contractual penalties?
The calculation is simpler than it seems and completely changes the conversation with finance. Add up the gross revenue generated per operating hour, the hourly cost of the payroll that is prevented from producing, the contractual penalties stipulated for downtime, and the estimated cost of recovery and customer communication. Manufacturing and logistics companies tend to find hourly figures significantly higher than they imagined, because the stoppage propagates across the entire chain.
With that number in hand, investment in response capacity stops being a security expense and becomes a continuity decision with a calculable return. If every hour of downtime costs a known amount, and continuous backup costs the equivalent of a few hours of downtime per year, the discussion settles itself. An objective estimate of the cost per hour of downtime is the first artifact that should exist before any new tool purchase.
Why does buying more detection tools tend to make the problem worse when there is no human capacity for continuous triage?
Because detection and response scale differently. Tools scale with licensing, in a practically linear and inexpensive way. Triage scales with trained people, in an expensive and slow way. By adding a new source of alerts without expanding analysis capacity, the company increases the denominator without touching the numerator, and the percentage of alerts actually investigated plummets.
The side effect is cultural and irreversible in the short term. A team that has learned, through repetition, that most critical alerts don't require action will treat the real alert with the same indifference. Before approving the next acquisition, ask a simple question: what percentage of the alerts classified as critical over the last ninety days was analyzed by a human being in under fifteen minutes? If the answer is low, the right investment isn't in additional detection, it's in response capacity.
What can your company handle on its own, what requires specialized backup, and how do you decide that on economic grounds?
The healthy split is rarely all in-house or all outsourced. The internal team is irreplaceable in anything that depends on business context: knowing which system sustains revenue, which client won't tolerate downtime, which decision requires the president on the line. Continuous monitoring, first-level triage, and response at unlikely hours, on the other hand, are functions of scale, and scale is exactly what a shared SOC (Security Operations Center) offers at a cost no mid-sized in-house operation can replicate.
The decision criterion should be economic, not emotional. Compare the total cost of maintaining your own continuous coverage, including turnover, training, and vacation replacement, with the cost of specialized backup plus the gain in containment time. Technical pride is one of the most expensive variables in this calculation, because it delays the decision until a crisis makes it in the manager's place. The final question isn't whether the team is competent. It's whether it can, sustainably, be awake at 3 a.m. every Sunday of the year.
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 generally performed by automated tools. Response is the human decision that contains the damage, such as isolating a device or blocking a compromised account. The NIST Cybersecurity Framework 2.0 treats Detect and Respond as separate functions, with their own owners and metrics, precisely because investing in one does not produce the other.
How do you measure incident response time outside business hours?
Record three timestamps for each critical event: the generation of the alert, the first reading by a professional, and the effective containment action. Segment this data by time of day and by day of the week, comparing the business shift with nights, weekends, and holidays. A difference of an order of magnitude between the two scenarios indicates a lack of continuous operational capacity, not a technology failure.
When does it make sense to hire an external SOC instead of building an internal team?
Maintaining true 24/7 monitoring, with coverage for vacations, holidays, and leaves of absence, requires roughly six dedicated professionals working in shifts. Organizations below a few thousand employees rarely justify that fixed cost for a function that sits idle under normal conditions. The decision should compare the total internal cost with the cost of external backup plus the gain measured in containment time.
If the interval between the alert and the decision still doesn't have a proven number at your company, a no-obligation Strategic IT Assessment is the cheapest way to find it out before a crisis reveals it.