Scope
A security incident is any event that puts at risk the confidentiality, integrity or availability of data the app processes, for example unauthorised access, data shown to the wrong store, a leaked secret or tampering with points.
The policy covers the app’s production environment on Microsoft Azure in France Central (Paris, EU): the admin and webhook service, the loyalty engine, the PostgreSQL databases, the key vault and the logs, and the app’s configuration in Shopify.
Data at risk is mainly shoppers’ Shopify customer IDs and the loyalty data linked to them (points, order summaries, tiers, activity), and merchant data such as store settings, staff user IDs and Shopify access tokens, which are stored encrypted. Shopper names and e-mail addresses are not stored. For shopper data, the merchant is the controller and Tryino the processor.
Roles
- Incident Lead: declares the incident, sets its severity, owns decisions and the incident record, and approves external notices.
- Technical Responder: investigates, contains, removes the cause and recovers; preserves evidence; rotates credentials.
- Communications: prepares and sends notices to merchants, Shopify and authorities, and answers [email protected] and [email protected].
Tryino is a small team, so one person may hold more than one role. Each role has a named backup, who takes over if the Incident Lead cannot be reached for 2 hours during a SEV-1 or SEV-2 incident.
Severity levels
| Level | Examples | Response starts | Contain within |
|---|---|---|---|
| SEV-1 Critical | Confirmed unauthorised access to or disclosure of shopper or merchant data; data visible across stores; a leaked production secret; points changed at scale by an attacker | Immediately, any hour | 4 hours |
| SEV-2 High | Suspected but unconfirmed access; an exploitable vulnerability in production; a compromised Tryino account with production access; Shopify privacy webhooks failing for more than 24 hours | Within 4 hours | 24 hours |
| SEV-3 Medium | A vulnerability with limited exposure or no known exploit; an incident confined to one store with no data disclosed; repeated attacks that our controls blocked | Next business day | 5 business days |
| SEV-4 Low | A policy deviation or hardening item with no data at risk | Planned work | Next release |
We raise the severity as soon as new facts justify it. Outages that only affect availability are handled as operational issues unless an attack caused them.
Detection and reporting
Incidents can come to light through application logs (for example rejected webhooks, signature failures and refused staff point changes), access logs for secrets in Azure Key Vault and for database connections, Azure activity records, cost alerts, notices from Shopify, and reports from merchants, shoppers or security researchers. Key Vault and database connection logs are kept in Azure Log Analytics for 90 days; application logs contain no shopper data.
To report a suspected security issue, write to [email protected]. Anyone at Tryino who suspects an incident tells the Incident Lead at once, and nobody investigates alone for more than 30 minutes before doing so.
How we respond
- Identify: open an incident record (times in UTC), set the severity and establish the scope: which stores, which data and which period. Production data is examined only inside the protected environment and is never copied to laptops, tickets or chat.
- Contain: take the smallest action that stops the harm, such as limiting traffic, closing access, removing suspicious permissions, revoking sessions or rotating any credential that may be exposed. Shopify webhook outages are kept short, and orders are checked against Shopify afterwards.
- Eradicate: fix the root cause, rebuild and redeploy from reviewed, committed code, and remove anything an attacker may have left behind.
- Recover: if data integrity is affected, restore from point-in-time backups (the last 14 days) to a new server, compare before switching over, re-process pending order notifications, check the app end to end, and watch closely for 14 days.
- Review: hold a post-incident review (see below).
Notification
| Who | When |
|---|---|
| Affected merchants (controllers) | Without undue delay after we become aware of a breach affecting their data. Our target is the first notice within 48 hours, with updates as facts become clear. |
| Shopify | Within the time and through the channel Shopify’s partner and API terms require, at the same time as the merchant notice or earlier. |
| Supervisory authorities | Within 72 hours where notification is required: under the GDPR, and to the Personal Data Protection Board under KVKK. For shopper data this is the merchant’s duty, and we support it. We notify for data we control ourselves. |
| Affected individuals | As the merchant decides or the law requires. We provide the facts and draft wording on request. |
A merchant notice says what happened and when; the stores and categories of data affected, with approximate counts; the likely consequences; the measures taken and planned; what the merchant should do; and a contact person.
Evidence and records
We preserve evidence before changing anything we can avoid changing: relevant log results are exported at once (application logs, Key Vault access and database connection logs are kept 90 days), databases are restored to a separate server rather than altered, and deployment versions and Shopify webhook delivery logs are recorded. Old secret versions are kept, not purged. Evidence is stored with access restrictions and integrity hashes, and shopper personal data is kept out of incident notes.
Each incident record holds its severity and status, detection time and source, timeline, scope, actions taken, notices sent, root cause and follow-up actions.
Credential rotation
Production secrets are kept in Azure Key Vault and read by managed identities. When a credential may be exposed, we rotate it (for example the Shopify app secret, the key that encrypts store access tokens, service keys or database passwords), deploy new versions of the services that use it, and revoke and review the access of people and identities involved.
Post-incident review
We hold a blameless review within 10 business days of every SEV-1 and SEV-2 incident, and of SEV-3 incidents where useful. It covers the timeline, the root cause and why it was not prevented or found sooner, what worked and what did not, and the data and notification outcome. The result is a list of owned, dated actions and, where needed, updates to this policy, our data inventory and our monitoring.
Testing and maintenance
At least once a year, and after any major change to the architecture, we run a tabletop exercise of a SEV-1 scenario and a test restore of the production database, and record the findings. The policy is reviewed every year and after each SEV-1 or SEV-2 incident.
Contact
Security and privacy: [email protected] · Support: [email protected] · Tryino, İstanbul, Türkiye