The IT director of a logistics company brings a SIEM console to a board meeting: seventeen log sources, correlation rules from the integrator, retention measured in months. A question comes from the room that was not on the agenda: “and who actually watches this?”. The answer — “alerts go to the infrastructure team’s mailbox” — sounds sufficient until it has to be repeated three months later, at a table that now seats a lawyer and a forensic expert. The alerts really were arriving. The first of the series landed in the mailbox on a Friday after five.
This text is not another SIEM definition — if you are looking for the basics, we covered them in the article on what a SIEM is and how it works. One boundary interests us: between what the tool does on its own and what requires a person with the authority to decide and a clock running overhead. That boundary is not a matter of opinion or of deployment maturity. It runs exactly where activities performed on data end and activities performed on responsibility begin.
Does a SIEM detect incidents on its own?
It does not — it produces the grounds for detection. The difference is operational rather than semantic: a SIEM turns a stream of events from many systems into a smaller set of suspicious events. What happens to that set next no longer follows from the tool’s configuration.
You can see this in the structure of the NIST recommendations themselves. SP 800-61r3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management (April 2025), names SIEM and SOAR as tools for analysing events (element DE.AE-02) and for correlating data from multiple sources (DE.AE-03). Right beside them it places a separate requirement — DE.AE-06 — phrased like this: “Generate alerts and provide them to cybersecurity and incident response tools and staff (e.g., the SOC and incident responders)”.
Staff are listed separately from tools because they serve a different function. An alert that is generated and delivered to nobody closes the first half of the requirement and leaves the second open. In post-deployment documentation the two look identical: there is a rule, there is an alert, there is a log entry.
The distinction that matters: the tool answers the question “did something happen”. The question “is this an incident and who is going to handle it” is answered by the organisation. The second question cannot be configured.
Which jobs does a SIEM do by itself, and which are not in the licence?
It does four things by itself, and does them well: it collects logs from distributed sources, normalises them into a common format, correlates them according to defined rules, and retains them for a set period. That is real work which cannot be done by hand, and it is the reason buying a SIEM is a sound decision.
What stays outside the licence is another four: maintaining the correlation rules, triage and escalation within a defined time, the business context of assets, and post-incident activities together with evidence for an auditor. We unpack each of them separately in this text, because each carries a different cost and a different route to closing it.
Note that this split is visible even in the standard that describes log collection itself. CIS Critical Security Control 8 is titled Audit Log Management and comes down to a single sentence: “Collect, alert, review, and retain audit logs of events that could help detect, understand, or recover from an attack” — Center for Internet Security, description of Control 8. Of those four verbs, two are machine activities, one is a human activity, and one depends on a retention policy that a human also sets.
Why is an alert with no recipient not a detection?
Because detection is an event in the organisation, not in the system. Until somebody has picked the alert up and given it a status, nothing has happened as far as the process is concerned — even though a complete set of evidence is sitting in the SIEM database.
There are two consequences and both are expensive. The first concerns time: the regulatory clock and the attacker’s clock both run from the event, not from the moment somebody looks at the console. We develop the measurement of that delay separately in the article on SOC metrics: MTTD, MTTR and security KPIs; here it is enough to note that a time-to-detect metric measured without staffing measures office hours, not organisational capability. How to break that time into segments and which lever applies to each one is settled in a separate article on how to reduce mean time to detect (MTTD) — this article answers the question “why”, that one answers “how to measure and shorten”.
The second consequence concerns evidence. A shared mailbox has no statuses, no assignment, and no record of the decision to dismiss an alert as a false positive. After an incident there is no way to reconstruct from it who saw what and why they concluded nothing was happening. That gap closes only with a process that assigns work to named people — regardless of whether an in-house team or a provider runs it.
Why do correlation rules age faster than you assume?
Because they describe techniques, and techniques change. A rule written at deployment is a snapshot of what was known on the day it was created — it keeps working correctly, it simply covers an ever-smaller slice of what attackers actually do.
The scale of that change can be checked without any vendor report. MITRE ATT&CK publishes catalogue releases on a half-yearly cycle: the version history shows April and October releases going back to at least 2019, and the most recent one — v19.2 of 6 August 2026 — is an out-of-cycle release added between the scheduled ones. That single release adds the ShinyHunters and TeamPCP groups to the catalogue, along with the Kali365 phishing kit that harvests OAuth tokens and session cookies.
Rule maintenance is therefore not “post-deployment fixes” but a standing entry in the calendar. Somebody has to read the catalogue releases, translate new techniques into rules for a specific environment, measure the share of false alarms, and switch off rules that have stopped discriminating. Without that, a SIEM does not fail visibly — it simply grows quieter, and quiet looks exactly like safety.
A practical note: check the date of the last change to your correlation rules and compare it with the release date of the ATT&CK catalogue your team works against. If the gap is measured in years, you have your answer about the effectiveness of the monitoring without running any test at all.
Who is supposed to decide that an alert is an incident?
A person with explicitly granted authority — and that is not a formality. Under element DE.AE-08, NIST SP 800-61r3 requires the organisation to hold defined criteria for declaring an event an incident and to apply them to analysed activity, taking known false positives into account. The criteria are a document belonging to the organisation, not a setting in a console.
On top of that comes element GV.RR-02, which requires roles, responsibilities and authorities to be documented in policies and requires the appropriate people to be given the authority needed to carry out their tasks. The document explicitly allows some of those roles to be held by third parties working under contract — it does not demand an in-house team, it demands a named recipient.
In practice the most common mistake is treating the severity field in the SIEM as the qualification criterion. The vendor’s scale describes the characteristics of a rule, not the weight of an event in your organisation, nor thresholds arising from legislation. We covered the separation of those two things in more detail in the context of regulatory requirements, in the article on whether a SIEM is enough for NIS2.
Why can the order of handling alerts not be first come, first served?
Because resources are finite and events do not arrive in order of importance. NIST puts this plainly under the RS.MA category: “Because of resource limitations, incidents should not be handled on a first-come, first-served basis”. The same passage calls risk evaluation and appropriate prioritisation “perhaps the most critical decision points in the incident response process”.
Prioritisation needs inputs that the alert itself does not contain. Element RS.MA-03 names them specifically: the scope of the event, its likely impact, how time-critical it is, and resource availability. Three of those four quantities come from outside the SIEM — from the service register, the map of business dependencies, and the duty roster.
The earlier stage, triage, is described by element RS.MA-02: a preliminary review of the report, confirmation that an incident has in fact occurred, and an estimate of its severity and urgency. That is analytical work performed under time pressure, not clicking through a console — and it is what decides whether a four-in-the-morning alert is set aside deliberately or by accident.
How is a SIEM supposed to know which asset is business-critical?
It has no way of knowing until somebody tells it. A SIEM knows the IP address, the hostname, the account and the process. It does not know the customer contract, the penalty for downtime, or the fact that a server with an uninformative name issues invoices for the largest client.
NIST addresses this under element DE.AE-07, requiring contextual information — including asset inventories — to be integrated into event analysis alongside threat data. An asset inventory with an assigned business owner and a criticality class is therefore part of the detection capability, not tidy-up documentation.
This is where the most frequently overlooked maintenance cost sits. An inventory goes stale on its own: virtual machines multiply, services migrate, owners change after a reorganisation. Updating it is organisational work that somebody has to have written into their responsibilities — otherwise, a year later, an analyst gets an alert from a host that nobody can say may be cut off from the network.
What is left after an incident that a SIEM will not produce?
Three things are left: establishing what happened, feeding conclusions back into the configuration, and evidence for a third party. The tool produces none of them.
Establishing what happened is described by element RS.AN-03 — reconstructing the sequence of events and identifying which assets and resources were involved. A SIEM supplies the material; the reconstruction and the root cause are the product of analytical work. The conclusions then have to travel back into the process: the ID.IM category in the same document requires improvements to be derived from actual incident handling, from exercises and from tests, and plans to be updated accordingly.
Evidence for an auditor is a separate category altogether. A supervisory authority or an insurer does not ask for a console screenshot but for who took which decision and when, on what basis, and how the escalation ran. Records of that kind are created in a ticketing system and in a procedure, not in the SIEM — we develop the regulatory context in the article on why a SOC is practically essential for KSC and NIS2 compliance.
What does an unmanned SIEM really cost to run?
It costs the full price of the tool and delivers zero detection value — with one addition that never shows up in the spreadsheet: a false sense of coverage. A board that has seen the console on a slide stops asking about staffing.
It is worth doing the time-coverage arithmetic before sitting down with a provider. Round-the-clock operation means 168 hours a week. One full-time role covers roughly 40 hours, so the arithmetic alone gives more than four full-time roles to staff a single duty position — before you add leave, sick days, training, turnover and a second person on the night shift, without whom there is nobody to check a decision. On top of that come roles that shift work does not cover: a correlation-rule engineer and someone running post-incident activities.
That is the right figure for comparing offers — not the licence price. The cost structure of deploying and running the platform itself is laid out in the article on building a SOC: costs and technologies; what matters here is only that the “people” line is not an add-on to the “tool” line but its precondition.
Which of the three routes should you take: in-house team, managed service or hybrid?
The choice depends on three variables: the time coverage you need, the availability of skills in your labour market, and whether knowledge of the environment has to stay inside the organisation. The table below organises the decision by those variables rather than by company size.
| Decision criterion | In-house team | Managed service | Hybrid model |
|---|---|---|---|
| 24/7 coverage | requires full shift staffing and cover | built into the contract, verifiable by report | nights and weekends on the provider’s side |
| Knowledge of the environment | highest, and grows over time | requires onboarding and updates as things change | contextual knowledge stays inside |
| Correlation-rule maintenance | requires a dedicated engineering role | on the provider’s side, written into the scope | split: generic rules with the provider, specific ones with you |
| Time to go live | measured in quarters: recruitment and training | measured in weeks: connecting the log sources | depends on the scope of handed-over tasks |
| Effect of staff turnover | one departure opens a gap in the roster | the contract and service level carry the risk | gap limited to roles kept in-house |
| Evidence for an auditor | your own procedure and records | provider reports plus your own records | split — needs the boundary written down explicitly |
| When it makes sense | large scale, full control required, skills available | duty coverage cannot be staffed, fast start needed | a daytime team exists, nights and weekends are missing |
If the second or third column comes out of that table for you, the next step is to settle the scope and response times in a contract — that is what a 24/7 SOC service is. Two things are worth resolving straight away, because they are the ones most often left unsaid: who takes the decision to cut a system off from the network, and who prepares the material for a regulatory report.
Scope of this table, made explicit. The comparison above settles the choice of route from the tooling side: what happens to correlation rules, to staffing and to knowledge of the environment once you already run a SIEM. It does not set out the split of duties inside the “managed service” column — that is a separate question, because even the broadest service leaves the customer with obligations that cannot be handed over. Those are set out in the article on SOC as a service for mid-sized companies: the responsibility matrix, the “authority to act on behalf of the organization” (NIST SP 800-61r3’s wording, section 2.2) and the NIS2 reporting duty. The third text in this family is the cost analysis of the in-house and managed models — there, and only there, do we give the economics.
How can you check in a week whether your SIEM has an operation behind it or only a licence?
Seven questions and one test are enough. Collect the answers in writing — the difference between a spoken answer and a written one is the whole value of this exercise.
- Who by name receives an alert at three in the morning on a Saturday, and how long do they have to acknowledge it?
- Where is the threshold recorded above which an alert becomes an incident, and when was it last changed?
- When were the correlation rules last modified, and against which version of the ATT&CK catalogue?
- What share of last month’s alerts was closed as false positives, and who counted it?
- Does the asset inventory have an assigned business owner and a date of last verification?
- Who holds the authority to disconnect a production system, and is it written into a policy?
- Where are the decision records from the most recent event qualified as an incident?
There is one test: ask for a controlled event to be generated on a Friday after hours and measure how long it takes for a human to respond. What you are measuring then is not the tool — it is what you actually bought. If the answer arrives on Monday morning, you own a log store with a notification feature rather than a detection capability, and you already know which of the four missing pieces to close first.
