Visitor Data at an Office Gate: What DPDP Requires

Visitor data at an office gate

A visitor gives their name and phone number at your reception, and a camera takes their photograph. That is personal data, collected by your company, for your purposes. Under India's Digital Personal Data Protection Act your company is the data fiduciary for it.

This is the part of visitor management that offices think about last and that carries the most downside. It is also mostly solvable with four decisions rather than a project.

This is general information about how to think about the problem, not legal advice. Where the stakes are high, take advice on your specific circumstances.

Why an office is treated more strictly than a housing society

A housing society collecting visitor details has an obvious and narrow security purpose, a defined community, and usually no commercial use for the data. A company has employees, systems, marketing functions and vendors, which means visitor data sits inside an organisation that has reasons to want it for other things.

The practical consequence: an office needs to be able to say what the data is for, show that it is not being used for anything else, and demonstrate that it goes away. A society is rarely asked. A company with enterprise clients will be asked, often as part of a vendor security questionnaire long before any regulator is involved.

The four decisions

1. Collect less

Purpose limitation is the cheapest control available, and it is a decision rather than a feature.

For a security purpose, you almost always need: the visitor's name, a phone number, who they are visiting, and the times of entry and exit. That is enough to answer every question an incident review asks.

Things frequently collected that usually fail a purpose test:

• ID document scans. Photographing an Aadhaar or PAN card at reception collects far more than the security purpose needs, and creates a high-value store of identity documents. If you believe you need it, write down why, for which categories of visitor, and how long you keep it. Most offices cannot complete that sentence.
• Company name and designation for visitors who are not there on business.
• Vehicle details where parking is not being allocated.
• Signatures where nothing is being agreed.

A visitor photograph is defensible for a security purpose in most offices, because identifying who was inside is the point. Face recognition against a stored template is a different matter: it turns a photograph into biometric processing, with a considerably higher bar. Do not adopt it because it demos well.

2. Tell the visitor, at the point of collection

A visitor should be able to see, at the desk, what is being collected, why, and for how long. A short notice on the tablet or a card at reception is sufficient. It does not need to be a policy document.

Something like: We record your name, phone number, host and a photograph to know who is in the building for security. We keep it for ninety days and then delete it. Ask at reception to see or correct your record.

Two failure modes to avoid. A notice hidden in a privacy policy nobody reads at a desk is not notice. A consent checkbox that blocks entry unless ticked is not meaningful consent, and for a genuine security purpose you are generally better relying on a clearly stated legitimate purpose than on a coerced tick.

3. Decide a retention period and automate the deletion

This is where almost every office fails, and it is the failure most likely to be discovered.

Pick a period based on how long you would plausibly need to answer a question about a past visit. Ninety days covers incident review and most audit cycles. Some offices keep entry logs longer and visitor photographs shorter, which is a sensible split: the photograph is the sensitive part and the least often needed after the fact.

Then make the deletion happen without anybody remembering to do it. A retention policy that depends on an administrator running something quarterly is a retention policy that does not exist. Ask your vendor specifically: is the purge automatic, and can you show me evidence it ran?

An indefinitely growing store of visitor photographs is the single largest avoidable liability in a visitor management deployment.

4. Limit who inside can see it

Visitor records should be visible to the people who need them for the security purpose: reception, security, and the host of that particular visitor. Not to every employee, and not to whoever has an admin login.

This is where a common design flaw bites. If the only way to let a receptionist approve visitors is to make them a full administrator, then temporary front-desk cover gets access to the employee roster, company settings and every visitor record ever collected. That is a permissions problem masquerading as a convenience.

Ask whether reception can be a narrow role. If the answer is no, at minimum know that you are granting administrative access to a rotating position.

Employee data is a separate question

An employee directory used to route visitors to hosts contains employee names, departments, phone numbers and sometimes photographs. Employees are data principals too.

Two rules worth adopting:

• Employee photographs should be visible only where they serve a purpose. A guard confirming a host is a purpose. Every colleague browsing a photo directory is not necessarily one.
• Do not quietly turn gate logs into attendance. If entry and exit events for employees start being used to assess punctuality, you have changed the purpose the data was collected for. That is both a compliance problem and the fastest way to turn a security system into an industrial-relations dispute. Keep visitor logging and attendance separate, deliberately and visibly.

Vendors and cross-border transfer

Your visitor management vendor is a data processor acting on your instructions. Reasonable things to establish before signing:

• Where the data is stored, and whether it leaves India.
• Whether the vendor's staff can access your visitor records, and under what controls.
• What happens to the data when you stop being a customer.
• Whether the vendor will support a visitor's request to see or delete their record.
• Whether sub-processors are disclosed.

A vendor that cannot answer where the data lives is not ready to hold it.

A minimum viable position

If you want the short version, an office that does the following is in a defensible place:

1. Collects name, phone, host and timestamps. No ID scans without a written justification.
2. Shows a plain-language notice at the desk.
3. Sets a retention period, writes it down, and has automatic deletion.
4. Restricts visitor records to reception, security and the relevant host.
5. Keeps employee attendance out of the gate system.
6. Knows where the vendor stores the data.

None of that requires a compliance programme. It requires deciding six things and configuring them once.

How this works on Plinth

Visitor records on Plinth are scoped to the tenant by row-level security on every table, so no other company on the platform can read them, and that isolation is covered by a cross-tenant test suite rather than asserted.

Visitor photographs live in a private storage bucket reached only through short-lived signed URLs, and employee photograph access goes through an explicit permission check rather than being readable by any authenticated user. Access is logged.

Gate visitor data follows the retention behaviour the gate module already applies, with automatic purging after the retention window rather than a manual clean-up task.

Employee gate movements are deliberately not treated as attendance. Attendance is a separate module for staff who are actually rostered, and the gate module tracks visitors only.

Two things worth being straight about, because they are on the roadmap rather than shipped: a visitor-facing consent notice captured at the point of collection, and a per-tenant retention setting so a company can choose a period shorter or longer than the platform default. Both are recorded as open items in our own gap analysis for this feature.

Frequently asked questions

Do we need a visitor's consent to photograph them at reception? You need a lawful basis and clear notice. For a genuine building-security purpose, a plainly stated purpose at the point of collection is usually the stronger footing, because a consent tick that gates entry is not freely given.

Can we scan visitors' Aadhaar or PAN cards? You would need to justify why the security purpose requires an identity document rather than a name and phone number, and then protect and purge those scans accordingly. Most offices cannot justify it, and the stored scans become the most attractive thing in the system to an attacker.

How long can we keep visitor records? As long as the purpose needs, decided deliberately and documented. Ninety days is a common and defensible choice for entry logs. Consider a shorter window for photographs.

Does a visitor have the right to ask what we hold about them? A data principal can seek access to and correction of their personal data. In practice you need to be able to find a visitor's records and act on such a request, which is another argument against a paper register.

Is face recognition of visitors allowed? It moves you into biometric processing with a higher bar for necessity, notice and safeguards. Treat it as a significant decision, not a feature toggle.

Can we use gate entry times for employee attendance? Not without changing the stated purpose and telling employees. Keeping the two systems separate is both cleaner compliance and better workplace practice.

Step-by-step guides

• Admin: Set Up Office Visitor Management
• Reception: Approve Walk-in Visitors

Related: office visitor management · visitor register vs software