Review build Not the live site — unlaunched products, unfinished copy, no prices. comsky.ai →

This page is not in force yet.

We are preparing this policy with counsel. What is written below is the structure of the document plus an honest description of how Comsky already works. It is not a contract and nothing on this page is a commitment you can rely on. The terms that currently bind us are available on request — write to legal@comsky.ai and we will send you the executed version rather than point you back here.

Legal

Privacy policy

Comsky is operated by Comhard Technologies Pvt Ltd, Noida, Uttar Pradesh — the contracting entity on every Comsky agreement and invoice. This policy will cover every product in the suite and the comsky.ai site, because the account, the wallet and the audit trail are shared across them.

Sections are numbered below in the order the final document will carry them. Each says what it will govern and states our actual practice where that practice is already settled. Where a number, a period or a named individual belongs, an em dash stands in until counsel fills it.

Sections 1 and 2

What personal data we collect.

Split by how it reaches us, because the answers differ. Data you put inside a product is yours; we process it to run the product and for nothing else.

1.1 Account and identity

Name, work email, phone number, organisation and role, collected when an account is created or a user is invited. Sign-in is handled by a separate credential authority, so passwords and second factors are never held in a product database.

1.2 What you put into the products

Contacts and deals in CRM, ledgers synced from TallyPrime, files and drive images in Backup, and the equivalent records in each further product as it ships. This is customer content. We hold it to run the product you are paying for and we do not mine it.

1.3 Usage and diagnostics

Sign-in events, API calls, resource consumption, error traces and the append-only audit trail of administrative actions. The audit trail is a product feature as much as an internal record — it is yours to read.

1.4 Billing and wallet

Top-ups against the prepaid wallet, metered usage per product, GST registration details and invoice history. Card and UPI details are handled by the payment gateway, not stored by us.

1.5 Support correspondence

Tickets, email threads and call notes from support in IST, including anything you attach to them. Impersonated support sessions are time-boxed, read-only and written to your own log.

1.6 Site visitors

Pages requested on comsky.ai, approximate location from IP, and whatever a form you submit contains. Section 9 covers cookies and the analytics we run; the cookie policy is the operative detail.

Sections 3 to 5

Why we hold it, where it sits, how long it stays.

3. Purpose and lawful basis

Each category above will be tied to a stated purpose — performing the contract, meeting a statutory obligation such as GST records, or a legitimate interest we name rather than imply. Consent will be used only where it is genuinely the basis, and never as a catch-all.

4. Where it is stored

Instances, volumes, snapshots, backup vaults and databases are created in Indian data centres and do not leave them. Sub-processors that necessarily sit outside India are listed in section 6 with what each one receives.

5. How long we keep it

Retention will be stated per category: live account data, billing records held for statutory reasons, and the audit trail, which is append-only by design. The period for each is —.

The per-product residency table on the security page already says what is stored where. It is the same answer this section will give, written out product by product.

Sections 6 and 7

Who else sees it.

Three cases, kept separate because they are separate: the vendors we depend on, the people we refuse to sell to, and lawful demands.

6. Sub-processors

Payment gateways, SMS and WhatsApp carriers, and email delivery are named in the Data Processing Addendum along with exactly what each receives. Ask for the DPA and we will send the current list rather than a category.

6.1 What we do not do

We do not sell personal data, we do not share it with advertising networks, and we do not use customer content to train models. If that ever changed it would be a new policy with notice, not a quiet edit.

7. Lawful demands

Requests from an authority will be assessed on their face, met only to the extent legally required, and notified to you where we are permitted to notify. The governing law and forum for disputes are —.

Section 8

Your rights over it, in practice.

These are the four that people actually exercise. The final text will add the statutory framing; the mechanics described here are what the products already do.

01

See what we hold

You can read your own account record, your audit trail and your billing history inside the product without asking us for them.

  • ·Audit trail is append-only and hash-chained
  • ·Admin impersonation appears in your own log
02

Correct it

Account and organisation details are editable by an owner. For anything you cannot reach yourself, support in IST will correct it and record that it was corrected.

  • ·Turnaround for a correction request: —
03

Take it out

Every product exports in an open format — CSV, JSON or the product’s native file — and export is not gated behind a plan, a notice period or a conversation with sales.

  • ·No minimum term and no lock-in
  • ·Export works while an account is being closed
04

Have it deleted

Deletion requests are honoured and confirmed back to you in writing. Records we are obliged to retain for statutory reasons are named in the confirmation rather than silently kept.

  • ·Deadline for confirmed deletion: —
Sections 9 to 12

The remaining sections.

9. How it is protected

Credentials held by a dedicated authority, tenant isolation forced at the database row rather than in application code, encryption in transit and at rest. The security page states each of these specifically; this section will restate them in policy language.

10. Cookies and analytics

What comsky.ai sets, what is strictly necessary and what is not, and how to refuse the rest. The detail lives in the cookie policy and this section will simply point there.

11. Breach notification

What counts as a reportable incident, who we tell, and in what order. The notification period and the regulator we report to are —.

12. Changes to this policy

Material changes will be notified to account owners by email before they take effect, and the previous version kept available. The notice period before a change takes effect is —.

Section 13

Who to write to.

Two routes. Use the first for a question about this policy and the second when you want something escalated formally.

Privacy questions

legal@comsky.ai reaches the people preparing this document. Ask for the currently binding terms, the Data Processing Addendum or the sub-processor list and you will get the actual file.

Grievance officer

The statutory grievance route, with a named officer and a published response time, will be set out on the grievance page. The officer’s name and contact are —.

Need the terms that actually apply today?

Ask and we will send the executed agreement and the Data Processing Addendum. We would rather you read the binding document than a draft.