CACHE & DATA RETENTION POLICY
AtithiBhaarat — Hotel Partner Platform (Website & Mobile Application)
Effective Date: 10 June 2026 Last Updated: 10 August 2026 Version: 1.0
1. PURPOSE AND SCOPE
This Cache & Data Retention Policy ("Cache Policy") explains how AtithiBhaarat DigiSolutions Private Limited ("AtithiBhaarat", "we", "us") temporarily stores data to make the Platform fast and reliable, how long each category of data is kept, and how it is ultimately deleted.
It applies to:
- the AtithiBhaarat website at https://atithibhaarat.com;
- the AtithiBhaarat Hotel Partner mobile application (Android and iOS) and progressive web application;
- the reception-desk and kiosk interfaces used by Hotel Partners;
- our servers, content delivery network and backup infrastructure.
This Cache Policy forms an integral part of the AtithiBhaarat Privacy Policy and should be read with the Cookie Policy. It is published in furtherance of the storage limitation principle under Section 8(7) of the Digital Personal Data Protection Act, 2023 ("DPDP Act"), which requires a Data Fiduciary to erase personal data once the purpose is no longer being served and retention is no longer necessary for legal compliance.
2. WHAT "CACHING" MEANS
A cache is a temporary store of data kept close to where it is needed, so that the same information does not have to be fetched or recomputed every time. Caching is what allows a hotel reception desk to load a check-in screen in under a second instead of waiting several seconds for a fresh server response.
Caching is a technical performance measure. It is distinct from retention, which is the deliberate, policy-driven storage of records for business or legal purposes. Both are covered here: Sections 3 to 7 deal with caching, and Section 8 deals with retention.
3. TYPES OF CACHE WE OPERATE
3.1 Browser Cache (on the Hotel Partner's computer)
When a Hotel Partner opens the Platform in a browser, the browser stores static resources locally so that subsequent visits load faster.
| What is cached | Typical lifetime | Contains personal data? |
|---|---|---|
| Stylesheets, JavaScript bundles, fonts | Up to 12 months, versioned by content hash | No |
| Logos, icons, illustrations, static images | Up to 12 months | No |
| Application shell and offline fallback page | Up to 30 days | No |
| Language and localisation files | Up to 30 days | No |
3.2 Local and Session Storage (in the browser or app)
| What is stored | Lifetime | Purpose |
|---|---|---|
| Authentication session token | Until logout, or 30 minutes of inactivity, whichever is earlier | Keeps the user signed in |
| Refresh token | 7 days | Renews the session without re-login |
| Selected property, language and theme preference | Until cleared by the user | User convenience |
| Draft check-in form entries not yet submitted | Until submission, or 4 hours, whichever is earlier | Prevents data loss on accidental refresh |
| Cookie and consent choices | 12 months | Records consent state |
3.3 Mobile Application Cache (on the Hotel Partner's device)
| What is cached | Lifetime | Purpose |
|---|---|---|
| Property profile, room inventory and tariff configuration | 24 hours, refreshed on each app launch | Fast dashboard loading |
| Static reference data (State and district lists, nationality codes, document types) | 30 days | Offline form completion |
| Check-in records created while the device is offline | Until successfully synchronised to the server, and thereafter purged within 24 hours | Business continuity during connectivity loss |
| Application logs and crash diagnostics | 7 days on device | Troubleshooting |
3.4 Content Delivery Network (CDN) and Edge Cache
Static, non-personal assets are distributed through a CDN with points of presence in India. Every response containing personal data is transmitted with Cache-Control: no-store, no-cache, private headers and is never held at the edge. Authenticated API responses bypass the CDN cache entirely.
3.5 Server-Side Cache
| What is cached | Lifetime | Purpose |
|---|---|---|
| Session and token validation state | Until session expiry | Authentication performance |
| Rate-limiting and throttling counters | 15 minutes | Abuse prevention |
| Aggregated, non-identifying dashboard metrics | 5 minutes | Dashboard responsiveness |
| Database query result sets for reference tables | 1 hour | Reduces database load |
| One-time password verification state | Validity period of the OTP only | Verification flow |
All server-side caches holding any identifier are encrypted at rest and are flushed on deployment, on logout and on any credential change.
4. WHAT IS NEVER CACHED
The following are excluded from every cache layer — browser, application, CDN, edge and server — without exception:
- Aadhaar numbers and any other Government identity document numbers. These are not stored anywhere in the system in the first instance, and therefore never enter any cache.
- Raw facial images, video streams and core biometric information. The live capture is processed in memory and discarded; only the verification result persists.
- Facial templates. These are never written to a browser, device or edge cache.
- Complete payment card numbers, CVV, card PIN, net-banking credentials or UPI PIN. These never reach our systems.
- Passwords in plaintext. Credentials are stored only as salted, irreversibly hashed values.
- Statutory guest register submissions transmitted to police or immigration authorities. These are written directly to the audited system of record.
- Any personal data on a shared reception device after logout. Logout triggers a full clearance of local and session storage.
5. HOTEL PARTNER OBLIGATIONS REGARDING CACHED DATA
Because Hotel Partner devices frequently sit at a public-facing reception desk, the following obligations are mandatory and form part of the Terms & Conditions:
- Log out at the end of every shift. Logging out purges the local session cache, cached property data and any unsynchronised drafts.
- Do not permit browsers to save Platform passwords or to auto-fill credentials on shared machines.
- Do not use private, incognito or guest browser profiles as a substitute for logout, and equally do not rely on a shared browser profile across multiple staff members.
- Enable device-level screen lock with a timeout of not more than five minutes on every device used to access the Platform.
- Clear the application cache before transferring, selling, servicing or discarding any device on which the Platform has been used. The in-app Settings — Privacy — Clear Local Data control performs this.
- Report a lost or stolen device to info@atithibhaarat.com within twenty-four (24) hours, so that we may revoke all sessions and tokens issued to that device.
- Do not install unauthorised screen-capture, screen-recording, keystroke-logging or remote-access software on any device used for the Platform.
6. HOW TO CLEAR CACHED DATA
In the AtithiBhaarat mobile application: Settings — Privacy — Clear Local Data. This removes cached property data, drafts, preferences and diagnostic logs. It does not remove server-side records.
In the AtithiBhaarat web application: Profile menu — Sign Out. For a deeper clearance, use Profile menu — Privacy — Clear Local Data.
In the browser:
- Google Chrome: Settings — Privacy and security — Delete browsing data
- Mozilla Firefox: Settings — Privacy & Security — Cookies and Site Data — Clear Data
- Microsoft Edge: Settings — Privacy, search, and services — Delete browsing data
- Safari (macOS): Safari menu — Settings — Privacy — Manage Website Data
At the operating-system level:
- Android: Settings — Apps — AtithiBhaarat — Storage — Clear Cache
- iOS: Settings — General — iPhone Storage — AtithiBhaarat — Offload App
Please note. Clearing the cache signs the user out and removes locally saved preferences. It does not delete personal data held on our servers. To request server-side erasure, exercise the right to erasure under Section 13 of the Privacy Policy.
7. CACHE INVALIDATION AND FORCED PURGE
We forcibly invalidate cached data in the following circumstances:
- On logout, password change, or any change of role or permission;
- On withdrawal of consent by a Data Principal;
- On suspension or termination of a Hotel Partner account;
- On deployment of a new application version;
- On detection of anomalous access, credential stuffing or a suspected compromise;
- On receipt of a lawful direction from a competent authority;
- On a Hotel Partner reporting a lost or stolen device.
8. DATA RETENTION SCHEDULE
Personal data is retained only for as long as it serves the purpose for which it was collected, or for as long as a law in force in India requires it to be kept, whichever is longer.
| # | Record Category | Retention Period | Basis |
|---|---|---|---|
| 1 | Hotel Partner account, KYC and licensing records | Term of the relationship + 3 years | Contract; fraud prevention; defence of claims |
| 2 | Hotel Partner user accounts and role assignments | Term of the relationship + 1 year | Contract; audit |
| 3 | Statutory guest register entries | As prescribed by the applicable State police rules; for foreign nationals, as prescribed under the Registration of Foreigners Rules, 1992 | Section 7(b), DPDP Act — compliance with law |
| 4 | Digital check-in and check-out transaction records | 3 years | Service delivery; dispute resolution; billing |
| 5 | Traveller ABIN identity record | For so long as the ABIN is active, and until consent is withdrawn or the account is closed | Consent |
| 6 | Facial liveness template | Deleted immediately on completion of the verification attempt | Data minimisation |
| 7 | Raw liveness capture (video or image frames) | Never persisted; processed in volatile memory and discarded | Data minimisation |
| 8 | Security, access and audit logs, and associated traffic data | 1 year — not less than one (1) year under Rule 6 of the DPDP Rules, 2025, and, for ICT system logs, not less than 180 days maintained within India under the CERT-In Directions dated 28 April 2022. The longer of the two applies. | Security; detection, investigation and remediation of unauthorised access; investigation of offences |
| 9 | Application and error logs | 90 days | Troubleshooting |
| 10 | Invoices, credit notes, GST records and payment records | 72 months from the due date of furnishing the annual return, per Section 36 of the CGST Act, 2017 | Tax law |
| 11 | Books of account and statutory financial records | 8 financial years, per Section 128(5) of the Companies Act, 2013 | Company law |
| 12 | Consent records and consent withdrawal logs | Life of the consent + 3 years | Demonstrating lawful basis |
| 13 | Grievance and complaint records | 3 years | Consumer Protection (E-Commerce) Rules, 2020 |
| 14 | Marketing consents and unsubscribe records | Until withdrawal + 12 months | Proof of opt-out |
| 15 | Backups and disaster-recovery snapshots | 30 days, rolling, on a rolling basis | Business continuity |
| 16 | Anonymised and aggregated analytics | Indefinitely, as no individual is identifiable | Outside the scope of the DPDP Act |
Where two periods conflict, the longer statutory period prevails, and the data is placed under restricted access ("legal hold") for the remainder of that period, accessible only for the compliance purpose.
9. DELETION AND ANONYMISATION PROCESS
9.1 Automated purge. A scheduled job runs daily to identify records that have crossed their retention threshold and to delete or anonymise them.
9.2 Method of deletion. Records are removed from primary databases by hard deletion, not by a "soft delete" flag, save where a legal hold applies. Deletion is recorded in the audit log.
9.3 Anonymisation. Where a record has continuing analytical value, direct and indirect identifiers are irreversibly stripped so that no individual can be re-identified, whether alone or in combination with other data reasonably available. Anonymised data ceases to be personal data.
9.4 Backups. Deletion propagates to backups on the next backup rotation. Backups are encrypted, access-restricted, and are used only for restoration in a disaster-recovery event and never for routine access. Maximum residual persistence in backups is 30 days, rolling.
9.5 Sub-processors. On expiry of a retention period, or on termination of a sub-processing arrangement, each sub-processor is contractually required to delete or return the relevant data and to certify deletion.
9.6 Legal hold. Where data is the subject of pending or reasonably anticipated litigation, an investigation, or a direction of a competent authority, automated purge is suspended for that record until the hold is lifted.
10. WHAT HAPPENS ON TERMINATION OF A HOTEL PARTNER ACCOUNT
| Stage | Timeline | What Happens |
|---|---|---|
| Termination or expiry | Day 0 | Platform access revoked; all sessions and tokens invalidated; all caches purged |
| Data export window | Day 0 to Day 30 | The Hotel Partner may download its own records in a machine-readable format |
| Grace period | Day 30 to Day 90 | Data retained in a restricted, read-only state to permit reactivation |
| Deletion | After Day 90 | Operational data deleted or anonymised |
| Statutory residue | Per Section 8 above | Guest register, tax, audit and grievance records retained for their prescribed statutory periods only, under restricted access |
11. YOUR RIGHTS
Nothing in this Cache Policy limits the rights of a Data Principal under Chapter III of the DPDP Act, including the right to seek erasure. Where a request for erasure is received, we shall comply save to the extent that retention is compelled by law, and shall inform the requester of the specific ground and the residual period.
Requests may be made to info@atithibhaarat.com.
12. AMENDMENTS
We may revise this Cache Policy to reflect changes in technology, law or our practices. Material changes will be notified at least 30 days in advance through the Platform and by email to registered Hotel Partners.
13. CONTACT
Data Protection Officer: Jayant Chaubey, info@atithibhaarat.com Security Incidents: info@atithibhaarat.com Grievance Officer: Jayant Chaubey, info@atithibhaarat.com, +91 77938 80880 Address: 101, Vishveshwariya Nagar, Gopalpura Bypass, Durgapura, Jaipur, Rajasthan – 302018
Governed by the laws of India. Courts at Jaipur, Rajasthan shall have exclusive jurisdiction, subject to the arbitration provisions of the Terms & Conditions.