Data Retention & Personal-Data Breach Notification Procedure

DRAFT for legal review — not final, not in force. See 00-README. Internal procedure + merchant/counsel reference. Supports the Privacy Policy and DPA. `` / [PLACEHOLDER] as defined there.

Owner: CIQRA OÜ · privacy@ciqra.com · Version: 1.0-draft · 2026-07-08

---

Part A — Data Retention

A.1 Principles

We retain personal data only as long as necessary for the purpose collected or as required by law, then delete or irreversibly anonymise it. Retention is enforced by process and, where feasible, automated jobs. Where CIQRA is processor (Storefront Customer data), the Merchant's instructions and the DPA govern; the periods below are CIQRA's defaults absent a conflicting lawful Merchant instruction.

A.2 Retention matrix (defaults)

Data category	Retention period	Basis / rationale
Order, invoice, tax & accounting records	7 years after the financial year	Estonian Accounting Act (legal obligation)
Merchant account & profile data	Life of account + 90 days after closure, then delete/anonymise	Contract; wind-down; disputes
KYC/KYB & verification records	Per legal/AML requirement (typically 5 years after relationship ends) ``	Legal obligation
Payment & chargeback records	13 months+ (extended for open disputes)	Dispute/chargeback windows; legal claims
Customer/order personal data (as processor)	Per Merchant instruction; default aligned to accounting (7 yrs for tx records) + deletion of non-essential fields sooner	DPA; controller instruction
Support tickets & correspondence	12–24 months	Legitimate interests; service quality
Application & security logs	Application logs 12 months; security/audit logs up to 24 months	Security; legitimate interests
Marketing consent & preferences	Until consent withdrawal / objection, + record of consent for evidence	Consent; accountability
Marketing engagement data	24 months after last interaction	Legitimate interests
Cookies / tracking identifiers	Per Cookie Policy durations; consent-based	Consent
AI feature inputs/outputs	Zero-retention at provider; CIQRA keeps only minimal operational metadata	Contract; data minimisation
Backups	30–35 days rolling, then overwritten	Resilience
Deleted-account residual (legal hold)	Only data under a specific legal obligation/hold	Legal obligation

A.3 Deletion & anonymisation

• On account closure/termination: export window (ToS §13.3), then deletion/anonymisation per this matrix, minus legally-required retention (segregated, access-restricted).
• Backups containing deleted data are purged on the rolling cycle; restores re-apply deletions.
• KVKK note: TR overlay requires periodic destruction/anonymisation and, where applicable, a VERBIS-aligned retention & destruction policy (saklama ve imha politikası) — see TR overlay. ``

---

Part B — Personal-Data Breach Notification (GDPR Art. 33/34)

B.1 Definition & scope

A personal-data breach is a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. This procedure covers breaches affecting data for which CIQRA is controller (we notify the supervisory authority/data subjects) and data for which CIQRA is processor (we notify the Merchant/Controller — see B.5).

B.2 The 72-hour clock

When CIQRA (as controller) becomes aware of a breach that is likely to result in a risk to individuals' rights and freedoms, it notifies the competent supervisory authority — the Estonian Andmekaitse Inspektsioon — without undue delay and, where feasible, within 72 hours of becoming aware. If notification is later than 72 hours, reasons for the delay are given. If unlikely to result in a risk, notification to the authority may not be required (documented in the internal register). ``

B.3 Incident response steps

1. Detect & report — anyone aware of a suspected breach reports immediately to security@ciqra.com (internal incident channel).
2. Triage & contain — the incident lead assesses scope, contains, and preserves evidence; the 72-hour clock starts at "awareness" of a likely-personal-data breach.
3. Assess risk — data categories, volume, data subjects, likelihood/severity of harm, whether data was encrypted/pseudonymised.
4. Notify authority (if risk) within 72h — nature of breach, categories/approx numbers, likely consequences, measures taken/proposed, DPO/privacy-contact details (staged notification allowed).
5. Notify data subjects (if high risk) — without undue delay, in clear language, with advice to mitigate (Art. 34), unless an exemption applies (e.g. encryption rendering data unintelligible, or subsequent measures, or disproportionate effort → public communication).
6. Notify Merchants/Controllers & partners — see B.5; notify Stripe/insurers/authorities as required.
7. Record — log every breach (facts, effects, remediation) in the internal breach register, regardless of notifiability (Art. 33(5)).
8. Remediate & learn — root-cause fix, preventive measures, post-incident review.

B.4 Roles

• Incident lead / privacy contact: privacy@ciqra.com coordinates; the incident lead is the on-call member of the management/engineering team designated in the internal incident-response runbook (roles: Incident Lead, Engineering/Forensics, Legal/Counsel liaison, Comms).
• Engineering (containment/forensics), Legal/counsel (notifiability, regulator liaison), Comms (external messaging).

B.5 CIQRA as processor

Where the breach affects data CIQRA processes for a Merchant (Controller), CIQRA notifies that Merchant without undue delay and within 72 hours of awareness (per the DPA §8), providing the information the Merchant needs for its own Art. 33/34 duties, and assists the Merchant's response. The Merchant decides on authority/data-subject notification for its data (unless otherwise agreed).

B.6 Cross-regime

• TR / KVKK: where TR data subjects are affected, additional KVKK breach-notification duties apply (notify the KVKK Kurumu and affected persons per KVKK/Board decisions and timelines). See TR overlay. ``
• Payment/card data: although CIQRA is SAQ A (no raw PAN), any suspected payment-data incident is escalated to Stripe and handled per card-scheme/PCI rules. ``

B.7 Testing

This procedure is reviewed and tested at least annually; contact lists and the register are kept current.

---

End of Retention & Breach procedure (draft). See: Privacy Policy · DPA · TR overlay.