When forensic investigators arrive after a breach, the first request is always the same: show me the logs. What follows that request tends to be uncomfortable. Logs are either missing entirely, truncated at the wrong moment, covering the wrong systems, or stored in a format that makes timeline reconstruction almost impossible. These aren't edge cases. They're consistent findings across Australian incident response engagements, and the pattern has barely shifted in years.
The gap between what organisations think they're logging and what they're actually capturing is where attackers hide. Understanding what forensic teams find missing is a faster path to fixing your logging posture than any checklist.
The most common gaps forensic teams encounter
Authentication events top the list. Investigators routinely find that failed login attempts to VPNs, cloud consoles, and administrative portals were never forwarded to a central log store. The events existed on individual hosts, briefly, before local log rotation removed them. By the time anyone looks, the credential-stuffing campaign that preceded the breach is gone.
Process creation and command-line logging is the second major gap. Most Windows environments log Event ID 4624 for logon events but never enable Sysmon or Windows audit process creation policies. An attacker running a discovery script, deploying a remote access tool, or exfiltrating data via robocopy leaves almost no trace unless process telemetry is explicitly captured. On Linux systems, the situation is often worse: bash history is trivially cleared, and auditd is either absent or logging at a level too coarse to reconstruct what ran.
Network flow data is the third consistent finding. Perimeter firewall logs exist on most networks, but east-west traffic between internal segments is rarely captured. Investigators trying to understand lateral movement need to know which hosts talked to which, when, and on what ports. Without NetFlow or equivalent telemetry from internal switches, that picture can't be reconstructed. This is precisely why network segmentation matters beyond just limiting blast radius: segmented environments with per-segment logging give responders far more to work with.
Why cloud logging gaps are getting worse
On-premises logging problems are well understood. Cloud logging problems are growing faster than most security teams recognise.
The default logging configuration in AWS CloudTrail, Azure Monitor, and Google Cloud Audit Logs covers management-plane events reasonably well. It doesn't cover data-plane events by default. An attacker who compromises an IAM credential and reads thousands of S3 objects, downloads blob storage contents, or queries BigQuery datasets may leave almost nothing in the default logs. Data access logging costs extra. Most teams don't enable it until after the first incident that would have required it.
The second cloud gap is log retention. Default retention on many cloud services sits at 30 or 90 days. Australian incident response engagements frequently begin well outside that window. An attacker with 60-day dwell time, which is not unusual in financially motivated intrusions, will have pre-breach activity that's simply gone. The retention decisions made before an incident determine whether a root-cause analysis is ever possible.
Third: cloud identity logs are frequently not centralised. Azure AD sign-in logs, AWS IAM role assumption events, and Okta access logs often sit in separate systems. Correlating them after the fact requires manual export, normalisation, and timeline merging. Investigators end up doing that work under deadline pressure.
What's missing from endpoint telemetry
EDR coverage gaps are more widespread than procurement records suggest. It's common for forensic teams to discover that 15 to 20 per cent of endpoints in an environment have non-functional or outdated EDR agents, either because of deployment failures, OS compatibility issues, or hosts that were spun up after the last fleet scan. Attackers who gain network access can probe for these uncovered hosts.
Even where EDR coverage is complete, the telemetry is often configured at a reduced verbosity level to manage storage costs or agent performance impact. That trade-off is legitimate. It becomes a problem when no one revisits the configuration after the threat environment changes, and when the verbosity reduction happens to exclude exactly the event types an attacker's tooling generates.
USB and removable storage events are a specific endpoint gap worth naming. Many organisations block USB execution via policy but don't log insert and removal events. Insider threat investigations, which are hard enough without evidence, become nearly impossible when there's no record of what storage devices connected to which workstations during which shifts.
The log forwarding problem
A surprising number of environments collect logs in the right places but lose them in transit. Log forwarding agents buffer events locally and forward them to a SIEM on a schedule or batch threshold. When an endpoint is rebooted abruptly, the buffer is flushed. When a log source generates events faster than the forwarder can transmit, the forwarder drops the tail rather than buffering indefinitely.
This means the most forensically interesting moment, the one right before a breach is detected, is often the moment where log forwarding was most likely to fail. High-volume attack activity generates high-volume logs, which is precisely when forwarding pipelines are most likely to drop events.
Investigators verify forwarding integrity by comparing event counts between source systems and the SIEM. This comparison is almost never done proactively. The gap is only discovered when someone needs the logs and they're not there.
What to check before an incident forces you to
Three checks that don't require a full logging program review:
- Pull a list of log sources registered in your SIEM and compare it against your asset inventory. The difference between those two lists is your blind spot.
- Test log forwarding for 5 high-value sources by generating a known event (a test authentication failure, a policy rule trigger) and confirming it appears in the SIEM within your expected ingestion window.
- Check the retention settings on your cloud audit logs explicitly. Don't assume defaults match your incident response needs.
These checks are fast and routinely reveal gaps that audit reports missed. The goal isn't comprehensive coverage in a single pass. It's removing the specific blind spots that forensic teams document most often.
Australian organisations dealing with a notifiable breach also face regulatory timelines: the obligations under the NDB scheme require notification within 30 days of becoming aware of an eligible breach. That clock is much easier to meet when the evidence base is intact. When logs are missing, legal and compliance teams are left making assessments without a clear factual record, which creates its own category of risk entirely separate from the technical one.
Logging gaps don't announce themselves. They're discovered by investigators who needed something that wasn't there. The organisations that avoid that situation are the ones that ran the same discovery process proactively, before someone else had a reason to.