Introduction
Every person who walks through your office doors has a legal right to privacy. Not in theory β in law, and enforceable before India’s Data Protection Board of India with penalties reaching βΉ250 crore.
Yet most Indian organisations treat visitor data as administrative background noise. The sign-in sheet fills up. The tablet app logs entries. The spreadsheet grows. Nobody asks whether the person who visited last Tuesday consented to their data being stored, who can access it, or when it will be deleted.
The Digital Personal Data Protection Act, 2023 (DPDP Act) and the DPDP Rules, 2025 β fully effective from May 13, 2027 β change all of that. Visitor data is personal data. Collecting it creates legal obligations. Ignoring those obligations creates financial risk.
This article is the definitive guide to every data privacy obligation your organisation carries the moment a visitor checks in.
Visitors Are Data Principals With Enforceable Rights
The DPDP Act defines a Data Principal as any individual whose personal data is being processed. A visitor to your office is a Data Principal from the moment they provide their name at reception.
As a Data Principal, every visitor has six rights your organisation must enable:
- Right to Access β they can ask what data you hold about them
- Right to Correction β they can ask you to fix inaccurate records
- Right to Erasure β they can ask for complete deletion of their data
- Right to Grievance Redressal β they can raise a formal complaint with you
- Right to Withdraw Consent β they can revoke consent they previously gave
- Right to Nominate β they can nominate someone to exercise these rights on their behalf
These are not aspirational norms. They are statutory rights. If a visitor exercises any of these rights and your organisation fails to respond within 90 days, they can escalate directly to the Data Protection Board of India (DPBI) β from their phone, in minutes, through the DPBI’s digital complaint app.
What Obligations Arise the Moment You Collect Visitor Data?
Obligation 1: Issue a Privacy Notice Before Collecting Data
Under Section 5 of the DPDP Act and Rule 3 of the DPDP Rules, you must provide a standalone privacy notice to every visitor before their data is collected. This is not a privacy policy on your website. It is not a footnote on the sign-in screen. It is a clear, plain-language statement presented before the check-in process begins.
The notice must tell the visitor:
- Exactly what data you are collecting (name, phone, photo, ID, purpose β itemised specifically)
- Why each data type is being collected (building security, host notification, badge printing β purpose-specific)
- How long their data will be kept (your retention period, stated clearly)
- Who can access their data (reception staff, security team, your VMS platform provider)
- How to withdraw consent (a direct link, email, or phone number)
- How to exercise their rights (access, correction, erasure)
- How to file a complaint with the Data Protection Board of India
Language requirement: The notice must be available in English and in any of the 22 Eighth Schedule languages if the visitor requests it. For offices in Tamil Nadu, Maharashtra, Bengal, or any regional hub, consider proactively offering the notice in the primary local language.
Retrospective obligation: The DPDP Rules require that privacy notices also be issued retroactively for data collected before the Act’s compliance date. Your existing visitor database β months or years of records β must be covered by a retrospective notice issued before May 2027.
Obligation 2: Obtain Valid Consent
Consent under the DPDP Act has a specific, strict definition. It must be:
- Free β not coerced; not made a condition of entry where consent is not strictly required
- Specific β separate consent for each distinct purpose
- Informed β preceded by the privacy notice
- Unconditional β no hidden obligations attached
- Unambiguous β a clear affirmative action; a checkbox ticked, a button pressed
What does not count as valid consent:
- Proceeding with check-in without any consent interaction
- A pre-ticked checkbox
- Completing an OTP verification (OTP verifies identity; it is not data processing consent)
- Consent embedded at the bottom of a long terms-and-conditions screen
Separate consent is required for:
- Face photo / biometric capture: standalone consent for this specific purpose
- ID document recording: standalone consent
- Marketing communications: completely separate from visit consent
Obligation 3: Collect Only What You Need
Data minimisation requires collecting only what is genuinely necessary. Ask of every field in your check-in form: “What specific, active purpose does this serve?” If you cannot answer clearly β remove the field.
| Field | Typically Justified? | Notes |
| Name | Yes | Identity for building access |
| Phone number | Yes | OTP verification, host notification |
| Company | Yes | Security context |
| Host name / department | Yes | Routing and notification |
| Purpose of visit | Yes | Security categorisation |
| Face photo | Conditionally | Only if used for badge or liveness β delete after |
| Only if actively used | Not needed for most standard visits | |
| Government ID number | High-security areas only | Must be justified and documented |
| Date of birth | Rarely | Almost never needed for office visits |
| Emergency contact | Safety contexts only | Explicit separate consent required |
Obligation 4: Define and Enforce Retention Periods
Rule 8 mandates deletion once purpose is served. Personal data cannot be stored beyond one year of user inactivity unless legally required. A documented retention schedule is mandatory:
| Data Type | Suggested Retention | Notes |
| Visit record (name, time, host, purpose) | 90β180 days | Security review window |
| Face photo | 24β48 hours post check-out | Purpose ends on departure |
| OTP verification log | 30β90 days | Security audit |
| ID verification record | 90 days | Delete after security review window |
| Signed NDA | NDA term + limitation period | Legal document retention applies |
| Processing / access logs | Minimum 1 year | Mandatory under Rule 8 |
Retention must be automated β manual cleanup does not scale and will not be consistently applied.
Obligation 5: Implement Security Safeguards (Rule 6)
- Encryption at rest (AES-256) for all stored visitor records
- Encryption in transit (TLS 1.2+) between kiosk and cloud
- Role-based access control β reception sees today; management sees reports; nobody gets bulk access without documented justification
- Audit logging of all record access β who, when, what action β retained minimum 1 year
- Device security on kiosk tablets β restricted-app mode, no guest file system access
- Verify your VMS provider’s security standards through SOC 2 or ISO 27001 certification
Obligation 6: Enable Data Principal Rights
Publish a data contact. A specific, functional email or web form for visitor data requests β included in the privacy notice and on your website.
90-day response SLA. Every access, correction, and erasure request must be acknowledged and resolved within 90 days.
Individual erasure capability. Your VMS must support deletion of individual records β not just bulk purges.
Easy withdrawal. Consent withdrawal must be as simple as consent was to grant.
Obligation 7: Sign a DPDP-Compliant DPA with Your VMS Provider
You remain legally responsible for visitor data even when it sits in a third-party platform. Your vendor contract must include:
- Processing scope limitation (only per your instructions)
- Security safeguards implementation
- 24-hour breach notification SLA (Processor β you)
- Deletion on instruction
- Data Principal rights support
- Sub-processing restrictions
Obligation 8: Prepare for Breach Notification
If visitor data is compromised:
- Initial intimation to DPBI β without delay (immediately on awareness)
- Full report to DPBI β within 72 hours
- Notify affected visitors β simultaneously, in plain language
Your breach response plan must include a mechanism for mass individual notification at scale.
The Visitor Privacy Obligations at a Glance
| When | Obligation | Penalty for Non-Compliance |
| Before check-in | Issue standalone privacy notice | Invalid consent; DPBI complaint |
| At check-in | Obtain explicit consent per data type | Up to βΉ50 crore |
| During collection | Apply data minimisation | Violation + increased breach exposure |
| Throughout retention | Enforce retention; auto-delete | Erasure requests must succeed |
| Throughout retention | Security safeguards | Up to βΉ250 crore on breach |
| Any time | Honour rights requests within 90 days | Up to βΉ50 crore |
| On breach | Notify DPBI + visitors | Up to βΉ200 crore |
The Bottom Line
A visitor’s name, phone number, and face photo are not administrative trivia. They are personal data belonging to an individual with statutory rights under Indian law. The moment your reception tablet logs that data, you have obligations β to protect it, to delete it, and to honour the person’s right to know what you did with it.
Build those obligations into your visitor management workflow before May 2027. The DPBI is operational. The complaints portal is live. And every visitor to your office is one unanswered data request away from filing a formal complaint.
This article is for informational purposes only and does not constitute legal advice. Consult a qualified data protection professional for specific compliance guidance.
Onfra’s visitor management platform is built for India’s DPDP era β with consent flows at every check-in, configurable retention policies, automated deletion, and a full audit trail. Explore Onfra’s DPDP-ready visitor management β
Sector-Specific Visitor Privacy Priorities
Corporate Offices and Tech Parks
Standard obligations apply in full. The highest-risk gap in most corporate offices is the absence of any consent step at the kiosk β the visitor completes an OTP and their photo is captured, but no explicit consent screen exists. This is the first thing to fix.
Priority actions: deploy privacy notice as first kiosk screen; add consent checkbox for photo capture; set a 90-day auto-deletion rule for visitor records; publish a data rights email address.
Manufacturing and Industrial Facilities
Visitor logging often includes gate entry timestamps, ID verification, vehicle numbers, and zone-specific access records. The security justification for richer data collection is stronger here β but so is the need to document that justification and set clear retention periods aligned to your actual security review needs (typically 90β180 days, not forever).
Healthcare Facilities
Patient visitors may be sensitive about their presence being logged β visiting a mental health facility or oncology ward, for instance, is information a visitor may not want retained. Healthcare visitor management should apply strict minimisation, short retention, and robust consent.
Educational Campuses
Visitors may include parents of minors. Children’s data protections under Rule 5 apply to any records involving under-18 individuals. If parents bring children during a campus visit, children’s data must be handled under verifiable parental consent or applicable Rule 5 exemptions.
Government and Public Sector Offices
Public authorities are Data Fiduciaries under the DPDP Act on equal terms with private sector organisations. Government office visitor management must comply with all the same obligations β privacy notice, consent, retention, rights. There is no public authority exemption for visitor data processing.
Building a Visitor Privacy Programme: The 90-Day Quick Start
For organisations that need to move fast toward compliance, here is a prioritised 90-day action plan:
Days 1β30: Assess and Design
- Complete a data audit of your current VMS: what data is collected, stored, who has access, current retention (if any)
- Draft a standalone visitor privacy notice
- Map which data fields are genuinely necessary vs. legacy additions
- Identify your VMS provider’s current DPDP posture
Days 31β60: Build and Configure
- Deploy the privacy notice as the first screen of your check-in flow
- Add explicit consent checkboxes (general visit data; separate for photo; separate for ID recording)
- Configure a retention policy in your VMS (90β180 days for records; 24β72 hours for photos)
- Enable automated deletion
- Restrict VMS access by role; verify audit logging is active
Days 61β90: Formalise and Train
- Update your VMS contract to include a DPDP-compliant Data Processing Agreement
- Publish a data rights contact on your website and in the privacy notice
- Build a basic intake process for access and erasure requests
- Train reception and security staff on DPDP obligations and how to direct visitor data queries
- Document your retrospective notice plan for historical visitor records
By Day 90, you will have closed the majority of your visitor management DPDP compliance gaps β with a clear path to full May 2027 readiness.