When an incident hits, outside forensic investigators usually ask on day one: "How far back do your VPN sign-in logs go? Is auditing turned on for the domain controllers? How long are your Microsoft 365 or Google Workspace audit logs kept?" That is when many companies discover that the firewall only kept logs on the device itself and has long since overwritten them, that cloud sign-in logs only cover the last few days, or that the attacker used admin rights to wipe the server event logs on the way through. Logs you start collecting after the incident only show what happens next, not how the attacker got in.

This article is for IT staff and managers without a large security operations center (SOC) who keep getting asked "do we have logs?". It works back from the investigation: which questions investigators need to answer, which logs answer them, how to make those logs searchable and trustworthy when you need them, and how long to keep them. For preserving evidence during an incident, see the first 24 hours of a suspected breach.

Why work back from the investigation

Based on the incident investigations it handled in 2025, Mandiant reports a global median dwell time (from intrusion to detection) of 14 days, up from 11 days the year before; for cyber espionage and North Korean IT worker incidents the median was 122 days in both categories, and threats such as BRICKSTORM reached dwell times of nearly 400 days[1]. Mandiant notes that against dwell times like these, standard 90-day log retention policies leave organizations completely blind to the initial access vector and the full scope of the intrusion[1].

The joint guidance "Best Practices for Event Logging and Threat Detection", published in August 2024 by Australia's ASD with the US CISA, FBI and NSA and agencies from several other countries, makes the same point: default log retention periods are often insufficient, in some cases it can take up to 18 months to discover an incident, and some malware dwells on a network for 70 to 200 days before causing overt harm; an absence of historical logs frequently hurts incident response[2].

Investigators can only reconstruct what was logged at the time and is still kept today. The questions an investigation most often has to answer map directly onto the logs you need:

  • How did the attacker get in? Logs from VPN and remote access, firewalls, the email gateway and internet-facing services.
  • Which accounts were used, and were privileges escalated? Sign-in and account-change records from identity systems such as AD, Entra ID and Google Workspace.
  • What did they do once inside? Process execution and PowerShell logs on endpoints, plus administrative actions on servers and databases.
  • Where did they connect, and did data leave? DNS, proxy and firewall connection logs, and cloud service audit logs.
  • When did it start? Every one of the above has to be kept long enough, with clocks that line up across systems.

Without answers to these questions you cannot tell which accounts to reset or which data may have leaked, and you will struggle to explain the scope of the incident to regulators, customers or affected individuals.

What to log first, by investigative value

The ASD-led guidance ranks the log sources an enterprise network should prioritize by how likely an asset is to be targeted and the impact if it is compromised. At the top are critical systems and data holdings likely to be targeted, internet-facing services (including remote access), identity and domain management servers, other critical servers, edge devices such as boundary routers and firewalls, and administrative workstations; DNS, web proxies and email servers are on the list too[2]. For cloud services it prioritizes the use of tenant user accounts that access and administer cloud services, administrative configuration changes, the creation, deletion and modification of security principals and permissions, and authentication successes and failures to third-party services via SAML or OAuth[2]. A small IT team can fill the gaps in roughly this order.

Identity: sign-ins, MFA and privileged groups

Successful and failed sign-ins (with source IP) on domain controllers, Entra ID or Google Workspace; MFA methods being added or changed; accounts being created or disabled accounts being re-enabled; and changes to privileged group membership. Attackers almost always pass through the identity system, and these records are the main basis for deciding which accounts need resetting. The anomalies ASD lists include a single IP address trying to authenticate as multiple users, impossible travel (sign-ins from distant locations within a short time), and the creation of user accounts or re-enabling of disabled accounts, especially those with administrative privileges[2].

Edge devices and remote access

VPN sign-in successes and failures with source IP, administrator logins, configuration changes, firmware updates, and outbound connections the device starts on its own. Edge devices are a common entry point and their local logs can be tampered with or wiped, so send them somewhere off the device; details are in the edge device hardening checklist.

Email and cloud admin audit logs

The Microsoft 365 unified audit log, Entra ID audit and sign-in logs, and Google Workspace admin and user logs. Inbox rules, forwarding settings, app consents and mailbox access records needed for business email compromise investigations all live here; see what to do when a company mailbox is compromised. Default retention for these logs is often short; see below.

Endpoints: EDR, or at least process and PowerShell logging

The ASD-led guidance recommends considering endpoint detection and response (EDR), which records process creation events in greater detail and can spot attackers disabling security monitoring, and recommends always enabling detailed logging that includes process creation events and command-line auditing, with script block logging and module logging for PowerShell[2]. On Windows without EDR, at least turn on process creation auditing: Windows records new processes as event ID 4688, but the command line is only captured when both the "Audit Process Creation" audit policy and the "Include command line in process creation events" Group Policy setting are enabled, and both default to "Not configured"[3]. Attackers routinely "live off the land" with built-in tools, and without command lines there is almost nothing that looks abnormal; for background see state-sponsored hackers (APT) and their tradecraft.

DNS, proxy, key servers and databases

DNS query and proxy logs answer "which computer contacted which domain, and when", which is how you find machines talking to command-and-control servers and where exfiltrated data went. Key servers and databases should log administrator sign-ins, permission changes and bulk exports.

Making logs usable: time, centralization, protection, alerts and drills

Having logs is not the same as being able to search them. The ASD-led guidance lists centralized collection and correlation, and secure storage and log integrity, as two of its four key factors for logging[2]. In practice, check five things:

  • Consistent time: use an accurate, trustworthy time source and the same date-time format on every system; the guidance prefers Coordinated Universal Time (UTC), which has no time zones or daylight saving, in ISO 8601 format, with multiple time sources where possible[2]. A few minutes of drift between devices is enough to get the sequence of events wrong when you piece it together across systems.
  • Central collection off the host: some attackers modify or delete local logs to avoid detection, and many network devices have limited local storage and overwrite old logs once it fills. The guidance recommends forwarding logs to centralized, secure storage on a separate or segmented network, restricting the right to delete or modify logs to people with a justified need, and backing the logs up[2]. Put simply, an attacker who gains domain admin rights should not also be able to delete your central logs.
  • Integrity protection: use secure transport such as TLS 1.3 and cryptographic verification so logs cannot be altered in transit or at rest; the SIEM itself is a target and should be hardened and segmented from the general IT environment[2].
  • A few high-value alerts first: rather than ingesting everything and watching nothing, start by alerting on events that someone must look at whenever they occur, such as unexpected clearing of logs, account creation or re-enabled accounts, configuration changes to security or log management software, one IP trying multiple accounts, and impossible travel[2].
  • Practice searching: the guidance lists making logs and logging platforms usable and performant for analysts as one of its aims, and stresses timely ingestion, because delayed ingestion delays detection[2]. Pick a random date four months ago and try to find out who signed in to the VPN from which IP that day and which servers they logged on to afterward. If you cannot, or a log source quietly stopped sending months ago without anyone noticing, you have found a gap to close. This scenario also works well in a tabletop exercise.

How long to keep logs: international benchmarks and Taiwan rules

International benchmarks

The ASD-led guidance does not give a single number. It recommends retention long enough to support cyber security incident investigations, based on a risk assessment of each system and compliant with local regulations; logs that are crucial for confirming an intrusion and its impact should be prioritized for longer retention, storage allocation should be checked alongside retention periods, and logs should be tiered into hot storage (quick to query) and cold storage (cheaper)[2].

US federal rules are often used as a reference point, but they apply only to US federal agencies and have recently changed. OMB memorandum M-21-31 of August 2021 required most log categories to be kept for 12 months in active storage and 18 months in cold data storage, with full packet capture data kept for only 72 hours, and stated that these were minimums[4]. On May 22, 2026, OMB rescinded M-21-31 with M-26-14, noting that retaining vast quantities of logging data without clear utility proved neither operationally feasible nor cost-effective for most agencies; the new minimum baseline is that logs must be actively searchable for at least 6 months after creation and retrievable for a year (for example, restored from an archive or cold storage for analysis)[5]. M-26-14 also lists what logs must at minimum let agencies determine, including the identity used to perform operations, source and destination network addresses, data that was accessed or modified, changes to privilege levels, and the attack vectors used for initial access and lateral movement[5].

NIST's log management guide, SP 800-92, dates from 2006; its revision, SP 800-92 Rev. 1, was released as a draft in October 2023, and NIST says it is still addressing public comments, so it is not yet a final standard[6].

Taiwan rules

  • Regulations on Classification of Cyber Security Responsibility Levels (資通安全責任等級分級辦法): last amended on January 7, 2026; Article 11 requires agencies to apply the controls in Attachment 10, the Information and Communication System Protection Baseline[7]. Its event logging requirements include setting a policy for log recording periods and retention and keeping logs for at least six months; deciding which events to log and logging all functions performed by system administrator accounts; including the event type, time, location and user identity in each log; and timestamps that map to UTC or GMT, with system clocks synchronized regularly to a reference time source. Systems at the "medium" protection level and above must also review logs regularly and protect their integrity with hashing or similar mechanisms, and "high" systems must regularly back up logs to a separate physical system outside the original one[7]. These rules apply to government agencies and specified non-government agencies; see Taiwan's Cyber Security Management Act for who is covered. Other companies are not bound by them but can treat them as a minimum reference.
  • Cybersecurity Control Guidelines for Listed and OTC Companies (上市上櫃公司資通安全管控指引): require monitoring of information systems and related equipment, covering authentication access records (such as failed sign-ins, sign-ins outside working hours, and multiple users signing in successfully from the same source IP), resource access records, important actions, important data changes, detection of attacks and unauthorized connections, functional errors and administrator actions, with appropriate protection for the logs; for remote access they call for keeping a complete audit trail of user operations[8]. The guidelines set no retention period and state that listed companies may adopt them as appropriate to their industry, size and cyber risk[8].
  • Enforcement Rules of the Personal Data Protection Act, Article 12: the appropriate security measures for personal data may include "usage records, trail data and preservation of evidence", in proportion to the protection purpose; the article does not set a retention period[9].

Logs are personal data too

Logs contain account names, IP addresses and sign-in locations; command lines can even include passwords, and once command-line auditing is on, anyone who can read the security event log can see them[3]. The longer logs are kept and the more people can read them, the bigger the impact if they leak. The ASD-led guidance also warns that logs may contain sensitive data and that users should only have access to the logs they need for their work[2]. A workable balance: state the purpose and retention period in your logging policy and delete logs when it expires; restrict who can search logs and record those searches; and keep content you do not need, such as email bodies, out of the logs.

A tiered starting point

Putting this together, treat identity systems, VPN and edge devices, domain controllers and cloud admin audit logs as tier one: searchable for at least 6 months and retrievable for a year or more, which meets both the six-month floor in Taiwan's Attachment 10 and the M-26-14 minimum baseline. If budget allows, keep edge device and identity logs longer still, so they cover intrusions that last for quarters or years; other logs can be kept for shorter periods based on risk. This is a starting point, not a ceiling.

Cloud and SaaS: default retention is shorter than you think

Cloud providers keep your logs for you, but only for a set period; after that they are gone and cannot be recovered:

  • Microsoft Entra ID: audit and sign-in logs are kept for 7 days on the Free edition and 30 days on P1 and P2; upgrading afterward is not retroactive, and data that has already expired cannot be recovered unless it was archived beforehand. To keep them longer, route them to an Azure storage account through Azure Monitor; these logs are also separate from the Microsoft 365 unified audit log[10].
  • Microsoft 365 unified audit log: Audit (Standard) keeps records for 180 days (90 days for records generated before October 17, 2023); Audit (Premium) keeps Entra ID, Exchange, OneDrive and SharePoint audit records for one year by default, and up to 10 years with an add-on license; the Office 365 Management Activity API also lets you pull records into a SIEM and keep them beyond 180 days[11].
  • Google Workspace: admin log events, user log events (formerly the login audit log), Gmail and Drive log events are kept for 6 months, other reports and log events generally for 6 months as well, and administrators cannot change how long the data is available[12].

Compared with the dwell times above, 7 days, 30 days or even 6 months may not be enough. The practical answer is to set up exports now: send cloud audit and sign-in logs regularly to a SIEM or storage you control, administer that storage with accounts separate from your cloud tenant admins, and check regularly that the export has not stopped. When an incident occurs, export these logs first so they do not expire mid-investigation.

Action checklist

  • Take the five questions (how they got in, which accounts, what they did, where data went, when it started) and check each against your current logs: is it recorded, where is it stored, and how many days are actually kept?
  • Confirm the real retention periods for Entra ID, Microsoft 365 and Google Workspace, and set up exports to your own SIEM or storage where you need longer.
  • Centralize VPN, firewall, domain controller and cloud audit logs in a separate system whose permissions are kept apart from everyday admin accounts, so administrators cannot delete them.
  • On Windows, enable process creation auditing with command lines and PowerShell script block logging; if you have EDR, check how long its telemetry is kept and whether it can be exported.
  • Point every server, network device and cloud service at the same NTP time sources, and log in UTC or in ISO 8601 with an explicit time zone.
  • Start with 5 to 10 high-value alerts: log clearing, new or re-enabled admin accounts, privileged group changes, MFA method changes, security software being disabled, and one IP trying multiple accounts.
  • Write a logging policy: what is logged, how long it stays searchable and how long it is archived, who can search it, and how it is deleted at expiry; organizations covered by the Cyber Security Management Act must meet at least the six-month floor in Attachment 10.
  • Run a search drill every six months: pick a date several months back, trace VPN sign-ins and what followed, and add whatever you could not find to your improvement list.
  • When an incident occurs, export and back up the relevant logs and pause anything that would overwrite them before you start remediating; see the first 24 hours of a suspected breach. If you need outside forensic and investigation help, see our incident response service.