The scarce resource is response, not detection
Teams without a security operations centre usually assume their problem is coverage: not enough logging, not enough detections, not enough tooling. In practice the failure sits on the other side of the pipeline. The telemetry existed, the alert fired, and nobody did anything with it, because it arrived in a mailbox nobody owns or a channel everyone muted months ago. The scarce resource in a ten-person IT function is not detection logic. It is the number of times a human can stop what they are doing and investigate something. Detection engineering for a team without a SOC means budgeting that resource deliberately, and the budget is smaller than most alert consoles assume.
That reframing produces a hard rule: an alert nobody acts on is worse than no alert at all. It manufactures assurance that monitoring exists when it does not. It trains the people receiving it to dismiss the channel, which is precisely the reflex an attacker needs from them. And it leaves a written record that the organisation was told and did nothing, which reads very differently after an incident than honest silence does. Everything that follows comes from taking that rule seriously.
Every alert needs a named owner and a first action
Before tuning anything, run a contract test over every alert you have or are considering. Who, by name, receives it? What do they do in the first ten minutes, written as an actual instruction rather than the word investigate? What does resolved look like? If you cannot answer all three, the detection is not an alert. It may still be worth keeping, but it has not earned a place on anyone's phone.
In practice detections sort into three tiers. The top tier pages a person and interrupts whatever they are doing, including sleep. The middle tier lands in a weekly digest that someone is rostered to read, which suits slow-burn signals like a creeping rise in failed sign-ins or an unusual pattern of new device registrations. The bottom tier is audit trail: recorded, indexed, pushed to no one, and invaluable when you are reconstructing an incident. Most of what security products ship as default alerts belongs in the bottom two tiers. Small teams leave everything in tier one because demoting a detection feels like accepting risk. It is the reverse. Demotion is what keeps tier one credible enough to act on.
The short list that earns a wake-up
For an Australian business running Microsoft 365 and Azure, which describes most of the market, the wake-up tier can stay small because a handful of events sit at choke points in the attack chains that actually hurt small organisations: business email compromise and ransomware. Each of the following marks a moment where hours of delay change the outcome.
That is eight entries. Some environments justify one or two more; very few justify fifteen. Notice what is absent: failed sign-in floods, vulnerability scanner findings, atypical travel flags on ordinary accounts. Those are genuine signals, and they belong in the digest tier, where a pattern across a week means something and a single event does not.
- A new assignment to a privileged Entra ID role, Global Administrator above all. Legitimate assignments are rare and known in advance; anything else is a takeover in progress.
- A conditional access policy modified, disabled, or newly excluded from. Attackers who reach admin loosen the door behind them before doing anything else.
- A new MFA method registered on a privileged or executive account. Method registration is how a stolen session becomes a durable foothold.
- A new inbox rule that forwards mail externally or deletes messages matching finance keywords. This is the signature move of business email compromise, and it fires early in the chain.
- Consent granted to an OAuth application requesting broad mail or file scopes. Illicit consent grants survive password resets, which is exactly why attackers like them.
- Backup jobs failing, retention shortened, or backups deleted. Ransomware crews stage this before encrypting, and it is worth knowing promptly for unglamorous operational reasons too.
- Any sign-in by the break-glass account. It should stay silent for years, so a single use justifies a phone call.
- An endpoint detection on a server rather than a workstation. Server-side tooling implies hands on a keyboard, not a commodity phish.
Tuning is mostly deletion
Tuning has a reputation as a craft of thresholds and clever exceptions. For a small team it is mostly the discipline of removal. Start with base rates: run any candidate alert silently for two weeks and count how often it would have fired. A rule that would have paged someone daily is not an alert, whatever severity label the vendor gave it, because the internet supplies a permanent background of password spray and scanner traffic that nobody should ever be woken for.
Then narrow scope before you raise thresholds. A geographic sign-in alert across all staff breaks the first time someone takes a holiday in Bali; the same alert scoped to privileged roles and service accounts stays quiet and meaningful. Suppress known-good behaviour by identity rather than by IP address, because addresses churn and identities are the thing you actually trust. Then put one recurring task in the calendar: each month, list every alert that fired and mark whether anyone took an action because of it. Anything with a ninety-day streak of no action gets deleted or demoted, without sentiment. The alert that fires every morning and gets closed without a second look is not harmless noise. It is daily training in the exact dismissal reflex that will eventually be applied to the real event.
The unread alert becomes evidence
There is a regulatory dimension that Australian executives tend to discover at the worst possible time. Under the Notifiable Data Breaches scheme in the Privacy Act 1988, an organisation that suspects an eligible data breach has up to thirty days to assess it, and must notify the OAIC and affected individuals as soon as practicable once it concludes serious harm is likely. After an incident, every one of those timelines is reconstructed from logs, tickets, and mailboxes.
An alert that fired into an unmonitored shared mailbox three weeks before anyone noticed the intrusion does not read as detection capability. It reads as the moment the organisation knew. That distinction shapes the conversation with the regulator, with the cyber insurer assessing whether policy conditions were met, and with the customers whose data left the building. An honest gap in coverage is defensible; documented indifference is not. This is the sharpest form of the rule: silence keeps your posture honest, while a decorative alerting pipeline quietly converts every future incident into a story about the day you were warned and did nothing.
Making it hold without a SOC
The pipeline needs the same rigour as the rules. Wake-up alerts go to at least two named humans through a channel that reaches their phones, never to a distribution list or a shared mailbox, which is where alerts go to die. The weekly digest needs a rostered reader and a fifteen-minute calendar slot, because "someone will look" means nobody will. And test the whole path quarterly by generating a synthetic event, a test inbox rule or a sign-in from a clean virtual machine, and timing how long a human takes to acknowledge it. A detection you have never watched fire end to end is a hypothesis, not a control.
Revisit the list after every incident, every near miss, and every penetration test, because a good test report is effectively a map of which detections stayed silent while an attacker moved through the environment. Building this layer and then holding it to the actioned-or-deleted standard is the detection work Black Shard runs inside Azure security reviews and ongoing vCISO engagements, and the monthly review is the part that decides whether any of it is real.
Start by deleting
The practical version fits in a week. Export every alert currently configured across Microsoft 365, Azure, your endpoint product, and your backup platform. Mark each one either actioned in the last ninety days or not, and demote or delete the rest. Then build the wake-up list from the choke points above, write the ten-minute first action beside each entry, and put two names on every one.
You will finish with fewer alerts than you have today and more detection than you have ever actually had, because a detection only exists at the moment a person acts on it. Everything before that moment is logging with ambitions.