Security Incident Response Policy

Any event that compromises, or credibly threatens to compromise, the confidentiality, integrity, or availability of systems or personal data. Examples: unauthorized data access, credential/token leakage, database exposure, malicious code, account takeover, or accidental data disclosure. Applies to all bijnis production systems (application servers, our managed database, third-party APIs — Meta/WhatsApp, Google, Shopify — and stored credentials).

• Incident Lead — the on-call engineer/founder who receives the alert; owns the incident end-to-end until closed. Default: SOT Labs technical lead.
• Communications owner — notifies affected merchants, Shopify, and (where required) regulators. May be the same person on a small team.
• Scribe — records the timeline and evidence (can be the Incident Lead).

Incidents surface through:

• Automated error/anomaly alerts — an in-app log collector emails new and grouped production errors to our team; external uptime monitoring (UptimeRobot).
• Application signals — failed webhook signature (HMAC) verifications, authentication failures, and unexpected data-access patterns.
• Reports — from merchants, buyers, Shopify, or security researchers via hello@sotlabs.net.

1. Identify & triage — assign a severity (Section 3), open an incident record, name the Incident Lead. Start the timeline.
2. Contain — stop the bleeding: revoke/rotate affected credentials and API tokens (Meta/WhatsApp, Shopify, Google, and our database service keys), disable the affected code path or connection, block offending access. For a suspected token leak, rotate the token-encryption secrets and re-encrypt as needed.
3. Eradicate — remove the root cause (patch the vulnerability, remove malicious artifacts, fix the misconfiguration).
4. Recover — restore service from a known-good state; verify data integrity; confirm monitoring is green before closing.
5. Evidence — preserve logs, the alert emails, database audit trails (order and message records, connection timestamps), and access records relevant to the incident. Do not destroy evidence during containment.
6. Notify — see Section 6.
7. Post-incident review — within 5 business days for SEV1/SEV2: root cause, timeline, what worked, corrective actions with owners and dates. Feed fixes back into the product and this policy.

• Shopify — for any incident involving Shopify protected customer data, notify Shopify without undue delay (target ≤ 72 hours of confirmation) via the Partner Dashboard / partner support channel.
• Affected merchants — notify impacted merchants promptly with what happened, what data was involved, and what they/their customers should do. Merchants are the controllers for their buyers' data and may have their own notification duties.
• Regulators / data principals — where the DPDP Act (or other applicable law) requires, notify the Data Protection Board and affected individuals within the legally mandated timeframe. Our Grievance Officer (see the privacy policy, Section 19) coordinates this.
• No silent handling — a confirmed personal-data breach is never closed without the notifications above considered and documented.

• Secrets and tokens encrypted at rest (AES-256-GCM) and in transit (HTTPS/TLS); encrypted backups.
• Least-privilege staff access; 2FA enforced on all infrastructure accounts (database, hosting, Google).
• Test and production data separated; webhook receivers fail closed on invalid signatures.
• Regular dependency and security review.

Incident records and post-incident reviews are retained for at least 2 years. This policy and its effectiveness are reviewed on the cadence noted above.