Security

Security Incident Response Policy

Oriuum — order management for Shopify merchants

Owner
Abdullah Aslam, Founder
Last reviewed
3 October 2026
Review cycle
every 6 months
Jump to section

1. Scope

This policy covers any suspected or confirmed security incident affecting Oriuum, its infrastructure, or merchant and customer personal data processed on behalf of merchants. Personal data processed by Oriuum is limited to the customer name, phone number, email address and shipping address attached to a merchant's orders, which are required to verify, dispatch and deliver cash-on-delivery orders.

2. Roles and responsibilities

Oriuum is operated by a single founder, who holds the Incident Owner role and is responsible for detection, containment, merchant notification, recovery and post-incident review. Where an incident involves a third-party platform (Shopify, Supabase, Vercel, Resend), the Incident Owner is responsible for raising a support case with that provider and tracking it to closure.

3. Severity levels

P1 — CriticalConfirmed unauthorised access to, or exposure of, personal data; compromised credentials with production access; data loss.Begin containment within 4 hours of detection
P2 — HighVulnerability that could expose personal data but no evidence of exploitation; loss of access control on a production system.Begin containment within 24 hours
P3 — ModerateSecurity defect with limited blast radius and no personal data exposure.Remediate within 7 days
P4 — LowHardening issue or dependency advisory with no immediate risk.Scheduled remediation

4. Detection

Incidents are detected through application error and audit logging (audit_log, operational_events), centralised log monitoring, Shopify and Supabase platform alerts, dependency vulnerability advisories, and reports from merchants or external parties. Reports may be sent to the support address published in the application.

5. Response procedure

  1. Record — log the time of detection, what was observed, and the systems involved.
  2. Assess and classify — determine the severity level, which data may be affected, and which merchants are in scope.
  3. Contain — take the shortest effective action to stop ongoing exposure. Depending on the incident this may include rotating API keys and secrets, revoking Shopify access tokens, invalidating user sessions, disabling an affected feature through the feature-flag system, restricting database access, or taking the affected surface offline.
  4. Preserve evidence — retain relevant logs, audit records and database state before remediation, so the cause and scope can be established afterwards.
  5. Eradicate and recover — fix the underlying cause, verify the fix in a non-production environment, deploy, and confirm normal operation. Restore from backup where data loss has occurred.
  6. Notify — see section 6.
  7. Review — see section 7.

6. Notification

Merchants affected by a confirmed personal data breach are notified without undue delay and within 72 hours of confirmation, by email to the account owner. The notification states what happened, which categories of data were affected, the period of exposure, the steps taken, and any action the merchant should take. Where Shopify platform data or API credentials are involved, Shopify Partner support is notified in the same period. Regulatory notification is made where required by applicable law.

7. Post-incident review

Within 14 days of closing a P1 or P2 incident, the Incident Owner records a written review covering the timeline, root cause, why existing controls did not prevent it, and the corrective actions taken. Corrective actions are tracked to completion and this policy is updated where the incident reveals a gap in it.

8. Supporting controls

  • Access to production data is restricted to the service role used by the application; the public client keys have no privileges on application tables (row-level security enforced).
  • All data is encrypted in transit and at rest, including backups, by the managed database platform; automated backups with point-in-time recovery are retained by the provider.
  • Staff access within the application is role-based and tenant-scoped. Support access to a merchant's account requires that merchant's explicit, time-limited consent, and administrator impersonation is read-only by default, requires a recorded reason, and is shown to the merchant in their own access history.
  • Access to personal data is logged with the acting user and is reviewable per merchant.
  • Test and production environments use separate databases; production personal data is not copied into development environments.

Last reviewed 3 October 2026