- web-server access and error logs
- WAF, CDN, and load-balancer events
- hosting, SFTP, SSH, and control-panel logs
- WordPress account and audit events
- database, mail, and form records where available
Copy originals without modification, record their timezone and coverage, and calculate a hash. Perform filtering and interpretation on working copies.
Coordinate evidence and privacy
Logs may contain IP addresses, account identifiers, URLs, and content. Retention, access, and deletion require an approved policy.
Rotation, disabled logging, and mismatched timezones create gaps. A useful report records missing sources and the period actually covered.
Which logs should be preserved first?
Start with sources that have short retention or a high risk of being overwritten: temporary hosting views, WAF events, and current web-server logs. Then collect identity, SFTP/SSH, control-panel, database, mail, and application records.
For each source, record the system, export time, covered period, timezone, filters, and known gaps. A screenshot may preserve one warning but cannot replace a complete machine-readable export.
How is the export kept traceable?
Store original exports read-only and calculate cryptographic hashes. Analyse working copies. Record who exported the data, when, from which system, and whether the provider had already filtered it.
Normalize timestamps only in the working dataset. Keep UTC, daylight-saving changes, local server time, and clock drift visible so events are not correlated incorrectly.
What questions can logs answer?
Logs can connect requests, authentication, file transfer, role changes, errors, and outbound actions. They show only what the logging point recorded. An access log, for example, does not automatically prove which PHP branch executed internally.
Coverage and integrity are especially important in a data-exfiltration assessment. The sample report demonstrates how evidence sources and limitations are recorded.