Shogram / Help and policies
Data Retention and Deletion Policy
Applies to: Personal and Company information processed by the Platform
Summary of changes: Initial retention framework; no retention period is invented.
Contact: [SUPPORT EMAIL] · Privacy/DPO: [DPO EMAIL]
Draft for review. No complete, approved retention schedule was found in the audit. Do not publish until every period, deletion mechanism, backup cycle and legal exception has an accountable owner and has been tested.
In plain words
Shogram should keep information only as long as needed for the stated service, security, legal and dispute purposes. The actual retention periods are not yet approved. Deleting an account may not immediately remove every scan, Report, security record or backup if it must be retained for a defined reason. The final schedule must explain what remains, why, and for how long.
1. Scope and principles
This Policy applies to account, device, scan, Report, Company, KYC, Product, Batch, Code, billing, security, audit, session and backup information processed by [COMPANY LEGAL NAME]. Retention must be tied to an identified purpose, restricted to authorized access and reviewed periodically. No indefinite retention should be assumed.
2. Retention schedule — completion required
The following schedule lists categories found in the application audit. The owner must set and verify each period before this draft becomes effective.
| Category | Proposed trigger | Retention period | Deletion or disposition |
|---|---|---|---|
| Consumer account/profile and preferences | Account closure or last activity | [PERIOD] | Delete, anonymize or retain only fields required for a stated purpose |
| Guest device identifier/history | Last guest activity or device unlink | [PERIOD] | [METHOD] |
| Scan and Code status records | Scan or Code status change | [PERIOD / CODE INTEGRITY RULE] | [METHOD; describe any non-identifying status retained] |
| Consumer Reports and attachments | Report closure or last action | [PERIOD] | Delete or restrict evidence under [RULE] |
| Company account and Product/Batch records | Company closure or Code lifecycle event | [PERIOD] | [METHOD; account for active Codes and legal holds] |
| KYC documents | Review decision or Company relationship end | [PERIOD] | Secure deletion and backup expiry under [RULE] |
| Billing and payment references | Transaction or subscription end | [PERIOD REQUIRED BY COUNTRY/LAW] | [METHOD] |
| Audit, security and session records | Event creation or account end | [PERIOD BY LOG TYPE] | [METHOD] |
| Legal acceptances and publication versions | Acceptance or document retirement | [PERIOD] | Retain minimum record required to evidence version and decision |
| Backups and disaster-recovery copies | Backup creation | [BACKUP CYCLE] | Expire/delete within [MAXIMUM PERIOD] |
The Platform must also document how data in exports, failed jobs, temporary storage, email providers, payment providers and support systems expires. A legal hold should identify its scope, reason, approving role and review date.
3. Account closure and deletion requests
Where account deletion is available, a Registered User may request it through [ACCOUNT DELETION ROUTE] or [DPO EMAIL]. The Platform may verify the request to prevent unauthorized deletion. The final process must explain whether account credentials are deleted, whether identifiers are anonymized, which scans/Reports remain, what a Company can still access and how long the deletion takes: [PROCESS AND TIMELINE — decision required].
The application currently provides a consumer account deletion action and states that some records may be retained or anonymized for security or active investigations. The precise effect must be confirmed against the deletion service before making a broader promise. A deletion request does not automatically delete information held independently by a Company or payment provider.
4. Code status and security records
The service uses single-use Code status. Before publication, the engineering and privacy owners must decide which minimal record must remain to prevent a previously used Code from being treated as unused after account deletion or subscription expiry. The policy must distinguish that status from personal data and describe any retained link to a person, device, Company or Report.
Security logs and records may be retained to detect or investigate misuse, protect accounts, preserve audit integrity or meet law. Each exception needs a defined access control, retention period and review point. Do not use “security” as an unlimited reason to retain all information.
5. Backups and service providers
Backups may retain information for a limited recovery period even after it is deleted from the active database. The backup cycle, isolation, access, expiry and restoration process must be documented. Restored backups must respect subsequent deletion requests where technically and legally possible.
Providers used for hosting, email, payment, file storage or support may hold copies under their own processing terms. List each provider, its role, location, deletion process and contract before publication: [PROVIDER SCHEDULE REQUIRED].
6. Roles and review
The privacy owner and engineering team should review the schedule at least [REVIEW FREQUENCY — decision required] and whenever a feature, law, provider or storage system changes. The review must confirm that automated deletion jobs work and identify any manual queues. No review cadence is set by this draft.
Contact and complaints
Operator: [COMPANY LEGAL NAME] · Address: [ADDRESS]
Privacy/DPO: [DPO EMAIL] · Support: [SUPPORT EMAIL]
How to complain
Send a deletion or retention question to [DPO EMAIL] or use [PRIVACY REQUEST ROUTE — pending]. If unresolved, contact [COUNTRY / PRIVACY REGULATOR — counsel to verify]. Do not send passwords or full payment credentials.
Change log
| Version | Date | Summary |
|---|---|---|
| [VERSION] | [DATE] | Initial draft; periods and deletion behavior require validation and approval. |