GDPR Data Deletion in SaaS: What to Do with Backups, Logs, and Data Held by Contractors

A user deletes their account in a SaaS product. Their profile disappears from the interface, but their email address remains in the error log, a file remains in a backup, and their support history remains in the support system. From the product’s perspective, the account has been deleted; from the perspective of data processing, the process is not yet complete.

This is where the practical complexity of the right to erasure under the GDPR arises. SaaS products store information across multiple systems for different purposes, and some copies cannot technically be modified as easily as a row in the primary database. The company must determine which data actually needs to be deleted, where it is stored, and how to prevent it from reappearing after a system restore.

Deleting an Account and Fulfilling an Erasure Request Are Different Actions

The «Delete Account» button usually triggers a predefined process. A GDPR request additionally requires checking which information relates to the individual and whether there are grounds for retaining some of it after the account has been closed.

For example, the profile and product usage history may no longer be required, but certain payment documents may need to be retained to comply with legal obligations. Data required for a specific dispute may also be retained where there is an applicable legal basis. This does not mean that the entire account may be kept «in case of claims»: it is necessary to determine exactly which information is retained, for what purpose, and for how long, and then restrict its further use.

A request may also concern an individual user within a corporate account that remains active. Deleting the client’s entire database in such a case would be a mistake. The data of the specific individual must be identified without disrupting other users’ access to their information.

For data subject requests, the GDPR requires a response without undue delay, generally within one month. For a complex request, the response period may be extended subject to the applicable conditions and notification of the requester. Therefore, the deletion process must make it possible not only to take the required actions but also to explain the outcome and the limits of deletion to the individual in a timely manner.

Where Data Remains After a Profile Is Deleted

The first technical step is to identify all copies and derivative records associated with the user. In a SaaS product, these may include:

• Production systems: the primary database, file storage, search index, cache, task queue, and exports for internal analytics.
• Operational tools: error and access logs, the support ticketing system, email service, and incident investigation dashboard.
• Backup environments: database snapshots, file copies, archives, and backups held by a cloud provider.
• External systems: analytics, mailing, or support services to which the company transferred data for the operation of the product.

This list does not mean that every record must be deleted in the same way. Its purpose is to ensure that data does not continue to be used in a system that was simply overlooked during the deletion process.

It is also useful to check indirect identifiers. After an email address is deleted, an individual may still be identifiable by an account ID, support ticket number, IP address, or the contents of an uploaded file. Simply replacing a name with a random code does not always make a record anonymous.

What to Do with Backups

A backup is used to restore a product after a failure or attack. In some architectures, deleting a single user’s record from a backup without modifying the entire snapshot is impossible, or such a modification would compromise the integrity of the backup. However, the rule «we do not touch backups» does not resolve the GDPR issue.

A separate procedure for handling backups is required. The company should define their retention period, restrict access, and prevent them from being used for routine purposes. If selective deletion is technically impossible, backups should be deleted according to an established cycle, and information covered by an erasure request should be taken into account during any restoration. The duration of the retention cycle must be justified; indefinite storage of an old snapshot cannot be justified merely by calling it a backup.

The most important check concerns the reappearance of data after restoration. Suppose a user’s profile was deleted on April 10, but on April 15 the database was restored from a snapshot dated April 8. If the restored product is immediately made available to users, the deleted profile will reappear. Therefore, the restoration procedure must include reapplying deletions recorded after the backup was created and verifying the result before the system is returned to normal operation.

In 2026, the EDPB specifically highlighted the issue of companies that do not have procedures for handling erasure requests in relation to backups. The appropriate approach depends on the architecture and risks, but relying solely on automatic backup rotation without taking previously received requests into account is insufficient for a reliable process.

Can Data Be Retained in Logs

Logs help investigate failures, protect the service, and verify actions within the system. Deleting an entire log because of a single record is often impossible or detrimental to the security of other users. However, this does not mean that any log can be retained without limits on its retention period or the types of data it contains.

The first step is to determine exactly what is being recorded in the log. For diagnosing an error, the event time, a technical code, and a limited identifier may be sufficient. An email address, the full text of a request, an access token, or the contents of a user document may be unnecessary. In such a case, the best solution is to change the logging process so that new personal data is no longer recorded there.

For existing records, the purpose, retention period, and possibility of deleting or anonymizing a specific individual’s data without destroying a meaningful part of the log should be assessed. If certain records need to be retained temporarily, access to them should be restricted, their use limited to the stated purpose, and the deletion date documented.

Logs that are automatically sent to a monitoring provider require separate attention. Deleting a record from the company’s own dashboard does not mean that it has disappeared from the provider’s system.

How to Organize Data Deletion by Contractors

A SaaS provider may use external hosting, analytics, support services, and mailing tools. For each of them, it is necessary to know what data is transferred and who can initiate its deletion.

If a contractor processes data on behalf of the SaaS company, the erasure request must reach that contractor through the process established by the contract and technical integration. This may be an API, an administrative panel, or a request to the provider’s support team. A verifiable result is important: the team should understand whether the request has been accepted, which data has been deleted, and whether the action also applies to the provider’s copies.

Not every external recipient acts solely on the instructions of the SaaS company. For example, some payment or other independent services may retain certain information to comply with their own legal obligations. In such a situation, the company cannot promise the user that it has «deleted all data from all partners». The nature of the data transfer should be accurately determined, and the actions taken should be communicated without exaggeration.

A separate risk arises when a contract with a large corporate client is terminated. Its data may be held by several subcontractors at once, while the period for returning and deleting the data is defined in the agreement with the client. The team needs a procedure that covers this entire chain, rather than merely disabling access to the primary account.

What a Practical Deletion Process Looks Like

It is useful to treat the request as a sequence of actions with assigned responsibilities and confirmation of the outcome:

1. Clarify the scope of the request. Identify the individual or account, verify the requester’s authority, and determine whether the request concerns the user’s data, the corporate client’s data, or both.
2. Separate the data according to the grounds for retention. Determine what can be deleted now, what must be temporarily retained, and why. The decision should be made for specific categories of data rather than for the account as a whole.
3. Delete data from active systems. In addition to the primary database, check files, indexes, caches, queues, and derivative datasets. Re-running a delayed task must not restore a deleted record.
4. Initiate actions in external systems. Forward the request to the relevant contractors and record the status of its execution; where necessary, notify other recipients of the data.
5. Handle backups and test restoration. Determine when the backups will be replaced and ensure that the restored system reapplies the deletions.
6. Respond to the requester. Explain what has been done, which information continues to be retained on a specific basis, and how the company handles data contained in backups.

For internal control purposes, it is sufficient to retain a minimal record of the request itself: the date, the decision made, the actions taken, and the response. Such a record helps demonstrate compliance, but it should not become a new indefinite copy of the deleted profile.

What to Check in the Product Before the First Request

Deletion is difficult to manage manually if the same information is recorded across dozens of systems without a common identifier. Therefore, as a SaaS product develops, it is useful to assess each new integration not only in terms of receiving data but also in terms of whether the data can be found, deleted, and its deletion confirmed.

A useful test is to create an account, use the key features, submit a support request, then delete the data and check all related systems. A second test is to restore an environment from a backup in which that account still existed and verify whether it reappears after the restoration procedure has been applied.

Such testing reveals problems that are not visible in the interface: a forgotten search index, a log containing the full contents of requests, or a contractor for whom no deletion command was ever implemented. These details determine whether a SaaS provider can fulfill its promise to the user in practice.