How we keep your data
honestly safe

Customer data — VMs, block volumes, S3-compatible objects, database backups — sits on dedicated bare-metal hardware in ISO 27001-certified, GDPR-compliant facilities — that certification is the data centre operator's, not ours; see “Certifications” below. Two regions are live: EU West in Finland, and Mumbai for customers who require Indian data residency.

You choose the region when you launch, and your compute and storage stay in it. Backups are the one deliberate exception: a copy is replicated to the other region so that losing a site does not lose your data. If your residency obligations rule that out, tell us and we will pin your backups to a single region — see contact.

In transit:TLS 1.2+ (1.3 preferred) on every customer-facing endpoint (portal, API, S3, mail). Certificates issued by Let's Encrypt, auto-renewed by certbot, monitored by Prometheus.

At rest: Secrets are encrypted at the application layer with AES-256-GCM — IAM access-key secrets, TOTP seeds, and customer-supplied service credentials. Passwords are bcrypt (cost 12), rehashed on login.

What we do not yet do: host disks are not full-disk encrypted, and database backups are not separately encrypted before leaving the host. If your threat model requires encryption at rest for the underlying block storage, we are not there yet — tell us and we will give you a date rather than a claim. Customer-managed keys (KMS) are on the roadmap; the design uses AES-256-GCM envelope encryption with the root key escrowed offline.

Every state-changing HTTP request across the auth, compute, and storage services is logged to an append-only audit_logstable — actor user_id, account_id, service, method, path, status, IP, user-agent, request-ID, duration. GET/HEAD/OPTIONS, /healthz, and /metrics are skipped by design.

Append-only, enforced by the database. UPDATE, DELETE and TRUNCATE on the audit table are rejected by trigger, so a row cannot be edited or removed after it is written — including by our own application. To be precise about the guarantee: a database superuser could disable that trigger, so this is tamper-evident, not WORM. We do not currently write audit data to external immutable storage, and we would rather tell you that than call it immutable.

Retention: we have never deleted an audit row — the trail runs back to platform launch — but there is no automated retention job yet, so we do not quote a contractual retention period. Visible to your account owner at /portal/audit-logs with filter-by-service and free-text path/IP/UA search. Bulk export for your own SIEM is not built yet; ask and we will pull it manually.

Postgres: Nightly logical dumps viapg_dump --format=custom at 02:30 IST, plus continuous WAL archiving. Retention: 14 days.

Customer VMs: Live Proxmox snapshots nightly (retention 7 days) for fast rollback, and a weekly full disk image shipped to a second site. Snapshots and images are taken online — your VM is never paused or stopped to back it up.

Object storage: Your buckets replicate daily to the second site alongside the database backups.

A second site, not a second disk. This is the part most providers are vague about, so: local snapshots protect you from deleting your own data, but they live on the same hardware as the VM and would die with it. Every class of customer data — database, VM disks, objects — is also copied to a physically separate node, with a different provider, in a different country. Losing one site does not lose your data.

Restore drill: A weekly automated job restores the latest Postgres dump into a fresh container and verifies the schema and row counts came back. Failure alerts us. Postgres restore RTO target is 30 minutes; recovery from total host loss is longer and we have not yet drilled it end-to-end, so we will not publish a number for it — ask and we will tell you where we are.

Status: Backup runs publish a textfile metric consumed by Prometheus; alerting fires if no successful backup in the last 26h.

Customer-facing: Sub-users under your account (IAM users), grouped into IAM groups, governed by attached IAM policies. Five managed policies seeded by default (CloudNxFullAccess, CloudNxReadOnlyAccess,CloudNxComputeFullAccess, CloudNxStorageFullAccess,CloudNxBillingReadOnly) plus custom policies you define.

Programmatic: Access key + secret key pairs, signed via AWS sigv4-compatible request signing. Secret keys are encrypted at rest with a service-level AES-256-GCM key separate from the root KMS key.

Owner accounts: Password (bcrypt, cost 12) + TOTP 2FA. TOTP secret is itself AES-256-GCM encrypted in the DB. OAuth via GitHub and Google supported as alternative sign-in.

Active today

• GDPR (EU 2016/679) — data residency in our EU West region, Finland (ISO 27001 datacenter), data processing addendum available on request, data-subject access (DSAR) handled via privacy@cloudnx.in within 30 days. Erasure requests are actioned manually by our team.
• India DPDP Act, 2023 — audit logging, data-subject access via portal export, DPO contact published, breach-notification workflow established per Section 8.
• CCPA / CPRA (California)— "Do Not Sell" is N/A (we don't sell user data, ever), DSAR honoured per privacy@cloudnx.in within the statutory window for California residents.
• GST tax invoice flow (India) — a GST-compliant tax invoice for every charge, with GSTIN and CGST/SGST/IGST split per buyer state, downloadable as a PDF.

Not yet certified — being transparent

CloudNx does not hold ISO 27001 or SOC 2. Our data centre operators do, and a certification does not transfer from the facility to the company running inside it: theirs covers the building, power, and physical access, not our software, our access controls, or how we handle your data. If a vendor questionnaire asks whether CloudNx is certified, the honest answer today is no. We would rather lose a deal on that sentence than win one and have it surface during your audit.

• SOC 2 Type II — engineering preconditions (audit logs, KMS, MFA, RBAC, change management) ship across 2026. The formal audit is planned for FY27.
• ISO 27001— same window; we'll start the pre-audit gap analysis after SOC 2.
• PCI-DSS— we don't store card data; Razorpay holds PCI scope. Out-of-scope for us by design.

If your procurement requires "SOC 2 Type II today", we'll tell you that on the first call rather than waste your time. We'll happily share our SOC 2 readiness checklist and interim control evidence under NDA.

• Patches: Unattended OS security updates on the host (no auto-reboots). Weekly Sunday maintenance window (22:00–24:00 IST) for kernel reboots, container deploys, and schema migrations — pre-announced on the status page.
• Renovate bot: Weekend-grouped dependency updates, auto-merge on patch with green CI; majors are manually reviewed.
• Container rollback: Every deploy tags the previous image as :rollback; a single command reverts to the last-known-good in ~5s with health-check guard.
• Incident response: We notify affected customers by email and write up what happened. We have not yet published a post-mortem archive or a hosted status page — both are being built, and until they exist we are not going to claim them.

We don't (yet) run a public bug-bounty program — we're small. But we read every report and we credit researchers in release notes when they accept.

Send disclosure to security@cloudnx.in. PGP key fingerprint coming soon — until then, please tolerate plain-text. Standard 90-day coordinated-disclosure window unless we negotiate otherwise.