Security

Security at PG Nexonis built around one assumption: the most damaging failure is not an outsider breaking in, but one operator’s staff seeing another operator’s tenants, or a staff member seeing money they have no business seeing. The controls below are organised around preventing that.

1. Tenancy isolation

Every record in the platform — property, branch, floor, room, bed, tenant, invoice, ticket — is scoped to the operator that owns it. That scope is enforced on the server, on every query, for every request. There is no code path in which a request authenticated as one operator can read another operator’s data, and no interface flag that can be flipped to widen it.

2. Access control

• Roles are server-side. Permissions are checked at the API, not by hiding buttons. A staff member who is not allowed to settle a deposit cannot do it by calling the endpoint directly.
• Roles are yours to define. Owners create custom roles and grant only the permissions a job actually needs — a warden who manages complaints need not see finances.
• Tenants see only themselves.A tenant’s app session can reach that tenant’s own invoices, deposit, complaints and visitor approvals, and nothing about any other resident.
• Passwords are stored as salted hashes using a modern key-derivation function. We never store them in a form we could read, and we cannot tell you your password — only reset it.
• Sessionsexpire, and revoking a staff member’s access ends their active sessions rather than waiting for them to lapse.

3. Encryption

• All traffic is served over TLS 1.2 or higher. HTTP requests are redirected, not accepted.
• Data at rest, including database storage and uploaded documents, is encrypted.
• Backups are encrypted with keys held separately from the data they protect.
• Uploaded identity documents are served through short-lived, signed URLs, never public links.

4. Audit trail

Every action that moves money or changes occupancy is recorded with the actor, the timestamp and the before-and-after values: payments marked received, late fees waived, deposits settled, tenants moved in or out, rent amounts changed. This is what makes a disputed deduction resolvable six months later, and it is why the trail is append-only — entries cannot be edited or deleted from the interface, by any role.

5. Infrastructure

• Hosted on managed cloud infrastructure in Indian regions, in private networks.
• Databases are not exposed to the public internet.
• Administrative access requires multi-factor authentication and is limited to the engineers who need it.
• Dependencies are monitored for known vulnerabilities and patched on a defined schedule; critical fixes are applied out of band.
• Secrets are held in a managed secret store, never in source control.

6. Backups and recovery

• Automated encrypted backups run daily, retained for 35 days.
• Point-in-time recovery lets us restore to a moment before an incident rather than to the previous night.
• Restores are tested periodically — a backup that has never been restored is not a backup.

7. Data handling by our team

Our engineers do not browse customer data. Access to production data is limited, requires a recorded reason, and is logged. Where we need to reproduce a problem, we ask you first and work from the smallest slice of data that will do. What we collect and how long we hold it is set out in the privacy policy.

8. Incident response

If a breach affects your data, we will contain it, investigate it, and notify affected account holders without undue delay and within 72 hours of confirming it, along with CERT-In and the Data Protection Board of India as the law requires. The notification will say what happened, what data was involved, and what we are doing about it — even where that is not flattering to us.

9. What we need from you

The platform cannot protect you from an account you leave open. Please:

• give every staff member their own login, and never share credentials;
• grant the narrowest role that lets someone do their job;
• revoke access the day a staff member leaves;
• upload identity documents only where you genuinely need them on record;
• report anything that looks wrong, quickly.

10. Reporting a vulnerability

If you believe you have found a security issue, email security@pgnexon.in with enough detail to reproduce it. We acknowledge within 2 business days and keep you updated until it is closed.

We will not pursue action against researchers who report in good faith, give us reasonable time to fix the issue before disclosing it, and avoid privacy violations, data destruction or service degradation while testing. Please do not run automated scans against production, and do not access any account that is not yours.

11. Contact

Security questions, or a security review before you sign: email security@pgnexon.in or srd0766@gmail.com.