DPDP Act 2023 for Housing Societies: What Your Committee Must Fix Before November 2026

The DPDP Act was passed in 2023 but given an 18-month transition period before enforcement began in earnest. That window closes on 13-14 November 2026, a little over eight weeks from now. After that date, the Data Protection Board of India moves from a guidance posture to active enforcement, meaning it can act on a resident's complaint rather than simply asking an organisation to fix things quietly.

Penalties for serious violations under the Act can run up to ₹250 crore. That figure is written with large corporations in mind, not a residential society, but the law itself makes no such distinction. What it does specify is that the persons who decide the purpose and means of processing, in a society's case, the managing committee, are the ones who answer for it. Property management platforms like ADDA and MyGate have already been running DPDP workshops for RWAs since the start of this year, and that's usually a reliable sign that the better-run societies are already ahead of this, not waiting for November.

Almost every society's DPDP risk sits in the same three places, and none of them need any malicious intent to become a violation, just a process nobody has looked at since it was set up.

The visitor register is the most obvious. A security guard collects a visitor's name and phone number because that's how it has always been done, not because anyone asked the visitor for consent or decided how long the entry should be kept. Registers running back years with no retention policy are common.

CCTV is the more serious exposure. Footage gets pulled for a parking dispute or a theft complaint and ends up forwarded into a resident WhatsApp group as informal justice, footage collected for security now being used for something else entirely. That gap between why data was collected and what it's actually used for is exactly what the Act is built to catch.

The society management app is the third, and the one committees examine the least. Every resident's phone number, flat number, family details and payment history sits on a vendor's servers, and most committees have never read what that vendor's data processing agreement actually says about where the data is stored, who can access it, or how long it's kept after a resident moves out.

This is the part committees underestimate most. A complaint under the DPDP Act isn't filed against 'the society' as an abstract entity, it's examined against the people who made the decision, the managing committee members who approved the CCTV vendor, signed off on the visitor management process, or never set a retention policy in the first place.

This is the same pattern Maharashtra housing societies already know from the MCS Act, where committee members carry personal liability for bye-law non-compliance rather than the society absorbing it collectively. DPDP works the same way. There's no separate legal shield for a 40-flat committee that doesn't exist for a listed company, there's simply a much lower chance anyone has checked, until a resident actually complains.

Before fixing anything, sit down as a committee and list out every place personal data enters the society. For each one, write down what's collected, why, who can access it, and how long it's kept. Done properly, this single exercise usually surfaces most of the gaps on its own.

• Visitor register: name, phone number, vehicle number, purpose of visit, entry and exit time
• CCTV footage: entrance, lobby, parking, and how long each camera's footage is actually retained today
• Society management app: resident phone numbers, flat details, family members, payment and dues history
• Tenant and staff KYC: Aadhaar copies, PAN, police verification forms kept in physical files
• Informal records: the treasurer's Excel sheets, the secretary's WhatsApp broadcast list, any shared Google Sheet with member details

Once the audit is done, four changes cover most of the gap for a typical society.

• Set a CCTV retention limit, thirty days is a reasonable default unless a specific incident needs longer, and stop pulling footage into resident WhatsApp groups. Route any footage request through one named person and a short written request instead.
• Tighten the visitor register to what security genuinely needs, and if visitor entry runs through a digital app, ask that vendor directly what happens to the data afterward.
• Get explicit, separate consent for anything beyond basic security use. A resident directory shared for festival planning is a different consent from a directory handed to a vendor for marketing, and most societies never draw that line today.
• Name one person, not 'the committee' collectively, as the point of contact for any resident's data request or grievance. The Act gives residents the right to ask what data the society holds on them and to request correction or deletion, and having nobody clearly responsible for that is a governance gap that looks bad the moment it's tested.

If your society runs its accounting, billing or gate access through an app, and most do now, the vendor's own DPDP posture becomes your society's exposure too. Ask directly where resident data is stored, how long it's retained after a member exits, who inside the vendor's team can access it, and what happens to it if the society ever switches software.

On SocietyBee, society data is stored on Supabase in AWS's Mumbai region, encrypted with AES-256 at rest and TLS 1.3 in transit, with each society's data isolated from every other society on the platform, even when the same CA manages multiple societies. That's the baseline any vendor handling resident phone numbers, flat details and payment history should be able to answer without hesitation. If yours can't, that's worth knowing before November, not after a complaint.