Ganakys
Trust

Security & trust

We treat your data the way we want our own data treated. This page describes the layered controls we run, the standards we test against, and how to report a security issue. We do not claim "absolute" security — that would be a lie. We do claim defense-in-depth, rapid detection, and a real incident-response path.

Last updated: 29 April 2026

Data in transit

TLS 1.2 or higher on every host. HSTS preload-eligible policies on every public hostname. Strict CSP headers blocking inline scripts and third-party origins by default.

Data at rest

Sensitive identifiers (PAN, GSTIN, bank account) are stored with column-level AES-GCM encryption via Postgres pgcrypto. Disk volumes on the production VPS are encrypted at the OS layer.

Authentication

Mandatory two-factor authentication on the client portal — TOTP (Google Authenticator) or email OTP. Salted password hashes; never plaintext. Session JWTs are short-lived and rotated on logout. Cloudflare Access guards the admin interface (amma).

Authorization

Role-based access for staff. Operators see only what their role requires. Cross-client data leakage is prevented at the query layer — every authenticated read scopes by client_id from the session JWT, audited by per-collection lifecycle hooks.

Audit logging

Every sensitive read and mutation lands in an append-only audit log: actor, action, target, IP, user agent, outcome, timestamp. Audit rows are immutable post-write. Retention 1 year hot, 6 years cold (Income Tax Act-aligned).

Network edge

Cloudflare in front of all four hosts (free tier). WAF rules drop common OWASP categories. Per-route rate limiting at nginx — 3 r/min on /api/auth, 30 r/min on payment webhooks, general envelope on the rest. fail2ban guards SSH.

Backups

Encrypted database snapshots taken locally on the VPS by the operator. Sensitive identifiers stay encrypted in the snapshot. Restore drills are run periodically against a throwaway environment to verify the snapshot can actually be brought back.

Vulnerability management

Dependabot alerts on all repositories. Gitleaks pre-commit and CI scan for accidentally-committed secrets. Dependency audits (npm audit) run before each release; high-severity advisories block the release until fixed.

Sub-processors

We use a small number of vetted sub-processors. Each one handles a specific data category for a specific purpose. The current list — including data residency and a link to each sub-processor's privacy policy — is at /sub-processors. Existing clients receive an email notification at least 7 days before any new sub-processor is added.

Compliance posture

  • Digital Personal Data Protection Act, 2023 — Grievance Officer designated; data principal rights (access, correction, erasure, nominee) exercisable from the client portal at /me/privacy; consent log per DPDP Section 6; retention schedule per Section 8(7); breach notification path per Section 8(6).
  • Goods & Services Tax — invoices numbered per GST Rule 46 (sequential, financial-year-keyed), HSN/place-of-supply/RCM fields modelled per the CGST Act, e-invoice IRN where applicable.
  • Income Tax Act, 1961 — invoice and supporting-record retention 8 years from the end of the relevant financial year.
  • Companies Act, 2013 — incorporated as a One Person Company; statutory records retained 8 years per Section 128.

Incident response

On confirmation of a personal-data breach we:

  1. Contain the breach (rotate compromised credentials, revoke sessions, isolate affected systems).
  2. Notify the Data Protection Board of India within the window prescribed by the DPDP Rules, 2025.
  3. Notify affected Data Principals via email with: the categories of data involved, the likely consequences, the steps we are taking, and what they can do to protect themselves.
  4. Run a post-incident review and publish lessons learned (anonymized).

Reports of suspected security issues are triaged within 24 hours of receipt.

Reporting a vulnerability

If you believe you have found a security issue affecting Ganakys, please email support@ganakys.com with a description, steps to reproduce, and the affected hostname. Please do not test against production with intrusive payloads — a description is enough for us to verify and fix. We will acknowledge within 24 hours and keep you informed through to remediation.

We currently do not run a paid bug bounty programme; once we are 12 months in production with a paying customer base, we plan to publish responsible-disclosure terms via /.well-known/security.txt.