Preserve the alert and define the question to investigate
Retain the original alert, source, event time, detection time and affected account or hostname where available. Write the specific question: was a request blocked, did an account authenticate, was a setting changed or did an application operation complete? A vague label such as suspicious traffic does not identify what evidence is needed next.
Confirm authority and the system owner before collecting records. If there are signs of active misuse, coordinate the incident decision alongside evidence review; do not delay necessary authorized containment merely to obtain a perfect export. Record any change made during the investigation so later analysis can distinguish original activity from response actions.
Map the layers and their actual coverage
CDN or WAF records can describe traffic evaluated at the edge. Server access logs describe requests reaching that listener. Application and identity records can describe different internal events. A blocked edge request may never appear at the origin, and a cached response may not require an origin request. Missing correlation is a question to investigate, not proof that one layer is wrong.
Record which sources were enabled, what fields exist, the available period and who can export them. OWASP distinguishes application-level security logging from other infrastructure evidence. A single access log cannot substitute for every account, integration or business-operation record. Keep uninspected supplier systems and retention gaps visible in the scope.
| Layer or field | Evidence to retain | Inference to avoid |
|---|---|---|
| Alert provenance | Source, rule, detection time and original context. | The label alone proves an incident. |
| Edge or proxy | Action, hostname and available request correlation. | A blocked request reached the application. |
| Origin server | Observed route, method, response and time context. | HTTP success proves authentication or sensitive access. |
| Application or identity | Relevant account, state change and outcome records. | A familiar IP establishes the person behind the action. |
| Time and linkage | Timezone, clock offset and correlation fields. | Similar timestamps alone prove a causal chain. |
| Coverage | Enabled sources, retention and inaccessible periods. | No recorded event proves no event occurred. |
Align timestamps without pretending every clock is exact
Keep the original timestamp and timezone from each source. Add a normalized working time for comparison, documenting any known offset or uncertainty. OWASP recommends time synchronization and recording uncertainty when synchronization is not possible. Do not silently replace original timestamps with a cleaned timeline that hides how the sequence was constructed.
Use available request or event identifiers and the application context alongside time. Similar paths and nearby timestamps can be leads without establishing the same request or actor. Proxies, retries, queues and asynchronous jobs can create gaps between receipt and business completion. Record the link as confirmed, plausible or unresolved according to the available evidence.
Separate attempted requests, successful actions and attribution
Inspect what a status or action field means for the source. A server can return a success code for a login page without authenticating anyone. A valid login can be separate from a later data export or permission change. Confirm the relevant application outcome rather than use one HTTP field to claim the entire business action succeeded.
An IP address may represent a proxy, shared connection or intermediary; user-agent text can also be supplied by a client. Follow the trusted proxy configuration when interpreting forwarded fields, and avoid attributing activity to a person or country from a single field. Correlate the authorized account and application evidence while retaining the possibility of incomplete or misleading records.
Keep useful originals protected and working copies limited
Preserve provenance, collection time, operator and the source of exported records. Restrict access to original evidence and use appropriately redacted working material for routine collaboration. OWASP identifies secrets and sensitive data that should not be copied into ordinary logs or reports. Existing records may still contain such material and need careful handling rather than casual forwarding.
Agree retention and sharing with the accountable owner under applicable requirements. There is no single worldwide retention period to apply from this guide. If formal evidence handling or specialist forensics is needed, involve the appropriate authorized professional and follow the required procedure. A normal operational export should not be misrepresented as a complete forensic acquisition.
Close with observations, gaps and an owned next decision
Summarize what the evidence supports, what remains a hypothesis and which sources were unavailable. Connect each unresolved question to a next action: configuration review, account investigation, provider request or controlled retest. Preserve the references that let another authorized operator reconstruct the reasoning without receiving an unnecessary dump of customer data.
CyberFixCrew is an Israeli cybersecurity company serving businesses worldwide with practical Israeli knowledge of websites, Cloudflare and digital infrastructure. We can scope technical evidence review and coordinate supported next steps with the system owner. The handover separates observations from conclusions and identifies when broader incident or specialist work is needed.
