Cyber security incident logging sits in an uncomfortable position in most Australian organisations. Everyone agrees it's essential. Few give it the resources it deserves. When a breach or a regulatory inquiry arrives, the absence of useful logs is consistently one of the first things that compounds the damage.
The Australian Signals Directorate's ACSC advisories repeatedly reference logging adequacy as a gap in Australian defensive posture. Yet the operational specifics of what to log, for how long, at what fidelity, and where to store it tend to get glossed over in favour of higher-profile controls like endpoint detection or multi-factor authentication.
Why logging failures matter more than most teams realise
A logging gap doesn't trigger an alert. Nothing breaks. The first sign of a problem is usually a forensic investigator asking for authentication records from six weeks ago that no longer exist.
The 2024 Medibank and Latitude Financial aftermath made this concrete for Australian IT leaders. In both cases, post-incident analysis revealed that the window of attacker dwell time extended far beyond what logs could confirm. That's not unusual. IBM's 2024 Cost of a Data Breach report put the global mean time to identify a breach at 194 days. Most log retention policies keep endpoint and network data for 30 to 90 days, which means the earliest attacker activity is already gone before anyone knows to look for it.
Regulators are paying attention. The Office of the Australian Information Commissioner's Notifiable Data Breaches reports have increasingly cited inadequate audit trails as an aggravating factor in assessed breaches. Under the Privacy Act, organisations must demonstrate what happened to personal data. Without logs, that's not possible.
The four most common logging mistakes
1. Logging the wrong things
Most organisations log what's easy: firewall accept/deny events, system syslog, and Windows event IDs for obvious security events. What gets skipped is more revealing. Authentication events for service accounts, changes to group policy objects, privilege escalation attempts, DNS query logs, and outbound connections from servers running internal APIs are all regularly absent from log pipelines. Attackers know this. Lateral movement inside a network often leaves no trace precisely because the paths taken generate logs no one bothered to collect.
2. Retention periods that don't match threat reality
Thirty days is not a retention policy. It's a compromise between cost and the pretence of coverage. The Essential Eight maturity model at Maturity Level 2 requires at least 12 months of log retention, with the most recent 3 months online and immediately searchable. Most Australian organisations, particularly those in the mid-market, fall short of this. Logs older than 30 to 60 days are either deleted or archived to cold storage that nobody has tested restoring in the last two years.
3. No integrity protection on the logs themselves
A log that an attacker can modify or delete is worse than no log, because it creates false confidence. Write-once log storage, cryptographic signing, or shipping logs to an immutable SIEM destination in real time are the controls that separate useful evidence from compromised evidence. Many teams send logs to a SIEM without ever confirming that the SIEM itself is hardened against the same attacker who may already be on the network.
4. Collecting without querying
This is the most expensive mistake. A log pipeline that ingests terabytes of data with no search capability, no defined queries, and no alert thresholds attached is a storage bill, not a security control. If your team can't run a query asking "which accounts authenticated to this server between 11pm and 3am over the past 90 days" and get an answer in under a minute, your logs aren't functioning as a defensive asset.
What the Essential Eight actually requires
The ASD's Essential Eight framework addresses logging directly through the "audit logging" mitigation strategy. At Maturity Level 1, organisations must log events from internet-facing services and security systems. Maturity Level 2 adds OS, application, and DNS logging, 12-month retention, and protection of log stores from modification. Maturity Level 3 extends that to centralised, time-synced logging with comprehensive event coverage across cloud services, third-party platforms, and privileged access management systems.
The specifics matter. Centralised logging means a SIEM or equivalent aggregation layer, not logs sitting on individual servers. Time synchronisation means NTP-aligned timestamps, without which log correlation across systems is close to useless. Privileged access audit trails must capture both successful and failed events, including those from system and service accounts, not just human logins.
Cloud and hybrid environments add complexity
On-premises logging is hard enough. Cloud environments introduce a new set of defaults that are almost always wrong for security purposes.
AWS CloudTrail, Microsoft Entra sign-in logs, and Google Cloud Audit Logs are all available, but none of them are turned on comprehensively by default, and none of them send data anywhere useful unless explicitly configured to do so. Data plane logging in S3, for example, is disabled by default and can cost real money to enable at scale. Many organisations operating in AWS discover this only when they're trying to determine who accessed a specific bucket six weeks before a breach notification.
SaaS platforms are worse. Microsoft 365's Purview audit logging is tiered. The 10-year audit log retention that regulators are starting to expect from financial services firms requires the E5 licence tier. Organisations running E3 get 90 days by default. Most have never changed that setting.
Practical steps to close the gap
Start with a log coverage audit. Map every system that handles sensitive data, processes authentication, or sits on a network boundary, then confirm which of those systems is actually sending logs to a centralised destination. The gap between what teams think is covered and what is covered is usually large and immediately actionable.
Set retention policy before configuring any new log source. Decide on the minimum retention window based on your regulatory obligations and threat model, then configure storage accordingly. Twelve months is the floor for any organisation subject to the Privacy Act. Financial services, health, and critical infrastructure operators face additional obligations that push that further.
Define a baseline query library. Five to ten saved queries covering the most common attacker behaviours, off-hours authentication, mass file access, new admin account creation, and outbound connections to unusual geographies, will generate more value than any dashboards built to look impressive in a review meeting.
Test log pipeline integrity quarterly. Trigger a known event, then confirm it appears in your SIEM with the correct timestamp and source identifier. This sounds obvious. Most teams last did this during initial SIEM deployment.
The regulatory pressure is real and growing
Australia's Privacy Act reforms, currently moving through Parliament, will lift the accountability bar for organisations that suffer breaches. The proposed amendments include stronger obligations to demonstrate reasonable technical measures, and audit logging is one of the clearest technical measures regulators examine. An organisation that can show comprehensive logs, intact and searchable, is in a materially different position during an OAIC investigation than one that cannot.
The ACSC's incident response guidance is also explicit: teams cannot effectively contain an incident they cannot trace. Logging isn't a compliance checkbox. It determines whether a containment effort targets the actual scope of a breach or a guess.