1. Purpose and scope
This policy applies to personal and service data processed by SW11 Software Ltd in operating ZeRaLD, including the Website/account platform, controlled Beta, Community where enabled, server-management/Panel services, Store/platform functions, AI Handoff and Backup where enabled. It should be read with the ZeRaLD Privacy Notice. Customer-controlled data processed under a business customer's instructions may also be governed by applicable data-processing terms and the customer's lawful retention instructions.
2. Retention principles
We do not keep information merely because storage is available. Retention is tied to service operation, security, support, contractual evidence, legal claims and compliance. Where the purpose expires, information is deleted or anonymised unless another lawful reason requires preservation.
Automated pruning runs in bounded batches through ZeRaLD's retention engine. Records covered by an active legal/security or privacy-processing hold are excluded from automated deletion until the hold is explicitly released.
3. Operational retention schedule
AI Handoff ZIP: physical deletion after expiry or revocation, unless held. AI Handoff metadata: 7 days after expiry and only after the ZIP is confirmed absent.
Login access challenges/grants: 1 day beyond expiry. Password-reset records: 1 day. Stale sessions: 1 day after last activity.
Security events: 180 days. Release-download telemetry: 90 days.
Successful server-install attempts: 30 days after completion. Failed server-install attempts: 90 days after completion.
Installation challenges: 1 day beyond expiry. Expired/revoked installation access tokens: 1 day. Expired installation authorisations: 30 days. Expired unclaimed pairings: 7 days. Eligible closed-account pairings: 30-day post-closure period.
Pending beta requests: 90 days. Declined beta requests: 90 days after review. Approved beta requests: 365 days after review.
Beta availability updates: unconfirmed sign-up records 7 days; confirmed subscriptions while subscribed; unsubscribed records 30 days.
Failed queue jobs: 14 days. Aggregate retention-run audit: 730 days.
Staff authority audit: staff-role assignments remain while the role is assigned. Staff authority change events are retained for up to 730 days for access-control and security accountability, then removed through the retention engine unless a documented hold applies.
Support cases: closed cases and their customer-visible messages, attached safe diagnostic context, support-release snapshot, audit records and private attachments are retained for 730 days after closure unless held for a documented legal, security, complaint or privacy-processing reason. Open cases remain while support is being provided. Authenticated requester identity follows the existing closed-account anonymisation process. Update-support exceptions: remain only while their linked installation exists and are treated as support-administration evidence; expired exceptions cease to grant support status immediately and are removed with the linked installation lifecycle. Support operations: internal ZeRaLD engineering Problem records and saved-reply templates are product-operations records rather than customer project records. Problem records are designed not to contain customer project content or unnecessary personal data; links from deleted support Cases disappear with the Case lifecycle. Support email and feedback: support email receipt/thread metadata and customer support feedback are retained with the associated support Case and removed with that closed-case lifecycle unless a documented hold applies.
Community: Community data categories are processed only where the corresponding Community feature has an approved and configured lifecycle. Categories without an approved retention/deletion lifecycle remain unavailable. Where Community is enabled, ordinary member content, private communications, moderation/safety evidence, appeals and audit records follow their approved category-specific lifecycle rather than defaulting to indefinite retention; account closure, anonymisation and any justified legal/security hold are applied according to the owning Community rules.
Resolved privacy-rights requests: 730 days after completion, decline or withdrawal.
Store promotional-credit ledger: retained while the account is active so the Store can maintain an auditable balance. After account closure, eligible credit-ledger records are removed after 730 days unless a documented hold requires longer preservation. Store Credits have no cash redemption value.
Store Beta membership: retained while Store Beta participation or the associated ZeRaLD account remains active. On account closure, active Store Beta membership is ended; eligible operational membership records are removed after 730 days unless held. The separate Store Beta Agreement acceptance remains subject to the applicable contractual/legal-evidence retention period rather than this shorter operational period.
Store feature requests: retained while the account is active so requests can contribute to Store roadmap planning and, where applicable, be linked to a released product. Eligible request records are removed 365 days after account closure unless a documented hold requires longer preservation.
Store Beta feedback: retained while the account is active so feedback can be reviewed against the relevant Store product or integration attempt. Eligible feedback records are removed 365 days after account closure unless a documented hold requires longer preservation.
Active account and installation identity: retained while the account or installation remains active because it is required to provide and secure the service. Core release history: retained as a product/change-control record rather than ordinary user telemetry. Legal acceptance evidence: retained for the applicable contractual/claims evidence period rather than the short operational periods above.
4. Account closure
When an account closes, active access and reusable credentials are revoked. The operational user profile is anonymised after 30 days. Completed, cancelled and expired closure-workflow records are removed after 90 days. Limited closure evidence is retained for up to 2,190 days (approximately six years) to support contractual/legal evidence, unless a documented hold requires longer preservation.
Closure does not silently defeat a valid legal/security hold. Held information is isolated from ordinary deletion for the duration of the hold, while reusable access remains revoked.
5. Legal, security and privacy-processing holds
A hold may be applied where information must temporarily be preserved for a security incident, complaint, fraud investigation, dispute, legal claim, regulatory matter or a data subject's processing-restriction request. Each hold records a reason and can carry a review date. A review date does not automatically release the hold: release must be explicit and auditable.
6. Deletion and anonymisation
Deletion means removing the eligible application record or stored artifact from the active ZeRaLD service, including Community-specific tables and records where applicable. Anonymisation removes the operational identity where the application must retain a non-identifying account shell for referential integrity. ZeRaLD does not delete a Handoff metadata pointer while the corresponding archive still exists; if file deletion fails, the pointer remains so deletion can be retried rather than orphaning customer data.
7. Legal evidence, application logs and provider records
Legal-acceptance records and other core contractual evidence are retained for the minimum period reasonably required for the applicable contractual/claims purpose and are not overwritten when a new legal-document version is published.
Ordinary application logs, transactional-email mailbox/delivery records and infrastructure-provider records do not all live in the ZeRaLD database and therefore do not share a single database deletion rule. SW11 Software minimises those records, applies operational/provider lifecycle controls and does not intentionally retain them indefinitely. Where a provider is responsible for its own security or delivery logs, its applicable service and retention terms also apply.
