What should be preserved in the first hour after discovering an incident?
Two things, and both take minutes. Suspend log rotation everywhere — endpoint detection and response, firewalls, VPN concentrators, the identity provider, the cloud tenant, and any application logging sensitive access — because retention windows are usually configured to expire data on a rolling basis and will keep doing so while the incident is being triaged. Second, do not reboot, reimage or restore anything that has not been forensically imaged first.
Neither of these is reversible in the other direction, which is what makes them the first hour’s work rather than the first week’s. Almost every other decision — which responder to engage, whether to notify, how to contain — can be made a day later without permanent loss. These two cannot. A written litigation hold covering security telemetry, ticketing, chat and vendor records should follow the same day.
Why does volatile memory matter if the disk is still available?
Because a great deal of modern intrusion activity never touches the disk in a recoverable form. Memory holds the process list as it actually ran, active network connections and their destinations, code injected into legitimate processes, credentials and encryption keys held in cleartext, and the decrypted form of tooling that exists on disk only as an encrypted or packed blob. Fileless techniques that execute entirely in memory can leave a disk image looking close to unremarkable.
All of it is gone at power-off. There is no later opportunity, no partial recovery, and no expert who can reconstruct it — which is why memory capture sits ahead of almost everything else in incident-response guidance, and why we rebooted it to see if that would clear the problem is one of the more expensive sentences in this field.
How long are logs actually kept?
Usually far less time than people assume, and the defaults are what most organizations are running. Thirty days is a common retention setting across security tooling and network devices; some appliances with limited local storage roll over in a week or less under load. Cloud platforms and identity providers apply their own retention by license tier, which frequently differs from the on-premises settings and is configured by a different team.
The problem this creates is arithmetic. Attacker dwell time — the interval between initial access and detection — is commonly measured in weeks or months. When dwell time exceeds retention, the logs covering the initial intrusion have already expired before anyone knew to look, and the surviving record starts partway through the incident. That gap is a recurring feature of these matters rather than an unusual misfortune, and it is one of the strongest arguments for extending retention as a routine measure rather than an incident response.
Which log sources are most often missed?
Identity and cloud sources, consistently. Authentication logs from the identity provider are frequently the only record showing how a credential was actually used — where from, when, and against what — and they are held in a system the security team may not own. Cloud tenant audit logs, administrative activity logs and object-storage access logs each have separate retention and separate configuration.
Beyond those: VPN and remote-access authentication records, DNS query logs, email gateway logs, backup system logs showing what was accessed or deleted, and the logs held by managed service providers and other vendors on the organization’s behalf. That last category is the most frequently overlooked, because preserving it requires somebody to send a third party a written request quickly — and third parties run their own rotation schedules that no hold notice reaches automatically.
What should a litigation hold cover in a breach matter?
Considerably more than email, which is where most standard holds stop. The categories that matter are security telemetry in all its forms, endpoint and server images, network device configurations and logs, identity and cloud audit records, ticketing and change-management systems, internal chat, vulnerability scan history and penetration test reports, risk registers and board materials, backup media, and all vendor and managed-provider records.
Two practical points are worth stating plainly. Chat platforms often have short default retention and are where the frankest discussion of the incident happens, so they need attention early. And a hold notice does not stop automated deletion by itself — somebody has to change the retention configuration in each system, which is a technical task with a technical owner and is the step most often assumed to have happened.
Is it too late if machines have already been rebooted or reimaged?
Not necessarily, and the question is worth answering carefully rather than despairingly. Memory from a rebooted host is gone, but disk artefacts, centralised logs, identity-provider records and network telemetry may all survive independently — and a compromised host is rarely the only place its activity was recorded. Central logging is what rescues most of these situations.
For reimaged machines, the immediate question is what happened to the original media. A drive that was swapped and retained is fully recoverable; one that was wiped and reused is not. Backups taken before the incident, and any images the responders captured before remediation, are the other recovery paths. This is dealt with at length in whether reimaging destroys the evidence.