Skip to content

Security practices

What actually protects your data, described concretely enough that you can hold us to it — including what we do not yet have.

Last updated 1 August 2026. This policy is published by [LEGAL ENTITY NAME] Private Limited, referred to below as “we”, “us” or “Pharmizo”.

Tenant isolation

Every customer company is a separate tenant. Users, reporting hierarchy, module entitlements, subscriptions and invoices all belong to an organization, and requests are scoped to the requesting user’s organization. There is no cross-organization view other than the platform administration console, which only our staff can reach and which writes every action to the audit log.

Within a tenant, access follows the reporting hierarchy: a regional manager sees their region, not the country.

Authentication

  • Passwords are stored as PBKDF2-HMAC-SHA256 hashes with a per-user salt. We cannot read your password, and neither can anyone who obtains the database file.
  • Sessions use JSON Web Tokens delivered in HTTP-only, Secure, SameSite cookies. Because the token is not readable from JavaScript, a cross-site scripting bug cannot exfiltrate it.
  • Refresh tokens are rotated and blacklisted on sign-out, so a stolen token expires.
  • State-changing requests are protected against cross-site request forgery.
  • Single sign-on is available on the Enterprise plan. Multi-factor authentication is on the roadmap and is not available today — if you need it before signing, say so and we will tell you when.

Encryption and transport

  • All traffic is served over HTTPS. Plain HTTP is redirected, and HSTS is sent with a one-year max-age, subdomain inclusion and preload.
  • Certificates are issued and renewed automatically by Let’s Encrypt, so they do not lapse through human error.
  • Responses carry a Content Security Policy, X-Content-Type-Options: nosniff, frame denial and a strict referrer policy.
  • Backups are encrypted in transit to object storage and encrypted at rest there.

Auditing

Privileged actions — provisioning an organization, suspending one, changing a role, changing a plan — are written to an append-only log recording the actor, the action, the target, the time and the source IP address. The log has no update path and no delete path. Not permission-restricted: absent. An administrator cannot quietly remove the record of what they did, and neither can we.

Data durability

Architecture
A single SQLite database in write-ahead-log mode on the application server’s local disk. Sole tenancy — your data does not share a database process with another customer’s.
Continuous replication
Litestream tails the write-ahead log and ships every committed transaction to S3-compatible object storage within seconds. This is not a nightly dump: the recovery point objective is measured in seconds, not hours.
Point-in-time recovery
Hourly snapshots with a rolling seven-day retention window, so the database can be restored to any moment inside it — not only to the last snapshot.
Rehearsed restores
Restores are run as a routine drill: restore from the live backup stream to a scratch copy, run an integrity check, count rows. A backup nobody has restored is not a backup, it is a hope.
Soft deletion
Deleting a record marks it deleted and hides it; the row remains and can be restored. No database relation cascades, so removing one record cannot silently remove others.

Hosting

The platform runs on dedicated infrastructure operated by Hetzner Online GmbH in Falkenstein, Germany, with backups in object storage in the same region. Hetzner’s data centres hold ISO 27001 certification. Personal data therefore leaves India for storage and processing; see the privacy policy. If your procurement requires India-resident data, tell us — it changes where we deploy, not what the product does.

Application security

  • Containers run as an unprivileged user, never as root, with a read-only application directory.
  • Every change goes through automated checks before an image is published: the test suite, Django’s deployment checks, a migration-drift check and an API schema check.
  • Images are built in CI from a pinned build context and deployed by digest. Nothing is built on the production server, so a deployed image is exactly what CI produced.
  • Configuration assertions that other components silently depend on are covered by tests, so a regression fails the build rather than the customer.

What we do not have

Stated plainly, because you will ask and because a vendor who claims everything is telling you nothing:

  • No SOC 2 or ISO 27001 certification for Pharmizo itself. Our hosting provider is certified; we are not. We are happy to complete your security questionnaire.
  • No independent penetration test has been performed to date.
  • No multi-factor authentication yet.
  • No uptime SLA unless one is written into your order form. The platform runs on a single application node, so planned maintenance means brief downtime.
  • No customer-managed encryption keys and no bring-your-own-cloud deployment.

Reporting a vulnerability

Email [SECURITY@EXAMPLE.COM] with enough detail to reproduce the issue. We acknowledge within two working days and will keep you informed while we fix it. Please do not test against another customer’s tenant, do not access data that is not yours, and give us a reasonable window before disclosing publicly. We will not pursue legal action against anyone who reports in good faith within those bounds.

Incident response

If a breach affects your data we will notify your administrators and the Data Protection Board of India as the Digital Personal Data Protection Act, 2023 requires, with what we know, what we are doing and what you should do. We would rather tell you early and incompletely than late and neatly.

Contact

Security: [SECURITY@EXAMPLE.COM] · General: [SUPPORT@EXAMPLE.COM]