The DPDP Act and Housing Societies: A Data Compliance Guide for RWA Committees

Why a data protection law applies to a housing society at all

Most committees hear "data protection law" and assume it is a problem for banks, hospitals, and tech companies — not for a residential society that just wants to know who is at the gate. The Digital Personal Data Protection (DPDP) Act, 2023 does not carve out an exception for housing societies. The moment an RWA or managing committee collects a resident's phone number, a visitor's ID details, a domestic staff member's biometric attendance, or footage from a gate CCTV camera, it is processing personal data under the Act — and under the Act's terms, the society (through its committee) is a "Data Fiduciary": the entity responsible for how that data is collected, used, stored, and eventually deleted.

That responsibility does not shift to a vendor. If a society uses a visitor management app, an accounting platform, or a CCTV system from a third-party provider, the vendor is typically a "Data Processor" acting on the society's instructions — the committee remains the party accountable for what happens to residents' and visitors' data, regardless of which software or hardware is doing the actual collecting.

Where a typical society is already handling personal data

• Visitor logs: names, phone numbers, vehicle numbers, photographs, and the flat being visited
• CCTV footage covering common areas, gates, and in many societies, lift lobbies and parking levels
• Resident directories: names, contact numbers, family details, and in some cases ID proof collected at onboarding
• Domestic staff and vendor records: ID verification details, biometric attendance, police verification documents
• Payment and billing data tied to individual flats and residents
• Communication data: broadcast lists, complaint records, and committee correspondence naming specific residents

Any committee that reviews this list honestly will find it is already sitting on several categories of personal data the Act treats as sensitive by association — even without touching medical or financial data specifically.

What the Act expects from the committee, in practical terms

• Purpose limitation: data collected for gate security (a visitor's identity, for instance) should be used for that purpose, not repurposed to track resident lifestyle or movement patterns without a separate basis for doing so
• Notice and consent: residents and visitors should be told, in reasonably clear terms, what is being collected and why — a printed or digital notice at the gate, and terms residents see when they use a resident app, go a meaningful distance here
• Data minimisation: collect what the stated purpose actually needs. A visitor's phone number for approval is defensible; also asking for their full address rarely is
• Reasonable security safeguards: access to visitor logs, CCTV footage, and resident records should be restricted to committee members or staff who genuinely need it — not left open to anyone with a login
• Retention limits: CCTV footage in particular should not be retained indefinitely on the assumption that it might be useful someday. A defined retention window (commonly cited in general guidance as somewhere in the 30–90 day range, though there is no single number fixed by the Act itself) is far easier to defend than an unlimited archive
• Breach handling: if resident or visitor data is exposed or misused, the Act contemplates a duty to report the breach — not to quietly patch the gap and move on

Where the exposure is real, not theoretical

The DPDP Act's penalty structure is meaningfully larger than most societies expect from an "internal" governance matter — provisions for significant financial penalties on a data fiduciary exist for serious failures such as not taking reasonable security safeguards or failing to report a breach. A society is unlikely to be anyone's first enforcement target, but "unlikely to be targeted" and "not accountable" are different things, and the exposure sits with the committee members who signed off on how data is handled, not with an anonymous "society."

Where societies commonly fall short today

• CCTV footage kept indefinitely because nobody owns the decision to delete it, or because the DVR simply overwrites on its own schedule with no one having actually set a retention policy
• Visitor and resident data spread across WhatsApp groups, personal phones of security staff, and paper registers, with no single point of accountability or access control
• No visible notice at the gate or in the resident app explaining what visitor or resident data is collected and why
• Vendor or staff verification documents (ID copies, police verification papers) stored in a shared, unrestricted folder rather than access-controlled storage
• No process for what happens to a resident's or a departed staff member's data after they leave the society

What a defensible position looks like

• A short, plainly worded notice — at the gate and in whatever app or portal residents use — describing what visitor, resident, and CCTV data is collected and its purpose
• A named point of accountability at the committee level for data-handling decisions, rather than an implicit assumption that "the security agency handles it"
• Role-based access to visitor logs, resident directories, and footage, so data is only visible to committee members or staff with an actual operational need
• A stated retention period for CCTV footage and visitor logs, applied consistently rather than left to whatever a device's storage happens to allow
• A basic incident process: who is told, and what happens, if a laptop with resident data goes missing or an unauthorised person is found accessing logs

How MySocietyEntry helps

MySocietyEntry does not replace the committee's obligations as data fiduciary — that responsibility stays with the society. What the platform helps with is reducing the number of places resident and visitor data actually lives: gate entries, resident records, and staff verification documents sit in one access-controlled system with role-based permissions, rather than spread across personal phones, paper registers, and shared folders with no clear owner. That does not by itself make a society DPDP-compliant, but it removes several of the sloppiest and most common exposure points — the WhatsApp group with a visitor's phone number in it, the unattended register at the gate — that make a genuine compliance effort harder than it needs to be.

Final takeaway

The DPDP Act does not require a housing society to become a compliance department. It does require the committee to know what personal data it is holding, why it is holding it, who can see it, and how long it stays around — and to be able to answer those questions if a resident, a departed staff member, or eventually a regulator asks. Most societies are not in a strong position to answer any of that today, which makes this a governance gap worth closing before it becomes an incident rather than after.