You collect logs, but is anyone reading them? SIEM, MDR and 24/7 monitoring

Collecting logs and detecting an attack are two different things. Piling records onto a disk gives you an archive. Detection is the meaningful event surfacing fast enough for someone to act on it. SIEM is the tool half of that job: it centralises scattered records, correlates them, and fires alerts from rules. MDR (managed detection and response) or a SOC service is the human half: the team that looks at the alert at three in the morning, confirms it, and pulls the machine off the network if it has to be pulled. In most companies the missing piece is not the tool, it is the person watching. Mandiant's M-Trends 2026 puts the global median dwell time, the stretch of time an intruder sits in a network unnoticed, at 14 days, and only 52% of intrusions were first spotted by the victim's own detection. The rest were reported to them by someone else. Over the same period CrowdStrike's 2026 report measured average eCrime breakout time, the gap between landing on the first machine and moving laterally, at 29 minutes. The alerts are firing. The distance between the alert and a pair of eyes is the problem.

What "we have logs" usually means

The pattern we run into most often looks like this. The firewall writes to its own disk. Servers keep their own event logs. The mail platform's audit trail sits somewhere in the cloud. The accounting system has its own internal history. Every one of them works, and none of them talk. When a suspicion comes up, four systems get opened separately, the clocks disagree, so the sequence of events cannot be reconstructed, and the piece that mattered most has usually already been overwritten.

The second pattern is quieter. A central platform exists, alerts are generated, and they flow into a mailbox nobody opens on a schedule. In the SOC study Omdia ran for Microsoft in mid-2025 across 300 organisations with more than 750 employees, 46% of alerts turn out to be false positives and 42% are never investigated at all. Those are the numbers from companies that have a security team. Where there is no team, you can guess the ratio.

Which sources first

Projects that try to collect everything burn the budget in the first quarter and drown in noise. The sane order starts where incidents actually happen:

• Identity. Microsoft 365 / Entra ID or Google Workspace sign-in records, failed attempts, denied MFA prompts, admin role assignments, new mailbox forwarding rules. Most breaches today start with a valid account, not an exploit.
• Endpoint telemetry. Without EDR data, reconstructing what happened on a machine after the fact is close to impossible.
• The network edge. Firewall, VPN and remote access logs. Who connected, from where, at what hour.
• Cloud control plane. AWS CloudTrail, Azure Activity, Google Cloud audit logs. A newly minted admin key shows up here and nowhere else.
• The audit trail inside your critical application. Who viewed and who exported which record in the ERP or the finance system. Proof of data theft usually lives in the application log, not the network log.
• Backup and virtualisation management. M-Trends 2026 documents ransomware crews going after backup infrastructure, identity services and the hypervisor management plane before they encrypt anything. In a ransomware scenario, a login record from vCenter is one of the most valuable signals you own.

There is one category that gets skipped almost every time: devices that cannot run an agent. Firewalls, VPN concentrators, management appliances, virtualisation hosts. That is precisely why the operators behind the BRICKSTORM campaign chose them, since on a device with no EDR the log is the only visibility you have. Mandiant measured an average dwell time of 393 days in that campaign.

90 days, 14 days and 393 days

Retention looks like a settings question until an incident turns it into the boundary of your investigation. The defaults are not generous. Microsoft Purview Audit (Standard) keeps audit records for 180 days. The free CloudTrail event history shows the last 90 days. Plenty of firewalls keep nothing at all beyond their local buffer. For a median 14-day intrusion, 90 days sounds fine. For espionage-style activity, M-Trends 2026 measured a median of 122 days, and BRICKSTORM ran to 393. In a case like that, 90 days of retention produces a specific kind of failure: you can see the intruder is inside, and you will never learn how they got in. You cannot find the door to close.

Which is why regulations write down durations. PCI DSS 4.0 requires audit log history to be kept for at least 12 months with the most recent three months immediately available for analysis (10.5.1), and requires daily review of alerts from security tools (10.4.1). In Turkey, commercial public-access providers under Law 5651 must retain access records for two years and preserve their accuracy and integrity. A workable balance in practice: identity and critical application audit trails for at least 12 months, endpoint telemetry 6 to 12 months, high-volume network flow data shorter but hot.

An unprotected log is not evidence

One of the first things an intruder does after reaching a target is clear the traces. MITRE ATT&CK tracks it as its own technique (T1070, indicator removal), and wiping the Windows event log is the best known version of it. If a record only exists on the machine that produced it, whoever owns that machine owns the record too. Central collection is not a convenience, it is an evidence requirement: records should leave the host as they are written, into a store the host's own account has no rights to delete from.

An equally mundane and equally decisive detail: the clock. If systems are not synchronised over NTP and time zones are not recorded, you cannot order events coming from three different sources. An incident with no timeline is an incident with no explanation.

Buying a SIEM is not buying detection

SIEM licensing is usually priced by ingested volume, so the decision to "just send everything" lands straight on the invoice. The bigger issue is that out-of-the-box rules know nothing about your environment. A detection rule that actually works needs three things: an owner (who receives the alert), a threshold (what makes this abnormal here) and a response step (what happens when it fires). Missing any of the three, what you have produced is noise rather than an alert.

A concrete example. "User added to the administrators group" means nothing on its own, because your sysadmin does that legitimately. It becomes meaningful when the alert is matched against a change record. No approved request, real alert. Most of what people call detection engineering is building that kind of context, and it does not arrive with a product licence.

The arithmetic of 24/7

If you want to run monitoring with your own staff, the maths is unkind. A week is 168 hours and a full-time analyst works 40. Continuous coverage needs roughly 4.2 people of capacity, and once you add annual leave, sick days, training, the sensible rule of never leaving one person alone on a shift, and normal turnover, the real number lands somewhere between 8 and 10. That team also has to write detection rules, handle incidents and stay current. For a fifty-person company this does not add up, and yet a fifty-person company can still be attacked at 3am.

MDR exists to close that gap: monitoring and first response go to a provider, while the decision-maker and the process owner stay with you. The choice is commercial rather than technical, and the test is simple. When a suspicious admin login happens at 3am, whose phone rings, and what is that person authorised to do?

Questions to put to a provider

• What exactly does the SLA commit to: time to detect, time to notify you, or time to contain? Get it in minutes.
• Who holds the authority to act? Can the provider isolate a host and lock an account, or only tell you about it? How does the approval chain work overnight?
• What is in scope? Endpoints only, or identity and cloud logs too, and are the network devices that cannot run an agent included?
• Where are the logs stored, in which country, for how long? If the contract ends, in what format is the data handed back? If it leaves the country, how is the transfer structured under KVKK or GDPR?
• Does escalation work in your time zone and your language, and what is the first-contact time?
• How many confirmed incidents get reported in a typical month, and can you see a sample incident report?
• Are the detection rules tested? Is anyone measuring how many rules actually fire during a controlled attack simulation?

What auditors and regulators expect

Turkey's KVKK Article 12 asks for technical and organisational measures, and the Authority's data security guide spells out the expectation: user activity should be logged on a regular basis, access control records and reporting tools should be reviewed regularly, and alerts should be acted on. The practical link shows up in breach notification. If you have to report an incident within 72 hours, the only way to state which personal data was affected is from logs. Without them the notification rests on guesswork, which is both incomplete and risky.

On the ISO 27001 side, two controls sit separately for a reason: A.8.15 covers producing, storing, protecting and analysing logs, while A.8.16 covers monitoring activities to detect anomalous behaviour. An auditor keeps them apart because generating records is one thing and reading them is another. In banking, Turkey's IT regulation puts it in writing: audit trails are to be monitored and analysed through a central log management system, with correlation rules defined and alerting mechanisms established for early detection.

A minimum setup you can stand up in thirty days

Before launching a large platform project, this sequence gets most SMEs half the visibility within weeks. One: inventory the assets and sources, which system produces which record. Two: pipe identity, EDR and firewall logs into a single place. Three: write down the retention decision. Four: build about ten high-value detection rules (impossible-travel sign-in, admin role assignment, successful login after a run of failures, new mail forwarding rule, backup job disabled, event log cleared). Five: attach a one-line response step to every rule. Six: connect it to your incident response plan, because an alert that is not wired into a decision chain is worth nothing.

Here is a test that costs you nothing today. Using your own test account, without trying to bypass multi-factor authentication, sign in to an admin console through a VPN exit in another country and start a stopwatch. How many minutes until an alert fired, who received it, what did they do? If the answer is that nothing happened, your problem is not missing logs, it is that nobody is watching. That is the point where Wedevit works independently: we define which records you actually need and how they should be retained, write detection rules for your environment rather than a generic one, compare MDR proposals without selling a product, and verify with controlled simulation that the rules really fire.