Resident Directory for a Housing Society: Privacy, Consent and Access
The resident directory
Every society needs to know who lives where. The committee needs it for billing and notices, the gate needs it to verify visitors, and residents genuinely benefit from being able to reach the neighbour whose car alarm has been going for an hour.
The trouble starts with how it is usually done: a PDF or an Excel file with every resident's name, flat, phone number and often email, circulated to a WhatsApp group. That file is now on two hundred phones, permanently, beyond recall, and it will be forwarded outside the society within a year.
A directory is worth having. A circulated spreadsheet is a data breach with a helpful format.
What the law expects
India's Digital Personal Data Protection Act applies to a housing society processing residents' personal data. The obligations are not onerous but they are real:
- Purpose limitation. Collect for a stated purpose, use it for that purpose.
- Data minimisation. Collect what you need, not what might be useful.
- Consent, with a genuine ability to withdraw it.
- Security safeguards appropriate to the data.
- Retention limits — remove data when the purpose ends, which for a directory means when the resident leaves.
- Correction rights. Residents can require inaccurate data to be fixed.
- Children's data requires verifiable parental consent, and should generally not be in a society-wide directory at all.
A society that circulates an unrestricted contact list satisfies almost none of this.
Separate the statutory register from the social directory
This distinction resolves most of the tension, and societies rarely make it.
The register of members is a statutory record the society must maintain — member name, flat, share details, nomination. It exists because the state act requires it, members have inspection rights over parts of it, and it is not optional or consent-based.
The resident directory is a convenience: contact details residents share with each other so neighbours can reach neighbours. It is optional, consent-based, and a resident may decline entirely without any consequence.
Conflating them produces both failures at once — residents feel compelled to publish personal contacts, and the society still cannot produce a proper members' register at audit.
Visibility tiers
Not everything should be visible to everyone. A workable model:
| Field | Visible to |
|---|---|
| Flat number and resident name | All residents |
| Owner vs tenant status | Committee |
| Phone number | Residents, only if the resident opted in |
| Committee only, by default | |
| Alternate and emergency contact | Committee and gate, not residents |
| Vehicle details | Gate and committee |
| Household help associations | Gate and committee |
| Identity documents | Restricted office-bearers only |
| Children's details | Not in the directory |
| Date of birth | Not needed; do not collect |
Two defaults do most of the work. Phone numbers should be opt-in, not opt-out — a resident who has not made a choice should not be published. And an in-app call or message path that connects residents without revealing the number is better than publishing it, and removes most of the reason to.
Collect the minimum. A directory does not need dates of birth, blood groups, occupations, native place, or photographs. Each field you add is one more thing to protect and one more reason a resident declines.
Rules to adopt
Put these in a short data policy approved by the committee, and tell residents:
- No bulk export. No PDF or Excel of the directory, ever, to anyone. This is the single most important rule. If someone needs to contact all residents, they use the notice system.
- No directory data for commercial use. Residents will ask for the list to promote a business. The answer is no.
- No sharing outside the society. Including with vendors, brokers and the security agency beyond what the gate genuinely needs.
- Search, not browse. Looking up a specific flat is a legitimate use; downloading everything is not. Rate-limit and log lookups.
- Deactivate on move-out. Part of the move-out checklist, not a later cleanup.
- Annual refresh. Ask residents to confirm their details once a year — it fixes accuracy and refreshes consent at the same time.
- A named person accountable for directory data, usually the secretary.
Tenants
Tenants belong in the directory. Excluding them is common, unkind, and operationally foolish — the gate and the committee need to know who actually lives in a flat, and a tenant who is invisible in the society's records is a problem when there is an emergency in that flat.
Record the owner separately for billing and governance, and the occupant for operations. Both, not one.
How this works on Plinth
The directory runs off the society's flat roster, so residents, gate records and billing refer to the same people rather than three lists that drift apart.
Fields carry visibility tiers, and contact details are opt-in per resident rather than published by default — with an in-app path to reach a neighbour without exposing their number. There is no bulk export of resident contacts, which is what prevents the circulated-spreadsheet failure entirely.
Residents can correct their own details, move-out deactivates the record along with associated gate access and household help, and lookups and changes write to the society's append-only audit log so misuse is visible rather than invisible.
Frequently asked questions
Is a housing society allowed to publish a resident directory? It can maintain one, with consent for contact details and appropriate access controls. Circulating an unrestricted list of every resident's phone number is where societies get into trouble.
Can a resident refuse to be in the directory? They can decline to share contact details. They cannot be left out of the statutory register of members, which serves a different purpose.
Can a society share resident contacts with vendors or brokers? No. That is outside the purpose for which the data was collected.
Should tenants be listed? Yes. The society needs to know who occupies a flat. Record the owner separately for billing and governance.
Can we keep a WhatsApp group instead? A group is not a directory, and adding residents to a group exposes every member's number to every other member — including people who never agreed to that.
How long should we keep a former resident's details? Remove them when they leave, as part of move-out. Retain only what the statutory register requires.
Step-by-step guides
Related: society document management · move-in and move-out checklist · WhatsApp and SMS broadcast
Get Plinth in your inbox
Monthly digest of governance tips and product updates.