Visitor Management Policy for Indian Offices: The 2026 Framework That Survives an Audit

Key Takeaways

A visitor management policy is a governance document. The software enforces it; the policy decides what gets enforced and who is accountable.
Imported templates fail in India because they carry no DPDP notice, consent, retention or erasure architecture, and no POSH route for non-employees.
India’s DPDP Rules were notified in November 2025. Notice, consent, security, rights and penalties all bite in mid-May 2027.
The Data Protection Board exists, but its inquiry and penalty powers are not yet in force. Nobody is being fined for a visitor register in 2026.
Rule 6(1)(e) sets a one-year floor on logs and personal data, which cuts against the standard “delete visitor data after 90 days” advice.
A never-digitised paper register sits outside DPDP. Photograph or type one entry and the whole practice comes into scope.
Visitors fall inside the POSH Act’s definition of an aggrieved woman, so your policy needs a complaint route for non-employees.
In shared buildings, lobby security and your reception are separate data fiduciaries collecting twice. Write the boundary into the policy.

Most Indian offices already have a visitor policy. It runs to about two pages; it was adapted from a template written for a company in Ohio, and it says something close to: all visitors must sign in at reception, wear a badge at all times, and be accompanied by their host. It has never failed, because nothing has ever tested it.

Three things are about to test it. The Digital Personal Data Protection Rules are notified and running on a clock. Your ISO 27001 auditor has started asking to see the visitor log for a specific Tuesday rather than glancing at the register. And a growing share of Indian offices no longer own the front door they are writing rules about.

That last one is worth a number. Flexible space operators took 27% of gross office leasing in Q2 2026 on CBRE’s count, against a record 24.6 million sq ft for the quarter; JLL’s sector cut for the same quarter puts flex at 28.4%, just behind technology; and Colliers expects operators to account for 20–25% of full-year leasing. Different methodologies, same conclusion: roughly a quarter of new Indian office space is being taken by companies whose actual business is running somebody else’s front door.

This guide is about the document itself: what belongs in it, what the law now requires it to say, and where the standard templates quietly leave you exposed.

What Is A Visitor Management Policy?

A visitor management policy is the written rule set that defines who may enter your premises, what personal data you collect from them, who approves and escorts them, what they may and may not do inside, how long their records are retained, and who is accountable when any of that fails. It is the governance layer that sits above your reception desk and your visitor management software.

The distinction matters more than it sounds, because four separate artefacts routinely get collapsed into one and the gaps show up during audit.

Artefact	What it does	Who owns it	Who reads it
Visitor management policy	Sets the rules and the accountability	HR / Admin / Security, board-approved	Employees, auditors, counsel
Front-desk SOP	Tells reception and guards what to do, step by step	Facilities or security lead	Reception, guards, shift supervisors
Visitor privacy notice	Tells the visitor what you collect and why, before you collect it	Legal / DPO	The visitor, at the point of check-in
Visitor management system (VMS)	Enforces the policy and produces the evidence	IT / Admin	Nobody reads software; it just has to behave

Write only the SOP and you have instructions with no authority behind them. Buy only the software, and you have a well-instrumented process that nobody has agreed to. The policy is what makes the other three defensible.

The short version of the difference: the policy is a decision, the system is an enforcement mechanism. A VMS can capture consent, expire a pass and run a deletion job, but only after someone has decided what consent text to show, how long a pass lives and when data goes. That decision is the policy, and no software makes it for you.

Why Imported Visitor Policy Templates Fail In India

Search for a workplace visitor policy template, and you will find a dozen good ones. They are almost all written against US or UK assumptions, and they break in four predictable places once you apply them to an Indian office.

They treat visitor data as an etiquette question, not a legal one: The typical template devotes a paragraph to badges and nothing to consent, notice, lawful basis, retention or erasure. Under India’s framework, those are not best practices. They are obligations.

Their retention advice is wrong for India: “Keep visitor logs for 90 days” is the standard line. India’s notified Rules impose a minimum retention floor on logs and personal data that runs longer than that. Deleting on a 90-day cycle without reconciling the two is a documented decision to under-retain.

They have no POSH hook: Section 2(a) of the Sexual Harassment of Women at Workplace Act, 2013 defines an aggrieved woman as a woman of any age, whether employed or not, which, as SHRM’s summary of the Act’s common myths sets out, expressly reaches clients, customers and others who are not on your payroll. A visitor can be a complainant. A visitor can be a respondent. Almost no imported template gives either one a route.

They assume you control the building: Most Indian offices sit inside a multi-tenant tower or a managed flex facility with its own security layer at the ground-floor lobby. A policy that says “all visitors sign in at reception” without saying which reception is describing a workflow that does not exist.

What Indian Law Actually Requires At Your Front Desk

Five instruments do the real work. None of them mandates a visitor management system by name; together they make an undocumented, unconsented, indefinitely retained paper register very hard to defend.

The DPDP clock, and what is actually switched on

The Digital Personal Data Protection Rules, 2025 were notified in November 2025, alongside the notifications commencing parts of the Act and establishing the Data Protection Board. Enforcement is staggered across three tranches under G.S.R. 843(E), analysed here by Shardul Amarchand Mangaldas:

Tranche	Approx. date	What comes into force	What it means at your front desk
Commencement	13 Nov 2025 (gazetted 14 Nov)	Definitions; constitution of the Data Protection Board (ss.18–26); ss.35, 38–43	The Board exists institutionally. Its powers to inquire and penalise are not in this tranche
Twelve months	Mid-Nov 2026	s.6(9), s.27(1)(d) and Rule 4 all Consent Manager provisions	Little direct effect on visitor data
Eighteen months	Mid-May 2027	ss.3–5, most of s.6, ss.7–17, most of s.27, ss.28–34 (including s.33, penalties), s.44(2)	Notice, consent, purpose limitation, security safeguards, breach reporting, data principal rights and the penalty regime. This is the date your check-in form is written for

Two points of precision that most published timelines get wrong.

The Board cannot yet act on a complaint: Sections 18 to 26 constitute the Board and are in force. Section 27, which sets out its powers and functions, sits in the eighteen-month tranche apart from clause (d) of sub-section (1). Through 2026, no Chairperson or Members had been appointed, a gap LiveLaw examined in August 2026. If a vendor tells you the Board is hearing visitor-data complaints today, they have not read the notification.

The exact date is 13 or 14 May 2027, and it depends on how you count: The notification is dated 13 November 2025 and was published in the Gazette on 14 November. Reputable sources are split. Do not build an implementation plan whose margin is one day.

What the penalties actually are

The way this is usually explained to buyers is that a paper register attracts fines of ₹250 crore. That is wrong twice over, and repeating it makes the rest of your compliance argument easy to dismiss.

The Schedule to the Act sets seven categories, each a ceiling rather than a tariff:

up to ₹250 crore for failing to take reasonable security safeguards to prevent a breach (s.8(5))
up to ₹200 crore each for failing to notify a breach (s.8(6)) and for breaching children’s data obligations (s.9)
up to ₹150 crore for a Significant Data Fiduciary’s additional obligations (s.10)
up to ₹10,000 on an individual for breach of a data principal’s duties (s.15)
the amount applicable to the underlying breach where a voluntary undertaking is broken (s.32)
and up to ₹50 crore as the residual category covering everything else. A defective consent or notice practice at a reception desk sits in that last bucket.

And section 33, which carries the penalty regime, is itself in the eighteen-month tranche. Nobody is being fined for a visitor register in 2026. The ceilings are large enough without inflating either the number or the timing.

The paper register paradox

Here is the part that surprises most admin heads. The DPDP Act applies to digital personal data collected in digital form, or collected on paper and digitised afterwards. A handwritten register that is never scanned, photographed or typed into a spreadsheet sits outside the Act’s material scope, as DLA Piper’s India chapter notes.

That is not a defence. It is a trap, for three reasons.

The condition rarely holds: Somebody photographs the page for the daily security report, or an executive assistant types the week’s entries into Excel for the MIS. At that moment, the whole practice is inside the Act, with retrospective obligations you have no consent record for.

The other regime has an expiry date: Section 43A of the Information Technology Act, 2000 and the SPDI Rules, 2011 framed under it still apply today. Section 44(2) of the DPDP Act omits section 43A, and s.44(2) is itself in the eighteen-month tranche. So the sensitive-data rules some organisations still rely on and the DPDP obligations that replace them change places in mid-2027 rather than overlapping indefinitely. Meanwhile your ISO 27001 certification, your customers’ vendor security questionnaires and your own contractual commitments are unaffected by DPDP’s scope carve-out either way.

And it fails on its own terms: An open register shows every subsequent visitor the name, company and mobile number of everyone before them. No statute is required to see the problem. That single design flaw is the clearest argument for digitising the visitor log, and it holds regardless of which commencement date you are counting to.

ISO 27002 control 7.2: what your auditor is testing

If you hold ISO/IEC 27001:2022, physical entry is control 7.2, and the supporting guidance is unusually specific for a standard that normally avoids prescription. Authenticate visitor identity by an appropriate means. Record date and time of both entry and departure. Grant access only for a specific authorised purpose, with instructions on the area’s security requirements and emergency procedures. Supervise visitors unless an explicit exception has been granted.

Read that list against your current policy. Most fail on the second and fourth items: departure times and the escort exception, and those are exactly the two an auditor can test in ninety seconds by pulling a single day’s log.

POSH: visitors are inside the definition, in both directions

The POSH Act has not been replaced by a 2026 statute, despite what a few sites now claim. What has changed is the evidence expectation around it. Employers are increasingly registering Internal Committees on the Ministry of Women and Child Development’s SHe-Box portal, and complaints routed through it come back to the employer for action, which means your internal process has to be able to receive one.

Two things follow for a visitor policy. First, a visitor who is harassed on your premises is an aggrieved woman under s.2(a), and your policy has to tell her where to go which means the Internal Committee’s contact details need to be available at reception and inside the visitor notice, alongside the display obligation you already carry under s.19. Second, in Dr Sohail Malik v. Union of India (2025), the Supreme Court confirmed that the Internal Committee at the aggrieved woman’s workplace may have jurisdiction even where the respondent works somewhere else. That is exactly the visitor scenario: your employee complaining about a vendor’s engineer, or a client’s executive complaining about your employee. A complaint should not be waved off because the other person is on somebody else’s payroll.

Contractors: the governing law changed in November 2025

Most visitor policies still cite the Contract Labour (Regulation and Abolition) Act, 1970 by name. That reference is now stale. All four labour codes were brought into force on 21 November 2025, and the Occupational Safety, Health and Working Conditions Code, 2020 consolidates thirteen statutes including the Contract Labour Act and the Factories Act. The codes are in force; the central and state rules that operationalise them were still being notified through 2026.

Practically, that means two things. Write your contractor clauses against the OSH Code rather than the 1970 Act, and write them so a state rule notification does not force a rewrite: reference the obligation, not the rule number. And treat the reference itself as a freshness signal: an auditor who sees a 1970 citation in a 2026 policy will assume, usually correctly, that nothing else in the document has been reviewed either.

Evacuation: a real obligation with no national form

There is no central statute telling an Indian office how to log visitors for fire safety. Fire services and building safety are state subjects; the operative duties sit in state fire service legislation and municipal building bye-laws, most of which adopt Part 4 of the National Building Code of India, 2016 by reference.

What those instruments consistently require of an occupier is a workable means of escape and a rehearsed drill. Neither works without an accurate count of who is inside. That is the honest way to state it: the roll-call is not a prescribed statutory form; it is the thing every evacuation obligation quietly assumes you can produce.

This article is a practitioner’s guide, not legal advice. Have your final policy and your visitor privacy notice reviewed by counsel before adoption.

The Twelve Sections Every Visitor Management Policy Needs

What follows is the structure we see holding up best in Indian offices, grouped four ways: accountability and scope, entry controls, data, and operations. Each section states the decision you actually have to make and gives a sample clause you can adapt.

1. Start with host accountability; it is the highest-leverage clause you will write

Most policies bury this. Put it near the top, because it is the single change that improves the largest number of downstream outcomes at zero cost.

Name the host as accountable for the visit, not the security guard. The guard controls a gate; the host knows why the person is there, whether they should be in a restricted area, and when they left. Every unclosed checkout, every unescorted wander and every stale badge traces back to an unnamed owner.

Sample: Every visitor must have a named employee host. The host is accountable for approving the visit, receiving the visitor at the entry point, supervising them in non-public areas, and confirming departure. A visit without an identified host will not be approved.

2. Purpose, scope and who counts as a visitor

Define the premises the policy covers, including parking, loading bays, terraces and any leased space in a shared building. Then define “visitor” broadly enough that nobody argues about it later: clients, candidates, auditors, vendors, contractor workers, delivery and courier personnel, employee family members, alumni, and employees from other locations who lack local access credentials.

State the exclusions explicitly too. If a courier who never crosses the lobby line is not a visitor for policy purposes, say so, and say where the line is.

If you operate more than one office, decide here whether this is one policy or several. One policy with site-specific annexures is almost always right: the accountability, data and retention rules should be identical across Chennai and Gurugram, while entry points, zone maps and building operators plainly are not.

3. Visitor categories and differentiated entry rules

One flow for everyone is why check-in queues form. Categories let you collect less from most people and more from the few who need it.

Category	Pre-approval	Identity check	Data collected	Escort	Extras
Guest/client	Host invite	Name confirmation	Name, mobile, company, host, purpose	In non-public areas	—
Interview candidate	HR schedule	Name confirmation	Name, mobile, host	To and from interview room	Candidate data goes to HR retention, not visitor retention
Vendor/auditor	Host invite	Photo ID sighted, not stored	Standard set	Full escort	NDA acknowledgement
Contractor worker	Contractor supervisor	ID verified against contractor roster	Standard set + firm name	Zone-restricted	Safety induction, work permit
Courier/delivery	None	None at lobby line	Name, firm, recipient	Not beyond drop point	—
VIP / executive	Named approver, usually EA or CXO office	Discreet, by recognition or invite match	Minimum set; no photograph unless agreed	Personally received	Protocol note; discretion is a security requirement, not a courtesy
Repeat / long-term vendor	Standing approval	On first visit	Standard set + firm name	Zone-restricted	Pass validity end date, mandatory

Two rows deserve a note.

VIP visits are where policies get suspended, which is precisely when they need to hold. The realistic answer is not to exempt VIPs but to give them a category with a named approver, minimal data capture, and a person rather than a queue. Write it down and the exception stops being improvised.

Long-term passes are where most offices leak. They get issued and never expire. Every one must carry an end date written into the policy, not left to whoever issues it.

After-hours and weekend visits need their own rule rather than an assumption. State the standard visiting window, name who can authorise entry outside it at a level, not a person and require that the authorisation is recorded against the visit rather than given verbally at the gate. Most after-hours incidents are not intrusions; they are ordinary visits that nobody could account for afterwards.

4. Pre-registration as the default, walk-ins as the exception

This is the operational decision that determines whether the rest of your policy is enforceable, and almost no template addresses it.

	Pre-registered	Walk-in
Host approval	Before arrival, in writing	At the door, under time pressure
Notice and consent	Shown with the invite and again at check-in	Only at check-in, in a queue
Identity	Name matched against an invite	Nothing to match it against
Check-in time	Seconds	Minutes, with a queue forming behind
Denial of entry	A decision made calmly, in advance	A confrontation at reception

Host accountability only works if approval happens before the person is standing in your lobby. Once they have arrived, the host approves under social pressure, and the record you keep is of a decision that was never really made.

Sample: Visits by clients, vendors, auditors, candidates and contractor personnel must be pre-registered by the host. Walk-in entry is permitted only where [named role] authorises it; the authorisation and its reason are recorded on the visit record.

5. Identity verification, kept proportionate

Decide what you verify and what you store, and write both down. Those are different decisions, and conflating them is how offices end up with a folder of Aadhaar photocopies at reception.

For a routine business guest, confirming a name against a host-issued invite is proportionate. For a contractor entering a plant room, checking a photo ID against the contractor’s roster is proportionate. Retaining a scan of a government identity document for either is usually not, and it converts your reception desk into a high-value target.

Aadhaar deserves its own line, and the useful line is narrower than most policies assume. The 2022 UIDAI advisory telling private entities not to hold Aadhaar photocopies was withdrawn days later, which is why the position feels muddy. It is less muddy than it feels. Aadhaar authentication by a private entity is not open season: it runs through the Aadhaar Authentication for Good Governance Rules, which require a proposal to the relevant ministry, a reference to UIDAI, and central government approval for a specified purpose. A reception desk verifying a vendor is not that. Separately, UIDAI has approved a registration requirement for entities seeking Aadhaar-based verification, with QR- and app-based checks intended to replace paper copies; as of mid-2026, the formal notification was still pending. The current instruments sit on the UIDAI legal framework page.

The defensible policy line does not depend on how that resolves: do not make Aadhaar your default visitor ID, never photocopy it, and if a visitor offers it, sight it and move on.

Biometrics and facial recognition need a decision, not a default. A face template is personal data. Collecting one requires the same notice and consent as a phone number, and it is harder to justify on minimisation grounds, because the point of a visitor system is that most visitors come once. The question to ask your vendor is what happens to the template after the visit ends. If the answer is “we keep it so check-in is faster next time”, that is a second purpose, and it needs its own consent rather than riding on the first.

Sample: Government identity documents may be sighted for verification where the visitor category requires it. Images or copies of identity documents will not be captured, uploaded or retained except where a specific legal or contractual obligation requires it and the DPO has approved it in writing. Biometric identifiers, including facial templates, will not be collected from visitors without a documented purpose, a separate consent, and a defined deletion trigger.

6. Notice and consent at the point of collection

This is the section that does not exist in imported templates, and the one your policy will be judged on after mid-May 2027.

Rule 3 of the DPDP Rules sets out what the notice has to be. It must stand on its own and be understandable without reference to any other document; you cannot point at a privacy policy on your website. It must be in clear, plain language. It must give an itemised description of the personal data being collected and the specific purposes. It must give a working link and means by which the person can withdraw consent as easily as they gave it, exercise their rights, and complain to the Board. And it must be available in English or any language in the Eighth Schedule to the Constitution, at the person’s option, not a requirement to publish all twenty-two at once. The Rules themselves are on MeitY’s DPDP Rules page. Rule 9 separately requires you to publish the contact details of a person who can answer questions about the processing which, for a visitor, means a name and a route rather than a generic inbox.

A pre-printed line at the top of a register saying “by signing below you consent to our data policy” satisfies none of this. Consent has to be free, specific, informed, unconditional and unambiguous, given by clear affirmative action, and limited to the data necessary for the stated purpose.

Your policy should require three things: that the notice is shown before any field is captured, that the notice version shown is logged with a timestamp, and that a visitor who declines is offered an alternative, usually a manually escorted, minimal-data visit rather than being turned away.

Sample visitor notice, adapt with counsel: We collect your name, mobile number, organisation, host name, purpose of visit and entry/exit times, to verify your identity at entry, notify your host, maintain a security record of who is on the premises, and account for everyone present during an emergency. We do not use this data for marketing. Records are retained per our published schedule and then deleted. To withdraw consent, access or correct your record, or raise a complaint, contact [DPO name, email, phone]. You may also complain to the Data Protection Board of India.

7. Escorting, zones and what a badge actually authorises

A badge is a claim about authorisation, so define what it authorises. Map your premises into zones: public (lobby, meeting rooms off the lobby), general work floor, restricted (server room, records room, plant room, labs) and state which categories may enter which, and under what supervision.

Then handle the exception honestly. ISO 27002 contemplates unescorted access as an explicitly granted exception, not as a default that emerges because everyone is busy. Name who can grant it, for whom, and for how long. If your badges drive physical doors rather than just being visual, the zone map and the reader groups have to agree, which is a systems question as much as a drafting one, and the failure mode is covered in our guide to integrating a VMS with access control.

8. Conduct: NDA, photography, POSH and removal

Cover four things and resist the urge to write a code of conduct.

Confidentiality: which categories sign an NDA or acknowledge one digitally at check-in, and where that record lives. Photography and recording: where it is prohibited, and that this includes visitors’ phones. Harassment: that visitors are both protected and bound, with the Internal Committee’s contact details available at reception and in the visitor notice, and a stated position that a complaint is not dismissed because one party works for a different organisation. Removal: who has authority to deny entry or ask someone to leave, and that the decision is logged with a reason.

The denial-of-entry clause is the one people skip and then improvise under pressure. Write it before you need it.

9. Retention, erasure and who else touches the data

The schedule itself is set out in full in the next section. Three things belong in the policy clause rather than the schedule.

Deletion runs on a schedule, not on request. If erasure only happens when someone asks, you cannot demonstrate a practice, only a favour.

Your VMS vendor is a data processor, and that has a contract consequence. If visitor check-in runs on somebody’s software, you are the data fiduciary, and they are almost certainly a processor. Rule 6(1)(f) requires the contract between you to carry appropriate provisions for reasonable security safeguards a drafting obligation, not just a diligence one. Three things belong in that contract and are usually missing: where the data is hosted, how long the vendor retains it after you delete it at your end, and what happens to it on termination. Section 8(1) keeps the fiduciary responsible for processing done on its behalf, which means a vendor’s failure is your exposure.

Breach has a procedure, and you should name it. If your visitor database is exposed, Rule 7 requires you to inform affected individuals without delay and the Board without delay, with a detailed report within 72 hours unless extended. Say who declares a breach, who notifies, and who writes the report. A visitor database is a small target with a lot of mobile numbers in it, which is a common combination in the ones that get sold.

10. Emergency roll-call and the checkout problem

State the requirement plainly: at any moment, an authorised person must be able to produce a list of everyone currently on the premises, and that list must be accurate.

Which means checkout is not an administrative nicety. It is the input to the roll-call. A visitor record with no exit time is indistinguishable from a person still inside the building, and an evacuation list that over-reports sends fire wardens back into a building for someone who left at eleven.

Your policy should therefore assign responsibility for closing open records, normally the host, with a defined auto-close rule and a note on the record showing it was system-closed rather than confirmed. Test it during your drill, not after.

11. Incidents, exceptions and deactivation

Three things happen constantly and are documented almost nowhere, which is why they surface as audit findings.

Incidents: Define what counts as a denied entry, an unescorted visitor found in a restricted zone, a tailgating event, a lost badge, a refused consent that escalated, a harassment complaint involving a visitor. Give each a log entry with date, people, decision and the person who made it. The value is not the incident record; it is that the pattern becomes visible before it becomes a finding.

Exceptions: Every unescorted-access grant, every walk-in override, every after-hours authorisation is an exception to your own rule. Log them in one place with an expiry. An exception register that is empty is not a compliant organisation; it is an organisation that is not recording exceptions.

Deactivation: Long-term vendor passes, contractor rosters and standing approvals all need an off-switch with an owner. State that a pass is deactivated on the earlier of its end date, the end of the contract, or notification by the contractor that the person has left and that the contractor is contractually obliged to give that notification. This is the visitor-side equivalent of employee offboarding, and it fails for the same reason: nobody owns the end of the relationship.

12. Ownership, review and enforcement

Name a policy owner by role. Set a review cadence annually, plus on any change to premises, entry points, building operator, or applicable law. State what happens when an employee bypasses the policy, because a rule that cannot be breached is a suggestion. Version the document and record approvals.

How Long Should You Keep Visitor Records In India?

If your office is inside a commercial tower or a managed flex facility, a visitor is very likely registered twice: once by building security at the ground-floor lobby, and again by your reception on your floor. Two collections. Two sets of purposes. Two organisations deciding what to do with the data.

The building operator determines the purpose and means of its own lobby collection. You determine the purpose and means of yours. Neither becomes the other’s processor by virtue of sharing a building. That has practical consequences a template will never surface for you:

You cannot rely on the building’s notice: Your collection needs your notice, naming you, with your DPO’s contact details.
You cannot rely on the building’s log for your roll-call: Lobby registration proves someone entered the tower, not that they reached or left your floor.
You inherit their retention practice by accident: Ask the operator, in writing, what they collect, how long they keep it and whether they photograph identity documents. If their practice is weak, your visitors’ data is still exposed, and your visitors will not distinguish between you.
Your policy needs a boundary clause: One paragraph stating which entry point is governed by whose policy, what data flows between the two, if any, and on what basis.

The same logic runs across sites. If you operate in four cities, the risk is not that each office does something different; it is that nobody can say which office does what. Keep one policy, one retention schedule and one consent text; vary only the annexure that describes entry points, zones and the local building operator. Then make sure whatever system you use can show you all four sites from one screen, because a policy you cannot audit centrally is four policies wearing the same cover page.

This is a conversation with the landlord or operator, not a drafting exercise. Have it before you publish, and record the outcome in the policy itself.

The Audit-Ready Control Framework

The title of this article promises a framework that survives an audit, so here is the actual mapping: what the policy has to define, and what someone can ask you to produce.

Control area	What the policy must define	Evidence you should be able to produce	Where the expectation comes from
Identification	Which categories are verified, how, and what is stored versus sighted	Visitor records for a named date	ISO 27002 7.2; DPDP minimisation
Approval	Who may host; who may approve exceptions and walk-ins	Host approval and invite records	Internal control
Notice & consent	What the visitor sees, before which field is captured	Notice text, version and timestamp per visitor	DPDP Rule 3
Access & zones	Which categories enter which zones, escorted or not	Badge/zone records; escort exception register	ISO 27002 7.2
Retention & erasure	Period per record type and the deletion mechanism	Deletion job schedule plus immutable deletion log	DPDP s.8(7), Rule 6, Rule 8
Data security	Who can read visitor data and how that list is reviewed	Admin access list with last review date	DPDP Rule 6(1)(b), (c)
Processors	Who processes on your behalf, and on what terms	Signed contract carrying the security clause	DPDP Rule 6(1)(f); s.8(1)
Breach	Who declares, who notifies, who reports	Breach register; drill or incident record	DPDP Rule 7
Rights & grievances	How a visitor asks what you hold, and by when you answer	Published request route and response period	DPDP Rule 14
Emergency	Who produces the on-premises list, and how fast	Roll-call output plus drill reconciliation	State fire rules; NBC 2016 Part 4
Contractors	Roster verification, induction, permits, zone limits	Induction and permit records	OSH Code, 2020
Conduct & incidents	NDA, photography, POSH route, denial of entry	Incident log with reasons and decision-makers	POSH Act ss.2(a), 19
Ownership	Named owner, review cadence, approval route	Versioned policy with approver and date	Governance

This is a working control map, not a compliance guarantee. Auditors scope differently; a customer’s security questionnaire is not an ISO audit, and neither is a regulatory inquiry. Use it to find your gaps, not to certify their absence.

The six-artefact spot check

If you want the fast version, these six are what get asked for most often. If you cannot produce all six today, that list is your implementation plan.

The approved, versioned policy, with the date and the approver.
A visitor log for a named date, showing entry and exit times against a named host.
The consent and notice record for one specific visitor, showing what they saw and when.
Evidence that deletion ran on schedule, and the deletion log proving it.
The list of people with administrative access to visitor data, and when that list was last reviewed.
The roll-call output from your last evacuation drill, with the reconciliation of any discrepancy.

Rolling It Out In 30 Days

Days 1–5: Count what you actually collect at every entry point, including the building’s lobby. Most offices discover a field or two nobody can justify.
Days 6–10: Draft the categories table and the retention schedule first. These two decisions constrain everything else in the document.
Days 11–15: Write the visitor notice, and send it and the retention schedule to counsel together.
Days 16–20: Have the landlord conversation. Get the boundary clause right before you publish.
Days 21–25: Configure the system to match the policy categories, notice display, consent capture, pass validity, auto-close, deletion job. If your platform cannot express a rule the policy requires, change the platform or change the rule, but do not publish a policy you cannot enforce.
Days 26–30: Brief hosts and reception, run one drill against the roll-call, and publish with a review date.

The order matters. Teams that configure software first end up with a policy written backwards from whatever the tool happened to support.

Where Qudify Fits

A policy is only worth the enforcement behind it, and most of the clauses above map to specific system behaviour: showing a standalone notice before the first field is captured, logging which notice version a visitor saw, expiring long-term vendor passes automatically, closing open records, running scheduled deletion, and producing a live on-premises list during a drill.

Qudify was built around that mapping for Indian offices specifically. Visitors check in by scanning a QR code on their own phone, hosts approve over WhatsApp, and there is no kiosk, badge printer or app install in the path, which matters when your policy says a visitor who declines something must still have a workable route in. Multi-site operations run from one dashboard with office-wise admin controls, which is the practical answer to the multi-tenant and multi-city boundary problem.

Qudify reports 500+ live sites, 400+ client organisations and over 64,000 monthly active users. Those are self-reported figures and are not independently audited; treat them as you would any vendor’s.

If you are earlier in the process, our fact-checked comparison of the leading platforms in India covers the selection question, and contactless visitor management in India covers why the check-in method itself is now a policy decision. For the surrounding controls, see office security best practices for Indian enterprises.

A demo is available if you want to see the check-in flow against your own front desk.

Frequently Asked Questions

What is a visitor management policy?

It is the written rule set defining who may enter your premises, what data you collect from them, who approves and escorts them, how long records are kept, and who is accountable when something fails. It governs the front desk; it is not the same thing as the software running it.

What should a visitor management policy include?

Twelve sections in four groups. Accountability and scope: host accountability, purpose and definitions, visitor categories. Entry controls: pre-registration versus walk-ins, identity verification limits, notice and consent, escorting and zones. Conduct and data: NDAs, photography, POSH, removal, retention and processors. Operations: emergency roll-call and checkout, incidents and deactivation, and named ownership with a review cadence.

What is the difference between a visitor policy and a visitor management system?

The policy is a decision; the system is an enforcement mechanism. Software can capture consent, expire a pass and run a deletion job, but only after someone has decided what the consent says, how long the pass lives and when data goes. Buying a VMS without a policy gives you a well-instrumented process nobody has agreed to.

Is a visitor management policy legally required in India?

No statute names the document. But the DPDP Act and Rules impose notice, consent, security, retention and rights obligations on any organisation collecting visitor data digitally, and ISO 27001, POSH and state fire-safety obligations attach to people on your premises regardless. The policy is how you evidence all of it in one place.

Does the DPDP Act apply to visitor data?

Yes, where the data is digital. A name, mobile number, organisation and entry time collected through a tablet, kiosk or QR form is digital personal data; you are the data fiduciary, and the notice, consent, purpose-limitation, security and erasure obligations apply from mid-May 2027. Paper collected and then digitised is also covered.

Is a paper visitor register illegal under the DPDP Act?

Not directly. The Act covers digital personal data and data digitised after collection, so a register that is never scanned or typed up falls outside its scope. In practice, that condition rarely holds, and a shared open register still exposes every visitor’s details to the next one.

What information should offices collect from visitors?

For a routine guest: name, mobile number, organisation, host name, purpose and entry/exit times. That set supports identification, host notification, security records and emergency roll-call, which are the four purposes you can actually justify. Anything beyond it ID images, biometrics, vehicle details, health data needs a stated purpose of its own.

How long should visitor data be retained in India?

Long enough to satisfy the one-year floor Rule 6(1)(e) places on logs and personal data, and no longer than the purpose requires. Twelve months for the entry/exit log is a defensible default, with contractor and candidate records moved onto their own schedules and CCTV kept under its own policy. Confirm the specifics with counsel.

What should a visitor sign-in process look like?

Pre-registration by the host; a standalone privacy notice shown before the first field; consent captured by an affirmative action and logged with the notice version; minimal fields; identity confirmed against the invite rather than stored; host notified; a pass with a stated validity and zone; and a checkout that actually closes the record.

How do you prepare visitor records for an audit?

Be able to produce six things: the versioned policy with its approver, a full day’s log with entry and exit times against named hosts, one visitor’s consent record showing what they saw and when, proof that deletion ran on schedule, the admin access list with its last review date, and the roll-call output from your most recent drill with any discrepancy reconciled.

Should we use Aadhaar or facial recognition to verify visitors?

Neither should be your default. Private-entity Aadhaar authentication runs through an approval route that a reception desk does not sit in, and copies should not be retained. Facial templates are personal data and are hard to justify for people visiting once. Sight a photo ID where the category warrants it, store a confirmation rather than an image, and keep biometrics for a documented purpose with its own consent.

Who owns the visitor management policy: HR, IT, or facilities?

Facilities or admin usually operate it, and IT configures the system, but the policy needs a single named owner with authority to enforce it, and legal or the DPO must sign off on the notice and retention sections. Split ownership without a named owner is why these documents go stale.

Does the policy apply to contractors and delivery personnel?

Yes, with different rules. Contractors typically need roster verification, a safety induction, zone restrictions and permits, now framed by the OSH Code, 2020 rather than the repealed Contract Labour Act. Delivery personnel who stop at a defined drop point usually need minimal data and no escort. Define both categories explicitly rather than treating everyone as a guest.

What happens if a visitor refuses to give their data?

Your policy needs a documented alternative, normally a minimal-data, fully escorted visit because consent given under threat of refused entry is difficult to characterise as free. Turning people away by default is the outcome you want to avoid designing into the process.

How does a visitor policy work in a shared or coworking office?

Building security and your reception are separate collections by separate organisations. You need your own notice, your own retention practice and your own on-floor record for roll-call. Add a boundary clause naming which entry point is governed by whose policy, agreed with the operator in writing.

How often should a visitor management policy be reviewed?

Annually at minimum, plus on any change to your premises, entry points, building operator, visitor volume or applicable law. Given the mid-May 2027 DPDP date and the labour codes commencing in November 2025, most Indian offices should schedule a review in 2026 rather than waiting.