- NESA does not certify a SIEM product. It expects logging coverage, correlation, retention and a working incident response process, backed by evidence.
- The failure mode is not the tooling. It is deploying a SIEM once and never tuning it again.
- Alert fatigue is a design problem, not an alert-volume problem. Fix correlation and deduplication before adding more sources.
- Automation (SOAR) shortens response time on known patterns. It does not replace an analyst's judgment on anything novel.
- Assessors want proof: retention logs, tuning history, tested playbooks, response time records. Not a dashboard screenshot.
What NESA Actually Expects From a SIEM/SOC
NESA sets baseline information assurance controls for UAE government entities and critical infrastructure, and the logging, monitoring and incident management requirements are usually the section that drives a SIEM/SOC purchase. Those controls generally ask for continuous log collection from in-scope systems, a defined retention period, correlation capable of surfacing anomalous activity, and an incident response capability that can be demonstrated, not just described in a policy document.
None of that is satisfied by installing a SIEM. An assessor does not ask whether you own a platform. They ask to see retained logs from the last audit period, a record of correlation rule changes, a ticket trail showing alerts were triaged, and evidence that an incident response plan has actually been exercised. A licence and a dashboard prove none of that. Ongoing operational records do.
Why the Tooling Is Rarely the Real Problem
Organisations that fail this part of an assessment almost never fail because the platform was wrong. They fail because the SIEM was treated as a one-time deployment rather than an ongoing discipline. Correlation rules get set at go-live and never revisited. Log sources get onboarded and never re-checked when an application changes. The team that built the use cases moves on and nobody owns tuning afterward.
That stagnation has a security cost, not just a compliance one. Attackers change tactics faster than static correlation logic can track. A ruleset untouched for over a year is tuned to threats from over a year ago. Detection gaps widen quietly, and because logs are still flowing and the dashboard is still green, nobody notices until something gets through.
The Gap Between Deployed and Tuned
Out-of-the-box correlation rules exist to get a SIEM running, not to detect anything specific to your environment. They fire on generic conditions and, applied to a real network, generate volumes of noise that have nothing to do with your actual risk. Getting from "deployed" to "tuned" means building correlation logic around your own asset criticality, your own normal traffic patterns, and the specific TTPs relevant to your sector, then revisiting that logic on a schedule rather than only after an incident. A structured approach to this, like the one in a SIEM tuning guide, matters more to the eventual compliance outcome than which vendor's logo is on the console.
Building Detection That Actually Works
Start with what needs protecting, not with what the vendor's default content pack ships. Map the systems in NESA's scope, understand what normal traffic and authentication behaviour look like for each, and build use cases against the threats those specific systems actually face. A SIEM cannot flag an anomaly in a system whose baseline nobody has established.
Platform choice matters less than architecture fit. A deployment that forces a wholesale rebuild of log forwarding, agent rollout and network access to fit the tool is a deployment that will stay half-tuned for years, because every change needs an unplanned project. Products built to correlate across on-premise, cloud and OT sources without a fork-lift migration, such as FortiSIEM, tend to reach a workable tuned state faster than platforms that need heavy custom engineering just to see the whole estate. That is an architecture argument, not a feature-list argument: the platform that ingests your actual log sources with the least friction is the one your team will keep maintaining.
Where Automation Actually Fits
SOAR earns its place on repetitive, well-understood tasks: enriching an alert with threat intelligence and asset context, isolating an endpoint that matches a known lateral-movement pattern, blocking an IP that a threat feed has already flagged. Done well, it compresses the time between detection and first containment action from hours to minutes.
It does not replace the analyst. Automated containment on a false positive is an outage you caused yourself. The workable pattern is automation that acts on high-confidence triggers and immediately routes the case to a human for verification and scoping, not automation that closes the loop unsupervised on anything ambiguous. Orchestration built for that handoff cuts manual enrichment work for Tier 1. It does not cut the number of analysts you need.
Solving Alert Fatigue Without Buying More Tools
An analyst looking at hundreds of alerts a day, most of them noise, stops reading them carefully. That is not a discipline failure, it is a predictable human response to signal-to-noise ratio, and it is how real alerts get missed. The fix is rarely more tooling. It is fewer, better alerts.
Deduplicate before correlating: the same event ingested from three log sources should produce one alert, not three. Suppress known-good activity through behavioural baselining instead of writing an exception for every noisy but benign pattern. Apply risk scoring so Tier 1 only sees alerts above a real severity threshold, and route lower-confidence signals to a slower review queue instead of an interrupt-driven one. Cutting volume through deduplication and tighter correlation is consistently the most effective change available to an overloaded SOC, and it is one every SOC metrics programme should track as a number, not a feeling.
Continuous Monitoring Means Continuous Change
A SIEM that passed last year's audit and hasn't changed since is not a stable, compliant system. It is a system tuned to last year's threats. Rules need scheduled review. Log sources need periodic re-validation, because applications and network topology change underneath them. Detection coverage needs testing against real attack behaviour, not assumed.
Purple team exercises are the direct way to answer whether the SIEM actually catches what it is supposed to catch: run a known attack technique, confirm whether it generates an alert, and fix the gap if it doesn't. A purple team exercise run against your own detection stack, rather than a generic pentest report, is what turns "we have a SIEM" into "we know what our SIEM sees and what it misses." Vulnerability scan output should also feed the SIEM directly. An unpatched, internet-facing system is a known risk the moment the scan finds it, not only after something exploits it.
Incident Response Cannot Be Written During the Incident
Detection without a rehearsed response is a false sense of security. A response plan needs defined roles, clear escalation paths, and containment steps that are specific enough to execute under pressure, and none of that works if the first time anyone reads the plan is during a live incident. Tabletop exercises against realistic scenarios, run on a schedule rather than after something goes wrong, are what separate a plan that works from a document that exists.
What This Looks Like Against a Real Attack Pattern
Ransomware operators, including groups like LockBit, rarely rely on a single loud exploit. A common pattern: a compromised credential, quiet internal reconnaissance, lateral movement over RDP or SMB, escalation to domain admin, and only then encryption deployed in waves. Each stage generates a weak signal on its own: a failed login followed by access from an unusual location, SMB traffic between hosts that don't normally talk, a burst of file renames. None of those, alone, is an alert worth waking someone up for.
Detection rules built around single events miss this pattern almost every time, because no single event looks malicious. What catches it is correlation logic that chains behaviour across a time window and across log sources: this account, this sequence, escalating to privilege it has never used before. That is a use-case design problem, not a licensing problem, and it is the gap most SIEM deployments never close because closing it takes deliberate work rather than default content.
Threat intelligence sharpens this by giving the correlation engine something to check against beyond your own history: known malicious infrastructure and current TTPs being used against your sector. A SIEM that flags an internal system calling a newly reported command-and-control address, before that address has any local history, closes a window pure behavioural analysis leaves open.
What Assessors Actually Ask For
In practice, assessors want documents and records more than they want to watch a dashboard. Retained logs covering the full required period, with evidence the retention setting hasn't lapsed. A change history for correlation rules, showing tuning happened rather than being asserted. A ticket trail for triaged alerts, showing the SOC actually works the queue. A tested incident response plan, with dates and outcomes from the last exercise, not just a document version number. Response time metrics that show detection-to-containment intervals moving in the right direction over time.
None of that is expensive to produce if the SIEM/SOC is being run as an operating discipline. All of it is expensive to reconstruct after the fact if it has been running as a checkbox.
The Actual Decision
If your SOC is drowning in alerts, the next step is deduplication and risk scoring, not another data source. If your incident response plan hasn't been tested in the last six months, schedule the tabletop before you schedule anything else. If your correlation rules haven't changed since go-live, that is the single biggest compliance and detection gap in the environment, and it is the cheapest one to fix. NESA compliance for a SIEM/SOC is not a state you reach once. It is an operating cadence you either maintain or fall behind on.
