Insufficient Logging and Monitoring Gaps That Enable Attacker Dwell Time

Logging failures don't cause the breach. They cause everything after the breach to go unwatched. An attacker who gets in through a phished credential or an unpatched service is a bad day. Logging failures don't cause the breach. They cause everything after the breach to go unwatched. An attacker who gets in through a phished credential or an unpatched service is a bad day. An attacker who gets that same foothold and then operates for weeks without a single alert firing is a different category of problem, and the gap between those two outcomes is almost always logging and monitoring.

OWASP tracks this directly. In the OWASP Top 10:2025, the category is A09: Security Logging and Alerting Failures, holding its #9 spot from the prior list but with a name change that matters. The old name leaned on "logging." The new one adds "alerting" on purpose, because a log nobody looks at doesn't stop anything.

Security programs still underrate this category. Only 723 CVEs map to it, with an average incidence rate of 3.91% and average test coverage of 46.48%. Compare that to SQL injection or broken access control: both are visible in scanners as clean, reproducible CVEs that get flagged automatically. Logging gaps don't work that way. There's no CVE number for "the SIEM never got the login failure event." So it gets pushed down the priority list, year after year, even though it's the exact condition that turns a minor compromise into a monthslong incident. Teams that treat this as a checkbox instead of a detection problem are the ones who find out about a breach from a customer, or a regulator, instead of a dashboard.

What attackers accomplish while undetected

The core asymmetry is speed. Global median attacker dwell time in 2025 landed at 14 days, up from 11 days the year before. Part of that increase traces to a surge in cyber espionage activity and to North Korean IT worker infiltration cases, where median dwell time reached 122 days. Four months of uncontested access, in some cases, before anyone noticed anything was wrong.

Attackers are also getting faster at moving from the first compromised host to the second. Average eCrime breakout time, the span between landing on the first machine and jumping to a second one, dropped to 29 minutes in 2025, a 65% acceleration from the year before. The fastest recorded breakout clocked in at 27 seconds. In at least one documented case, data exfiltration started within 4 minutes of initial entry. And in a number that says a lot about how fragmented the criminal ecosystem has gotten, the median time between initial compromise and handoff to a secondary threat group sat at 22 seconds in 2025. Access brokers resell a foothold fast, and the window between compromise and handoff is measured in seconds.

So what happens during those 14 days, or 122, when nobody's watching? A fairly consistent sequence:

• Map the environment through reconnaissance and network enumeration, figuring out what's connected to what, which credentials open which doors, where the data that matters actually lives.

None of that takes sophistication. It takes time. A logging gap is what hands an attacker that time for free, and pretending otherwise is how a routine intrusion turns into a 122-day residency.

The specific logging failures that give attackers their window

Three failure modes do almost all the damage here, and they don't overlap the way they sound like they should. Each produces its own operational consequence beyond a line item on an audit.

Missing logs for security-critical events. OWASP calls this out by name: logins, failed logins, and high-value transactions that either aren't logged at all or get logged inconsistently across systems. Infrastructure logging usually looks fine on paper, server uptime, resource use, disk space. Application-layer event logging sits right next to it, shallow, sometimes disabled, rarely built with abuse cases in mind. Nobody wrote a log line for "someone tried this password 40 times in 90 seconds," because nobody was thinking about that scenario when the login flow got built. Without that data, there's no baseline for what normal looks like, so nothing ever reads as abnormal.

Logs exist but never trigger an alert. OWASP treats this almost as a litmus test. Their diagnostic is blunt: if penetration testing and DAST tool scans run against an environment and don't trigger any alerts, that application has no real-time or near-real-time detection capability. Events land in a log file somewhere, sure. Logging without alerting logic is a filing cabinet. It's a filing cabinet. Someone has to go dig through the record after the fact, and by then the attacker's three systems deeper.

Alert overload that buries the real signal. Here the problem flips. Alerts fire, plenty of them, and nobody can tell which ones matter. 59% of organizations report having too many alerts. 55% deal with too many false positives clogging the queue. 57% say they lose real investigation time to data management problems, just sorting and correlating what's already been collected. A genuine lateral movement event gets triaged at the same priority as a routine warning about a certificate expiring next month. The signal's in there somewhere. It's just standing in a crowd, and nobody has time to pick it out.

What active monitoring changes, shown in dwell-time outcomes

The Sophos 2025 Active Adversary Report, built on 2024 incident response and managed detection and response (MDR) cases, gives one of the clearest before-and-after pictures available. The numbers are stark, and they settle an argument that shouldn't still be open: monitoring without a human watching in real time isn't the same thing as monitoring.

Across incident response (IR) cases overall, median dwell time sat at 7 days. Broken down by attack type, ransomware dwell time was 4 days and non-ransomware dwell time was 11.5 days. Compare that to MDR-managed organizations: ransomware dwell time drops to 3 days, and non-ransomware dwell time drops to 1 day.

That inversion tells the whole story. In IR-only cases, non-ransomware incidents sit undetected longer than ransomware incidents, for a simple reason: ransomware announces itself. Files get encrypted, systems lock up, someone notices immediately. A quiet network breach with no ransom note goes unnoticed. Under active monitoring, though, that quiet breach collapses to a 1-day median, because someone's actually watching the telemetry as it comes in and catching it before it escalates into something worse.

The attack-type distribution backs this up. MDR customers see network breaches, not ransomware, as the dominant incident type: 56% network breaches versus 29% ransomware. IR-only customers see the reverse, with ransomware dominating at 65% of cases. Active monitoring catches intrusions at the network-breach stage, before they get the chance to mature into a full ransomware event. The gap between a 1-day dwell time and an 11.5-day one comes down to one variable: a human watching the alerts as they arrive, not the logs existing somewhere.

Logging posture surfaced by a rigorous pen test

Most penetration tests stop short of the question that actually matters. A tester finds a working exploit, chains a privilege escalation, documents it, moves on. What almost never gets tested is whether that exploit triggered anything on the defensive side. Logging posture goes completely unexamined, even in engagements that otherwise look thorough, and that's the gap a buyer should be pushing back on before signing anything.

A test that covers this ground checks a specific set of things:

Simulated attacks, brute-forcing authentication, escalating privileges, moving laterally, either generate a log entry at the application layer that reaches something alerting a human, or they don't.

OWASP's own diagnostic doubles as a pen test deliverable here. If a full engagement runs and no alert fires anywhere in the environment, that isn't a clean bill of health. That's a documented finding, and a tester who doesn't write it up that way isn't doing the job.

Whitebox access changes what's visible, and it changes it a lot. A black-box tester probing purely from outside the network can confirm an exploit worked but has no way of knowing whether the resulting event landed in a SIEM or got dropped somewhere between the application and the log pipeline. Reviewing source code and cloud configuration directly is often the only way to see that gap. Anyone scoping a test that's supposed to say something about detection should ask for whitebox access up front.

Pen test vendor assessment of logging gaps

A handful of questions, asked before a contract gets signed, separate vendors who treat logging as in-scope from vendors who just run a scanner and call it a day.

• Ask whether they document, after each exploitation attempt, if it triggered an alert in the environment. A no here means logging posture was never part of the engagement, whatever the proposal says.
• Ask what share of the engagement is manual testing versus automated scanning. Vendors who dodge specifics are usually scanner-heavy, and scanners don't evaluate whether detection worked.
• Ask if the report includes findings about monitoring coverage, or only about exploitable vulnerabilities.
• Ask whether they get whitebox access to application code and cloud config, or whether this is entirely external testing.

Ask for a sample report, too. If it has zero observations about logging or alerting behavior, that category almost certainly never got examined, no matter what the sales deck promised.

Proposals that list tool names, Nessus, Qualys, an automated Burp Suite sweep, without describing any manual methodology behind them, usually mean there isn't much methodology to describe, and that pattern counts as an outright red flag rather than a minor concern. Proposals that list tool names, Nessus, Qualys, an automated Burp Suite sweep, without describing any manual methodology behind them, usually mean there isn't much methodology to describe. Flat-fee quotes with no detailed scoping tend to mean an underscoped test that won't run enough attack chains to say anything meaningful about detection. Reliance on CEH-only credentials matters too: the CEH is a multiple-choice exam, it checks knowledge, not hands-on exploitation, and a tester who can't chain exploits together won't generate a realistic attack pattern that reveals a logging gap. No retesting policy after remediation is the last flag, since a vendor with no retest offering has no actual stake in whether the gap ever closes.

Credentials that signal real depth instead: OSCP, which is a hands-on exploitation certification, GXPN (GIAC Exploit Researcher and Advanced Penetration Tester), which covers advanced penetration testing techniques, and OSWE, which specializes in web application exploitation. These sit behind testers capable of running a layered attack chain that actually stresses a detection pipeline instead of just poking at it.

Any finding about a logging gap needs proof attached. A documented attack sequence with timestamps, showing the exploit ran and no alert fired anywhere along the way, gives an auditor something to actually evaluate. "Logging may be insufficient" is a guess dressed up as a finding, and a report that leans on language like that hasn't done the work.

Logging posture mapping to SOC 2, HIPAA, and ISO 27001 requirements

SOC 2. SOC 2's letter stays silent on pen tests, yet auditors expect one anyway. It's typically a key piece of evidence for Trust Services Criteria, especially the monitoring activities under CC4.1. Auditors don't just want to know a test happened. They want to know what it found, what got fixed, and that the sequence is documented in the right order. A test that never looks at logging can't satisfy CC4.1, full stop, because that control asks whether a monitoring program actually works in practice, not whether one exists on paper.

ISO 27001. As of November 2025, ISO/IEC 27001:2022 is the only valid version. The 2013 transition window has closed. The 2022 revision leans harder on continual improvement and risk-driven testing, and logging and monitoring controls sit inside the updated Annex A requirements. ISO 27001-driven pen tests turn up an average of 11.67 vulnerabilities, the highest average of any compliance framework measured, against 7.0 for SOC 2 tests. That gap is notable, though the evidence does not explain its cause.

HIPAA. The Security Rule requires covered entities and business associates to run periodic technical and nontechnical evaluations, particularly after environmental or operational changes. A proposed 2025 update to the HIPAA Security Rule would go further and make annual penetration testing an explicit, named requirement, so this framework is actively shifting, not settled law. For PHI environments, a logging gap carries a double penalty: the breach itself, then the regulatory fallout, since breach notification timelines depend on scoping what happened, and that's impossible without records to reconstruct it.

A single, properly scoped pen test can satisfy SOC 2 CC4.1, the relevant ISO 27001 Annex A controls, and PCI-DSS Requirement 11.3 at once, but only with a vendor who understands all three frameworks well enough to scope the engagement correctly. The cost premium for combining SOC 2 and ISO 27001 scope into one statement of work runs 15 to 30% over a single-framework engagement, comfortably below the cost of running two separate tests through two separate vendors.