Information Security Policy

1. Purpose and Scope

Eassy Finserve handles information that matters: identity documents, income and bank statements, property papers, and the details of what people are trying to borrow or insure. This policy sets out how that information is protected.

It covers the Eassy Finserve website, its administrative Dashboard, the Client Portal, the systems that store their data, and everyone who has access to any of them — employees, contractors, and third-party service providers.

2. Principles

• Least privilege. Access is granted to what a role needs and nothing more.
• Defence in depth. No single control is relied upon alone. A check in the browser is never the control; the server enforces it independently.
• Secure by default. A feature that is misconfigured fails closed, not open.
• Verify server-side. Anything a browser sends is treated as untrusted input, including identifiers that claim to say who the sender is.

3. Access Control and Authentication

• Access to the Dashboard and the Client Portal requires authentication. There is no anonymous access to either.
• Every request is authorised individually. Permission is checked on each request against the acting user's role and, where relevant, their ownership of the specific record — not once at sign-in.
• Staff roles are tiered (Super Admin, Admin, Manager, Staff), and each tier grants a defined set of permissions. Sensitive operations, including creating management accounts, are restricted to the highest tier.
• A customer signs in to the Client Portal with a one-time code sent to their registered email address. Codes are short-lived, limited in attempts, stored only as a hash, and invalidated once used.
• Identity is always re-derived from the authenticated session on the server. An identifier supplied by the browser is never accepted as proof of who the sender is.
• Sessions expire on inactivity and again at an absolute lifetime. Signing out revokes the session on the server, not only in the browser.
• Accounts are deactivated immediately when a person leaves or no longer needs access.

4. Passwords and Credentials

• Passwords are stored using a modern memory-hard hashing algorithm with a per-password salt. They are never stored in a recoverable form.
• Plain-text passwords are never written to logs, audit records, error reports, or any other store.
• A password change requires the current password to be re-entered, so an unattended signed-in session cannot be used to take over the account.
• Password strength requirements are enforced on the server.
• Repeated failed sign-in attempts are rate-limited by both source and account identifier.
• Account lookup and sign-in responses are written so they do not reveal whether an account exists. The same message is returned whether an identifier is unknown, malformed, or belongs to a deactivated account.

5. Encryption and Secure Transmission

• All traffic is served over HTTPS. HTTP Strict Transport Security is enabled.
• Session cookies are HttpOnly, SameSite-restricted, and marked Secure in production.
• Credentials and secrets are never placed in URLs, query strings, or referrer-visible locations.
• Uploaded documents are stored in access-controlled object storage and served only through authenticated, authorised, short-lived links — never from a publicly guessable address.

6. Application, API, and Database Security

• Input validation. Every request body, query parameter, and route parameter is schema-validated on the server before use. Unknown fields are rejected rather than ignored, so a field that was not part of the form cannot be smuggled into a database write.
• Output control. Responses return an explicit set of fields. Password hashes, one-time-code hashes, internal notes, and other users' data are never included.
• Injection. Database access uses a parameterised query layer throughout. User input is never concatenated into a query.
• Cross-site scripting. Content that is rendered as HTML is sanitised through an allow-list before display.
• Cross-site request forgery. State-changing requests require a matching token, including sign-out.
• Rate limiting. Public endpoints, authentication endpoints, and anything that triggers a costly side effect are rate-limited. Authentication endpoints are limited by source and by identifier.
• Server-side request forgery. Where the server fetches an external resource, the permitted hosts are an explicit allow-list, not a wildcard.
• Security headers. Content Security Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and Permissions-Policy are set. Authenticated areas are additionally marked no-store and noindex.
• Errors. Callers receive a generic message and the correct status code. Stack traces, database errors, and internal paths are never returned to a caller; the real error is logged server-side.
• Access to the production database is restricted to the application and to named administrators. Credentials are held as environment secrets and are never committed to the repository.

7. Backup and Recovery [TBD]

The backup procedure must, once confirmed:

• take regular automated backups of the database and of uploaded documents;
• encrypt backups at rest and restrict access to them as tightly as the production data they copy;
• retain them on a defined cycle, stated in the Data Retention Policy;
• be restore-tested on a schedule — an untested backup is an assumption, not a backup;
• re-apply any deletions that had already been made, after any restore, so a restore does not resurrect deleted records.

Until items in section 7 are confirmed with the hosting and database provider, this section describes a requirement, not a running process. It must be completed before this policy is presented as final.

8. Logging and Monitoring

• Meaningful actions and security events are recorded in an append-only audit trail: who acted, what changed, when, the outcome, and a request identifier that ties a log entry to the request that produced it.
• Authentication successes and failures, permission denials, role and account changes, and record changes are all recorded.
• Secrets are never logged. Passwords, one-time codes, tokens, API keys, and SMTP credentials do not appear in the audit trail or in application logs.
• Audit records are not edited or deleted to tidy the trail; they expire only under the Data Retention Policy.

9. Vulnerability and Update Management

• Dependencies are kept current, and known-vulnerable versions are updated promptly.
• Security-relevant updates to the framework, runtime, and libraries are applied on a priority basis.
• Changes are reviewed before release, and the application is checked against the standards in when routes or data handling change.
• A control is never disabled to make something work. Where a control blocks a legitimate need, the need is met a different way.

10. Employees and Contractors

• Access is granted on the principle of least privilege and only for as long as the role requires it.
• Everyone with access is responsible for keeping their credentials confidential and for not sharing accounts. Shared logins are not permitted.
• Customer documents are accessed only where there is a business reason to do so. Access is recorded.
• Access is revoked on the day a person's engagement ends.
• Anyone with access is expected to report a suspected security problem immediately, and will not be penalised for reporting one that turns out to be harmless.

11. Third-Party Services

Eassy Finserve relies on third parties for hosting, database, object storage, and email delivery. For each:

• the provider is chosen with regard to its security posture and its own obligations;
• access credentials are held as secrets, scoped to what the application needs, and rotated when a person with access leaves;
• only the information necessary for the service is shared;
• a security failure at a provider is treated as an incident under section 12.

The specific providers are [TBD] pending confirmation, so that this section can name their categories accurately.

Customer information is not shared with advertising networks, data brokers, or analytics providers. The website's own analytics is first-party; see the Cookie Policy.

12. Security Incidents

12.1 Detection

An incident is any event that compromises, or may have compromised, the confidentiality, integrity, or availability of information — including unauthorised access, unauthorised disclosure, loss of a device holding customer information, malware, and a security failure at a service provider.

Indicators are drawn from the audit trail (repeated authentication failures, permission denials, unusual access patterns), provider alerts, and reports from staff or the public.

12.2 Response

On becoming aware of a suspected incident:

1. Contain — revoke affected sessions and credentials, and cut off the route being used.
2. Assess — establish what information was involved, whose, and over what period, using the audit trail.
3. Preserve evidence — do not delete logs or records relating to the incident.
4. Remediate — fix the underlying cause, not only the symptom.
5. Notify — inform affected individuals and any relevant authority where required by law, within the applicable deadline [TBD], with what is known, what is being done, and what the person should do.
6. Review — record what happened and what changed as a result.

12.3 Reporting a Suspected Incident

If you believe you have found a security problem with this website, or that your information may have been exposed, please tell us.

Email: support@eassyfinserve.com — subject line "Security" Phone: +91 75429 79529

Please include what you found, how to reproduce it, and when you noticed it. We ask that you give us a reasonable opportunity to fix a problem before disclosing it publicly, and that you do not access, modify, or delete other people's data while investigating.

Reports are welcome from anyone, including people outside the company. We will not pursue action against someone who reports a genuine security problem in good faith and in line with the request above.

13. Review

This policy is reviewed at least annually, and whenever there is a significant change to the application, the providers it depends on, or the applicable law.

14. Contact

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, Data Retention Policy, and Grievance Redressal Policy.