Security and Incident Response

Last updated: 2026-10-06

Stores trust us with their catalog and their shoppers' conversations. This page explains how we protect that data and what we do if something goes wrong.

1. Data protection measures

• Encryption in transit: all traffic to Zeldina uses HTTPS (TLS 1.2 or higher).
• Encryption of secrets: store access credentials are encrypted with AES-256-GCM before they are saved. The encryption key is stored separately from the database.
• Passwords: merchant passwords are stored only as salted one-way hashes (scrypt). Login sessions use random tokens, and only their hashes are stored.
• Backups: the database is backed up every day. Backups are encrypted with AES-256 and kept for a limited time (see our Privacy Policy). We test restores regularly.
• Data minimisation: we do not receive shoppers' names, addresses or payment details. We do not store voice recordings. Conversations are deleted automatically after 12 months.
• Isolation: each store can only access its own data. Test stores are kept separate from live stores.

2. Access control

• Least privilege: only staff who need access to operate the service have it, and only to the extent they need.
• Admin access: administrative access requires two-factor authentication and is limited to approved network addresses.
• Merchants' own access: merchants see only their own stores. Passwords must meet minimum strength rules.
• Logging: access to conversations and other personal data is logged, and the logs are reviewed when needed.
• Servers: only authorised administrators can access our servers. Databases and caches are reachable only from inside the server and are not exposed to the internet.

3. Application security

• Verified platform messages: all messages from e-commerce platforms (webhooks) are verified with their cryptographic signatures. Repeated deliveries are ignored.
• Abuse protection: the service is protected by rate limits and a network firewall (Cloudflare).
• Updates: dependencies and systems are kept up to date. Security updates are applied promptly.

4. Incident response

A security incident is any event that may compromise the confidentiality, integrity or availability of data we process. When we detect or are told about one, we follow these steps:

1. Assess: we confirm the incident, determine which data and stores are affected, and rate its severity.
2. Contain: we stop the cause. This may mean revoking credentials, isolating systems or disabling affected features.
3. Notify:
   • affected merchants without undue delay, and within 72 hours at the latest, with what happened, what data is involved and what we are doing,
   • where we are the controller, the competent authority within 72 hours as the law requires (in Türkiye, the Kişisel Verileri Koruma Kurulu).
4. Recover: we restore normal operation, from backups if necessary.
5. Learn: we document the incident and its cause, and put measures in place to prevent it from happening again.

5. Reporting a vulnerability

If you believe you have found a security issue in Zeldina, please email [email protected] with the details. Please do not access other people's data or disrupt the service while testing. We will reply quickly and keep you informed, and we will not take legal action against good-faith research.