Security Policy

1. What we hold, and why this page matters

Digilight PMS holds a hotel's operating record: who is staying, when they arrived, what they paid, and the identity document they presented at the front desk. That is a more sensitive dataset than most software of this size carries, and this page has to be worth the trust it asks for.

So it is written to a rule: every sentence here is checkable against the code, and where a control does not exist, we say so rather than reaching for a comfortable word.

2. What we do not claim

Digilight India holds no security certification of any kind:

• No ISO 27001.
• No SOC 2.
• No PCI-DSS attestation of our own.
• No third-party penetration test has been carried out.

We are a young company and we have not been audited. Anyone telling you otherwise — including any page on this website — is wrong, and we would like to know about it.

We also do not currently offer:

• Multi-factor authentication. Sign-in is by password only.
• Application-level encryption of identity documents. See §6.

Stating this plainly is the entire point of the section. A security page that gestures at certifications it does not hold is worse than no page at all, because the buyer who relies on it has been misled about the one thing they came here to check.

Do not remove this section, and do not soften it, until the thing it disclaims actually exists.

3. How we protect your data

Each control below exists in the product today and was verified in the source code.

3.1 Tenant isolation

Every hotel's data is scoped to its own property. The property a request may touch is taken from the signed session token, never from anything the browser sends — so a user cannot ask for another hotel's data by changing a parameter.

This is covered by a dedicated automated isolation test that asserts one property cannot read, modify, or switch into another.

BUSINESS DECISION REQUIRED — before this sentence may be published

Reason: The isolation test is real and it is the strongest security artefact in the codebase. But there is no CI pipeline in the Digilight PMS repository, and the test skips itself when a database is not configured. Nothing currently guarantees it has ever run against the code being deployed.

A published claim that a test protects customers, when nothing runs that test, is not a security control — it is a sentence.

Suggested options:

1. Add a CI workflow that runs the isolation suite on every push, and block merges on it. Then this paragraph is true and evidenced. Recommended.
2. Remove the sentence.

3.2 Passwords

Passwords are stored as one-way bcrypt hashes with a cost factor of 12. We never store them in a recoverable form, we cannot read them, and we cannot tell you what yours is — only reset it.

3.3 Sessions

Signing in issues a signed session token, held in a cookie that is HttpOnly (unreadable by JavaScript), Secure (sent only over HTTPS) and SameSite=Lax. The token is valid for 7 days.

Be aware of what this means: the token is stateless. Signing out clears the cookie from your browser, but it does not revoke the token on our servers. Anyone who had already copied it could continue to use it until it expires.

BUSINESS DECISION REQUIRED — session revocation

Reason: The paragraph above is the honest description of a stateless JWT, and it is not a good look on a security page. The alternative is to fix it rather than to phrase it more kindly. This matters most for the case a hotelier will actually face: a member of staff leaves, their account is removed, and their token keeps working for up to seven days.

Suggested options:

1. Implement server-side revocation (a token version on the user, checked per request, or a denylist). Then this section says "signing out ends your session" and it is true.
2. Shorten the token lifetime materially.
3. Publish the honest paragraph as written.

3.4 Roles and permissions

Staff accounts carry roles — owner, manager, front desk, accountant, housekeeping, inventory, food service and read-only — and each role maps to a defined set of permissions.

BUSINESS DECISION REQUIRED — before this sentence may be published

Reason: The role model is real and well defined. Its enforcement is incomplete: a majority of the product's API routes authenticate the user but do not check their role. The details are in the internal review notes and are deliberately not published here.

As written, the paragraph above describes a model, not a guarantee, and a reader will take it as a guarantee.

Suggested options:

1. Close the enforcement gap, then publish the paragraph. Recommended — this is a correctness bug independent of what any policy says.
2. Publish nothing about roles until it is closed.

3.5 Audit logging

Changes to bookings, payments and sensitive settings are recorded in an audit log capturing the acting user, the action, the affected record, the IP address and the time.

Where a member of Digilight India's staff enters a customer's account to provide support, that session is time-limited to 30 minutes, requires a written reason, can be revoked, and is logged. It is described in full in the DPA — we would rather tell you it exists than have you discover it.

The audit log is not tamper-proof. It is an ordinary database table. It records what happened; it is not a legal evidentiary record and we do not present it as one.

3.6 Rate limiting

Sign-in, sign-up and password-change endpoints are rate limited per client IP address.

3.7 Payment integrity

Payment amounts are always derived on our server from the plan catalogue — the browser cannot propose a price. Notifications from the payment gateway are cryptographically signature-verified before they are acted on, and payment capture is idempotent, so a replayed notification cannot double-charge you.

4. Where it runs

The application and the database both run in Singapore — see the Privacy Policy, which explains what that means for you.

Database connections are encrypted in transit and refuse to connect otherwise. The website and the application are served over HTTPS.

LAWYER REVIEW REQUIRED — infrastructure claims

Reason: Beyond the two facts above, nothing about the production environment has been evidenced: who at Digilight India can reach the production database, how that access is controlled, and whether the database is network-isolated.

Suggested options: confirm each against the account's actual configuration — not against the vendor's marketing page — and state only what survives that. Anything that cannot be evidenced comes out.

5. Backups and recovery

Customer data is held in a managed PostgreSQL database with continuous point-in-time recovery. Our disaster-recovery runbook targets a recovery point objective of 5 minutes and a recovery time objective of 1 hour.

BUSINESS DECISION REQUIRED — an untested backup is not a backup

Reason: Those two numbers are the database provider's published capability, and a restore drill script exists — but it has never been executed. The drill log in the runbook is empty.

An RTO nobody has measured is a guess printed in a serious font, and it is the number a hotel will hold us to on the worst day of the year.

Suggested options:

1. Run the drill once, end to end, record the real numbers, and publish those. It is an afternoon's work and it converts this section from a claim into a fact. Recommended.
2. Publish the provider's figures, explicitly attributed to the provider, and say we have not yet rehearsed a restore.
3. Say nothing about RPO/RTO.

6. Encryption

We want to be exact here, because this is the sentence companies most often fudge.

• In transit: encrypted. HTTPS to the browser, TLS to the database.
• At rest: encrypted by our database provider at the storage layer.
• Application-level: Digilight PMS does not apply its own field-level encryption to guest identity documents. A passport, Aadhaar or driving-licence number entered at the front desk is stored as ordinary text in the database.

That last line is not a comfortable thing to publish, and it is why it is here.

LAWYER REVIEW REQUIRED — and this is a product blocker, not a wording problem

Reason: This section interlocks with the Aadhaar question in Privacy Policy §3.2. If counsel's answer there is "identity numbers must not be held in plaintext", then this section is not redrafted — the schema changes.

Two false claims are live in the product today and must be removed before this page is published: the settings screen tells hoteliers "All data is encrypted and stored securely" and "Bank-grade encryption at rest". Neither is true. They are listed as blockers in the internal review notes.

7. Reporting a vulnerability

If you believe you have found a security vulnerability in Digilight PMS, we want to hear about it before anyone else does.

• Write to security@digilightpms.com
• Tell us what you found and how to reproduce it
• Give us reasonable time to fix it before disclosing it publicly
• Do not access, alter or remove any data that is not your own while testing

We will acknowledge your report, keep you updated, and credit you if you would like us to.

UNCONFIRMED FACT — the mailbox does not exist

Reason: security@digilightpms.com has not been provisioned. Publishing a disclosure address that bounces is worse than publishing none — a researcher who cannot reach us discloses publicly instead, and the first we hear of it is a customer's phone call.

Suggested options:

1. Provision and monitor the mailbox before publication.
2. Use support@digilightpms.com and route it internally.

LAWYER REVIEW REQUIRED — safe harbour

Reason: A researcher acting in good faith within the rules above should be told, in terms, that we will not pursue them. Without that assurance, serious researchers do not report — they publish.

Suggested options: adopt standard safe-harbour wording, scoped to good-faith testing that does not access other people's data.

8. If something goes wrong

If guest or hotel data is exposed, we will tell the affected hotels and give them what they need to meet their own notification duties to the Data Protection Board and to their guests.

The deadline we commit to is set in the DPA, and that is the deadline that is operationally binding. Whatever number is chosen there is a promise an on-call rota has to be able to keep.

9. Your side of it

The security of a hotel's data also depends on the hotel:

• Give every member of staff their own login. Do not share one.
• Remove accounts for staff who leave — and see §3.3 for how long their session can outlive the account today.
• Use a strong, unique password.
• Lock the front-desk computer when you walk away from it.

10. Changes to this policy

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

11. How to contact us

For a security question, or if you are a customer whose auditors need more detail than this page carries: support@digilightpms.com