What to do when an alert arrives

It is four o'clock on a Friday. The console is showing a critical alert with one of your colleagues' names attached to it, and you are the person who has to deal with it. You are not a security analyst. This article is the order to do things in.

Nothing below needs security training. It needs you to resist two instincts. The first is to fix it immediately by deleting, wiping or rebuilding something. The second is to leave it until Monday because you are not sure. Both make the outcome measurably worse, and the first one is usually the more expensive of the two, because it destroys the record of what happened.

The first ten minutes, in order

Do these in sequence. Steps one to three cost you nothing and are never wrong. Steps four onwards start to change things, and the order matters because some actions destroy information that later steps need.

1. 1

   Read the decision summary and the named subjects before you touch anything

   An alert in Qorionix names real subjects — a specific person, a specific machine, a specific application. Read those names first. Half of all alerts resolve themselves at this point, because the named person is sitting three metres away and can tell you they were signing in from a hotel in Lisbon. That is not a security incident; it is a travel itinerary.

2. 2

   Check whether Sentinel-Q has already acted

   Depending on the autonomy tier you set, the platform may have already taken a reversible action — revoked a session, quarantined a file, isolated one machine. If it has, the action, its blast radius and its undo control are all on the decision itself. Read what it did before you do anything of your own, so you do not fight the platform for control of the same account. See Reading a Sentinel-Q decision and Undo a change.

3. 3

   Contact the named human on a channel that is not the compromised one

   Telephone them. Do not email them, and do not message them in Teams. If the alert concerns their mailbox or their account, an attacker sitting in that mailbox reads your email asking whether the sign-in from Lagos was theirs, and answers it for them. This has happened to real businesses. Use the voice channel.

4. 4

   If it is an identity alert, revoke the session and force a re-authentication

   For sign-in, token, consent and mailbox-rule alerts, revoking the active sessions and requiring the person to authenticate again is close to free. The cost of being wrong is that a colleague signs in a second time and mildly resents you. The cost of not doing it, when you were right, is every mailbox that account can reach. This asymmetry is why it is the first action worth taking, and it is self-correcting if the alert turns out to be nothing.

5. 5

   Do not delete, wipe or reset anything until you have recorded who had access

   This is the step people skip. Before you reset a password, rebuild a laptop or delete a suspicious mailbox rule, write down or export what is currently true: which accounts have access to what, which rules exist, which applications hold consent, when the first suspicious event occurred. Once you have reset the password, you cannot tell whether the attacker still had valid tokens, and once you have wiped the machine, the evidence of how they got in is gone. You need that record for the regulator, for your insurer, and for knowing whether you are actually finished.

6. 6

   Isolate one machine if you need to buy time

   Network isolation is reversible and it is the cheapest way to stop something spreading while you think. Isolate the single machine named in the alert. Do not isolate a subnet, a site or a server that other people depend on unless you have decided consciously to take that outage — the disruption becomes the incident, and you will be judged on it.

7. 7

   Say out loud that you need a specialist, if you do

   Anything that looks like ransomware before encryption, or anything that looks like an attempt at financial fraud, needs a human specialist. Those two categories are where working through it alone goes wrong most expensively, and where the decisions are legal and financial as much as technical. Stopping to make a phone call is not an admission of failure; grinding on alone for six hours is not diligence.

8. 8

   Record what you did, in the ticket, as you go

   Every step, with a timestamp and a reason. Not afterwards from memory. The chain of what was observed, what was decided and what was done is the artefact that answers a supervisory authority later, and it is the difference between a defensible response and an anecdote. Every privileged action the platform takes already produces a hash-chained audit row; your own manual actions need to sit alongside them.

What the alert is telling you, field by field

An alert is not a verdict. It is the output of a detection rule that matched, survived aggregation, and was allowed to raise work for a human. Four parts of it are worth your attention before you act.

Severity

A number, not an adjective — the platform uses the CEF scale, so critical is 10 and high is 8. It expresses how bad this pattern is when it is real, not how confident the platform is that it is real. The two are different things and Alert severity, and what a match actually means explains the distinction, which matters a great deal at four on a Friday.

Subjects

The entities the rule attributed risk to: a user principal, a host, a source address, an application. If the subject list is empty or reads oddly, treat the alert with more suspicion, not less — an alert you cannot attribute to something real is an alert you cannot act on safely.

False-positive guidance

Every rule in the library carries it, mandatorily; the validation gate refuses to load a rule without it. This is the field that tells you the three ordinary business situations that produce this alert. Read it before you telephone anyone. A rule without false-positive guidance is a rule a customer disables in week two, which is why the platform will not ship one.

Response actions and data sources

Also mandatory on every rule. The response actions are what the rule's author expected a responder to do. The data sources tell you which telemetry the finding rests on, which tells you how much weight it deserves — a conclusion drawn from one Sysmon event is not the same as one drawn from correlated sign-in and mailbox activity.

Which playbook you are in

Five response playbooks cover the situations that actually occur at organisations of your size. Each is structured the same way — Immediate, then Investigation, then Recovery — and each states plainly whether a human specialist is needed. Find your row before you start improvising.

All five playbooks are configurable per tenant, because a threshold that suits a fifteen-person architecture practice does not suit a three-hundred-person logistics operator. Automated responses have a dry-run mode for initial deployment, so you can watch what the platform would have done for a fortnight before letting it do it. Every response action must be auditable, and reversible wherever reversal is technically possible.

The recovery phase is the part people abandon halfway. Credential phishing is the clearest example: containment is fast, and recovery is the work that stops it recurring next week.

1. Force a password reset for the affected user — after you have recorded the current state of their access.
2. Review and revoke suspicious application consents. An application that was granted mailbox access during the incident survives the password reset perfectly happily.
3. Check for mailbox rule changes and revert them. A forwarding rule to an external domain is the standard way an attacker keeps reading the mailbox after you have locked them out.
4. Scan the user's endpoint for dropped payloads, because the link they clicked may have delivered more than a credential-harvesting page.

Things not to do

• Do not wipe the machine. It is the single most common irreversible mistake. The machine is the only place that records how the attacker arrived, and rebuilding it converts a knowable incident into an unknowable one.
• Do not reset the password as your first move. Revoke the sessions first, then record access, then reset. Resetting first tells the attacker you are watching and leaves you unable to reconstruct what tokens were live.
• Do not delete the suspicious mailbox rule, application or file before it has been recorded. Revert it, screenshot it, export it — but the configuration you are about to remove is evidence.
• Do not email the possibly-compromised person about the compromise. See step three. Telephone them.
• Do not mark it as a false positive to make it go away. A false-positive marking is an input to tuning; it changes future behaviour. Marking a real alert as false is how an organisation trains itself blind.
• Do not disable the rule at four on a Friday. If the rule is genuinely noisy for your organisation, tune it deliberately on Monday with a reason recorded. Every tuning write is audited with an actor and a reason precisely so that this decision is visible later.

Setting the status honestly

Statuses are not housekeeping. They are the record a regulator reads, and they drive what the platform does next.

Why the record matters more than the fix

If your organisation falls under NIS2, an incident starts a clock: a 24-hour early warning, a 72-hour notification and a final report within one month. None of those can be written from memory. What they are written from is the sequence of what was detected, what was decided, and what was done — which is precisely what the ticket and the audit chain hold. Every privileged action produces a hash-chained audit row, and chain verification locates the exact broken sequence number if a row is ever altered, so the record is defensible rather than merely present.

That is also why a posture finding you consciously accepted is worth as much in the record as one you fixed. A documented decision to accept a risk is a governance act. An undocumented one is indistinguishable from not having noticed.

What to do next

1. Read Alert severity, and what a match actually means — it explains why a critical alert is not the same as a certain one.
2. Read Shadow detections, and why some rules stay quiet — so you know what the platform is watching without telling you.
3. Decide now, in writing, who you telephone for suspected ransomware and who you telephone for suspected payment fraud. Put both numbers somewhere that does not require Microsoft 365 to read.