Security Incident Response Policy
Effective Date: 26 August 2026 Owner: Sunny Dhalia, incident lead for Kayease Global Solutions LLP — sunny@kayease.com Review cadence: Annually, and after any Severity 1 or 2 incident.
This policy exists so that a security incident is handled by a plan written in advance rather than improvised under pressure. It covers the Retrace application, its database, its object storage, and the accounts and credentials used to operate them.
It is published rather than internal because the Privacy Policy and the Data Processing Agreement both rest on it: each of them promises notification within 72 hours of a confirmed breach, and a promise whose procedure nobody outside the company can read is not a commitment a merchant can rely on.
1. What counts as an incident
Any event that compromises, or credibly threatens to compromise, the confidentiality, integrity or availability of merchant data or the systems holding it. Examples: unauthorised access to the production database or object storage, exposure of MASTER_KEY or a Shopify access token, a dependency compromise reaching production, exfiltration of encrypted blobs, or destructive loss of stored backups.
A failed backup run, an expired merchant token, or a Shopify API outage is an operational fault, not a security incident, and is handled through normal support.
2. Severity
| Level | Definition | Response starts |
|---|---|---|
| S1 | Confirmed unauthorised access to merchant personal data, or exposure of MASTER_KEY | Immediately, at any hour |
| S2 | Credible threat of S1, or exposure of a single shop's key or access token | Within 4 hours |
| S3 | Vulnerability with no evidence of exploitation | Within 2 business days |
| S4 | Hardening issue, no merchant data at risk | Next planned work |
Severity is assigned at first assessment and revised as facts arrive. When severity is ambiguous, the higher level applies until it is ruled out.
3. Roles
Retrace is operated by a single accountable owner, who acts as incident lead: directing the response, deciding on containment, and owning all external communication. Where specialist help is needed — forensics, legal, or the security team at Hostinger — the lead engages it and remains accountable for the response.
4. Response
Identify. Establish what happened, which systems are involved, and which shops are in scope. Record the time of detection and how it was detected.
Contain. Stop the exposure before investigating it further. Depending on the incident, containment means some combination of: revoking the exposed Shopify access tokens, rotating MASTER_KEY and re-wrapping every shop DEK, rotating database and object-storage credentials, revoking staff sessions and access keys, and taking the affected component offline.
Preserve evidence. Capture logs, the append-only activity log (server/activity/log.ts), and relevant database state before remediation alters them. Evidence is retained for at least 12 months.
Eradicate and recover. Remove the cause, patch the vulnerability, restore service from a known-good state, and confirm the fix in production before declaring the incident closed.
5. Notification
- Merchants. Any merchant whose data was, or may have been, accessed is
notified without undue delay and no later than 72 hours after the incident is confirmed, by email to the address on the shop record. The notice states what happened, what data was involved, what has been done, and what if anything the merchant should do.
- Shopify. Shopify Partner Support is notified of any S1 or S2 incident
involving data obtained through the Shopify APIs, within 72 hours of confirmation.
- Regulators. Where a notifiable personal data breach has occurred, the
relevant supervisory authority is notified within the period required by applicable law — 72 hours under GDPR Article 33.
Merchants are the data controllers for their customers' personal data. Retrace notifies the merchant; the merchant decides on and makes any notification to their own customers, and Retrace provides the information they need to do so.
6. What limits the blast radius
These are properties of the system, recorded here because they determine what an incident can actually reach:
- Every shop's stored data is encrypted with that shop's own key (DEK),
AES-256-GCM. There is no single key that decrypts all merchant data.
- The
MASTER_KEYthat wraps those DEKs is held outside the database, in
the environment. A stolen database dump yields ciphertext only.
- The internal admin surface exposes no merchant content by design — only
counts, sizes, timestamps, statuses and store domains (server/admin/fleet.ts). There is no staff-facing path that decrypts a merchant's data.
- Every action taken by the application is written to an append-only
activity log, which is never updated or deleted.
7. Post-incident review
Within 10 business days of closing any S1 or S2 incident, a written review records the timeline, the root cause, what detection missed, and the specific changes made so the same cause cannot recur. Actions from the review are tracked to completion.
8. Reporting something to us
If you believe you have found a vulnerability in Retrace, or that merchant data has been exposed, write to sunny@kayease.com with "security" in the subject line. Reports are triaged under section 2 on the day they arrive, and you will get an acknowledgement naming the severity assigned and who is handling it. Please do not test against another merchant's store — we will arrange a development store instead.