TenantSimplified
Privacy Policy
Version 1.0.0 · Effective 17 August 2026
1. Who this policy covers
This Privacy Policy describes how TenantSimplified ("we", "the operator") handles personal information in the TenantSimplified application.
It applies to people who sign in as users, and to personal information that a workspace stores about tenants, owners, vendors, staff, and other contacts.
This policy is not a certification, audit report, or guarantee. It describes practices that exist in the current application, and it states where a practice is not implemented.
2. Who is responsible
Each workspace (client) decides what operational records to store. The operator provides the software and hosting used to process those records.
If you are a tenant or owner whose details appear in a workspace, the workspace administrator is usually the organisation you should contact first about correction or deletion of that operational record.
3. Information we collect
Account users: name, email address, optional phone number, hashed password (not the password itself), role and permission assignments, sign-in metadata (time, IP address and user-agent when the server receives them), and legal-acceptance records when you accept the Terms of Use.
Workspace records may include property, unit, tenant, owner, lease, invoice, payment, expense, maintenance, vendor, document, and related notes or files that users upload.
Technical logs may include request paths, status codes, and correlation identifiers. Logging configuration redacts password and token fields.
We do not intend to collect device fingerprints beyond ordinary IP address and user-agent on relevant server requests.
4. How we use information
We use this information to:
- authenticate users and keep sessions;
- enforce workspace (client) isolation and permissions;
- operate property-management features you use;
- record Terms of Use acceptance;
- investigate security events and abuse;
- provide reports that a workspace exports.
We do not sell personal information.
5. Access control (what the software actually does)
The current application:
- stores user passwords using Argon2id hashing; passwords are not stored in plain text;
- uses short-lived access tokens and hashed refresh tokens, with logout that revokes refresh tokens;
- enforces client/workspace isolation on server-side queries for core modules (including properties, owners, tenants, leases, invoices, payments, expenses, maintenance, vendors, and documents);
- uses role-based permissions; platform SUPER_ADMIN is a separate operator role;
- applies HTTP security headers via Helmet;
- rate-limits many public auth routes; password sign-in also uses account lockout after repeated failures.
The current application does not implement application-level encryption at rest of database fields. A configuration key named for field encryption may exist in environment files without being used by application code. Do not assume disk or field encryption from this policy.
The current application does not claim ISO, SOC, or other formal security certification.
6. Files
Document uploads are associated with a workspace record and are served only after an authenticated check that the document belongs to the current workspace. Upload size and type limits apply.
Some property photos and client logos may be stored as files whose URLs are used in the product UI. Treat uploaded files as workspace-confidential and do not publish guessable links.
7. Cookies and browser storage
The web application stores session tokens in the browser session storage for the tab/session, uses a browser-session cookie to detect a new browser session, and signs users out after a period of inactivity. Clearing the browser session ends that stored session.
8. Third parties
Depending on configuration, the Service may use:
- a PostgreSQL database;
- Redis in some deployments;
- Google sign-in, if that option is enabled on the server and in the UI;
- a hosting provider for the application and files.
We do not list secret credentials here. Optional Google sign-in is processed by Google according to Google's terms when you use that button.
9. Retention, correction, and deletion
Users can edit their own first name, last name, and phone number in profile settings. Email is not self-service editable in the current application.
Authorised workspace users can edit operational records (for example tenant or owner details) according to their permissions.
The current application supports deactivating users and soft-deleting many records (including documents). It does not currently provide a self-service "download all my personal data" package, a tenant-hard-delete API, a client-hard-delete API, or a backup-purge API.
Backups, if any, are an infrastructure matter and are not promised by this policy.
10. Security incidents
There is no automated in-product data-breach workflow. If the operator becomes aware of a security incident affecting your workspace, the operator will handle it operationally. This policy does not invent a notification SLA.
11. Children
The Service is intended for adult business users. It is not directed at children.
12. International processing
The operator and hosting location are expected to be in India unless you have been told otherwise. Do not assume a specific data-residency certificate from this policy.
13. Changes
When this policy's published version changes, the new text will be shown at the public Privacy Policy page. Material changes to the Terms of Use may require a new in-application acceptance.
14. Contact
Privacy questions should be directed to the platform operator or your workspace administrator through the application.