1. Purpose
Personal information should be kept for as long as there is a reason to keep it, and no longer. This policy sets out what those reasons are for each category of information Eassy Finserve holds, so that:
- information is available while it is genuinely needed;
- information that is no longer needed is disposed of securely rather than accumulating;
- obligations that require us to keep something are recorded, rather than being discovered at the point of deletion.
It applies to information held in the Eassy Finserve website and its administrative Dashboard, in the company's email, and in backups of either.
2. Principles
- A retention period needs a reason. Every period in section 3 is tied to a stated purpose. When the purpose ends, the period ends.
- Legal holds override everything. Where a law, a regulator, a contract, or an active or reasonably anticipated dispute requires information to be kept, it is kept until that requirement ends — including where a customer has asked for deletion. Section 5 covers this.
- Delete rather than archive by default. Keeping something "just in case" is not a purpose.
- Minimise before retaining. Where a purpose can be met by a reduced or aggregated record, the identifying detail is removed rather than retained.
- Deletion means deletion. Section 4 sets out what must actually happen, including in backups.
3. Categories, Purpose, and Retention Periods
Periods marked
[TBD]await the business and legal decisions listed in the Document Status block above.
3.1 Contact and Enquiry Submissions
What: Name, email address, phone number, the service selected, enquiry details (which may include loan amount, employment or business type, and income range), message content, and any files uploaded with the submission.
Purpose: To respond to the enquiry, to assist with the requested service, and to keep a record of what was discussed and agreed.
Retention: [TBD] — proposed 3 years from the last substantive contact on the record, or from closure of the request, whichever is later.
Note: The Dashboard marks a record deleted before it is removed (deletedAt), so a deletion by staff is reversible for a short window and is recorded in the audit trail. That soft-deleted state is not the end of the retention period — it is the beginning of it. Permanent removal must follow.
3.2 Uploaded Documents and Attachments
What: Files a customer uploads with an enquiry or through the Client Portal — commonly identity, income, bank, and property documents.
Purpose: To assess and progress the request the customer submitted them for.
Retention: [TBD] — proposed the same period as the enquiry they belong to, and never longer. These are the most sensitive records the company holds; they should be the first thing deleted, not the last.
Note: Attachments live in object storage separately from the database row that points at them. Deleting the record does not delete the file. Any deletion procedure must remove both, and section 4.2 covers this explicitly.
3.3 Customer and Client Portal Accounts
What: Client record (name, email, phone), portal sessions, and one-time sign-in codes.
Purpose: To let a customer sign in and see their own requests.
Retention:
- Client record:
[TBD]— proposed 3 years after the last sign-in or last active request, whichever is later. - Sign-in codes (
ClientOtp): minutes. Each code carries an expiry and is invalidated once used or once the attempt limit is reached. Codes are stored hashed, never in plain text. - Portal sessions (
ClientSession): expire automatically at the end of the session lifetime or after the inactivity timeout, and are revoked server-side on sign-out.
3.4 Service and Case Information
What: Status history, staff notes, follow-ups, ownership history, and message threads attached to a request.
Purpose: To manage the request, hand it over between staff, and evidence what was done and when.
Retention: [TBD] — proposed the same period as the enquiry the record belongs to. Internal notes are not visible to the customer but are part of the same record and are governed by the same period.
3.5 Job Applications and CVs
What: Applications, CVs, and related correspondence.
Purpose: To assess a candidate for a role.
Retention: [TBD] — proposed 6 months after the role is filled or withdrawn, unless the candidate agrees to be kept on file for future openings, in which case 1 year from that agreement.
Note: The website does not currently have a careers page or any application form. This category exists so that applications received by email are covered, and so the rule is already written if a careers feature is added.
3.6 Emails and Communications
What: Email to and from support@eassyfinserve.com, and automated mail the site sends (enquiry acknowledgements, staff notifications, status updates, sign-in codes).
Purpose: To handle the matter discussed and to evidence what was communicated.
Retention: [TBD] — proposed 3 years, aligned with the enquiry retention period, so a request and the correspondence about it do not expire at different times.
Note: Automated mail is not stored by the website beyond what is recorded in the enquiry and audit records. Retention in the mailbox itself is governed by this policy and by the mail provider's settings.
3.7 Staff and Administrative Accounts
What: Staff account details, employee codes, roles, password hashes, session records, and password-setup tokens.
Purpose: To operate the Dashboard and control who can see what.
Retention:
- Account: deactivated immediately when a person leaves; the record is retained
[TBD]— proposed 3 years after deactivation so that historical actions in the audit trail remain attributable to a named person. - Passwords: stored only as a hash, never recoverable, and never written to any log or audit record.
- Sessions and setup tokens: expire automatically; sessions are revoked server-side at sign-out.
3.8 Security and Audit Logs
What: The audit trail of meaningful actions and security events — sign-ins, failed sign-in attempts, permission denials, record changes, and ownership changes — with the acting identity, timestamp, and request identifier.
Purpose: Security monitoring, incident investigation, and accountability. This is also the record that makes any other retention decision auditable.
Retention: [TBD] — proposed 1 year for routine entries and 3 years for security-significant entries (authentication failures, permission denials, privilege changes, account and role changes).
Note: Audit records are append-only and are not edited or deleted to tidy the trail — only expired by the periods above. Deleting a customer record does not delete the audit entries showing that it existed and was deleted; those entries retain the reference, not the customer's personal detail.
3.9 Website Analytics
What: Page address, referrer, campaign tag, coarse device, browser, and operating system, plus a salted daily visitor hash.
Purpose: To understand which pages are useful.
Retention: [TBD] — proposed 14 months.
Note: These records contain no personal identifiers. The visitor hash is one-way, is salted, and includes the date, so it cannot be linked across days or reversed to a person. IP addresses are not stored. Analytics is collected only where enabled by the business and allowed by the visitor.
3.10 Cookie Consent Records
What: The visitor's cookie choice, the time it was made, and the version of the categories shown.
Purpose: To honour the choice and not ask again.
Retention: 12 months, held in a cookie on the visitor's own device.
Note: This is deliberately not stored on our servers. Storing it server-side would require identifying returning visitors in order to look it up, creating exactly the tracking record that consent exists to limit.
4. Secure Deletion
4.1 Database Records
Records that reach the end of their retention period are permanently deleted from the production database, not flagged. Where a record must be retained in part for the reasons in section 5, the personal detail is removed and the non-identifying remainder kept.
4.2 Uploaded Files
Deleting a database row does not delete the file it points to. Any deletion of an enquiry, client record, or attachment must also delete the corresponding object from storage. A retention run that removes rows and leaves the documents behind has not deleted anything that matters.
4.3 Backups
Backups are retained on their own cycle and are not edited to remove individual records — doing so would compromise their integrity as backups. Information deleted from production therefore persists in backups until those backups age out of the cycle, which is [TBD] and must be stated here once confirmed.
Restoring from a backup must be followed by re-running any deletions that had already been applied, so a restore does not silently resurrect deleted information.
4.4 Paper and Devices
Any printed customer information is shredded. Devices and storage media that held customer information are securely wiped or destroyed before disposal, transfer, or reuse.
4.5 Evidence
Deletion runs are recorded in the audit trail: what category, how many records, when, and by whom. Deletion should be as evidenced as retention.
5. When Information Must Be Kept
Retention periods do not apply where information must be kept for:
- Legal or regulatory obligation — including record-keeping duties under applicable Indian law.
- Accounting and tax — transaction and financial records, for the statutory period.
- Contractual requirement — where an agreement with a lender, insurer, or partner requires it.
- Establishing, exercising, or defending a legal claim — including where a dispute is active or reasonably anticipated.
- Security — where a record is needed to investigate or respond to a security incident.
Where one of these applies, the information is kept for that purpose only, access is restricted to those who need it, and it is deleted once the obligation ends.
This also applies to a customer's deletion request: where the law requires us to keep something, we will say so and explain why, rather than deleting it or ignoring the request.
6. Responsibility and Review
The company is responsible for applying this policy. Retention periods are reviewed at least annually and whenever the website's data model changes.
Adding a new kind of record to this application requires adding it to section 3 in the same change. A retention policy that does not cover something the system stores is not a retention policy.
7. Contact
To ask about this policy, to ask what information we hold about you, or to request deletion:
Eassy Finserve (OPC) Private Limited Email: support@eassyfinserve.com Phone: +91 75429 79529 Address: Khushar Chowk, Near HP Petrol Pump, Kushar Khanpati, Mahua, Vaishali, Bihar 844122
See also our Privacy Policy, Cookie Policy, Information Security Policy, and Grievance Redressal Policy.