Privacy policy

1. Introduction and scope

This review draft describes Niwas Khata’s public website, owner accounts and PG/hostel management workspace. It covers account and service operations as well as tenant information entered by customers. It is not an accommodation marketplace privacy notice or a claim of legal compliance.

Niwas Khata is operated personally by Parth Khandelwal. Privacy complaints and account-deletion enquiries can be sent to support@niwaskhata.com. The correspondence address and effective date are awaiting confirmation. This does not identify Niwas Khata as an incorporated company. The remaining details must be completed before this draft is approved.

2. Legal framework and commencement

Legal review should consider the Digital Personal Data Protection Act, 2023, Digital Personal Data Protection Rules, 2025, applicable phased commencement notifications, other Indian technology/privacy requirements and relevant app-store policies. Requirements in force at the actual launch date must be checked against official sources; this draft does not assume that every provision commenced together.

No lawyer or legal certification is claimed. The policy and operating processes require review by a qualified Indian legal professional. Official-source verification and an approved implementation checklist remain launch requirements.

3. Account, business and property information

Owner registration collects a name, email, chosen password and PG/business name through the existing Supabase authentication flow. Supabase maintains the authentication account and internal user identifier. The workspace stores business memberships and roles, properties, rooms, beds and related operational records.

Contact and deletion-request forms collect the entered name, email, subject/message and a request receipt. A signed-in deletion request also records the verified user identity and, where authorized, the selected business scope. Do not include passwords, full identity documents or payment-card details in a support message.

4. Tenant information entered by PG owners

The existing profile and onboarding features can store tenant name, phone/email, gender, joining/stay dates, rent agreement, room/bed allocation, occupation or education details, institute/employer information, blood group, guardian/emergency contacts, permanent address, vehicle details and notes. Optional identity number/type, police status/reference and private uploaded tenant documents may also be entered.

These fields reflect information supplied by the business, not independent verification by Niwas Khata. Owners should collect only data necessary for a stated lawful purpose, give appropriate notices, respect permissions and avoid placing unrelated sensitive information in notes.

5. Financial and payment information

The application stores rent invoices, recorded payments, methods/references, advances, deposits, refunds/deductions, expense details and relevant reporting history. These entries organize records; a manual payment record is not itself a bank transfer.

Owner subscription implementation uses Razorpay when merchant checkout is activated. The application is designed to retain provider subscription/payment references, amounts and verified status rather than full payment-card credentials. Final live payment setup, invoicing and commercial policy review remain pending.

6. How data is obtained and used

Information is supplied through signup, business forms, owner/team entries, document uploads and support requests. The service uses it to authenticate users, maintain business records, show the selected property’s operations, generate supported invoices/reports, enforce roles and subscription access, handle requests and diagnose service failures.

The public marketing pages do not read protected tenant or property tables. Demonstration screenshots use isolated fictional records. Public content is not a public tenant directory.

7. Roles, legal grounds and consent

Roles depend on the activity. The platform operator determines purposes for its own account, support and service-security processing. A PG business ordinarily determines why it collects tenant records, while the platform provides tools to process those records. Contractual processor/fiduciary allocation and the roles of providers require activity-specific legal review, not one blanket label.

The operator and each PG business must identify the applicable lawful basis and provide notices and consent mechanisms where required under provisions in force. A general account signup or this policy must not be treated as blanket consent for every use of tenant data. The application does not claim a fully implemented DPDP consent-management system.

8. Access and sharing

Owners and assigned business members access information according to the existing organization and role controls. A business is responsible for inviting appropriate people and reviewing their access. Different owner workspaces are separated through application checks and database policies.

Relevant service providers include Supabase for authentication/database/private storage, Vercel for hosting, the configured SMTP service for authentication emails and Razorpay when subscription payments are activated. Provider contracts, subprocessors, transfer arrangements and current settings must be reviewed. Lawful disclosures or professional assistance may be needed in particular cases; no sale of tenant records is implemented by this website.

9. Cookies, technical information and analytics

The app uses authentication/session cookies and business/property selection cookies to keep the workspace working. Service providers may process technical request information such as IP addresses, browser/request metadata and operational logs under their configurations. Support-form rate limits use a server-derived keyed fingerprint rather than storing the raw client IP in the request table.

This implementation adds no advertising, marketing analytics pixels or nonessential tracking cookies. A decorative cookie-consent banner is therefore not added. If optional analytics or other tracking is introduced, review its data flows and obtain any required consent before activation.

10. Security and storage

Implemented safeguards include authenticated access, role/organization checks, database row-level policies and a private tenant document bucket. Supported document access is controlled rather than exposing a public tenant file directory. Server-only credentials are not placed in public page content.

These measures do not guarantee absolute security or certify the system to any standard. The operator must review configuration, access, backups, incident handling and maintenance. Accounts should use strong unique passwords and appropriate recovery controls.

11. Storage locations and transfers

The service relies on hosted providers. All processing locations, logs, email paths, backups and subprocessors have not been verified for this policy. No promise is made that all information stays only in India. The operator must confirm actual regions and applicable transfer restrictions before making a location-specific assurance.

12. Retention

There is no approved universal retention schedule in this draft. Trial expiry preserves viewing; checkout or a closed tenant status is not automatic erasure. Requests, business records, financial references, logs and backups may need different treatment.

The operator and PG businesses must define purpose-based retention, access restrictions, lawful exceptions and a deletion schedule. Unnecessary information should not be kept indefinitely merely because the system can store it. Actual deletion after a request requires authorized review; backup/log handling must be checked with providers.

13. Rights, correction and consent withdrawal

Users may request information, correction, withdrawal of consent where applicable, erasure or grievance review through the service’s request process, subject to applicable law and identity/authority checks. The operator must verify which statutory rights and procedures are in force and establish compliant handling before approving this policy.

Owners can correct supported operational records through their assigned access. A tenant should generally begin with the PG business that collected their information; the platform can route a request but must not disclose another person’s records or erase shared business data based solely on an unverified email.

14. Account deletion and identity verification

The public deletion page explains the process. Signed-in, verified users can submit a durable request; a business-wide request requires owner authority. Submitting creates a review ticket, not immediate deletion. Shared access, outstanding subscriptions, lawful retention and affected tenant/property records must be assessed first.

Losing access to an account does not justify bypassing verification. Recover access or contact the verified operator for an appropriate identity check. Keep the receipt reference; automated completion emails and a guaranteed completion period are not implemented or promised by this draft.

15. Children’s information

Student accommodation may involve children. The PG business and operator must assess the applicable age definitions, parental/guardian requirements and restrictions in force before processing such information. Guardian fields alone do not implement verifiable parental consent.

The platform does not independently verify age or parental authority. Do not start a workflow requiring parental verification until an appropriate reviewed process is in place.

16. Incidents and breach handling

The operator must maintain a response process to assess incidents, contain harm, preserve appropriate evidence and provide notices to affected people and authorities where required under applicable provisions in force. The service does not currently claim automatic breach detection, automated statutory notification or a verified response-time guarantee.

17. Grievances, contact and policy changes

A reviewed grievance and escalation procedure is required before approval; the operator and contact mailbox are identified above. The contact form provides a private support queue when activated; its receipt is not a promise of a legally sufficient grievance process on its own.

Material changes to the approved policy should be communicated appropriately, with a real effective date and version record. This draft was prepared on 20 October 2026; its legal effective date remains pending approval.