Data Retention and Deletion

Access requests and pre-contract correspondence

• Purpose: Answer and qualify a workspace request
• Where it is stored: Google Workspace mailbox and the serverless endpoint logs
• Deletion trigger: End of the commercial conversation
• Retention: Target: up to 24 months after the last contact, then deleted or de-identified

Verification status: documented. This is our stated practice; the exact period can be confirmed in writing for your deployment.

Contract, invoicing, and tax records

• Purpose: Perform the contract and meet statutory accounting duties
• Where it is stored: Accounting tooling and contract records
• Deletion trigger: End of the fiscal/statutory period
• Retention: Kept for the statutory period required by Turkish tax and commercial law

Verification status: requires verification. This period is not yet asserted as a guarantee. Confirm the current value with us in writing before relying on it in a review.

Site technical and security logs

• Purpose: Operate, secure, and abuse-protect the site and endpoint
• Where it is stored: Hosting provider logs
• Deletion trigger: Rolling operational window
• Retention: Target: short window, typically up to 90 days, unless held for an active investigation

Verification status: documented. This is our stated practice; the exact period can be confirmed in writing for your deployment.

Workspace administration and audit records

• Purpose: Administer the tenant and preserve accountability
• Where it is stored: Tenant PostgreSQL; immutable audit store
• Deletion trigger: End of subscription
• Retention: Immutable audit events are excluded from tenant erasure and kept for the agreement term and any legal hold

Verification status: configuration-observed. The behavior below was observed in product code or configuration and is exercised by the product’s own tests.

Customer assessment content (targets, source, findings, evidence)

• Purpose: Provide the authorized assessment
• Where it is stored: Tenant database and configured object storage
• Deletion trigger: Termination or customer deletion instruction
• Retention: Tenant erasure deletes resolved tenant records, session directories under the configured sessions root, and configured objects. Backup copies are outside this workflow; see the Backups row below.

Verification status: configuration-observed. The behavior below was observed in product code or configuration and is exercised by the product’s own tests.

Backups

• Purpose: Recover the service after loss or corruption
• Where it is stored: Cloudflare R2 (EU) via rclone; additional encrypted cloud storage in the EU used for PostgreSQL dumps
• Deletion trigger: No automated deletion
• Retention: Backups, including PostgreSQL dumps, are retained separately and are not deleted by tenant erasure. A retention period and purge process are not yet defined; a restore can reintroduce erased records. Additional backup providers must be named in the DPA before customer data is processed.

Verification status: requires verification. This period is not yet asserted as a guarantee. Confirm the current value with us in writing before relying on it in a review.

Agentic run records and session directories

• Purpose: Agent-assisted triage and follow-up
• Where it is stored: Tenant database and execution filesystem
• Deletion trigger: Run completion
• Retention: Observed cleanup: run records and phase artifacts after ~24h, session directories after ~48h; provider-side retention to be confirmed

Verification status: configuration-observed. The behavior below was observed in product code or configuration and is exercised by the product’s own tests.

AI-provider input and output (where enabled)

• Purpose: Model-assisted analysis
• Where it is stored: Configured AI provider and Guard-side records
• Deletion trigger: Run completion and provider policy
• Retention: Depends on the enabled provider and account settings; not asserted until confirmed

Verification status: requires verification. This period is not yet asserted as a guarantee. Confirm the current value with us in writing before relying on it in a review.

What the retention periods do and do not mean

• Verification labels are deliberate. CONFIGURATION-OBSERVED means we found the behavior in product code or configuration. DOCUMENTED means it is our stated practice. REQUIRES VERIFICATION means we do not yet assert the period as a guarantee and you should confirm it in writing.
• The 365-day report setting is not a hard-delete timer. It controls report inclusion and export guidance; findings follow a state machine rather than being hard-deleted in ordinary use.
• Agentic cleanup is a target, not a synchronous guarantee. A stopped cleanup loop, a locked file, or an active run can extend it. Tenant erasure is the explicit deletion path.
• Backup copies are not deleted by tenant erasure today. Backups are taken with rclone and retained separately; a retention and purge process is not yet in place, and restore reconciliation is not yet automated. A restored backup can therefore reintroduce erased records.
• Audit and accountability records are intentionally outside ordinary erasure for the agreement term and any legal hold. They are not presented as customer-content deletion.

How deletion works

• Live systems: a delete request removes the record from the live system so it is no longer retrievable through the application or its API.
• Execution filesystem: tenant erasure deletes session directories recorded for the tenant under the configured sessions root. Paths outside that root are refused rather than followed.
• Backups: tenant erasure does not delete backup copies. Backups are kept separately with rclone, and a defined retention and purge process is still required. Restoring a backup can reintroduce records; re-applying completed erasures with “governance erasure-reconcile” is a planned operator step, not yet automated.
• Object storage: assessment evidence stored in object storage is deleted through the tenant erasure workflow where object storage is configured, not only from the database. No object-storage lifecycle or TTL rule is confirmed; erasure is the deletion path described here.
• Immutable records: append-only audit and accountability records are deliberately excluded from ordinary erasure, because they exist to prove what happened. They are kept for the agreement term and any legal hold, then deleted.
• Legal hold: erasure is blocked while a legal hold applies, and the block itself is recorded.
• Erasure receipt: a completed tenant erasure writes an auditable completion event. It also records anything the erasure could not cancel, such as scan work a worker had already picked up, so the record shows what happened instead of only that the request finished.

Your requests

A customer administrator can trigger tenant erasure from the workspace, and can request an export of findings and evidence before erasure. Data-subject requests about assessment content are handled through the customer, who is the controller for that content; we refer such requests to the customer and assist as described in the Data Processing Addendum.