Apartment societies and visitor apps: ask who needs each field

Imagine a visitor arriving at an apartment building and being asked for a phone number, photograph, employer, vehicle number and identity-document image. The guard follows the app. The resident wants the guest admitted. The society may never have examined why the system asks for each field or who can see the answers afterwards.

Review the entry task before accepting the default form. The central question is what information is needed to manage this visit and what separate uses the system may create.

Identify the parties and the purposes

The society, the resident and the app provider may each have different roles in different activities. Under the DPDP definitions in section 2(i) and 2(k), deciding purposes and means differs from processing on another party’s behalf. A contract label does not resolve every activity performed by the provider.

As of 22 October 2026, the relevant substantive duties are scheduled for 13 May 2027 under the commencement notification. The personal or domestic exclusion in the future section 3(c)(i) concerns an individual’s processing for those purposes. Do not assume that a society’s organised visitor database automatically has the same position as a person’s private address book.

Map the actual flow: what the guard enters, what the resident receives, what society administrators can search and what the provider uses for its own purposes. A narrow entry purpose should not silently become an unrelated promotional database.

Ask why each field is required

For a field such as a vehicle number, identify the task it serves. For a photograph or identity-document copy, ask what problem it solves, whether a less intrusive method is adequate and how the copy is protected. The fact that a field is marked mandatory in software is not evidence of a statutory requirement.

Under the future sections 4 to 7, the processing route needs assessment. Do not assume that safety automatically creates a general legitimate-interest basis, or that a person agreeing at a gate has necessarily given valid consent for every additional purpose. Where consent is the intended route, examine the actual choice and explanation.

Prepare a usable alternative where the selected app process is unsuitable or requests information the society has not justified. Guards need an approved escalation route rather than being left to invent exceptions under pressure.

A hypothetical society review

A society introduces a visitor app that requests a photograph for every delivery. The committee asks the provider to explain where the image is stored, which users can search it and why the chosen workflow needs it. It discovers that the entry-confirmation task can be configured with a narrower set of fields.

The committee tests the revised path with synthetic visitor details. The resident sees the information needed to confirm the visit. Guards do not gain unrestricted access to historical visits across the complex. An administrator has a defined route for a justified incident review.

The society also asks whether the provider uses visitor information for any independent commercial activity. That question is assessed separately from the service needed at the gate. The committee records what it has accepted and which configuration controls the result.

Limit historical access

Visit histories can reveal routines and associations. Decide who can search them and for which task. A guard covering a temporary shift may need current entries without needing months of historical records. Remove access when staff or committee roles change.

The future rule 6 safeguards will be relevant to access controls and related security. Check exports, administrator accounts and shared credentials as well as the ordinary guard screen. A restricted interface is less helpful if any user can download a complete history.

Decide what happens after the visit

Set a purpose-based review process and assess applicable retention requirements, including the future rule 8(3) and Seventh Schedule. That provision includes a minimum of one year from processing for the specified Schedule purposes, with further retention where required by other law or government notification. Assess its application rather than inventing a visitor-log period or keeping records indefinitely because an incident might someday occur. Distinguish restricted retained evidence from routine searchable history and unrelated reuse.

Where a provider processes on the society’s behalf, the future section 8(1) accountability framework remains relevant. Include provider instructions, incident escalation and an exit plan in the arrangement.

The recurring failure is delegating policy decisions to a default app screen. A society can make the system more understandable by documenting the entry purpose, justifying the fields and giving guards, residents and administrators only the information their tasks require.