Most Indian reception screens ask for a name, a phone number, a photo and a host, then show one tick box: I agree to the terms and privacy policy.
That single box is the problem. Under India's Digital Personal Data Protection Act, 2023, consent must be specific and limited to what the purpose needs — and one box covering security, photography and marketing does not meet that standard.
This guide is about the words on the screen — the tablet, the kiosk, the QR page and the paper fallback. For the law itself, read our plain-English DPDP guide for visitor management; for the organisation-wide work, our DPDP Rules 2025 compliance checklist.
This is general information, not legal advice.

What must a visitor consent notice contain?
Four things: what data you take, why you take it, how the visitor exercises their rights and withdraws, and how they complain to the Data Protection Board.
Section 5(1) requires every consent request to be accompanied or preceded by a notice stating the data and purpose, how to exercise rights, and how to complain to the Board. Rule 3 of the DPDP Rules, 2025 tightens the form: the notice must be "presented and be understandable independently of any other information", in clear and plain language, with an itemised description of the personal data, and must give the means to withdraw consent "with the ease of doing so being comparable to that with which such consent was given".
| Requirement | Source | What it means at the desk |
|---|---|---|
| Standalone, understandable on its own | Rule 3 | The visitor must not have to open your website policy to understand it |
| Clear and plain language | Rule 3 | No "hereinafter", no "data subject", no six-point type |
| Itemised description of the data | Rule 3 | Name the fields: name, mobile, photo — not "certain information" |
| The specified purpose | Section 5(1), Rule 3 | "Site security and visitor records", not "business purposes" |
| Rights and withdrawal route | Section 5(1), Rule 3 | A real, monitored email or number on the screen |
| How to complain to the Board | Section 5(1), Rule 3 | One line pointing to the Data Protection Board |
| Language option | Section 5(3) | See below |
"Standalone" is the requirement most screens fail. A link saying see our privacy policy is not a notice.
Does the notice have to be in Hindi or a regional language?
You must give the visitor the option to access it in English or a language in the Eighth Schedule to the Constitution. You do not have to display all of them at once.
Section 5(3) says the Data Fiduciary "shall give the Data Principal the option to access the contents of the notice... in English or any language specified in the Eighth Schedule to the Constitution." Three practical ways to meet it:
- A language selector on the first screen — default to English plus the state language and Hindi, with the rest available.
- Printed cards at the desk, one per language, matching the screen text. They double as your paper fallback.
- A QR on the counter pointing to one language-switchable notice page. Useful across multiple states.
An English-only screen with no route to anything else does not offer the option the section requires.
Do you even need consent, or is visitor entry a "legitimate use"?
Probably consent. The Section 7 legitimate-use arguments are weaker than they look at a gate. Neither Section 7(a) nor Section 7(i) comfortably stretches to a photograph, an ID scan or a vehicle number taken as a condition of entry. Take clear consent, keep the field list short enough that consent is easy to give, and put the Section 7 question to your own counsel rather than assuming it.
Why your current check-in screen probably fails
Three patterns break consent, and almost every screen has at least one.
Pre-ticked boxes. Section 6(1) requires consent that is "free, specific, informed, unconditional and unambiguous with a clear affirmative action". A ticked box involves no affirmative action, and neither does a continue button that silently implies agreement.
Bundling. One tick covering security, photography and marketing is not specific. The Section 6(1) illustration makes the point: where a telemedicine app seeks consent for health data and contact list access, only the health data consent is valid, because the contact list is not necessary for the purpose.
Making optional data mandatory. If check-in cannot complete without agreeing to marketing follow-up, the consent is not free. Section 6(2) makes any infringing part invalid to that extent.
Separate what the visit needs from what you would like
Sort every field into three buckets before writing any notice copy: required for the purpose, optional with its own consent, or remove.
| Field | Business visitor | Courier | Contractor | Bucket |
|---|---|---|---|---|
| Name | Required | Required | Required | Required |
| Mobile number | Required (OTP, emergency) | Optional | Required | Varies by type |
| Host name | Required | Not needed | Required | Required |
| Photograph | Optional | Remove | Required (badge, safety) | Separate consent |
| ID proof number | Usually remove — a visual check often suffices | Remove | Justify per site policy | Review hard |
| Vehicle number | Only if parking | Optional | Required if driving on site | Conditional |
| Marketing follow-up | Separate opt-in | Never | Never | Unticked, non-blocking |
Two design rules follow. Give different visitor types different forms — a courier should not see a contractor's eight fields. And make conditional fields conditional: ask for a vehicle number only after the visitor says they drove in.
Photos, ID scans and biometrics
Give the photo its own toggle, its own purpose line and its own retention rule. If the photo is for a printed badge, say so and delete it when the badge comes back. If it is for a security audit trail, say that and set a period. Do not capture it because the system has the field.
Biometric capture — fingerprint or face templates used for matching, not just a stored photo — is a bigger step. It needs a specific purpose that routine check-in rarely justifies, and belongs in a separate consent flow with legal sign-off.
A sample visitor check-in notice
This is a drafting starting point, not approved legal text. It must be reviewed and adapted by your own counsel before you display it. Fill the bracketed fields with your details.
Before you check in
[Organisation name] collects the following from visitors at this site:
your name, your mobile number, the name of the person you are visiting, and your time of entry and exit.Why: to verify who is on the premises, to notify your host, and to maintain a visitor record for site security.
Optional — only if you tick it:
- Photograph, used only to print your visitor badge and deleted when you return it.
- Vehicle registration number, used only for parking access during your visit.
- Contact by email or phone about [Organisation name]'s products and events. You can check in without this.
How long we keep it: your visitor record is retained for [period] and then erased.
Your choices: you can ask what we hold about you, ask us to correct it, ask us to erase it, or withdraw your consent at any time. Contact [name/role], [email], [phone].
Complaints: if you are not satisfied, you may complain to the Data Protection Board of India.
Languages: this notice is available in [list]. Ask at the desk or tap [language icon].
☐ I agree to [Organisation name] collecting the required information above for site security. (unticked by default, required to check in)
☐ I agree to a photograph for my badge. (unticked, optional)
☐ I agree to be contacted about products and events. (unticked, optional)
Note what it never says: "I have read and accept the privacy policy". It does not combine the three consents, and it does not hide the withdrawal route behind a link.
Good vs bad check-in screen
| Element | Bad screen | Good screen |
|---|---|---|
| Notice | "By continuing you accept our privacy policy" | Standalone notice on screen, readable in 30 seconds |
| Data description | "We collect certain information" | Itemised: name, mobile, host, entry time |
| Purpose | "For business purposes" | "To verify who is on site and notify your host" |
| Consent control | One pre-ticked box | Separate unticked boxes, required vs optional marked |
| Optional data | Blocks check-in if refused | Check-in completes without it |
| Photo | Auto-captured on arrival | Separate toggle, stated purpose and deletion point |
| Fields | Same eight fields for everyone | Different forms per visitor type |
| Withdrawal | Not mentioned | Named contact and channel on the same screen |
| Language | English only | Language option per Section 5(3) |
| Board complaint | Absent | One line on the notice |
| Previous visitors | Visible on an open register | Never visible to the next visitor |
What happens when a visitor withdraws consent
They must be able to withdraw as easily as they consented, and you must stop processing within a reasonable time. Section 6(4) gives the right to withdraw at any time, with comparable ease. A workable desk process:
- One named channel on the notice — a monitored email or number, not a form buried on the website.
- Identify the person against something they gave you, usually mobile number and visit date.
- Act on the specific consent withdrawn. Withdrawing marketing consent removes them from the list; it does not automatically erase a security record held for a stated, still-live purpose.
- Delete everywhere — the Excel export, the emailed daily report, the WhatsApp group.
- Log it, then test it once before 13 May 2027.
Visitors under 18 and accompanied minors
Children need verifiable parental consent, and you cannot track them or target advertising at them. Section 9 requires verifiable consent of the parent before processing a child's personal data, and prohibits tracking, behavioural monitoring and targeted advertising directed at children.
At a reception desk, the simplest compliant option is not to create a separate record for the minor at all — record the accompanying adult and note "accompanied by one minor" as a count. A number is not personal data. Never photograph a minor at a self-service kiosk without the adult completing consent.
When the tablet is down: the paper fallback
The paper fallback needs the same notice as the screen, or it becomes your weakest point. Three things fix it: a printed notice card matching the screen word for word, individual slips instead of a shared page so nobody reads anyone else's, and a written re-entry rule covering who types them in, by when, and what happens to the paper.
What about the visitors already in your old register
You cannot retrospectively take consent, so decide per record: keep it under a stated purpose, or erase it. For most legacy visitor data the purpose is long served, and the cheapest compliant action is deletion. Set a cut-off date, delete everything before it with no live purpose, and document the decision.
10-point check-in screen design checklist
- The notice is on the screen itself and understandable without opening anything else.
- The data collected is listed field by field, by name.
- The purpose is one plain sentence a guard could repeat.
- Nothing is pre-ticked. Every consent needs a tap.
- Required and optional consents are visually separate, and check-in completes without the optional ones.
- The photo, if taken, has its own toggle, purpose and deletion point.
- Different visitor types get different forms, with conditional fields hidden until relevant.
- A named contact and channel for questions, erasure and withdrawal appears on the notice.
- A line tells the visitor they may complain to the Data Protection Board.
- A language option exists per Section 5(3), and the printed fallback card matches the screen exactly.
Failing more than three? Start with items 4 and 5 — the fastest fixes, and the likeliest to be tested.
Where a visitor management system helps
VizMan covers the structural side: role-based modules, OTP verification, digital and printed passes instead of an open counter register, and a dashboard an admin can pull or delete a record from. Offline mode keeps low-connectivity gates off the notebook.
Put these five questions to any vendor in writing before you sign:
- Can we edit the notice text ourselves, per site and per visitor type?
- Can we create separate, independently tickable consents rather than one agreement box?
- Can optional fields be genuinely optional, so check-in completes when they are refused?
- Can we display the notice in more than one language?
- Can we delete a single visitor's record on request, and is that deletion logged?
Frequently asked questions
What must a DPDP visitor consent notice contain?
The data collected, itemised by field; the specified purpose; how the visitor exercises rights and withdraws consent with comparable ease; and how to complain to the Data Protection Board. Under Rule 3 it must be standalone and in plain language.
Is a single "I agree to the terms" tick box enough?
No. Section 6(1) requires consent that is free, specific, informed, unconditional and unambiguous, with a clear affirmative action. One box covering security, photography and marketing is not specific.
Does the notice have to be in a regional language?
You must give the visitor the option to access it in English or any language in the Eighth Schedule to the Constitution, under Section 5(3). You need not display them all at once.
Can we take a visitor's photo at reception?
A photograph is personal data, so it needs its own specific consent, stated purpose and retention rule — a separate, unticked toggle, not part of the main consent.
How does a visitor withdraw consent, and what must we do?
Section 6(4) requires withdrawal to be as easy as giving consent. Publish a named channel on the notice, identify the requester, act on the specific consent withdrawn, delete across every copy, and log it.
What do we do about visitors under 18?
Section 9 requires verifiable parental consent and prohibits targeted advertising directed at children. The simplest reception practice is not to create an identified record for an accompanying minor at all.
Does the paper register need a notice too?
Yes, if the entries are later digitised — and they usually are. Use a printed card matching the screen, individual slips rather than a shared page, and a documented transfer rule.
When does this become enforceable?
Rules 3 and 5 to 16 of the DPDP Rules, 2025 come into force on 13 May 2027.
|
See how VizMan works for your site Book a VizMan demo and we will walk your current check-in screen against the 10-point checklist, field by field — the parts a system fixes, and the parts that stay yours. |
This article is general information, verified against the linked sources on 16 September 2026, and is not legal advice. The sample notice is a drafting starting point only and must be reviewed by your own counsel before use.
Explore more from VizMan: Visitor management system · Pricing · All blogs · Book a demo
Official sources
Statutory references in this guide were checked against the official texts published by the Ministry of Electronics and Information Technology (MeitY), Government of India:
- The Digital Personal Data Protection Act, 2023 (official text)
- The Digital Personal Data Protection Rules, 2025 (notified 13 November 2025)
This guide is general information, not legal advice.