Security & Incident Response
Last updated 29 July 2026
This page describes the controls that protect data held by MultiVendorOS, and exactly what happens when something goes wrong. It is written to be checked, not to sound reassuring — every control below is one that can be verified.
1. What we hold
The app holds order data, vendor business records, and an append-only financial ledger. From the customer, it holds only name and shipping address — a vendor cannot post a parcel without them. It does not hold customer email addresses, phone numbers, billing addresses, or payment details, and it never holds card data of any kind.
2. Controls
In transit
- TLS 1.2+ on every endpoint, HTTP redirected to HTTPS, certificates renewed automatically.
- Every request from the Shopify admin carries a cryptographically verified session token. A request that cannot prove which store it came from is rejected before it reaches any application code.
- Every webhook is verified by HMAC against the raw request body, using a constant-time comparison.
At rest
- Customer names and shipping addresses are encrypted in the database, including inside the stored copy of the original Shopify payload.
- Shopify access tokens and vendor bank details are encrypted. Bank account numbers are never displayed in full to anyone — only the last four digits.
- Vendor passwords are hashed with Argon2id and cannot be read by us or recovered.
Isolation
- Every database query is scoped to one merchant, enforced at the model layer rather than in individual controllers.
- A vendor sees only orders assigned to them. A cross-tenant request returns
404 Not Found, never403 Forbidden, so the existence of another merchant's data is never disclosed.
Integrity
- The financial ledger is append-only, enforced by a database trigger as well as application code. An entry cannot be edited or deleted after it is written, only reversed by a new entry.
- Every state change to a vendor, commission rule or payout is written to an append-only audit log with actor, IP address and timestamp.
Backups
- The database is dumped nightly, compressed and encrypted with AES-256 before it touches the disk — there is no window in which a plaintext copy exists.
- Each backup is verified automatically: it must decrypt, decompress, and contain the core financial tables, or it is discarded and the run fails loudly.
- Restores are tested by loading a backup into a scratch database and checking the schema, the seeded data and the ledger trigger all come back.
- 14 days are retained.
Access
- Production access is limited to named operators. There are no shared logins.
- Server credentials are long random strings held in a password manager, never reused, and never committed to source control.
- Application secrets live in environment files readable only by the service account, never in the repository.
3. What happens during an incident
An incident is any event that may have exposed data, altered financial records, or made the service unavailable.
| Stage | Target | What happens |
|---|---|---|
| Detect | — | Error alerting, failed-login monitoring, and the ledger reconciliation check that runs on every payout. |
| Contain | Within 1 hour of confirming | Revoke affected tokens, disable the affected path, or take the service offline. Stopping the bleeding comes before diagnosing it. |
| Assess | Within 24 hours | Determine what data was reachable, for how long, and by whom, from audit and access logs. |
| Notify | Within 72 hours | Affected merchants are emailed directly with what we know, what we do not yet know, and what they should do. Shopify is notified where their platform or their merchants are affected. We do not wait for a complete picture before telling people. |
| Remediate | — | Fix the cause, not the symptom. Rotate every credential that was in scope. |
| Review | Within 14 days | Written post-incident review: what happened, why it was possible, what changed so it cannot happen the same way again. Shared with affected merchants on request. |
We will tell you even when it is embarrassing. If we cause a problem, you hear it from us first, with the facts. A merchant discovering an incident from someone else is a worse outcome than the incident.
4. Reporting a vulnerability
Email security@multivendoros.com with steps to reproduce. We acknowledge within two business days and will keep you updated until it is resolved.
We will not pursue legal action against anyone who reports a vulnerability in good faith, gives us reasonable time to fix it, and does not access, modify or delete other people's data while investigating.
Please do not run automated scanners against production, run denial-of-service tests, or use social engineering against our staff or merchants.
5. What we do not claim
We hold no SOC 2, ISO 27001 or PCI certification, and we do not imply otherwise. We do not process card payments — Shopify handles merchant billing and vendor payouts move through the merchant's own bank or a licensed payment provider.
6. Contact
Security: security@multivendoros.com
Privacy: privacy@multivendoros.com
Support: support@multivendoros.com