BEYOĞLU PROFESSIONAL DATA RETENTION AND DELETION POLICY
BEYOĞLU PROFESSIONAL DATA RETENTION AND DELETION POLICY
Version: 1.0
Effective Date: 1 October 2026
Policy Owner: Beyoğlu Professional — Privacy & Legal
Review Cycle: At least annually and upon material regulatory or architecture change
1. Purpose
This Data Retention and Deletion Policy establishes the rules governing how Beyoğlu Professional retains, archives, restricts, deletes and preserves Personal Data and related business records.
The objectives of this Policy are to ensure that information is:
retained only for a justified purpose;
retained for no longer than necessary;
protected while retained;
deleted or anonymised when retention is no longer justified;
preserved where legal, regulatory or evidentiary duties require preservation; and
subject to documented legal-hold and record-governance controls where applicable.
2. Scope
This Policy applies to Personal Data and associated records processed in connection with:
user accounts and identity;
Client, AR and HQ workspaces;
country compliance accounts;
products, SKUs and packaging;
commerce, order and shipment data;
declarations and submissions;
regulatory obligations and calculations;
documents and evidence;
communications and email;
payments and financial reconciliation;
integrations;
notifications;
audit and security records;
AI-assisted operations;
and related object-storage content.
3. Retention Principles
Beyoğlu Professional applies the GDPR storage-limitation principle.
Retention is determined by the shortest period that remains compatible with the applicable Processing purpose, legal requirement, contractual obligation, regulatory evidence requirement, legitimate security requirement or establishment, exercise or defence of legal claims.
The mere fact that information can technically be stored does not justify indefinite retention.
Different copies or manifestations of the same information may be subject to different retention rules because they may serve different legal purposes.
4. Retention Hierarchy
Where more than one rule applies to a record, the applicable retention period is determined in the following order:
a binding legal or regulatory preservation obligation;
an active legal hold;
an explicit preserveUntil requirement;
an active regulatory/evidence retention policy;
a contractual retention requirement;
the ordinary operational retention rule for the applicable data category; and
deletion or anonymisation once no valid basis remains.
No lower-level deletion rule overrides a higher-level preservation requirement.
5. Retention Policy Model
The Platform supports configurable archive-retention policies.
A retention policy can define:
a policy code;
a retention period expressed in days;
whether the policy is compatible with legal hold;
whether the record constitutes immutable evidence;
and whether the policy remains active.
Documents may also carry a retentionClass.
Evidence may be assigned a retention policy or class and can additionally be governed by legal-hold and preserveUntil controls.
Because these controls are dynamic and can vary by country, obligation and evidence type, this Policy does not falsely impose one universal retention period across every PPWR/EPR record.
6. Retention Matrix
| Data or record category | Retention trigger and rule | Deletion / end-of-life treatment |
|---|---|---|
| Authentication session | 45 minutes from issuance unless terminated earlier | Session expires; logout removes active auth cookies |
| CSRF token | 10 minutes or completion of protected operation | Cookie deleted/expired |
| Workspace cookie | Up to authenticated-session lifetime, currently 45 minutes | Deleted on logout or expiry |
| Temporary OAuth state | Currently up to 10 minutes for inspected Amazon flow | Deleted/expired after authorisation workflow |
| Remembered login identifier | Until user disables “remember”, clears site data or the functionality is reset | Removed from browser local storage |
| Browser sessionStorage workflow state | Browser/session lifetime or earlier application removal | Removed by application or browser-session termination |
| UI layout/preferences | Until changed, removed or browser site storage is cleared | Browser local-storage removal |
| Browser-push installation/subscription identifiers | While browser push remains configured or until removal/reset | Removed on push de-registration or local-storage deletion |
| Active user/account information | Duration of active relationship and legitimate account administration, subject to other record obligations | Eligible account may enter account-erasure process |
| Pre-activation country-service information | Until activation is cancelled, converted or becomes subject to payment/effective regulatory history | Eligible pre-activation records may be physically deleted |
| Product/SKU/packaging operational records | While necessary for active compliance operations and applicable reporting history | Delete/anonymise when no longer required and not linked to retained compliance evidence |
| Placed-on-market / shipment regulatory data | For the period necessary to establish the relevant regulatory reporting and audit history | Delete/anonymise when the regulatory retention requirement expires, unless legal hold applies |
| Regulatory declarations/submissions | Applicable regulatory/evidence retention period | Preserve as regulatory history; deletion only when retention and legal obligations permit |
| Documents and document versions | Active retention class / applicable statutory or contractual requirement | Delete only where no immutable-evidence, retention, preservation or legal-hold restriction applies |
| Evidence artifacts | Applicable retention policy, legal hold, preserveUntil and regulatory requirements | User-facing deletion may archive the record while retaining immutable evidence/history |
| Signed agreements and signature history | Contractual/regulatory recordkeeping period and applicable limitation periods | Retain immutable signed record where legally required |
| Regulatory-payment evidence | Applicable accounting, tax, EPR and evidence-retention requirements | Delete after all applicable obligations expire and no legal hold exists |
| Finance and reconciliation records | Applicable accounting, payment, regulatory and claims periods | Restrict and subsequently delete where legally permissible |
| Communications/email | Operational need and, where linked to a regulatory/contractual record, the retention period of that record | Delete when no longer needed unless incorporated into retained evidence/history |
| Notifications | Operational notification lifecycle and applicable audit need | Soft deletion/archive may occur; physical purge according to approved notification-retention process |
| Audit/security events | Period necessary for security investigation, accountability, fraud prevention, compliance and legal claims | Delete/anonymise after applicable security/compliance purpose and claims periods expire |
| AI audit metadata | Retention applicable to the underlying feature, security audit or associated business record | Delete/anonymise according to the corresponding data category |
| Integration credentials | While integration remains authorised and for the minimum necessary revocation/rotation period | Revoke and remove secret references/credentials when connection terminates |
| Account export package | User-controlled after delivery; Platform need is limited to delivery workflow | Export receipt expires after 30 minutes; export file handling depends on delivery/storage implementation |
| Backup copies, where maintained | Applicable approved backup lifecycle | Aged out through the approved backup lifecycle; not restored for ordinary Processing after a valid deletion except where technically required for recovery |
7. Account Data Export
The Platform provides an account-data export mechanism before account deletion.
The export process identifies database records within the account-owned selection, identifies associated stored binary objects and creates an export archive containing a manifest, database data and relevant stored files.
For account exports, failure to read a storage object causes the export to fail closed rather than silently producing an incomplete export.
After a successful account export, the Platform issues a deletion receipt.
The current receipt is valid for 30 minutes.
A valid receipt is required before an eligible account deletion can proceed.
8. Account Erasure Eligibility
Account deletion is not automatically available where deletion would improperly destroy an active or legally relevant compliance relationship.
The inspected implementation can block account erasure where, among other things:
an activated CCCA exists;
activated/converted CCCA history exists;
an activation fee has been paid;
an activation finance cutover has completed; or
the user belongs to a shared Client workspace that must first be transferred.
These conditions exist to prevent an individual account operation from destroying shared, financial or regulatory records belonging to the organisation or other users.
9. Account Deletion Procedure
Where the account is eligible for erasure and the required export receipt has been validated, the Platform performs a deletion preflight.
The preflight executes the proposed database deletion inside a transaction and intentionally rolls it back to identify referential failures before destructive execution.
After a successful preflight:
associated object-storage items selected for erasure are deleted;
the corresponding Firebase identity is deleted;
the selected database reference closure is deleted in a database transaction; and
the operation returns a deletion result.
This is a physical deletion workflow, not merely a UI-level account deactivation, for records within the eligible erasure selection.
10. Country Activation Cancellation and Erasure
Pre-activation country-service data can have a different lifecycle from an established compliance account.
Erasure can be blocked when:
the activation has already converted;
the activation fee has been paid;
the service agreement has become effective;
a CCCA has been created; or
the financial cutover has completed.
Where none of these conditions applies, the Platform can delete the eligible activation record closure and associated storage objects.
Once the relationship has become effective or financially/regulatorily material, cancellation does not imply that historical evidence can be erased.
11. Documents and Immutable Evidence
Document versions can contain:
a content hash;
storage object reference and object version;
retention class;
immutable timestamp; and
immutable reason.
Evidence records can likewise be associated with retention policies and immutable history.
Where evidence is under legal hold, it must not be destroyed.
Where preserveUntil is a future date, destruction must not occur before that date.
Where an active retention class defines a retention period that has not expired, destruction must not occur before expiry.
12. Archive Is Not Necessarily Erasure
For regulatory evidence, a user action labelled “delete” may legally and technically mean archive rather than physical destruction.
The currently inspected Evidence Vault flow archives an evidence item and expressly retains immutable artifact bytes and audit history.
Accordingly, the Platform must not represent an archive operation to users as irreversible physical erasure.
13. Legal Hold
A legal hold suspends ordinary deletion where information may be relevant to:
litigation;
regulatory investigation;
audit;
authority inquiry;
internal investigation;
legal claim;
or another preservation duty.
Information under legal hold is restricted to purposes compatible with the hold.
Release of an active legal hold must be authorised and documented.
Where the Platform requires HQ authorisation and a reason for legal-hold release, that control must not be bypassed.
14. Regulatory and Financial Records
Regulatory and finance records frequently have retention requirements independent of the ordinary user account.
This can include:
declarations;
authority submissions;
registrations;
payment records;
PRO records;
service agreements;
invoices;
receipts;
regulatory calculations;
reporting-period evidence; and
financial reconciliation.
Such records are retained for the period required by applicable EU, Member-State, accounting, tax, EPR/PPWR, contractual and claims law.
Deletion of a user identity does not require destruction of an organisational regulatory record where continued retention has an independent lawful basis.
15. Data Subject Erasure Requests
GDPR erasure requests are assessed against Article 17 and the relevant Controller/Processor allocation.
Where Beyoğlu Professional acts as Processor, the Controller determines whether the request must be fulfilled and Beyoğlu Professional provides appropriate assistance.
Where Beyoğlu Professional acts as Controller, we determine the applicable Article 17 grounds and exceptions.
Information may remain where continued Processing is necessary for a legal obligation or for the establishment, exercise or defence of legal claims, among other applicable GDPR exceptions.
16. Shared Data
A record is not treated as exclusively owned by one user merely because that user created it.
Examples include shared workspaces, compliance records, conversations involving other participants, organisational declarations and regulatory evidence.
Deletion must preserve the rights and legitimate records of other authorised participants and organisations.
Where appropriate, user-specific identifiers may be removed or access revoked without deleting the shared organisational record itself.
17. Third-Party Systems
Deletion from Beyoğlu Professional does not automatically erase records lawfully held by an independent third-party controller such as:
a regulatory authority;
a PRO;
marketplace;
commerce provider;
a bank;
payment institution;
or other independently controlled system.
Where a provider acts as our Subprocessor, deletion instructions are propagated in accordance with the applicable DPA and subprocessing agreement.
18. Backups and Recovery Copies
Where Personal Data exists in backup or disaster-recovery copies, ordinary production deletion must not be defeated by restoring deleted information to active Processing without necessity.
If deleted information is temporarily reintroduced solely through a disaster-recovery restoration, the applicable deletion instruction must be re-applied where technically and legally appropriate.
The specific production backup retention schedule, RPO and RTO are operational infrastructure controls and are not represented by this Policy unless separately documented and approved.
19. Deletion Verification
Where appropriate to the risk, deletion operations should be auditable through:
operation result;
affected record/object count;
audit event;
transaction result;
identity-provider result;
or equivalent evidence.
Deletion logs themselves may be retained where necessary to demonstrate that the deletion occurred, provided they contain only information necessary for accountability.
20. Suspension of Automatic Deletion
Automatic deletion must be suspended where:
a legal hold applies;
a regulator requires preservation;
an active dispute exists;
there is evidence of fraud or abuse requiring investigation;
retention is necessary to establish or defend a legal claim;
or deletion would conflict with another binding legal obligation.
21. Policy Review
Retention classes and deletion rules must be reviewed whenever:
a new jurisdiction is introduced;
a new regulatory data category is added;
a new Subprocessor or storage platform is introduced;
a material legal requirement changes;
a material incident identifies an incorrect retention rule; or
the Platform data model materially changes.
22. Contact
Retention and deletion questions should be directed to:
https://beyogluprofessional.com/contact