Businesses have moved many of the systems they once ran on their own hardware into the cloud. They use services such as AWS, Microsoft Azure and Google Cloud to host applications, manage accounts and store information. Cloud evidence preservation has therefore become part of ordinary legal and security planning.
The move to the cloud has changed more than where businesses keep their data. It has also changed where the evidence of what happens to that data sits.
Consider a security incident in your cloud environment. The security team contains it and patches what it can.
Legal then needs to establish what happened. Which accounts did the attacker use? What information did they reach? When did the intrusion start?
But some logs no longer exist. Nobody enabled others. A managed service provider holds the remaining records.
The organisation now has more than a technical logging problem. It has an evidence problem.
The problem is not unusual. Thales’ 2024 Cloud Security Study surveyed nearly 3,000 IT and security professionals across 18 countries. It found that 44% had experienced a cloud data breach. Another 14% had experienced one in the previous 12 months.
If cloud records disappear before legal needs them, the organisation may struggle to investigate the incident. It may also struggle to make a defensible regulatory decision or prove its version of events later.
Cloud evidence preservation starts with the logs
Security teams use logs to record activity across systems. A log might show an administrator changing a configuration or a user signing in. It might also record an application programming interface call or an attacker attempting authentication.
During an incident, those records help reconstruct what happened.
Under section 15 of South Africa’s Electronic Communications and Transactions Act 25 of 2002 (ECTA), a court cannot reject a data message merely because it is electronic.
When assessing its evidential weight, the court can consider several factors. These include how reliably the system generated, stored or communicated the record. The court can also consider how the organisation maintained its integrity and identified its originator.
South African courts have also considered how electronic records interact with the rules of evidence. Michalsons discusses this in State v Ndiki and others: electronic evidence.
Legal may therefore need more than copied log entries. It may need to explain where the records came from. It may also need to show whether somebody could have changed them and when the organisation collected them.
The legal problem starts when the organisation decides what to log, where to store it and how long to keep it.
Will the evidence still exist when you need it?
Cloud providers do not necessarily keep every useful log for as long as you might expect.
AWS makes 90 days of certain CloudTrail management events available by default. Other activity types require additional logging.
Microsoft Azure also retains its Activity Log for 90 days. More detailed resource logs require extra configuration.
Google Cloud uses different default periods. It also requires customers to enable Data Access audit logs for many services.
The exact settings differ. The legal point does not.
Some records disappear after a set period. Others never exist unless your technical team turns the relevant logging on.
Imagine discovering in November that an attacker may have first entered the environment in June. A 90-day log may show recent activity but tell you little about the start of the compromise.
Changing the settings in November cannot recreate evidence from June.
That is why cloud evidence preservation needs to begin before legal asks for the records.
Missing logs can affect regulatory decisions
The problem becomes more serious when personal information is involved.
Section 19 of the Protection of Personal Information Act 4 of 2013 (POPIA) requires a responsible party to identify reasonably foreseeable risks. It must also establish appropriate safeguards and verify that they work. The organisation must update them when circumstances change.
Section 22 creates a notification duty where there are reasonable grounds to believe that an unauthorised person accessed or acquired personal information.
Our article on notifying the Information Regulator of security compromises explains the practical notification process.
To make that decision, the organisation may need to answer several questions. Which systems did the attacker access? Which accounts did they use? Was personal information involved? Which people did the incident affect? When did the compromise begin?
Logs may provide those answers.
Missing logs may leave legal teams making a regulatory decision with incomplete facts.
The same issue appears under the EU General Data Protection Regulation. It requires controllers to document personal data breaches, including the facts, effects and remedial action taken.
Different laws use different tests, but they all depend on evidence.
That evidence can also feed into a broader information security incident report. Such a report records what happened, the impact, the response and the decisions the organisation made.
Keeping everything forever is not the answer
Logs can themselves contain personal information. This may include usernames, IP addresses, device information and records of employee activity.
Section 14 of POPIA generally prevents organisations from keeping personal information longer than necessary, subject to specific exceptions. The GDPR applies a similar storage-limitation principle.
The answer is therefore not to keep every log forever.
An organisation needs a defensible retention schedule. That schedule should reflect its security, regulatory, contractual and evidential needs.
It also needs a way to stop ordinary deletion when an incident requires longer preservation. The same may apply to a dispute or investigation.
Good cloud evidence preservation balances two risks. The first is deleting useful evidence too early. The second is keeping personal information without justification.
Your provider may control the cloud evidence
A cloud provider, managed service provider (MSP) or software-as-a-service supplier may create or hold some of the logs.
That raises practical questions.
Which logs does the provider create? Who must enable them? How long does it retain them? Can you export them quickly? What happens if legal asks the provider to preserve records immediately?
For South African organisations, section 21 of POPIA already requires written arrangements with operators that process personal information on their behalf. Those arrangements must also address appropriate security measures.
Cloud and security contracts should also address the evidence problem.
They should address log availability, retention periods, customer access and export rights. They should also cover preservation requests, investigation support and access to records when the relationship ends.
A technically capable service may still create problems if the contract does not give the customer enough access or assistance.
Logging is becoming part of resilience
The EU’s Network and Information Systems Directive 2, or NIS2, provides a useful example of where cybersecurity regulation is moving.
A Commission implementing regulation under NIS2 sets detailed requirements for certain cloud providers and data centres. It also covers managed service providers and managed security service providers.
Those requirements include maintaining and reviewing logs. They also require predefined retention periods and protection against unauthorised changes. Relevant entities must record evidence during incident response.
The broader point is resilience.
Organisations increasingly need to detect an event, respond to it and recover from it. They also need to show what happened afterwards.
South African regulation is moving in a similar direction in some sectors. Michalsons discusses this trend in its article on the Joint Standard on Cybersecurity and Cyber Resilience.
A South African organisation may also encounter these expectations through European customers. Contracts and security requirements can therefore create similar demands even where EU law does not regulate the organisation directly.
Create a cloud evidence preservation process
The practical control is not simply a longer retention setting.
Legal, compliance and security should decide in advance which records are likely to matter. They should know where those records sit and how long they remain available. They should also decide who can preserve them when an incident occurs.
For important records, the organisation may need stronger integrity controls.
In simple terms, that can mean storing selected evidence so users cannot easily alter or delete it during the preservation period.
When an incident occurs, the process should allow security or legal to act quickly.
The organisation may need to preserve logs before they expire. It should record their origin and restrict access. It may also need to document who handled them and tell providers to preserve records they control.
The organisation should also decide when preservation ends.
Evidence preservation should not become indefinite data retention.
The key question is whether, six months later, your organisation can still show what happened.
Actions you can take next
Before the next cloud incident:
- Map the logs that matter across your critical cloud and software services.
- Check which logs exist by default and which need to be enabled.
- Compare current retention periods with your incident, regulatory and litigation risks.
- Decide which records need stronger integrity controls.
- Create a cloud evidence preservation trigger for incidents.
- Review provider and MSP contracts for log access, retention, export and preservation rights.
- Document how security should preserve evidence so legal can later explain its source and integrity.
Your cloud logging configuration may look like a technical decision. In practice, it can determine the evidence available to legal long after the security team has closed the incident.
A clear cloud evidence preservation process helps ensure that evidence still exists when the organisation needs to investigate, report or defend what happened.
Engage with us to find out how we can help you review your cloud and incident-response arrangements, develop an evidence-preservation process, review cloud and security-provider contracts, or advise you during a live cyber incident.
