Introduction
It’s one of the most common questions being asked by facilities managers, security teams, and HR compliance officers across India right now:
“We capture a visitor’s photo at check-in for their badge. Are we allowed to do that under the DPDP Act?”
The short answer is: yes β but only if you do it correctly. And most organisations are currently not doing it correctly.
The longer answer β the one that actually protects your organisation β requires understanding what “correctly” means under India’s Digital Personal Data Protection Act, 2023 (DPDP Act) and the Rules notified on November 14, 2025. It’s more nuanced than a simple yes or no, because the answer depends entirely on why the photo is taken, what is done with it, how long it is kept, and whether the visitor consented to each of those things explicitly.
This article walks through every scenario β from the standard badge-print to facial recognition for returning visitors β and tells you exactly what the DPDP Act says about each.
Scenario 1: Taking a Photo to Print a Visitor Badge
The setup: The visitor stands at your reception kiosk. The camera activates. A face photo is captured. It prints on the visitor’s badge. The visitor clips on the badge and enters.
Is the photo deleted immediately after printing, or stored?
This question determines your entire compliance posture for this scenario.
If the photo is used solely to print the badge and then deleted:
From a DPDP perspective, capturing a photo and deleting it immediately after use for badge printing is a limited-purpose, short-retention data processing activity. Your obligations are:
- Privacy notice: The visitor must be told, before the photo is taken, that their photo will be captured for badge printing and deleted immediately after. This notice must be standalone and visible before the check-in process begins.
- Consent: An explicit checkbox or affirmative tap: “I consent to my photo being taken for my visitor badge. It will be deleted immediately after the badge is printed.”
- Deletion confirmation: Your system should log that the photo was deleted (confirming the process completed).
- No secondary use: The photo must not be used for any purpose other than the badge. Not for analytics. Not for a return-visitor gallery. Not saved in the visitor record.
Compliance verdict: β Allowed β with notice, explicit consent, and immediate deletion.
If the photo is stored in the visitor’s check-in record in the cloud:
Now the processing goes beyond badge printing. The photo is retained β potentially for days, months, or indefinitely. Each additional day of retention is an additional obligation.
Your requirements:
- Privacy notice: Must disclose that the photo is retained, for how long, and for what specific purpose (not just badge printing β what is the purpose of keeping it?).
- Consent: Explicit consent for both the capture AND the retention. “I consent to my photo being taken and retained in our visitor management system for [X days] for security and identity verification purposes.”
- Retention period: Define it. State it in the notice. Enforce it with automatic deletion.
- Access control: Photo must be accessible only to authorised roles (security, not general reception staff).
- Encryption: Photos stored in the cloud must be encrypted at rest.
- Deletion: Automated deletion at the end of the retention period.
Compliance verdict: β Allowed β with notice, explicit consent for both capture and retention, defined retention period, access controls, encryption, and automated deletion.
Scenario 2: Liveness Detection (Is This a Real Person?)
The setup: Your VMS uses AI-based liveness detection at check-in β the system analyzes the camera feed to confirm that the person presenting is a live human, not a printed photo or a screen. No image is retained; only a pass/fail verification result is stored.
Under the DPDP Act, the key question is whether digital personal data is processed. The liveness detection process involves:
- Real-time analysis of the visitor’s face via camera
- An algorithmic pass/fail assessment
- If only the result (verified: yes/no) is stored β not the underlying image or biometric template
Compliance posture:
- The real-time image processing constitutes personal data processing β even if only momentarily
- A privacy notice and consent are required before the liveness check
- If no image is retained and no biometric template is stored β the processing is minimal and the retention concern does not arise
- If the pass/fail result is logged against the visitor’s record β that record must follow standard DPDP retention obligations
Compliance verdict: β Allowed β notice and consent required before the check; minimal concern if no biometric data is retained beyond the result.
Scenario 3: Building a Returning Visitor Recognition Database
The setup: Your VMS stores visitor face photos and uses them to automatically recognise returning visitors β pre-filling their check-in form, greeting them by name on the kiosk screen, or flagging them to reception before they arrive.
This scenario is fundamentally different from badge-print photography. You are now:
- Retaining biometric-adjacent data (face photos or facial templates) indefinitely
- Using it for secondary identification purposes beyond the original visit
- Potentially building a database of individual movement patterns across visits
This is high-risk territory under the DPDP Act. The issues:
Purpose limitation violation risk: If a visitor’s photo was originally taken for a badge, and is now being used for return-visit facial recognition β that is a secondary use beyond the original stated purpose. Unless the original consent explicitly covered this use, it is a purpose limitation violation.
Retention concern: Keeping face photos across visits means retaining biometric-adjacent data indefinitely or long-term. This requires a compelling, documented purpose and an explicit retention period.
Consent requirement: You need explicit, separate consent for the return-visitor recognition feature β separate from the general visit consent and separate from the badge-print photo consent. This consent must clearly explain that photos are being retained for future visit recognition.
Opt-out requirement: Since this is a secondary, non-essential processing purpose, visitors must be able to decline without it affecting their ability to enter the facility.
Compliance verdict: β οΈ Allowed only with β separate explicit consent for the recognition purpose, clearly disclosed retention period, opt-out mechanism, and access controls on the recognition database. Many organisations will find that the compliance overhead of this feature outweighs the operational convenience.
Scenario 4: Watchlist / Security Flagging via Face Recognition
The setup: Your access control system maintains a watchlist β a database of faces of individuals who have been flagged for security concerns. New visitors are automatically compared against this watchlist at check-in.
This is the highest-risk biometric scenario in the visitor management context. It involves:
- Facial recognition at the point of entry (not just photography)
- A biometric matching process against a stored database
- Potential denial of entry based on an algorithmic result
- Significant potential for harm if the match is incorrect (wrongful denial of access, reputational damage)
Under the DPDP Act:
Processing biometric data for security screening: This requires a documented, compelling legal basis. For a private corporate office, the legitimate use for “security of premises” is not explicitly listed in the Act’s Section 7 legitimate use categories. This likely means consent is required β which creates an obvious practical problem: a security watchlist typically works precisely because the subject does not know they are being screened.
Potential DPIA requirement: Processing that carries a high risk of significant harm β including wrongful denial of access based on facial recognition errors β should be the subject of a Data Protection Impact Assessment before deployment.
SDF designation trigger: Large-scale deployment of facial recognition for security screening is a strong indicator for Significant Data Fiduciary designation, bringing enhanced obligations including annual DPIAs and an India-based DPO.
Recommended approach: Consult qualified legal counsel before deploying facial recognition for security screening. The compliance complexity is high. A combination of human security staff review and card/ID-based access control may achieve comparable security outcomes with significantly lower DPDP risk.
Compliance verdict: π΄ High-risk β requires specific legal basis analysis, likely a DPIA, and legal counsel before deployment.
Scenario 5: Taking a Photo for an ID Badge With Indefinite Retention
The setup: Long-term contractors and regular vendors are issued photo ID badges that are retained for the duration of their engagement. The face photo is stored in the system for months or years.
This is common and manageable β but requires specific compliance steps:
- Legal basis: For a contractor whose engagement has been documented and who has been issued an access credential, processing their photo as part of that credential is arguably covered by “legitimate use for contractual necessity” under Section 7. However, best practice is to obtain explicit consent regardless.
- Notice: A specific privacy notice for contractor/vendor badge photos β stating the purpose (access control), the retention period (duration of the engagement + 30 days), and the deletion process upon contract end.
- Consent: Explicit consent for the photo capture and retention as part of the onboarding process.
- Deletion upon termination: When the contractor’s engagement ends, the photo must be deleted β along with their access credentials and visitor system record β within the defined window.
Compliance verdict: β Allowed β with notice, consent at onboarding, defined retention tied to engagement duration, and deletion protocol upon termination.
What the DPDP Act Does NOT Prohibit
To be clear: the DPDP Act does not prohibit taking photos of visitors. It does not prohibit storing face photos. It does not prohibit using liveness detection or automated badge printing. It does not require you to abandon any of these practices.
What it requires is that these practices be:
- Noticed: Visitors know about them before they happen
- Consented: Visitors actively agree to them, separately for each distinct purpose
- Purposeful: Photos are used only for the stated purpose β not repurposed without fresh consent
- Time-limited: Photos are deleted when the stated purpose is served
- Secured: Photos are encrypted, access-restricted, and protected from breach
- Reversible: Visitors can ask for their photo to be deleted, and you can honour that request
The Practical Compliance Design for Photo Capture at Check-In
Here is what a compliant photo capture flow looks like at a reception kiosk, step by step:
Screen 1 β Privacy Notice (standalone)
Before any form fields or camera activation:
“[Company Name] collects the following information during your visit: [itemised list]. Your photo will be taken for your visitor badge. [If retained: It will be stored for [X days] for security purposes and then permanently deleted.] You can request deletion at any time by emailing [address].”
Screen 2 β Standard Check-In Consent
Form fields for name, company, purpose, host. Followed by:
[ ] I have read the privacy notice above and consent to my visit details being recorded.
Screen 3 β Photo Consent (separate, not bundled)
Camera preview visible. Before capture activates:
“Your photo will now be taken for your visitor badge. [If retained: It will be stored for [period].]”
[ ] I consent to my photo being taken.
Then: [Capture Photo] button
Screen 4 β OTP Verification
Phone number entry and OTP verification β for identity confirmation. Separate from the photo consent.
Screen 5 β Badge Print and Check-In Confirmation
Badge prints. Visitor is confirmed as checked in. On-screen: “Your data rights contact: [email/web form].”
This five-screen flow takes approximately 90 seconds. It is compliant. It is auditable. It demonstrates that consent was obtained before each data collection step.
Summary: Photo at Reception β When It’s Allowed and When It Isn’t
| Photo Use | Allowed Under DPDP? | Key Conditions |
| Badge print β photo deleted after printing | β Yes | Notice + explicit consent + immediate deletion |
| Badge print β photo stored in visitor record | β Yes | Notice + explicit consent for storage + retention period + encryption + deletion |
| Liveness detection β no biometric template retained | β Yes | Notice + consent before check; minimal compliance burden |
| Return visitor recognition database | β οΈ Conditional | Separate explicit consent for recognition purpose; opt-out mechanism; retention period; access controls |
| Contractor/vendor photo badge (multi-month) | β Yes | Notice + consent at onboarding; retention tied to engagement; deletion on termination |
| Watchlist / security facial recognition | π΄ High-risk | Specific legal basis needed; DPIA recommended; consult legal counsel before deployment |
The Bottom Line
Yes, you can take a visitor’s photo at reception. Millions of organisations do it every day, and the DPDP Act does not change that.
What the DPDP Act changes is the responsibility that comes with that photo. The moment you capture a visitor’s face, you have processed their personal data. You owe them a notice. You need their consent. You must use the photo only for what you said. You must delete it when you said you would.
None of these requirements are technically difficult. A well-designed check-in flow can collect consent, display the notice, capture the photo, print the badge, and confirm deletion β in under two minutes.
The question is not whether you can take the photo. It is whether you are prepared to do it the right way.
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 check-in flow includes liveness detection, badge printing, and configurable photo retention β with DPDP-compliant consent steps built into the kiosk workflow. See how Onfra handles visitor photos β