Security and privacy at KeyMatrix
You are being asked to put a society’s members, bank ledger and gate footage into someone else’s system. These are the controls behind that, described plainly enough to take to a committee.
KeyMatrix hosts customer data in Indian data centres, encrypts it with AES-256 at rest and TLS in transit, restricts access by role, logs every sensitive action, and takes daily backups with point-in-time recovery. Resident data is never sold and the resident app carries no third-party advertising.
How your data is protected
A society’s data is not uniformly sensitive. A circular about the water tank cleaning is not the same as the members register, and neither is the same as the bank ledger or last night’s gate footage. The controls below apply across the platform, but the reason they matter varies by what they are protecting — which is worth saying to a committee that is about to approve this.
Encryption in transit and at rest
Every connection to KeyMatrix — the committee’s browser, the guard’s phone, the resident app, the API — is TLS-encrypted. Traffic over plain HTTP is redirected, not accepted, so a misconfigured client cannot silently downgrade.
Data at rest, including database contents, uploaded documents and backups, is encrypted with AES-256. That covers the case that actually happens in practice: not an attacker breaking encryption, but a storage volume or backup file existing somewhere it was not supposed to.
Backups and disaster recovery
Backups run daily, with point-in-time recovery so a restore can target a moment rather than a nightly snapshot. The distinction matters for the failure a society is most likely to hit, which is not a data-centre fire but somebody deleting or mis-importing a billing run at four in the afternoon.
Backups are encrypted and retained on the same India-resident infrastructure as production. A restore is a support request, not a self-service action, precisely because it overwrites live data.
Access control
Most real-world data incidents in property software are not intrusions. They are the wrong person inside the system seeing something they should not.
Role-based permissions
Committee members, staff, guards, accountants and residents each see only what their role permits. A guard can log a visitor and cannot open the ledger. A resident sees their own flat’s bills, dues and complaints, not their neighbour’s. An accountant can be given the books without the gate footage.
Roles are scoped to the property as well as the function, which is what makes multi-property operation safe: a manager running four societies sees four, and the committee of each sees only its own.
Complete audit logs
Every sensitive action — a bill edited, a payment recorded, a member’s details changed, a document deleted, a permission granted — is written to an audit log with the actor, the timestamp and what changed. The log is append-only from the application’s point of view: there is no screen that edits it.
This is as much a protection for the committee as from it. When a figure is questioned at an AGM, the answer is a record of who changed what and when, rather than a recollection. It is also what makes an outgoing committee’s handover defensible.
How KeyMatrix staff access data
Our support and engineering staff access customer data only when it is needed to resolve a support request, with the customer’s consent, and that access is logged like any other. There is no routine browsing of production data, and support does not need standing access to answer most questions.
Infrastructure and uptime
KeyMatrix runs on managed cloud infrastructure in Indian regions. Application servers, the database and file storage are all India-resident, including backups and logs — which is the answer a committee usually wants when it asks where the data physically is.
The platform is monitored continuously, and the parts a society notices first when something is wrong — payment collection, gate check-in, the resident app — are monitored as their own paths rather than only as part of overall availability. A gate that cannot check in a visitor is an outage even if every other page loads.
Planned maintenance is scheduled outside Indian business hours where it needs downtime at all, and communicated in advance to the committee contact rather than only to whoever happens to be logged in.
Privacy: what we collect and why
KeyMatrix processes personal data because a property cannot be run without it: names and flat numbers to bill, contact details to notify, visitor records to secure the gate, and payment records to keep the books. What matters is the boundary around that — what is collected, why, who sees it, and how long it is kept.
The society is the owner of its data. KeyMatrix processes it on the society’s instructions and does not repurpose it. Specifically: resident data is not sold, not licensed to third parties, and not used to target advertising, because there is no advertising in the product to target. The subscription is the entire business model.
India’s Digital Personal Data Protection Act frames this as a relationship between a data fiduciary and a data principal, and the practical obligations it creates — purpose limitation, consent, the ability to correct and erase, a named grievance officer — are ones the platform is built to support rather than ones a society has to satisfy around it.
- Purpose limitation. Data collected to run the property is used to run the property, and nothing else.
- Retention. Records are kept while the account is active and deleted from production after a defined window once it closes.
- Correction and erasure. Residents can have their details corrected, and erasure requests are handled subject to statutory record-keeping the society is legally required to maintain.
- Grievance officer. Privacy questions and data requests go to privacy@keymatrix.co and are answered by a named person.
Report a vulnerability
If you have found a security issue in KeyMatrix, we want to hear about it before anyone else does. Write to privacy@keymatrix.co with enough detail to reproduce the issue — the endpoint or screen, the steps, and what you were able to see or do that you should not have been.
We will acknowledge the report, keep you updated while it is being fixed, and credit you if you would like to be credited. We will not pursue action against a researcher who reports an issue in good faith, tests only against their own account or data, avoids privacy violations and service degradation, and gives us reasonable time to fix the problem before disclosing it.
Please do not test against another society’s live data, and please do not run automated scanning that degrades the service for the properties depending on it.