0.3 The Triage Clock

Introduction

The triage clock is the time an organization allows for each triage decision once an incident is known: how quickly it must be acknowledged, how soon a senior person takes it, how fast the first containment happens, and when leaders are told. The clocks are set by the priority tier, so a critical incident gets minutes and a low one gets days, and they turn a severity rating into a commitment someone can be held to. They are one of the course's four signatures, taught in full in Module 4 and measured again in Modules 10 and 11. This sub introduces them through Northgate's own policy and then tests it against the month, from both directions: attacks that finished faster than any person could meet the clocks, and incidents that waited far longer than any clock allows because nobody started it. By the end you'll be able to read any incident against its clock, starting from the alert rather than from the moment someone got round to it.

A triage clock is a promise the organization makes to itself about speed. It says, for each priority tier, how quickly each of the first steps must happen, and who is accountable when one does not. Northgate's policy, taught in Section 4.5, sets them like this:

Three things about the clocks shape everything in this course. They are set by the tier, which is why the scorecard of Module 4 matters: an incident scored too low runs on clocks that are too slow. They are measured from the alert, because harm starts then, not when someone opens the incident. And they are commitments with owners, so that a missed clock is somebody's to explain and to fix.

The clocks also differ in what they require. The acknowledge clock asks only that someone take the incident on; the senior-analyst clock asks that the right someone does; the containment clock asks for an action that stops harm; the CISO clock asks that leadership knows. Each can be met while the others are missed, and a report that gives one number for an incident hides which.

The clocks are also honest about people. Fifteen minutes to acknowledge a P1 is roughly what an on-call analyst can manage at any hour; an hour to first containment is roughly what it takes to validate, scope enough to act, and act. The numbers were set from how long the work takes, which is the right starting point and, as the next sections show, not the only one that matters.

Other organizations set quite different numbers, and there is no universal standard. Frameworks and regulators describe what must happen in an incident, and contracts with customers or providers sometimes set response times, but the internal clocks for acknowledgment and first action are each organization's own to set. What matters is that the numbers exist, are written down, and are measured. An organization without written clocks has no way to say whether its triage was fast enough, and the question will be asked, by a board, a regulator or a customer, after the incident that most needed speed.

The clocks run through every module of the course after this one. Module 1's validation and Module 3's scope are the work inside the first hour; Module 9's containment order is how the first-containment clock is met; Module 10 measures escalation against them.

A clock is also only as good as the tier behind it. A P1 incident rated P3 by mistake runs on a four-working-hour acknowledge clock and a one-day first action, and meets both while the attacker finishes. Every clock in the table depends on the scoring being right, which is why the scorecard comes before the clocks in the course and why the tier is rechecked as scope grows.

The clocks were set from how long the work takes a person. The first test is how long the attacks themselves take. Two of the month's attacks, each measured from its own alert:

union
    (SecurityAlert | where CompromisedEntity == "NE-BENNETT-LT"
        | summarize Time = min(TimeGenerated) | extend Step = "ransomware alert"),
    (DeviceFileEvents | where InitiatingProcessFileName == "notlocker.exe"
        | summarize Time = min(Timestamp) | extend Step = "first file encrypted"),
    (SecurityAlert | where CompromisedEntity == "WEB-NGE-MCR-01"
        | summarize Time = min(TimeGenerated) | extend Step = "intrusion alert"),
    (OfficeActivity | where ClientIP == "45.137.21.88"
        | summarize Time = max(TimeGenerated) | extend Step = "last file downloaded")
// two fast attacks: each alert, and the harm that followed
| order by Time asc

(sourcetype="ms365:defender:incident:alerts"
        (CompromisedEntity="NE-BENNETT-LT" OR CompromisedEntity="WEB-NGE-MCR-01"))
    OR (sourcetype="ms:defender:eventhub" category="AdvancedHunting-DeviceFileEvents"
        InitiatingProcessFileName="notlocker.exe")
    OR (sourcetype="o365:management:activity" src="45.137.21.88")
| eval Step=case(CompromisedEntity="NE-BENNETT-LT", "ransomware alert",
    CompromisedEntity="WEB-NGE-MCR-01", "intrusion alert",
    sourcetype="o365:management:activity", "last file downloaded",
    1=1, "first file encrypted")
| stats min(_time) as First, max(_time) as Last by Step

Four rows, two for each attack. The ransomware alert fired at 11:04 on 12 March and the first file was encrypted at 11:12, eight minutes later. The intrusion's alert fired at 15:35 the same day and the last of 146 files was downloaded at 16:20, forty-six minutes later. The first harm fell inside the P1 acknowledge clock; the second fell inside the first-containment clock.

Laid on one logarithmic time scale with the rest of the month's events, from a minute to a month, the problem is visible at a glance:

The two fast attacks sit to the left of the containment line, and one sits left of the acknowledge line as well, so a team meeting its clocks perfectly would still have watched them finish. Module 11 takes up what that means: for harm that runs faster than people can act, the first action has to be automatic, on a narrow and trustworthy signal, with the clocks governing the review that follows rather than the action itself.

The two attacks also show what the alert time can and cannot tell a triage. The ransomware alert arrived two minutes after the malware was first detected running, and the intrusion alert ninety minutes after the attacker first reached the server. An alert is not the start of the attack; it is the start of the organization's chance to respond. The earlier the alert, the more of the attack falls inside the clocks, which is why detection engineering and triage are two halves of one problem.

Seen from the attacker's side, the clocks are simply time. An attacker who can encrypt a laptop in eight minutes does not care whether the defender's policy says fifteen or five; the harm is done either way. The clocks protect the organization only where the attack is slower than the people working them, and the organization's job is to know where that line falls for the attacks it expects.

That does not make the clocks wrong. It makes them the right tool for the part of the work people do, and the wrong tool for stopping the fastest harm. Knowing which is which is part of reading any incident against its clock, and of explaining to a board why meeting every clock did not stop an attack.

The second test runs the other way, and at Northgate it found the larger failure. The clocks are set by the tier, and an incident nobody tiers has no clock running. The two open Highs at noon on 15 March, with how long each had waited:

SecurityIncident
// the two open Highs: how long each had waited by noon on 15 March
| where Status != "Closed" and Severity == "High"
| extend HoursWaitingAtNoon = datetime_diff("hour",
    datetime("2026-03-15T12:00:00Z"), CreatedTime)
| project IncidentNumber, Title, CreatedTime, HoursWaitingAtNoon,
    Owner = tostring(parse_json(Owner).assignedTo)

sourcetype="ms365:defender:incident" Status!="Closed" Severity="High"
| rex field=Owner "assignedTo\":\"(?<AssignedTo>[^\"]*)"
| eval HoursWaitingAtNoon=round(((strptime("2026-03-15T12:00:00", "%Y-%m-%dT%H:%M:%S")
    - strptime(CreatedTime, "%Y-%m-%dT%H:%M:%S")) / 3600) - 0.5)
| table IncidentNumber, Title, CreatedTime, HoursWaitingAtNoon, AssignedTo

Two rows, and neither had been acknowledged at the right rung. The domain compromise had been open for 30 hours, all of them with a Level 1 owner, and the multi-stage intrusion for 22 hours, with no owner at all. At P1, both should have been acknowledged within fifteen minutes and had a senior analyst within thirty. Neither had.

The board-pack sentence would still have been technically true, which is what makes it dangerous. Once the multi-stage intrusion was tiered at 13:15 on 15 March, its first containment was ordered at 13:40, well inside the hour. Measured from the tier, the clock was met. Measured from the alert, the incident waited 23 hours before its clock started:

Tiered P1 at 13:15; containment 13:40.
First-containment clock met.

Raised 13:41, 14 Mar; tiered 23 hours late;
containment 25 minutes after the tier.

The difference is exactly what the acknowledge clock exists for, and why it is the first clock in the table. It measures the gap between an incident appearing and someone taking it on, which is exactly the gap a queue hides. A report that measures only from the tier reports every incident as on time and misses the one failure that matters most.

The wait is rarely anyone's deliberate choice. At Northgate the multi-stage intrusion's alert was raised on a Saturday afternoon, created an incident with no owner, and sat in a queue that the Level 1 analysts, working their own assigned incidents, read from the top. Nothing in the workflow turned an unowned High into anyone's problem. The analysts met their own clocks on the incidents they held; the incident nobody held had no clock to meet.

The domain compromise shows the other half of the gap. It had an owner and still waited, because the owner could not make its decisions and nothing escalated it. The senior-analyst clock, thirty minutes at P1, exists for that case: it measures not whether someone has the incident but whether the right someone does.

The fix Section 10.2 set out is structural, not a matter of trying harder: every High alert becomes an owned incident within its acknowledge clock, and a missed acknowledge is escalated automatically. Then no incident can wait unseen, because its clock starts whether or not anyone reads it. The acknowledge clock becomes a tripwire rather than a target: a missed acknowledgment pages someone, which is cheaper than any review afterwards.

Some harm is slow, and slow harm defeats the clocks in a different way entirely. The phishing compromise of Module 6 began with a stolen session in February and forwarded a finance mailbox's mail to an outside address for days. Its timeline:

union
    (SigninLogs | where UserPrincipalName == "c.richardson@ne.com"
        | where IPAddress == "185.234.72.18"
        | summarize Time = min(TimeGenerated)
        | extend Record = "first attacker sign-in", Count = 1),
    (EmailEvents | where RecipientEmailAddress == "c.richardson@ne.com"
        | where DeliveryAction == "Delivered"
        | where Timestamp > datetime("2026-03-03T21:18:00Z")
        | summarize Time = max(Timestamp), Count = count()
        | extend Record = "latest of the messages forwarded out")
// a slow attack: when it began, and how long its harm ran
| order by Time asc

(sourcetype="azure:monitor:aad" category="SignInLogs"
        user="c.richardson@ne.com" src_ip="185.234.72.18")
    OR (sourcetype="ms:defender:eventhub" category="AdvancedHunting-EmailEvents"
        RecipientEmailAddress="c.richardson@ne.com" DeliveryAction="Delivered"
        earliest="03/03/2026:21:18:00")
| eval Record=if(sourcetype="azure:monitor:aad", "first attacker sign-in",
    "latest of the messages forwarded out")
| stats min(_time) as First, max(_time) as Last, count as Count by Record

Two rows, sixteen days apart from the first to the last. The attacker first signed in as c.richardson at 18:47 on 27 February. After the forwarding was set on the evening of 3 March, 108 messages reached the mailbox and went out with it, the latest at 11:46 on 15 March. Section 11.3 found that none of the alerts along the way became an incident anyone owned.

No P1 clock would have been missed here, because no clock ever started. The alerts that fired along the way, a high-risk sign-in from the phishing address, a keyword inbox rule, a Low rule change, were each rated by their tools and none became an incident anyone owned. The harm accrued at the rate the finance mailbox received mail, one message at a time, for eleven days.

Slow harm is where the clocks' other purpose shows. A clock is not only a deadline for speed; it is a guarantee that someone looks. An incident with an owner and a clock running gets at least a first action; an alert with neither gets nothing, however long it sits. The phishing compromise needed a person to look at it once, which any clock would have forced.

Slow harm is also where the tier, and the scoring behind it, matters most. Each of the phishing compromise's alerts, rated on its own, was Medium or Low, and a Low runs on a clock of days. Had one of them become an incident and been scored on the scorecard, the account's history would have put it in a higher band with a faster clock; left as individual alerts, each ran on its own slow clock or none. Module 4's scoring is what turns a string of small alerts into one incident with a clock that fits it.

The harm's rate is also worth measuring. 108 messages in eleven days is about ten a day, each one an invoice, a contract or an internal note leaving the organization. A triage that finds the forwarding in its first days stops most of it; one that finds it on the eleventh stops almost none. For slow harm, every day of delay has a count attached, and the count is what the notification assessment will later need.

The two tests together are the whole lesson of this sub, and of the clocks. Fast harm is met by automation acting within the clocks; slow harm is met by the clocks starting at all.

Every clock in this course is measured from the alert, without exception. That is a deliberate choice, and it is made because each of the alternatives hides something important. Measured from the tier, the wait before the tier disappears. Measured from the moment an analyst opened the incident, the queue's delay disappears. Measured from the first action, everything before it disappears.

Measuring from the alert is also fair to the analysts. A delay that happened before anyone could have seen the incident is not theirs, and a delay that happened while the incident sat unowned is the workflow's, not any one person's. Measured from the alert, each delay lands where it belongs, which is what makes the review about fixing the system rather than blaming whoever was on shift.

The alert is not always the start of the harm; the phishing compromise's attacker was inside for days before any alert mattered. But the alert is the earliest moment the organization could have known, and it is the one the organization controls. Measuring from it holds the part of the delay that the organization owns to account, and leaves the part it could not have known about to the detection review.

Measured that way, the month's key incidents read like this:

Five incidents and five different failures, and none of them is a slow analyst. It also makes the clocks comparable. A P1 measured from the alert at one incident means the same as at another, which is what lets a review say that last week's P1s met their clocks at most one time in four, as Section 4.5 found, and ask why the other three did not. Each miss is recorded with its cause while the people involved still remember it, so that the review changes the workflow and not only the number.

For the board pack, measuring from the alert turns a comfortable sentence into a useful one. It is also a sentence that survives scrutiny. A board member who later learns that the multi-stage intrusion waited 23 hours will ask why the pack said every clock was met; a pack that said so itself has already answered the question. The clocks worked once incidents were tiered; incidents waited too long to be tiered; and the fastest attacks finished inside even the shortest clock. Each of those is true, and each points to a different fix.

Every sub in this course that reads an incident against its clock uses the same starting point, and says so. When a time is quoted without saying where it was measured from, the first question is: from what?

The IT director's line is accurate and misleading at once, which is why it is worth checking before the board reads it. Read it beside the month's timings and make the call:

The call rewrites the line for the board, keeping everything true in it and adding everything important that it left out. Northgate's P1 clocks are acknowledge in 15 minutes and first containment in an hour. Measured from the alert, last week's two open High incidents waited 22 and 30 hours before anyone took them on at the right rung; once tiered, the multi-stage intrusion met its first-containment clock; and the two fastest attacks did their harm in 8 and 46 minutes, inside any clock a person can meet. The actions follow: every High alert becomes an owned incident within its acknowledge clock, and narrow automatic first actions cover the harm that runs faster than people.

The rewrite is longer, and less comfortable to present, and it is the version the board can act on. It names two fixes rather than none: one for the wait before the tier, which is a workflow change with no cost, and one for the fastest harm, which is automation of a few narrow first actions. Neither needs more analysts, which is what a board hearing "the clocks were missed" might otherwise assume. It also makes next month's measurement meaningful for the first time, since the numbers will show whether the waits before the tier have closed.

The steps fit a card that works for any incident, open or closed, at any priority:

The first row is the one this whole sub exists for. Every later module assumes it; this is where it is set.

Practice

The clock is best practiced on incidents your own team has already closed, where every one of the relevant times is already on the record.

If step two finds the longest gap before the tier, the fix is in how alerts become incidents, not in how fast your analysts work.

Section 0.4 turns to the environment you will practice in: the records built into every page, and the labs you can build alongside them.