Orkestr

Security

Last updated · Questions: security@orkestr.in

This page describes how we protect the data tenants and customers entrust to Orkestr. It’s the document Annex II of our DPA points to, and it’s what procurement teams should grade us against. We’ll keep it factual — if something isn’t in place yet, we say so.

Found a vulnerability? Email security@orkestr.in — responsible-disclosure reports are always welcome. We respond within 2 business days.

1. Infrastructure

  • Hosting: Google Cloud Platform, region us-east4 (Ashburn, VA). Compute runs on Cloud Run (stateless, autoscaling, no SSH access). Object storage on Cloud Storage. Secrets in Secret Manager (never on disk, never in env files in the repo).
  • Database: Neon Postgres (managed, SOC 2 Type II). Point-in-time recovery; encrypted at rest with AES-256; encrypted in transit with TLS 1.2+.
  • Authentication: Firebase Authentication. We never see your raw password — Firebase stores a salted hash and gives us back a verified ID token. Password resets and email verification flow through Firebase’s own channels.
  • Payments: Stripe (cards, Connect) and Razorpay (UPI, INR cards). Both PCI-DSS Level 1. Card data never touches our servers — the browser tokenises directly with the gateway, and we store only the resulting token plus the last four digits for receipts.
  • Edge + DNS: Cloudflare for DNS and static asset CDN, with DNSSEC enabled.

2. Encryption

  • In transit: TLS 1.2+ everywhere. HSTS with a 1-year max-age on apex and tenant subdomains. HTTPS-only cookies, SameSite=Lax, HttpOnly on the session cookie.
  • At rest: AES-256 on the Postgres data volume, on Cloud Storage objects, and on Cloud Logging archives. Customer-managed encryption keys (CMEK) available on the Enterprise tier on request.
  • Secrets: stored in Google Secret Manager, rotated on a documented schedule, injected at runtime — not checked into the repository.

3. Tenant data isolation

Orkestr is multi-tenant. We treat tenant-data isolation as a first-class correctness property, not an optional layer:

  • Every row in every tenant-scoped table carries a tenantId. Every read and write goes through a query layer that injects WHERE tenantId = $1 from the authenticated session context.
  • Cross-tenant queries are explicitly off — there’s no admin-side “peek into a tenant” without going through a separate, audit-logged support path.
  • Tests cover the isolation invariant: every tenant-scoped endpoint has a paired test that calls it with the wrong tenant token and asserts a 403/404.

4. Access control

  • Principle of least privilege: every Cloud Run service runs as its own service account with only the IAM roles it needs (e.g. orkestr-api can read its database secret but can’t list project resources).
  • Human access to production: restricted to a short list of named engineers, gated by 2FA on Google Workspace, and every privileged action emits an audit log.
  • Tenant-side RBAC: four roles (owner, admin, staff, customer) with documented capability matrix. Permission checks happen server-side; the UI is a hint, not a gate.

5. Audit logging

Every privileged action — sign-in, role change, refund, booking modification, integration toggle, support impersonation — writes an entry to an append-only audit log with actor, target, action, IP, user-agent, and timestamp. Tenants can view their own audit log at /admin/audit-log. Retention: 12 months online, 7 years cold.

6. Application security

  • Input validation: every API endpoint validates its input against a Zod schema before the handler runs. Rejected requests never reach business logic.
  • SQL injection: all queries go through Prisma (parameterised). No raw string concatenation against the database.
  • XSS: all user-provided HTML (listing descriptions, review bodies) passes through a sanitiser (DOMPurify-style allow-list) before storage and again before render.
  • CSRF: session cookies are SameSite=Lax; mutating endpoints require a custom header that browsers can’t set cross-origin.
  • Rate limiting: per-IP and per-account buckets on sign-in, sign-up, password reset, and the public search endpoints. 429 with backoff hints when exceeded.
  • Dependency hygiene: automated dependency updates via Renovate; npm audit and Snyk run on every PR; high-severity advisories block merge.

7. Software development lifecycle

  • Code review: every change to main is reviewed in a pull request before merge. No direct pushes.
  • CI gates: typecheck, lint, unit tests, and integration tests run on every PR. Merge blocked on red CI.
  • Deploys: Cloud Build pipelines triggered on merge to main. Every build is reproducible from the commit SHA. Rollback is a one-command redeploy of the previous revision.
  • Pre-production: staging environment with its own database + tenants for testing schema migrations and risky changes before they hit prod.

8. Backups + disaster recovery

  • Database backups: incremental snapshots every 24h retained for 7 days; weekly snapshots retained for 30 days; monthly snapshots retained for 12 months.
  • Point-in-time recovery: Neon supports PITR to any moment in the last 7 days.
  • RPO target: 24 hours. RTO target: 4 hours for a full database restore.
  • Restore drills: we run a documented restore-from-backup exercise quarterly.

9. Vulnerability management

  • Continuous dependency scanning (Renovate, Snyk).
  • Container image scanning on every build (Google Artifact Registry vulnerability scanning).
  • External penetration test annually (next: 2026 Q3); report summary available to Enterprise tenants under NDA.
  • Responsible-disclosure program: email security@orkestr.in with a description and reproduction steps. We respond within 2 business days, fix within 30 days for high severity (or sooner), and credit reporters publicly (with permission) once the issue is closed.

10. Incident response

We maintain a written incident-response runbook. If a security incident affects tenant data:

  • We’ll notify affected tenants without undue delay, and in any case within 72 hours of becoming aware (consistent with GDPR Art. 33).
  • Notifications include: what happened, what data was affected, what we’ve done, and what you should do.
  • A post-incident report is published to affected tenants within 30 days.

11. Compliance status — honest version

We’d rather tell you where we are than oversell. As of :

  • GDPR + UK GDPR + CCPA: we operate consistent with these. See Privacy Policy and DPA.
  • PCI-DSS: card data never touches our systems. Stripe (PCI-DSS Level 1) and Razorpay (PCI-DSS Level 1) handle it.
  • SOC 2 Type II: not yet. Planned to start the audit window in 2026 Q4 once revenue supports the audit cost. We can share our security questionnaire responses and policies in the meantime.
  • ISO 27001: not yet. On the post-SOC 2 roadmap.
  • HIPAA: Orkestr is not a HIPAA-covered platform. Don’t use it to store PHI.

12. Sub-processors

Each sub-processor we use is listed in Privacy §4, with the role it plays and the data-protection regime it operates under. We give 30 days’ notice before adding or replacing one (see DPA §6).

13. Contact

Security reports + questionnaires: security@orkestr.in. Privacy: privacy@orkestr.in. DPA + procurement: dpa@orkestr.in.