On a traditional server, we might think of “the disk” as the main source. In the cloud, evidence may reside in logs, snapshots, APIs, identity services and records managed by the provider.
What changes
Preservation depends more heavily on prior configuration, permissions, retention and exports. If a log was never enabled, no forensic tool can invent it afterwards.
Forensic readiness is designed before an incident: logging, time synchronization, retention, access and export procedures.
The record of an operation is distributed
In an organisation’s own infrastructure, it often seems intuitive to look for system files and disks. In cloud services, a single operation may leave traces in the identity provider, API call logs, the object storage system and the monitoring platform. If someone changes an access policy, the decisive evidence may be an administrative request linked to an identity and a specific moment, rather than the contents of a file. The first step is to identify which services were involved and which records they routinely produce.
A junior practitioner can begin with a simple model: the identity requesting the action, the affected resource, the service carrying it out and the place where the event is recorded. Next, they should check the time zone, clocks, request identifiers and retention period. An apparently inconsistent sequence may result from different timestamps or records arriving late. Reconstructing an incident is not the same as sorting screenshots by the time displayed on the investigator’s computer.
Preserving without unnecessary modification
When exporting records, it is advisable to document who obtained them, from which account, with what permissions, the period they cover and how the resulting files were protected. A hash can help detect later changes to a particular export, but it does not prove that every event was correctly generated by the provider. It is also important to record the search filters and queries used: two people may obtain different results if they query different regions, accounts or time intervals.
Snapshots and volume copies may be useful in some services, but they do not replace control-plane logs. On managed platforms, the customer may not even have access to a complete system image. It is therefore advisable to prepare procedures suited to each service and verify that they can be carried out promptly, without granting unrestricted administrative permissions to every member of the response team.
Preparation before an incident
An investigation often fails because of earlier decisions: logs disabled to save costs, retention periods that are too short, or accounts without permission to access evidence when an incident is detected. Designing forensic readiness means balancing coverage, privacy, costs and operational needs. Not every event should be kept indefinitely, but retention decisions should be based on risk and the organisation’s actual obligations.
A tabletop exercise can simulate a deleted resource, a change in permissions or anomalous access to data. The team should demonstrate where it would look for the facts, how long recovering them would take and how exports would be documented. This exercise can reveal gaps while they can still be corrected. In the cloud, readiness is less about physically possessing a machine than understanding the architecture and the limits of observation offered by each service.
Limits on what can be demonstrated
The evidence available determines which conclusions can be supported. If the provider records who changed a policy but does not retain a record of every file read, it may be possible to reconstruct a permission change without knowing with certainty who accessed the content while it was exposed. That limitation must be recorded. Gaps should not be filled with conjecture presented as fact. It is also necessary to distinguish records obtained directly from the service from summaries produced by a monitoring dashboard, as the latter may apply filters, aggregations or delays. A useful report explains which sources were examined, the periods they cover and which actions fall outside their observation.
What to communicate to non-technical decision-makers
In an incident meeting, nobody may need the details of every API call. They do need to understand which resource was affected, what evidence is available and which parts of the account remain uncertain. A clear way to report is to separate confirmed facts, plausible hypotheses and checks still outstanding. It is also useful to indicate whether records may be lost when their retention period expires. Precision does not mean presenting an excess of technical data; it means enabling others to make proportionate decisions about security, continuity or legal obligations.
A reproducible investigation
To allow someone else to review the work, it is important to preserve resource identifiers, search queries, time intervals and the export format. A report that merely states “the logs were analysed” does not make clear what was checked. It is also useful to distinguish the initial extraction from later searches performed on a copy. Reproducibility does not mean that every observer will always obtain identical information from a dynamic service; it means documenting the method sufficiently to assess its results and recognize when a source is no longer available.
An administrative change in the cloud
An administrative account changes permissions in a cloud service. There is no physical disk that can be removed and handed over to a laboratory. The activity is distributed across identities, APIs and provider logs.
Preservation may require exporting control-plane logs, retaining identifiers and time zones, taking snapshots supported by the service, and recording which tools and permissions were used.
The contract, retention periods and previous configuration determine what evidence will be available when an incident occurs.