Privacy Policy

1. Who we are

Digilight PMS is hotel management software. It is a product of Digilight India, and this policy explains what personal data the product holds, why, who it is shared with, and what rights you have over it.

UNCONFIRMED FACT — company identity

Reason: The registered legal entity name, its CIN, its registered office and its GSTIN have not been provided, and this policy is unpublishable without them. A privacy policy that names the wrong controller is misleading and unenforceable.

There is a live contradiction in the repository today. Marketing copy across the website says "Digilight India", while the site's SEO configuration (LEGAL_ENTITY_NAME in src/config/seo.ts) carries a different registered name, alongside a placeholder GSTIN and a placeholder phone number. That file is rendered nowhere, so it is not yet a published falsehood — but it is the only place in the codebase that names a registered entity, and it does not agree with the brand. The value is quoted in docs/legal-review/LEGAL_REVIEW_NOTES.md rather than here, because an unverified company name does not belong on a page a customer reads.

Suggested options:

1. Confirm the registered name and use it verbatim here, with "Digilight India" identified as a trading name. Delete the placeholders from seo.ts.
2. If the registered entity really is "Digilight India", correct seo.ts.

Required regardless: registered office address, CIN, GSTIN, and the grievance-officer details in §11.

2. Who this policy is for

Two very different sets of people have data in Digilight PMS, and they are owed different things. The rest of this document depends on the distinction.

2.1 Hotel operators — our customers

The hotelier who signs up, and their owners, managers, front-desk and accounts staff. Digilight India decides how this data is used, so for it we are the Data Fiduciary under the Digital Personal Data Protection Act 2023 ("DPDP Act").

2.2 Hotel guests — our customers' customers

The people who stay at the hotel. Their data is entered into Digilight PMS by the hotel, for the hotel's own purposes. The hotel is the Data Fiduciary for it. Digilight India is the hotel's Data Processor and acts only on the hotel's instructions.

If you are a guest and you want your data corrected or erased, the hotel you stayed at is the party who decides — see §10. The terms governing our role are in the Data Processing Addendum.

LAWYER REVIEW REQUIRED — role characterisation

Reason: The whole document rests on this split. Confirm the Fiduciary/Processor characterisation under the DPDP Act for each data category in §3, and confirm it does not shift for the records we generate ourselves (§3.5) — audit logs, security logs and rate-limit records are created for our purposes, not on the hotel's instruction, which may make us a Fiduciary in our own right even for guest-derived data.

Suggested options:

1. Single characterisation: Processor for everything a hotel enters, Fiduciary for everything we generate. Simplest, and probably correct.
2. Per-category table, if counsel thinks any category is genuinely mixed.

3. What personal data we hold

The lists below were compiled from the production database schema (prisma/schema.prisma), not from a template. They are accurate as at the date of this draft and must be re-verified before publication.

3.1 What a hotelier gives us

• Name, email address, mobile number (the signup form asks for a WhatsApp mobile)

• Hotel name and address; the owner's name, phone and email

• The hotel's GSTIN, where it issues GST invoices

• A password, stored only as a one-way bcrypt hash. We cannot read it, and we cannot recover it for you.

• Your acceptance of these terms. When you tick the box at signup (Terms §1.1) we record which documents you accepted, the version of each, the moment you accepted, and the IP address and browser user-agent you accepted from.

  We log that address for exactly one purpose: so that if you ever say you did not agree to something, the answer can be a time, a version and an origin rather than a tick in a box. It is not used for analytics, profiling or location. It is not shared. If a Digilight India employee sets your account up for you, the record says so and no IP is stored, because you did not click anything and inventing one would be manufacturing evidence.

3.2 Guest data a hotelier enters

Recorded by the hotel, about its guests, in the ordinary course of running the property:

• Name (required), email address, phone number
• Address, city, state, country, postcode, nationality
• Identity document type and number. The product accepts passport, driving licence, Aadhaar, voter ID and "other". It is stored as typed text.
• Vehicle number and purpose of visit
• Number of adults and children staying
• Free-text notes the hotel keeps against a guest, a booking or a stay
• Stay records: bookings, dates, rooms, folio charges and payments

Three things the product does not hold, which are worth stating because a reader will assume otherwise:

• No date of birth. No such field exists.
• No gender. No such field exists.
• No photographs, and no scans or images of identity documents. The only file upload in the product accepts a hotel logo and a favicon, nothing else. An identity document is captured as typed text and never as an image.

LAWYER REVIEW REQUIRED — Aadhaar. This is the most serious item in this document.

Reason: The guest record can hold an Aadhaar number, and today it is stored as plaintext text, in three separate tables (the guest master, the stay/visitor-register snapshot, and the additional-occupant record). It is not encrypted, not masked, not tokenised by the application, and — see §9 — it is never deleted.

The Aadhaar Act 2016 restricts who may collect, store and share Aadhaar numbers and in what form, with penal consequences, and the UIDAI has issued specific directions to private entities about storage. Counsel must decide whether Digilight PMS may hold Aadhaar numbers at all in this form.

This is a product decision as much as a legal one. If the answer is "not like this", the database schema changes before launch, not after.

Suggested options:

1. Remove Aadhaar from the accepted ID types and keep passport / driving licence / voter ID. Cheapest, and removes the exposure entirely.
2. Store only the last 4 digits of any Aadhaar (a common industry pattern), discarding the rest at entry.
3. Encrypt the ID number at rest at field level, with a separate key, and mask it in the UI and in exports.
4. Keep it as-is, if and only if counsel confirms in writing that plaintext storage by a Processor on the hotel's instruction is lawful.

LAWYER REVIEW REQUIRED — sensitive data and children

Reason: Two questions. (a) Which of the categories above, if any, are "sensitive" and what additional handling that triggers. (b) The DPDP Act imposes obligations around a child's personal data, including verifiable parental consent. Hotel bookings routinely record children — as a count, and, if the hotel enters an additional occupant, potentially by name and identity document.

Suggested options for (b):

1. Push the obligation to the hotel by warranty in the Terms and the DPA, on the basis that the hotel is the Fiduciary and takes the data at the front desk.
2. Change the product so an additional occupant can be marked as a minor and no identity document is accepted for them.

3.3 Guest communications

Where a hotel sends a guest a message through Digilight PMS, we store the recipient's phone number or email address, the subject, and the full text of the message that was sent.

3.4 Payment data — what we never see

Digilight India never receives, and never stores, your card, UPI or bank details. Subscription payments are handled by our payment gateway. Payment details are entered directly with the gateway; they do not pass through our servers.

This is verifiable rather than reassuring boilerplate: no card-number, CVV, expiry, UPI VPA or bank-account column exists anywhere in our database. What we store is the gateway's order reference, its payment reference, the amount, the status, and a method label.

We do store the raw notification payload the gateway sends us when a payment succeeds or fails, for reconciliation.

LAWYER REVIEW REQUIRED — PCI representations

Reason: The facts above are true, but they are not the same as a PCI-DSS attestation, and we must not imply one. Confirm what, if anything, Digilight India may say about PCI. See also §2 of the Security Policy.

Suggested options:

1. State the fact ("we never receive card data") and make no PCI claim at all. Recommended.
2. State the gateway's own compliance status, attributed to the gateway.

3.5 Data we generate

• Access and audit logs — who did what, and when, inside the product. These include the IP address and browser user-agent of the person who acted.
• Security logs of sensitive changes.
• Rate-limiting records, which briefly hold the IP address of anyone attempting to sign in or sign up. These are discarded about an hour later.
• Support-access records. Where a member of Digilight India's staff enters a customer's account to provide support, that session is time-limited, requires a written reason, and is logged. See the DPA.
• Subscription, invoice and payment records.
• Diagnostic and error logs.

4. Why we process it

LAWYER REVIEW REQUIRED — lawful basis

Reason: Each row above needs a stated lawful basis, and the DPDP Act's consent regime is narrower than the GDPR's — "legitimate interests", which would carry most of this table in an EU-facing policy, is not available in the same form here. A policy copied from a European template will be wrong on exactly this point.

Suggested options: produce the purpose-and-basis table, stating for each purpose whether consent is required, and if so who obtains it — Digilight India, or the hotel at the front desk on the guest's behalf. The second is the only workable answer for guest data, and it must then be backed by the hotel's warranty in the Terms.

5. What we do not do

• We do not sell personal data.
• We do not share it for advertising, and we run no advertising.
• We do not track visitors to this website. It sets no cookies at all — see the Cookie Policy.
• We do not use guest data to train machine-learning models. No AI or LLM service is integrated into Digilight PMS.

6. Who we share data with

Every third party below was identified from the codebase and the deployment configuration. This list is complete as at the date of this draft.

UNCONFIRMED FACT — sub-processor locations

Reason: Vercel and Neon are confirmed (see the marker below). The processing locations of Resend, Cloudflare and the Overpass API have not been confirmed against their contracts or documentation, and must not be guessed. The Overpass endpoint in particular is a public, volunteer-operated service with no contract, no SLA and no data-processing agreement with us.

Suggested options:

1. Confirm each location from the vendor's own DPA and print it.
2. Remove the last three entirely. The three map-related services exist only to serve one screen (/market-intelligence) which is not linked from any menu in the product. The Cloudflare dependency is three icon images that could be self-hosted in ten minutes. Removing that screen, or self-hosting its assets, would delete three sub-processors — including the one we have no contract with — from this table and from the DPA. This is the recommended option.

LAWYER REVIEW REQUIRED — cross-border transfer. Read this one carefully.

Reason: The application and the database both run in Singapore, not India. This is a matter of fact, taken from vercel.json ("regions": ["sin1"]) and the database connection string (ap-southeast-1.aws.neon.tech). Every piece of personal data in §3 — including guests' Aadhaar and passport numbers — is stored in Singapore.

That engages the DPDP Act's cross-border transfer provisions (s.16), and it must be disclosed here in plain words, not buried. It is also a fact that enterprise customers and any hotel with a government contract will ask about directly.

Suggested options:

1. Disclose and continue. Confirm Singapore is not a restricted territory under s.16 as notified, draft the disclosure, and say so plainly on this page.
2. Migrate to an Indian region (Vercel bom1; Neon offers an AWS Mumbai region). This removes the question entirely and is a strong commercial signal for an India-first product. It is an infrastructure change, not a code change.

Counsel should advise before the first paying customer, because migrating after the data exists is materially harder than migrating now.

7. Where your data is stored

In Singapore — see the marker immediately above. Encryption in transit is enforced on every database connection. What is and is not encrypted at rest is set out honestly in the Security Policy.

8. How we protect it

Set out in full, including what we do not have, in the Security Policy.

9. How long we keep it

LAWYER REVIEW REQUIRED — retention. This section cannot be written until a product change is made.

Reason: The honest answer today is: indefinitely. There is no retention period, no purge job, and no deletion schedule anywhere in Digilight PMS. Guest records — including plaintext Aadhaar and passport numbers — are kept for as long as the database exists.

It is worse than that, and counsel needs the detail:

• No hotelier can delete a guest. There is no delete endpoint for a guest record. It does not exist in the product.
• Even if there were, it would not erase the person. The guest's name, phone, nationality and identity-document number are copied into the stay record and into the additional-occupant record when they check in. Deleting the guest master leaves those copies intact.
• Deleting an entire property does cascade and remove everything — but that is a Digilight India super-admin action, not something a customer can do.

A privacy policy that promises erasure would therefore be false on the day it is published. That is the reason this section is a marker and not a clause.

Suggested options — these are product tickets, not drafting choices:

1. Build a guest-erasure path that scrubs the identity fields in all three tables, not just the guest master.
2. Set a retention period for each class of record (guest records; audit logs with IP addresses; message bodies; raw gateway payloads) and build the purge job. Note the conflict counsel must resolve: Indian tax law requires invoice records to be retained for years, while a guest exercising erasure may ask for deletion sooner. State which record classes survive an erasure request, and why.
3. Decide what happens to a hotel's data after it stops being a customer, and how long it survives. See also DPA §11.
4. Decide how long the terms-acceptance record survives (§3.1), and specifically whether it survives an erasure request. It is the only record in the product deliberately built to resist deletion — a foreign key with no cascade, so that removing a user cannot silently destroy the proof they accepted our terms. That is a defensible retention basis and it is also, unavoidably, a record containing an IP address that we decline to delete on request. Counsel must say whether that position holds under the DPDP Act, and for how long.

10. Your rights

Under the DPDP Act, a Data Principal has rights of access, correction, completion, erasure, grievance redressal, and nomination.

10.1 If you are a hotelier

Write to us and we will act on it.

10.2 If you are a guest

Contact the hotel you stayed at, not us. The hotel decides what happens to your record; we hold it on the hotel's behalf and act on the hotel's instruction. If you write to us directly, we will pass your request to the hotel and tell you that we have done so.

LAWYER REVIEW REQUIRED — rights we cannot currently honour

Reason: Two of these rights cannot be exercised in the product today, and this section must not promise them until they can.

• Erasure: see §9. There is no mechanism.
• Access / portability for one guest: the product can export an entire property's data as a CSV, but there is no per-person export. A hotel asked for one guest's data cannot produce it without dumping every guest's data.

Suggested options:

1. State the response deadline for each right, and build the two missing paths before publication.
2. State the escalation route where a hotel does not answer its own guest.

11. Grievance redressal

UNCONFIRMED FACT — statutory requirement, and a hard blocker

Reason: The DPDP Act requires a Data Fiduciary to publish the contact details of the person who will answer grievances. Digilight India has not appointed one. This is not optional, and the policy cannot be published without it.

Suggested options:

1. Appoint a named individual and publish their name, designation, email and postal address here.
2. Confirm with counsel whether a role-based mailbox is sufficient in place of a named person. Do not assume that it is.

12. Cookies

This website sets no cookies. The application sets two, both strictly necessary for signing in. The complete detail is in the Cookie Policy.

13. Changes to this policy

Every change is recorded in the version history at the foot of this page.

LAWYER REVIEW REQUIRED. State how a material change is notified to hoteliers, and how much notice they get before it takes effect.

14. How to contact us

Questions about this policy: support@digilightpms.com

UNCONFIRMED FACT. A registered postal address and the grievance officer's details (see §11) must appear here before publication. A privacy policy with no postal address is not compliant.