Review a security vendor's retention claim copy by copy, trigger by trigger. Ask when acquired source, temporary indexes, prompts, model outputs, logs, findings, exports and backups stop being accessible, when each stored copy expires, and what evidence confirms the operation. “Deleted after scanning” may mean a task's working folder was removed while a prompt log, versioned object or backup remains. The answer changes with logging, backup locks, failed tasks, support cases and the chosen AI model. AWS documents, for example, that a simple delete in a versioned S3 bucket creates a delete marker while the earlier object version remains (S3 version deletion).
For counsel, the first job is to make the technical lifecycle legible. The legal conclusion depends on the actual data, roles, agreement and applicable law. Where personal data is involved, counsel should assess the lifecycle and agreement against the relevant provisions of GDPR Article 28, including the handling of retained copies. This article supplies questions and evidence for that review; it does not decide whether a specific vendor has met them.
Identify all forms of the source
Do not stop at the cloned repository. A scanner may create file inventories, task-local indexes, prompt excerpts, model responses, code citations, reports and notifications. These objects differ in sensitivity and lifetime. A report paragraph can disclose a credential or vulnerable route even when the full source tree is gone. An error trace or support ticket can contain accidental source. Ask which records are source-bearing, which are source-derived and which carry only source-free accounting metadata.
Illustrative case; Bayline Software and all periods below are invented. Bayline sends one synthetic repository to a potential vendor. The vendor proposes to delete task-local source when the job ends, keep findings for the subscription term, retain ordinary application logs for 30 days and preserve backups for 90 days. A failed job can last 24 hours before cleanup. The vendor has not yet specified whether model invocation content is logged, how a cancelled job is treated or whether an exported report in a support case follows the same schedule. Bayline should record the known values and hold the missing ones open.
| Copy or event | Illustrative trigger and proposed lifetime | Evidence to request | Review result |
|---|---|---|---|
| Acquired repository files and task-local index | Job terminal state; cleanup expected within 24 hours even after failure | Task ID, revision, task-stop record, disk/container cleanup telemetry and exception handling | Proposed, not demonstrated |
| Prompt and model output | Each inference call; period depends on provider mode and vendor logging | Provider, model, effective retention setting per region, invocation-log configuration | Unknown |
| Finding text and source citations | Remain while account is active; customer deletion request starts a separate clock | Record classes, database deletion job and read denial after completion | Contract term needed |
| Application and access logs | 30 days from event | Log-group configuration, payload schema, destination and access list | Check for source leakage |
| Backups and restored copies | 90 days from backup creation | Recovery-point inventory, expiry policy, vault lock and restore handling | Proposed, verify actual lifecycle |
| Support ticket and customer export | Ticket closure or agreed retention event | Ticket system, region, attachments, subprocessors and purge mechanism | Unknown |
The illustrative dates are not benchmarks or recommendations. Replace them with the vendor's real configuration and the organization's approved schedule. A useful retention table names an event and a maximum period for each copy. “We normally delete” is not a measurable trigger.
Ask seven questions that expose the real lifecycle
- What is received? Request the data inventory for full files, snippets, repository metadata, credentials, prompts, outputs, findings, exports and user identifiers. Include content in failed jobs and retries. Have an engineering owner explain how source enters and leaves each component.
- What is retained deliberately? Ask which data the product needs for later reports, reassessment, audit or billing. Separate a customer's chosen report retention from temporary source retention. A source-free job status row and a source-bearing finding section need different answers.
- What is copied incidentally? Examine debug logs, exception traces, request bodies, model invocation logs, traces, support bundles, email and analytics. AWS says Bedrock invocation logging can collect model input and output in CloudWatch Logs or S3 when configured (Bedrock logging). Ask for the vendor's actual setting and all other telemetry paths.
- What controls provider retention? For each model route, request the effective retention mode, model requirement and region. The current Bedrock retention guide describes per-Region and, for some APIs, project settings; leaving a Region unconfigured can fall back to a model default. That provider behavior is separate from copies the vendor itself writes.
- What starts the deletion clock? Is it scan completion, cancellation, repository disconnection, account closure, customer request or contract termination? Does a failed task have a maximum lifetime? What happens if deletion fails or a queued job still holds a source-acquisition grant?
- Which copies cannot be removed on the ordinary clock? Ask about backup windows, versioned objects, legal holds, immutable recovery points and support evidence. Require the exact retention exception and who can authorize it.
- How is completion proven? Request machine-readable deletion/job status where possible, an access-denial check on live copies, and a dated record of the backup expiry schedule. A policy document without an execution record proves an intended rule, not that this account's data followed it.
Each answer should include an owner and a version date. A new model route or logging feature can change the answer without changing the words on the sales page.
Keep three meanings of “deleted” separate
No longer served to a user. Removing a repository connection or closing an account may stop ordinary reads. That is a valuable access result, but a backup or retained model log may still exist. Ask whether service identities and support roles also lose access.
Removed from the active store. An application may delete current database rows and working files. In S3, versioning changes what a delete means: without a version ID, a delete marker hides the current object while older versions remain; lifecycle rules or version-specific deletion handle noncurrent versions (AWS S3 documentation). A vendor should know whether its source-bearing buckets use versioning and how every version expires.
Expired from retained copies. Backups have independent lifecycles. DynamoDB point-in-time recovery can keep up to 35 days of recovery points (DynamoDB PITR). AWS Backup Vault Lock can block deletion of recovery points before their lifecycle completes, including by highly privileged users once compliance-mode grace time has ended (Vault Lock). CloudWatch Logs retains data indefinitely by default unless a log group has a retention setting; deletion after expiry is not necessarily instantaneous (CloudWatch log retention). These are AWS capabilities and defaults, not claims that the vendor uses them. Inspect the named resources.
Do not equate any of these states with physical erasure of every storage cell. Cloud services abstract media management, and already delivered plaintext cannot be recalled. If a vendor says it will delete an encryption key, ask which data uses that key, whether other copies exist and when deletion finishes. AWS KMS key deletion has a required waiting period of 7–30 days, and a key pending deletion cannot be used for cryptographic operations (AWS KMS deletion). A pending-deletion key cannot service new KMS cryptographic operations, but already decrypted data keys and plaintext copies may survive outside KMS. State the measured effect on each service rather than claiming immediate loss of every read path; “all bytes physically erased” is not established by key status.
Reconcile a deletion receipt with a restore
Bayline's synthetic pilot closes at Day 0, 09:00. The vendor sends a green receipt: “repository disconnected; job cancelled; source deleted.” Counsel asks which operation each verb describes. The following invented timeline exposes three different states:
| Time and copy | Evidence in the fictional packet | Correct status |
|---|---|---|
| Day 0, 09:02: Git connection | New acquisition refused | Future provider access removed for the checked path. |
| Day 0, 09:10: failed task | Task stopped; task-local directory removed | Active task copy cleanup completed as recorded; no physical-erasure claim. |
| Day 0, 09:12: source archive | Delete marker created; earlier object version V1 still listed | Ordinary current read hidden; V1 remains unresolved until version-specific deletion or approved expiry. |
| Day 0, 10:00: findings | Live record deletion receipt and read denial | Removed from active serving store; backup copies separate. |
| Day 1: support attachment | Ticket closed, attachment still downloadable to support | Deletion not completed; closure is the wrong trigger evidence. |
| Day 2: backup inventory | Recovery point RP7 expires on Day 90 under the example schedule | Retained copy scheduled for expiry; no immediate purge promise. |
The vendor corrects the archive process and supplies a V1 removal result. That closes the known versioned object, not RP7 or the support attachment. The ticket owner separately removes the attachment and checks its download path. If the ticket system keeps another retained version or backup, it gets its own row. A single account-level success flag cannot express these outcomes.
A restored row must not silently become an active customer again
At Day 14, an authorized synthetic recovery exercise restores RP7 into an isolated destination. The old finding row returns, as expected from a pre-deletion recovery point. The unsafe next step would be connecting that restored store to the live application before reconciling later deletions and revoked grants.
Bayline asks for a restore procedure that checks the restored data against an independently maintained deletion/offboarding record before serving it. In the example, an opaque account tombstone shows that the account closed on Day 0; the restoration process suppresses or re-deletes the restored content and does not restore its old access grants. Keep only the minimum metadata needed for that reconciliation under its own approved retention rule. A tombstone kept solely inside RP7 would be too old to record Day 0's later request.
The recovery acceptance record is therefore “restored data remained isolated; later deletion and grant changes applied before serving; no customer access restored.” This is an expected outcome for a planned exercise, not a claim that the exercise occurred. If the vendor cannot show this procedure, backup expiry is not the only open issue: accidental resurrection is also unresolved.
Write a receipt that stays true tomorrow
The corrected closeout reads:
“New repository reads stopped at Day 0, 09:02. Active task, live findings, known archive versions and the support attachment have individual completion records. Recovery point RP7 remains retained until its recorded Day 90 expiry; restore access is restricted and later deletions must be reapplied before serving. Provider-retained inference copies remain governed by the separately recorded model policy. No claim of physical erasure is made.”
Schedule the recovery-point expiry readback and retain failures as open work. A configured expiry date is evidence of a schedule; a later resource inventory or provider completion record is evidence about execution. The exact technical and contractual exception must remain visible until that distinction no longer matters. These fictional periods do not determine what any law or customer agreement permits.
Next action: obtain the vendor's lifecycle table for one synthetic assessment and mark every blank as a question with an owner and due date. Continue with how to assess processing location and how to explain model retention settings to procurement.