If your society runs a shared EV charger and keeps its records digitally (app accounts, RFID tags, session logs, vehicle numbers or a camera on the bays), then on the Digital Personal Data Protection Act's own definitions it is a Data Fiduciary for that data. The duties apply "eighteen months from the date of publication" of a notification dated 13 November 2025, which counts to 13 May 2027. By then the committee needs a lawful basis for each item, a written notice of what it collects and why, a contract with any app vendor that processes data for it, security with a year of logs, a breach routine and a retention schedule. This is our reading of the texts, not legal advice.
Why your society is a Data Fiduciary, and the date the duties start
Section 2(s)(v) of the Digital Personal Data Protection Act, 2023 says a "person" includes "an association of persons or a body of individuals, whether incorporated or not", so a registered co-operative housing society and an unregistered residents' welfare association both count. Section 2(i) makes a Data Fiduciary "any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data". A committee that decides the shared charger will be billed per flat, through an app or a register, has decided both.
The household exemption does not apply. Section 3(c)(i) excludes "personal data processed by an individual for any personal or domestic purpose", and a society is not an individual. The boundary that matters is section 3(a): the Act covers data collected "in digital form" or "in non-digital form and digitised subsequently". A paper register that stays on paper sits outside it; once it is typed into a spreadsheet or photographed into a messaging group, it is inside.
The commencement notification is G.S.R. 843(E) of the Ministry of Electronics and Information Technology, dated 13 November 2025. Clause (a) brought section 2, the definitions, into force on publication. Clause (c) brings in sections 3 to 5, most of section 6, sections 7 to 17, most of section 27 (the Board's powers) and sections 28 to 34 (inquiry and penalties) "eighteen months from the date of publication of this gazette". It prints no calendar date; counting eighteen months from 13 November 2025 gives 13 May 2027, the date we use throughout. The Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E), same date) run on the same clock: rule 1(4) brings rules 3 and 5 to 16 into force "eighteen months after the date of publication" (in the Official Gazette, as corrected by G.S.R. 892(E) of 10 December 2025).
Sources, all hosted by the Ministry and last verified 16 October 2026: the Act as gazetted on 11 August 2023; G.S.R. 843(E); G.S.R. 846(E), the Rules; G.S.R. 892(E), the corrigenda.
No exemption for housing societies is in place: sections 17(3) and 17(5) let the Central Government relieve notified Data Fiduciaries of some or all duties, and neither the Rules nor the commencement notification names housing societies. This page covers only data generated by shared charging; gate and visitor apps, and cameras elsewhere on the premises, are outside its scope.
The EV-charging data map: sessions, vehicle numbers, payments, RFID and CCTV
List what you hold first; each row becomes an item in your notice.
| Data item | Purpose to state | Basis, on our reading | Held by |
|---|---|---|---|
| Flat number, member name, phone number | Registering a user; session and billing messages | Voluntarily provided for a stated purpose, section 7(a) | Society register; the app vendor if residents sign in by phone |
| Vehicle registration number | Matching a vehicle to a flat at the bay | Section 7(a), if asked once at registration | Issue register; sometimes the app |
| RFID tag or card number | Starting a session and attributing it to a flat | Section 7(a); mapped to a flat, it identifies a person | Issue register; charger or app |
| Session log: point, start, stop, units | Billing, disputes, fault-finding | Unsettled: produced by the charger, not handed over | Charger and app vendor; treasurer's exports |
| Amount billed, payment reference, UPI handle in the bank narration | Recovering dues; reconciling the account | Section 7(a) for the payment; your accounting duties for the record (see Retention) | Treasurer, bank statement, app payment module |
| Camera footage of the charging bays | Investigating damage, misuse or a fire at the bay | The least settled row; see below | Recorder in the security cabin, or a cloud service |
Session timing shows when a household is out; the short data-hygiene section of our access-control guide covers who may see what. Maharashtra's draft revised model bye-laws keep the parking ask small (a draft, not in force; status under Retention below; last verified 16 October 2026): draft bye-law 79(vi) asks a member to "intimate the Society in writing or by electronic means the registration number of the vehicle proposed to be parked", and says the society "shall not ordinarily insist upon the Registration Certificate, insurance policy or ownership document of the vehicle, unless required by law or for resolving a specific complaint or dispute". Outside Maharashtra it is only an example.
Section 9(1) requires "verifiable consent of the parent" before processing a child's data, and section 2(f) makes a child anyone under eighteen, so issue a teenager's e-scooter credential to the flat's adult member.
Cameras are the hardest row. Digital footage of identifiable people is personal data under section 2(t), yet section 7 lists no general security use for a private body, and consent under section 6(1) needs "a clear affirmative action", which on our reading a sign on the wall does not supply. Section 17(1) lifts most duties in Chapters II and III, though not sections 8(1) and 8(5), where processing is "necessary for enforcing any legal right or claim" (clause (a)) or is "in the interest of prevention, detection, investigation or prosecution of any offence" (clause (c)). A clip pulled after a specific incident fits those words most easily; whether continuous recording of the bays counts as "prevention" or "detection" is not settled. Neither the Act nor the Rules mention cameras. Until advice settles it, point them at the bays only, restrict who can view, and log every export; claims are covered in who pays if a charger causes damage.
Lawful basis and the notice residents should receive
Section 4(1) allows processing only with consent or "for certain legitimate uses". The use that fits most charging rows is section 7(a): processing "for the specified purpose for which the Data Principal has voluntarily provided her personal data to the Data Fiduciary, and in respect of which she has not indicated to the Data Fiduciary that she does not consent to the use of her personal data". The Act's illustration is a pharmacy texting a receipt to a buyer who gave her number for that. A resident who gives a flat number, phone and vehicle number in order to charge and be billed looks similar.
Two cautions. Section 5(1) attaches the statutory notice to a request for consent, so a row resting only on section 7(a) needs no consent notice; but section 2(za) defines "specified purpose" as "the purpose mentioned in the notice given by the Data Fiduciary", so on our reading a written notice is still how you fix and prove the purpose. And session logs are produced by the charger rather than handed over; whether section 7(a) stretches to them is not settled, and the Board's inquiry powers in section 27 also start on 13 May 2027, so there is no ruling to lean on. Where a row is doubtful, ask for consent by signature or tick-box, and accept that section 6(4) lets the resident withdraw it "at any time". Section 6(5) puts the consequences of withdrawal on her; on the Act's own online-shop illustration, that lets a society end her app access for new sessions.
Rule 3 sets the minimum contents of a consent notice; use them for every row. It must:
- be "understandable independently of any other information", not a line buried in the society's rules;
- give "an itemised description of such personal data": the rows of your map;
- state the purposes and a "specific description of the goods or services to be provided or uses to be enabled": charging access, metering, billing, disputes;
- give "the particular communication link" for the website or app, and other means, to withdraw consent (as easily as it was given), exercise rights and "make a complaint to the Board".
Section 5(3) requires the option to read it in English or any Eighth Schedule language, so use the society's working languages. Where residents consented before 13 May 2027, section 5(2) requires a notice "as soon as it is reasonably practicable"; sending it to every existing user is simplest.
Then name a contact. Section 8(9) and rule 9 require you to publish the business contact information of "a person who is able to answer" on the society's behalf, and rule 9 says "on its website or app". If your society has neither, the Rules do not say what to do; put the name on the notice board, on the society's page in the charging app, and in every reply. Rule 14(3) requires you to publish your grievance response period, "a reasonable period not exceeding ninety days", and section 13(3) makes a resident use that route before approaching the Board. The policy walkthrough and policy discussion draft show where these lines sit.
The charging-app vendor as your processor: contract clauses
Section 2(k) defines a Data Processor as "any person who processes personal data on behalf of a Data Fiduciary"; a vendor whose app authorises sessions and produces your billing export is one. Section 8(1) makes the society responsible for that processing "irrespective of any agreement to the contrary", and section 8(2) allows a processor to be engaged "only under a valid contract". Ask for a data-processing addendum carrying these clauses:
- Purpose. Residents' data is used only to run access, metering and billing for the society, never for the vendor's own marketing or analytics. A vendor using it for itself decides a purpose; see the next section.
- Security. Encryption or masking, access control, monitoring and backups, matching rule 6(1)(a) to (d); rule 6(1)(f) itself calls for "appropriate provision in the contract".
- Logs. Access and processing logs kept for one year and handed over on request, matching rules 6(1)(e) and 8(3).
- Breach notice. Notice to the society within a stated number of hours, with the facts rule 7 needs, leaving time for the 72-hour report.
- Sub-processors. Hosting, messaging and payment providers named, with notice before any change. Section 11(1)(b) gives a resident the right to "the identities of all other Data Fiduciaries and Data Processors" her data was shared with.
- Withdrawal. Section 6(6) requires you to "cease and cause its Data Processors to cease" processing when consent is withdrawn; the vendor must act on your instruction.
- Erasure and return. Section 8(7)(b) requires you to cause the processor to erase what you gave it: on instruction and at contract end, after a full export of usage history in a format you can open, but not before the one-year floor in rule 8(3), which its illustration (Case 2) extends to processors.
- Rights requests. Help with access, correction and erasure under sections 11 and 12, within a turnaround that fits your ninety-day grievance period.
- Accuracy. If an export is used to suspend a defaulter's access, section 8(3) requires data "used to make a decision that affects the Data Principal" to be complete, accurate and consistent, so reported errors are corrected first.
- Location. Where the data is stored, with notice before it moves abroad; section 16 and rule 15 let the Central Government restrict such transfers.
Ask these with the lock-in questions in smart-charger features that matter. The choice in sub-meter versus smart-charger billing also decides how much applies: a hand-read sub-meter and a society-held ledger put far less personal data in a vendor's hands.
When the operator is a fiduciary in its own right
Where, under an operator-funded or revenue-share arrangement, the operator runs its own app, signs residents up, sets the price and bills them, it decides the purpose and means of that processing, and is a Data Fiduciary for it, not your processor. The words "alone or in conjunction with other persons" in section 2(i) allow two fiduciaries over overlapping data: the operator for accounts and payments, the society for the bay allocation list and whatever else it keeps.
Three things follow. The notice for the operator's sign-up is the operator's to give; the agreement should say so. Do not upload the member list to "onboard" residents; let each register directly, so the society is not disclosing data it has no basis to share. And the agreement should say who answers rights requests, who reports a breach, and what happens to residents' data and wallet balances on exit. The commercial terms (ownership, exclusivity, price revision) are in what the operator deal really costs; settle the data clauses alongside them.
Security safeguards and the one-year log rule
Section 8(5) requires "reasonable security safeguards to prevent personal data breach", and rule 6(1) lists the minimum. In a charging set-up:
- Masking, rule 6(1)(a): exports shared beyond the treasurer carry masked phone and vehicle numbers.
- Access control, 6(1)(b): named administrator accounts, at least two, never one shared password; an office-bearer's access ends with the term.
- Visibility, 6(1)(c), "appropriate logs, monitoring and review": get the vendor's administrator-access log and review it at each committee meeting.
- Continuity, 6(1)(d), "such as by way of data-backups": a monthly export held by the society, so a vendor's exit does not take your billing history.
- Logs for a year, 6(1)(e): "retain such logs and personal data for a period of one year, unless compliance with any law for the time being in force requires otherwise".
- Organisation, 6(1)(g): a one-page written procedure and a named person, so the safeguards survive a change of committee.
Rule 8(3) adds a separate floor: personal data, "associated traffic data and other logs of the processing" must be kept "for a minimum period of one year from the date of such processing", for the state purposes in the Seventh Schedule, then erased unless another law requires more. A session log cannot be deleted the month after billing.
Maharashtra's draft bye-law 37(a)(viii) lets a member inspect "those portions of the books and records in which the transactions of that Member with the Society have been recorded", and a note under draft bye-law 39 says the society "shall not disclose or provide copies of any confidential, personal or sensitive information relating to any Member or any other person, such as Aadhaar Card, PAN Card, Passport, bank account details" unless law or a competent authority requires it. Read together, a member gets her own flat's lines, not her neighbours' sessions. Your own state's bye-laws decide the detail.
If you add a camera, tag reader or router at the bay, its power supply and cable route share space with the charging circuit, so have that work specified and certified by a licensed electrician, not added on a spare socket.
A breach drill: who tells whom, within 72 hours
Section 2(u) defines a personal data breach as "any unauthorised processing of personal data or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access to personal data, that compromises the confidentiality, integrity or availability of personal data". There is no size threshold; in a charging set-up the likely cases are:
- the month's session export, phone numbers included, posted to the all-residents group instead of the committee's;
- a former office-bearer who still holds the app's administrator login;
- the guard-desk tablet running the charging register, lost or stolen;
- the vendor reporting unauthorised access to its database.
| When | What | Who, as a suggestion | Source |
|---|---|---|---|
| On becoming aware | Contain: delete the post, revoke the login, ask the vendor for facts. Note the time you became aware. | Named data contact, with the secretary | Rule 7 runs from "becoming aware" |
| Without delay | Tell each affected resident, via her app account or registered phone or email: what happened, likely consequences, what you have done, what she can do, whom to contact | Secretary | Rule 7(1)(a) to (e) |
| Without delay | Tell the Board: nature, extent, timing, location, likely impact | Chair or secretary | Rule 7(2)(a) |
| Within 72 hours | Detailed report to the Board: updated facts, causes, mitigation, who caused it, remedial measures, the intimations sent to residents | Chair, with the vendor's input | Rule 7(2)(b)(i) to (vi) |
| Next committee meeting | Minute the incident, fix the cause, update the drill sheet | Committee | Section 8(4); rule 6(1)(g) |
Count the 72 hours from awareness, not from the next working day: an export misposted and spotted at 9 pm on a Friday gives 9 pm Friday + 72 hours = 9 pm Monday. A longer period is possible only "as the Board may allow on a request made in writing". The Rules do not say how to reach the Board; find its published channel and write it on your drill sheet before 13 May 2027, not on the night.
Penalties are imposed by the Board under section 33, after an inquiry, where it finds a breach "significant". The Schedule sets ceilings: for failing to take reasonable security safeguards, "May extend to two hundred and fifty crore rupees" (item 1); for failing to notify a breach, "May extend to two hundred crore rupees" (item 2). Section 33(2) requires the Board to weigh "the nature, gravity and duration of the breach" and whether the person "took any action to mitigate", among other factors. A rehearsed drill is evidence for the last.
Retention: bye-law record rules against erasure
Section 8(7)(a) requires erasure "upon the Data Principal withdrawing her consent or as soon as it is reasonable to assume that the specified purpose is no longer being served, whichever is earlier", unless "retention is necessary for compliance with any law for the time being in force". Rule 8(1) fixes deemed periods only for the classes in the Third Schedule: large e-commerce, online gaming and social media platforms. A society must judge "reasonable to assume" for itself, above the one-year floor in rules 6(1)(e) and 8(3).
Bye-laws pull the other way. Maharashtra's draft revised model bye-laws for tenant co-partnership housing societies are a DRAFT: headed "DRAFT BYE-LAWS, 2026" on their forms pages and listed under 13 August 2026 on the model bye-laws page of the Commissioner for Co-operation and Registrar of Co-operative Societies, Maharashtra. The Commissioner's press note bound into the file invited suggestions and objections until 27 August 2026; on 16 October 2026 that page listed no adopted version. Draft bye-law 138 would say that "Parking records, EV charging records and other operational registers" "shall ordinarily be preserved for five years", that bank statements, vouchers, receipts and bills be kept for ten, and that "No record shall be destroyed before the expiry of the prescribed period" (sahakarayukta.maharashtra.gov.in; last verified 16 October 2026).
Whether a registered bye-law is "law for the time being in force" for section 8(7) is not settled: the Act does not say, and the Board cannot rule on it before its powers start. This is one state's draft, not a national rule. Ask your society's lawyer, and meanwhile split the record so the conflict shrinks:
| Record | Floor under the Rules | What may require longer | Erase when (the society's decision) |
|---|---|---|---|
| Monthly ledger: flat, month, units, amount, payment reference | One year, rules 6(1)(e) and 8(3) | Accounts and audit requirements; draft bye-law 138's ten years for receipts and bills, if adopted | When your auditor confirms the accounting period has passed |
| Session detail: start and stop times | One year | Draft bye-law 138's five years for EV charging records, if adopted | After the floor and your dispute window, unless an adopted bye-law requires more |
| A leaver's credential mapping: tag, vehicle number, phone | One year from the last processing | Draft bye-law 138's five years, if adopted and if the mapping counts as an EV charging or parking record | At the end of the floor, unless an adopted bye-law requires more |
| Camera footage of the bays | One year, if rule 8(3) is read to reach it | An open incident, claim or police request | Take advice before fixing a period |
When a resident moves out or a tenancy ends, deactivate the credential the same day and close the app account; the purpose has ended, though the floor and the ledger remain. See moving out or selling your flat and our guide for renters. Keep the ledger good enough to settle a disputed bill without session detail; resolving charging disputes shows what it needs.
A readiness checklist dated back from 13 May 2027
Only the last date comes from the notification; the others are our suggested pacing, leaving the general body time to approve changes at a meeting.
- November 2026. Build your data map from the table above, with who holds each item.
- December 2026. Send the app vendor, and any operator, the clause list; ask for their administrator-access log and sub-processor list.
- January 2027. Draft the rule 3 notice, the retention schedule and a one-page breach drill sheet. Name the data contact.
- February 2027. Committee approval, then the policy amendment on the general-body agenda; putting EV charging on the AGM agenda covers the mechanics.
- March 2027. General body adopts. Sign the vendor addendum. Remove stale administrator accounts and leavers' credentials.
- April 2027. Send the notice to every existing user (section 5(2) requires it where consent was the basis), publish the contact under rule 9, and run the breach drill once on paper against the clock.
- By 13 May 2027. Grievance route live, notice in the app and on the board, first monthly export on file.
- After that. Review the access log at each committee meeting; once a year, apply the retention schedule and minute what was erased.
Common questions
Is a housing society a Data Fiduciary under the DPDP Act?
For personal data it processes digitally, yes, on the Act's definitions: section 2(s)(v) includes "an association of persons or a body of individuals, whether incorporated or not", and section 2(i) covers anyone who "determines the purpose and means of processing". The domestic exemption in section 3(c)(i) applies only to an individual. This is our reading, not legal advice.
How long can a society keep EV charging session logs?
At least one year, under rules 6(1)(e) and 8(3); beyond that, only as long as the purpose or a law requires, under section 8(7). Maharashtra's draft bye-law 138 would say five years for EV charging records, but it is a draft, and whether an adopted bye-law counts as law for section 8(7) is unsettled.
Can the society ask for my vehicle registration number to use the shared charger?
On our reading, yes: a number you give once, at registration, for a purpose the notice states (matching a vehicle to a flat at the bay) fits section 7(a), and you keep the access and correction rights in sections 11 and 12. Maharashtra's draft bye-law 79(vi) says a society "shall not ordinarily insist upon" the registration certificate or insurance policy unless law or a specific complaint or dispute requires it.
Do residents have to consent before the society runs a charging app?
Not necessarily. Section 7(a) covers data residents voluntarily provide for a stated purpose unless they object, though on our reading a written notice is still the way to fix that purpose; session logs and cameras are less clear. Residents keep their rights either way: section 11(1) expressly includes "consent as referred to in clause (a) of section 7".
Who reports a breach if the charging-app company is hacked?
If the vendor is your processor, the society does: section 8(1) keeps responsibility with you and rule 7 puts the reporting duty on the Data Fiduciary, so your contract must make the vendor tell you fast. An operator that is a fiduciary in its own right reports for its own data; the society reports for what it holds.
Does the Act apply to a paper charging logbook at the guard desk?
Not while it stays on paper, because section 3(a) covers data collected digitally or "digitised subsequently". Once the register is typed up for billing, scanned or photographed into a group, it is covered, so plan as if it applies.