The alert was there. Weeks before anything ground to a halt, the system had reported the suspicious sign-in, neatly logged, with timestamp and account name. The email about it sat in a shared mailbox that nobody had opened since a staff change.
In our experience, this is how a large share of the incidents we review afterwards begin. Rarely does it start with a sophisticated attack that no security monitoring in the world would have caught. Usually it starts with a signal that was technically seen and still reached nobody. The company had monitoring. It just had nobody who was responsible.
What security monitoring has to deliver
The purpose of monitoring is unspectacular: you want to notice that something is wrong while reacting is still cheap. A compromised mailbox on day one is a password reset and an awkward conversation. The same mailbox after six weeks is a redirected payment and a case for lawyers.
For that to work, monitoring needs three things, and only one of them is technology. First, something has to watch: a system that observes sign-ins, endpoints and mail flows and reports anything unusual. Second, someone has to read the report, within a deadline you have set in advance, not «when there is time». Third, that person must be allowed to decide: lock the account, isolate the device, ask a question, close the case.
An alert is a task assigned to a human. Not a pixel on a screen. As long as it is clear for every alert type whose task it is and how fast the response has to be, almost any technology is good enough. Once that is unclear, even the best technology will not help.
The deadline deserves more attention than it usually gets. «We check in regularly» is not a deadline. A deadline sounds like this: identity alerts are reviewed within four hours on working days, everything else on the next day. Whether it is four hours or eight is a business decision and depends on what is at stake for you. What matters is that the number exists, that someone knows it, and that it gets checked from time to time. Without a number there is nothing to fail against, and that is exactly the problem.
Few alerts that mean something
Besides missing ownership there is a second quiet failure mode: volume. Many systems in their default configuration report everything that might be unusual. The owner's mailbox fills with signals, most of which mean nothing. People get used to noise faster than any security concept would like. After a few weeks the inbox rule appears that moves everything into a subfolder, and from that moment the monitoring is formally active and practically dead.
That is why thinning out is perhaps the most important monitoring work of all, and it is wonderfully unglamorous. The point is to define the handful of events that always get looked at, and to deliberately turn down the rest. For a typical SME, that short list includes roughly: sign-ins that are not plausible geographically or in time. Newly created forwarding rules in mailboxes, the classic precursor to payment fraud. A new account with administrator rights. Disabled backups or protection features. And the alerts your endpoint solution rates as critical.
Whether your list has six or ten items is secondary. The real measure is a different one: how many alerts arrived last month, and how many of them did someone look at? If the answer is three hundred and zero, your setup is currently training the owner to look away. Then better monitoring starts with deleting.
The dashboard is not the monitoring
In consulting conversations we regularly hear the same sentence: «We have a dashboard for that.» What is meant is an overview the IT provider set up, sometimes a portal with traffic lights, sometimes a weekly PDF report. The sentence is spoken calmly, as proof that the topic is taken care of.
A dashboard is a display case. It shows things. Being able to see something is not the same as doing something, and it is exactly in that gap that the expensive weeks between initial access and discovery happen. The uncomfortable control question is not «What does the dashboard show?» but «When did someone last act on what it showed?». If the answer lies far in the past, you are not running monitoring but decoration that reassures the auditor.
The same goes for the provider's monthly security report. It gets delivered, filed, and presented as evidence at the next audit. That is not worthless; a clean report has its place. But a report that summarises four-week-old events is bookkeeping, not detection. If initial access happens on the third day of the month and the report arrives on the first day of the next one, the attacker had a four-week head start, with full documentation.
The reflex at this point is almost always a purchase: a SIEM, an XDR platform, more sensors. Afterwards, more events get generated that still nobody reads, only at a higher price. We described the same pattern for vulnerabilities: the scanner is the easy part, the decision loop behind it is what protects. For monitoring this applies even more sharply, because here the deadline is measured in hours, not weeks.
How much monitoring does an SME need?
Less than the market wants to sell you, and more than most companies operate. Both at the same time.
Less, because the standard argument «without a 24/7 SOC you are blind» is rarely the first bottleneck for an SME with 50 to 500 employees. Before the question of night shifts comes up, the basic mechanics have to work during the day: few alert types with high signal value, a named owner, a defined response deadline, a short decision path. Much of that comes from the technology you already pay for. In Microsoft environments, the built-in tools provide usable alerts for identities, endpoints and mail before a single additional franc is spent.
More, because «the provider is watching» is, in our experience, the most common untested assumption in Swiss SMEs. Many IT contracts cover operations and availability, not security monitoring. Whether someone reacts when an account signs in from an unexpected country at 3 pm is rarely in the contract and even more rarely tested. The question «Who exactly reads our security alerts, and what has been agreed?» costs one email and answers more than any product evaluation.
And yes, attacks do not keep office hours. Encryption waves prefer to start when nobody is watching for as long as possible, meaning at night and on weekends. But for an SME the conclusion is not to build its own night shift. There are three honest answers for the hours outside business operations: contractually agreed on-call coverage at your provider for the few critical alert types, automatic immediate responses by the technology, such as isolating a suspicious device, or consciously accepted residual risk, as a documented decision by management. All three are defensible. What is not defensible is the fourth and most widespread variant: never having asked the question.
Only when the daytime mechanics are in place and you cannot carry them yourself is external monitoring the logical next step. Then you are buying the right thing: response with deadlines that are written into the contract, instead of yet more software. Which tasks you have to keep and which you can hand over is something we sorted out in our post on running IT security without a security team. The short version: you can buy the watching, but not the decision about your risk.
Exactly this operational question is the core of our Security Management & Operations offering: use the technology you have, reduce alerts to the meaningful ones, define ownership and deadlines, and only then talk about purchases. In most cases the setup ends up cheaper, not more expensive.
Who reads the next alert?
Back to the shared mailbox from the beginning. The bitter part of that story is not that anything was missing. Licence, sensors, alert: all present, all paid for. What was missing was a name. A person who understands the alert as their task, with a deadline and the right to lock an account without asking three people first.
If you want to know where your company stands, you do not need a project for that. Take the last security alert your environment generated and trace its path: who saw it, after how much time, and what was decided? The result of this one exercise says more about your detection capability than any datasheet.
The possible findings sort themselves out. If you find the alert together with a recipient, a response time and a decision, your monitoring works, no matter how modest the technology behind it is. If you find the alert but no human who read it, you now know your real construction site, and it costs no licence fee. And if you find no alert at all even though the business has been running for months, that too is an answer: either your environment is configured suspiciously quiet, or nothing is being reported at all. Both are things you want to know before an incident answers them for you.
And if it turns out that nobody knows the answer: that is exactly what we are here for. In a no-obligation initial conversation we look together at what you already have and where the gap is.
We are honestly curious: when was the last time an alert at your company led to someone changing something on the same day?
