Security and incident response

This page describes how Premium Holdings LTD ("NimiBot", "we") protects the data we process for merchants and their shoppers, and the steps we follow if a security incident happens. It applies to the NimiBot app, the team inbox, our APIs and the providers we use (listed in our privacy policy). It is written to meet the Israeli Privacy Protection (Data Security) Regulations, 5777-2017, and Shopify's requirements for apps that handle protected customer data.

Report a security issue

If you think you found a vulnerability or that data was exposed, email support@nimibot.com with "Security" in the subject. Please include what you saw and how to reproduce it, and don't access or change data that isn't yours. We confirm receipt within one business day.

How we protect data

• Least data: we read orders and customer details live from Shopify when they're needed and don't store them, except a log of refunds, store credit and discount codes made from the team inbox.
• Encryption: all traffic uses HTTPS (TLS). The database and its backups are encrypted at rest. API keys that merchants add are encrypted again with a separate key.
• Access: each store's data is only visible to that store's own team, with Owner, Admin and Support roles. Money actions need an admin's approval unless the admin allowed a teammate. The AI never makes refunds or credits.
• Sign-in: team members sign in with a one-time code, a password (salted and hashed, never stored in plain text) or Shopify or Google. Repeated wrong passwords lock the account for 15 minutes.
• Our own access: only NimiBot staff who need it for operating the service can reach production systems, behind separate credentials.
• Logging: we keep server request logs and a log of every refund, credit and discount action, with who asked and who approved.
• Retention: conversations are deleted after 90 days by default (stores can shorten this). When a store uninstalls, its data is deleted within 48 hours of Shopify's request.
• Test data: development and testing use demo data and development stores, never copies of real customer data.

What counts as a security incident

Any event where personal data may have been accessed, used, changed, disclosed or lost without permission, or where our systems' security was compromised. Examples: a leaked key or password, unauthorized access to a store's data, a vulnerability that exposes data, or data sent to the wrong store.

Our response, step by step

1. Report and record. Anyone at NimiBot who notices a possible incident reports it right away to the incident lead (a director of Premium Holdings LTD). We open an incident record with the time, what was seen and who is involved.
2. Contain. We stop the damage first: revoke or rotate exposed keys and tokens, end affected sessions, block the access path, take the affected feature offline if needed, and keep evidence such as logs.
3. Assess. We work out what data, which stores and how many people are affected, how it happened, and how serious it is, including whether it is a severe incident under the Data Security Regulations.
4. Notify.
   • Affected merchants: without undue delay, and no later than 72 hours after we confirm an incident involving their data, with what happened, what data, what we did and what they should do.
   • Shopify: as required by the Shopify Partner Program Agreement and API terms.
   • The Israeli Privacy Protection Authority: immediately for a severe security incident, as the regulations require, and we follow any instruction it gives, including telling the people affected.
   • Affected shoppers: through the merchant, who is responsible for its customers, or directly when the law or the merchant requires it.
5. Recover. We fix the cause, restore data from backups if needed, and check that the fix works before turning features back on.
6. Learn. Within 30 days we write a short report: the cause, the impact and the changes that prevent it from happening again. Incident records are kept for at least 24 months.

Keeping this policy current

We review this policy at least once a year and after any significant incident or change to how we handle data.