By Olivia Dubois
·
June 20, 2026
If I had to sum up this article in one idea: a GDPR SaaS audit comes down to five simple checks, but many teams miss one or two. That is where the risk starts, especially when data remains in backups, logs, exports, or connected tools.
In practical terms, I need to check:
A few reference points to keep in mind:
The main point I take away is this: a written retention period is not enough. You need a setting in the tool, a clause in the DPA, a process for erasure requests, and dated evidence of what was deleted.
Before going into the detail, here is the logic behind this checklist: inventory, locate, set retention periods, check contracts, then test erasure end to end.
This step links each SaaS application to the record of processing activities and its storage locations. To conduct a serious GDPR audit, start with a complete and structured SaaS inventory.
For each tool, document the purpose, data categories — including special-category data under Article 9 — recipients, the provider's role as a processor under Article 28, any subprocessors where relevant, the expected retention period, and the internal business owner. Also assign one owner per application.
At a minimum, the scope should include:
An audit conducted for a private clinic group showed how much this work can change the picture: an initial list of 47 processing activities grew to 136 after the discovery of unregistered systems, including car-park video surveillance, caterers' biometric data, and the geolocation of outsourced ambulances [1].
Once each SaaS application is linked to the record, move on to a very practical question: where the data is actually located, and how it flows outside the EEA.
For each application, identify precisely where the data is stored: in France, in the European Union, or in a third country. Check the actual location in the tool's configuration rather than relying only on what the contract says [1].
For every transfer outside the EEA, document the legal mechanism used: 2021 Standard Contractual Clauses (SCCs), Data Privacy Framework certification for US providers, or an adequacy decision. For countries without an adequacy decision, a transfer impact assessment (TIA) must be carried out and dated [1].
Also consider less visible data flows. Telemetry, automatic updates, or forced account creation can send data to the provider's home country without making it obvious [5]. This is often where problems begin.
For each transfer, archive the corresponding legal evidence.
| Evidence type | Purpose | Key point |
|---|---|---|
| DPA (Article 28) | Contractual safeguards | Defines the roles and the chain of subprocessors [1] |
| SCCs (2021 version) | Legal basis for the transfer | Used for transfers to countries without an adequacy decision [1] |
| TIA | Risk assessment | Assesses local laws that could require data disclosure [1] |
| DPF certification | EU–US transfers | Active verification on the US Department of Commerce website [1] |
After locating the data, check that retention periods and deletion settings follow the written policy.
A manual inventory often leaves blind spots. Continuous discovery helps reduce this risk.
Avanoo centralizes SaaS discovery, including unregistered tools linked to Shadow IT, to feed the record of processing activities and the data map.
During the audit, review one SaaS application at a time. The goal is simple: verify that each retention period is written down, implemented, and traceable.
Link each data category to a written period, a purpose, and a legal basis. Where no legal text sets a precise deadline, record a period proportionate to the intended purpose.
| Data category | Retention period | Basis / purpose |
|---|---|---|
| Invoices and accounting data | 10 years | Legal obligation (Commercial Code / Tax Code) |
| HR data | Contract duration + 5 years | Statutory limitation period for employment disputes |
| Unsuccessful candidates | 2 years | Period for challenging a recruitment decision |
| Sales prospects | 3 years after the last active contact | Legitimate interest / CNIL recommendation |
| Customer data | 5 years after the last order | Commercial limitation period |
| Technical and security logs | 6 months | Security monitoring and incident response |
| Analytics cookies | 13 months | Consent / CNIL recommendation |
| Video-surveillance images | 30 days | Security purpose, unless there is a dispute |
| Health data | Up to 20 years | Medical and insurance legal obligations |
Once the period has been defined, translate it into concrete rules for use, archiving, and deletion. Otherwise, it remains theoretical.
Three stages must be separated in the life of the data:
The point that is often forgotten is the start date. Without it, the rule does not hold.
For a prospect, the clock starts at the last active contact. For an employee, it starts on the contract end date. For an invoice, it starts at the close of the accounting period. At each stage, record the trigger, the owner, and the evidence that the data moved to the next stage. Without a written trigger, the period cannot be applied.
The rule only carries weight if the tool applies it through its settings.
The record sets the rule. The SaaS application must make it real. You therefore need to check that the periods recorded in the register match the purge rules configured in the tools.
This applies in particular to log rotation and purging, inactive-account deletion, and support-ticket retention.
Avanoo can compare SaaS settings with the periods documented in the record, bringing differences between the written policy and the actual configuration to the surface.
If a discrepancy appears — for example, a CRM retaining prospects for five years instead of three — it must be corrected or justified by a documented exception.
The next step is to check that the contractual clauses and deletion capabilities follow the same logic.
Once the periods are set, move to the practical side. You need to verify that the contract and the tool can actually apply these rules. Without this, the retention policy remains theoretical. It becomes enforceable only if the DPA states it clearly and the SaaS application can execute it.
The DPA must explicitly require several key points:
| Point to check | What to look for in the contract |
|---|---|
| Deletion or return at the end of the contract | A written commitment to delete or return all personal data when the service ends |
| Treatment of backups | A backup purge period after termination, and confirmation that copies are actually destroyed |
| Obligations of subprocessors | A clause imposing the same requirements on the entire processing chain |
| Location of data, support, and access | Identification of hosting regions and the countries from which support accesses the data |
| Right to audit | The controller's ability to verify the provider's practices |
This point is often underestimated: if support staff outside the EU access the data, even remotely, that is an international transfer that must be covered by the contract [4].
The contract is not enough. You also need to see whether the tool does the job in practice.
Check for selective deletion at account and field level, so that the data that must be deleted is removed without deleting data that needs to be kept [6].
Also check that deletion propagates to backups and archives, not just the active database [1]. In plain terms, deleting something in the interface does not mean that everything has disappeared. Test each erasure request through to the backups and record legal exceptions in the request register [1][6].
Avanoo centralizes contractual and configuration gaps to speed up compliance work. The platform automates SaaS mapping and identifies regulatory gaps — GDPR, NIS2, DORA — to surface discrepancies between the written policy and the reality of the configuration [2].
You must then check what the contract does not cover on its own: backups, logs, and exports.
After checking the contract and the configuration, verify what derived copies retain.
Once the active database has been handled, the risk often moves elsewhere: into copies, logs, and exports. This is where many organizations get caught out. They think they have deleted data, while it remains in a backup, a replication system, or an exported file.
A deletion click does not erase backups. You therefore need to test, technically, every erasure process through to replication and archiving systems, then record exceptions in the request register [1][6].
For logs, the CNIL recommends a retention period of six months for connection logs and professional email logs [7]. If your SaaS application or SIEM keeps this data longer without a documented reason, you have a gap to correct.
| Data type | Recommended period | Basis |
|---|---|---|
| Connection logs | 6 months | CNIL recommendation [7] |
| Professional email logs | 6 months | CNIL recommendation [7] |
Once these limits are set, test an erasure request end to end. Not on paper. In the tools, with the actual technical dependencies.
Responding to an erasure request within the GDPR deadline — one month, with a possible extension to two months for complex cases [1][6] — requires a traceable process, not a manual hunt through several applications. The first step is to verify the requester's identity to prevent fraudulent deletion [6].
Then formalize a six-step erasure process:
You must also audit free-text fields in CRMs and HR tools. This is a common blind spot: these fields often contain undeclared personal data that escapes standard deletion processes [5].
If immediate deletion from backups is technically impossible, document the residual data and the planned purge date in the next rotation cycle [6]. In other words, if everything cannot disappear immediately, you must at least know what remains, where it remains, and until when.
Before deleting anything, you need to locate the data and trace the actions.
Avanoo provides visibility into SaaS activity — files, exports, and undeclared usage — so you can identify personal-data locations before starting a deletion process. This view also helps identify unauthorized exports and cross-border transfers that could breach GDPR or NIS2.
"Avanoo gave us full visibility into our SaaS and AI usage, strengthened our security, and helped optimize costs effectively." — Pierre M., CIO, Big Four audit firm [2]
Traceability of deletion actions — who acted, when, and in which tool — matters as much as the deletion itself. Without a tracking log, it is impossible to prove compliance during an inspection.
At the end of this checklist, everything comes down to four simple controls: an up-to-date SaaS inventory, retention periods defined by purpose, verified DPA clauses, and technical settings aligned with the written policy. Add one often underestimated point: control over backups and logs, with rotation cycles set in advance. Above all, maintain complete deletion traceability: erasure evidence, request identifier, timestamp, and approver, without returning deleted data to active environments [1][2][3][6][8].
Evidence of deletion matters just as much as the deletion itself.
For the audit rhythm, the baseline is clear: review the record of processing activities quarterly, then carry out a full annual audit with the DPO and, where necessary, an external auditor [1]. This review checks that retention periods, purges, and deletions remain aligned. GDPR retention compliance is not something you handle once and forget. Every new SaaS application restarts the cycle: map, configure, check, trace.
::: faq
Start with a comprehensive inventory of your SaaS applications. This map helps identify Shadow IT and see which personal data each tool processes, whether or not it has been approved by IT.
Avanoo can help by automating application discovery and data classification. You get a broader view of risks, server locations, and retention practices more quickly. :::
::: faq
This is a well-known technical challenge. If immediate deletion is difficult to implement, set a clear and reasonable retention period for backups. Then tell the user, in writing, that their data will be deleted according to that period.
You also need to define the process. Document the risks and the steps to follow, and keep a record of deletions to replay if a restoration occurs. These backups should be used only to restore the environment. And, of course, the data they contain must be encrypted. :::
::: faq
Set up documented traceability. After each deletion, generate a deletion receipt or certificate containing anonymized data only:
Also keep a separate deletion log for backups and archives. Replay this log after every restoration. In plain terms, if a backup restores data that has already been deleted, the log lets you restart those deletions without delay.
Finally, document any legal exceptions. But be careful: this audit evidence must contain no personal data. :::
Shadow AI Expert & Chief AI Officer
Olivia Dubois is Shadow AI Expert and Chief AI Officer at Avanoo. An HEC Paris graduate and former BCG consultant, she helps enterprises detect and govern Shadow AI and Shadow IT.
See how Avanoo can map your SaaS and AI landscape, reduce risk, and optimize costs. A reliable platform with dedicated human support.
