# DPDP Rules 2025: the 18-month countdown for anyone with a visitor register
On 13 November 2025, the Ministry of Electronics and Information Technology notified the Digital Personal Data Protection Rules, 2025, the operating manual for the Digital Personal Data Protection Act, 2023. The Rules were published in the Gazette the following day, 14 November 2025, and they carry an 18-month compliance window — organisations have until 13 May 2027 to bring their data practices in line. That sounds like a long runway, and for most of India's offices, factories, warehouses and campuses it is. But the countdown starts now, and the register at your gate — the one that captures a visitor's name, phone number, photo, company, purpose of visit and sometimes an ID scan — is squarely inside the scope of this law.
This matters because a visitor register isn't paperwork anymore. It's a running record of personal data, collected daily, often by a security guard with no training in data protection, stored in a format nobody has really audited. Whether that register is a physical logbook, an Excel sheet at the reception desk, or a visitor management app, the question the DPDP Rules ask is the same: who is responsible for this data, why was it collected, how long is it kept, and what happens if it's misused or lost.
This article is a practical read for the person who actually owns this problem — the admin, HR lead or security head who signs off on gate procedures. It is not legal advice, and you should have your compliance or legal counsel review your specific setup against the final Rules before the May 2027 deadline; this piece is meant to help you understand what's coming and start preparing, not to substitute for that review.
The clock: what got notified and when
The DPDP Act itself was passed in 2023, but it needed implementing rules to actually function — things like how consent notices should be structured, how breaches get reported, and how long data can be retained. Those Rules are now final, notified on 13 November 2025, and the 18-month window running to 13 May 2027 is the period organisations have to get their house in order before enforcement begins in earnest.
Eighteen months feels generous until you map out everything that touches personal data in a typical facility: the gate register, the visitor pass printer, the HR onboarding form, the CCTV footage, the payroll system, the vendor contracts. A visitor register is usually one of the simplest of these to fix, which is exactly why it's a good place to start. If you can't explain today why your gate keeps ID photocopies for three years with no one responsible for deleting them, that's a gap worth closing early, while there's no penalty clock running.
Your visitor register makes you a Data Fiduciary
Under the Act, the organisation that decides why and how personal data is collected is the Data Fiduciary. If your company runs the gate and decides that visitors must give their name, phone number and photo before entry, your company is the Data Fiduciary for that data — not the security agency you've outsourced the gate to, and not the software vendor whose app runs on the tablet at reception. That vendor, if you use one, is typically a Data Processor: they handle the data on your instructions, but the obligation to justify the collection sits with you.
This distinction matters practically. If a visitor asks why their Aadhaar number was photocopied and stored, or wants to know who has access to their phone number, that request lands on your desk, not your software provider's. It also means your contracts with any visitor management vendor, facility management agency or third-party security provider should spell out what they can and can't do with the data your gate collects. The Ministry of Electronics and IT publishes guidance on personal data handling that's worth bookmarking as this framework matures, particularly if your organisation is still deciding how to formalise these vendor relationships.
What this looks like at a typical site
- A corporate office collecting visitor name, phone and photo at reception is a Data Fiduciary the moment that data is captured, not just when it's stored long-term.
- A factory or warehouse logging contractor entries alongside visitor entries is a Data Fiduciary for both categories, even if the purposes differ.
- A campus with multiple gates and multiple security contractors is still one Data Fiduciary if the entity operating the campus decides the collection policy — the guards don't each become separate fiduciaries.
What "consent" has to look like at the gate
The Rules require consent to be free, specific, informed and unambiguous, and the notice explaining what's collected and why has to be in plain language a visitor can actually read and understand before they hand over their details — not buried in a laminated sheet of terms taped to the reception desk. Equally, withdrawing consent has to be as easy as giving it. If a visitor can tap "accept" in three seconds on a tablet, they need a similarly simple way to ask that their data be removed later.
For most gates, this translates into a short, specific screen or form that a visitor sees before they're checked in, stating what's being collected (name, phone, photo, ID type), why (site security, statutory visitor logs, host notification) and roughly how long it's kept. It should not read like a blanket "we may use your data for any purpose" clause — that kind of vague catch-all is precisely what the Rules are designed to end.
Building a compliant check-in moment
- Keep the notice short enough to read in the time it takes to walk from the gate to the lift lobby — three or four lines, not a paragraph.
- State the purpose plainly: security screening, host notification, statutory record-keeping for the site.
- Make clear who to contact if a visitor wants their data corrected or removed, and don't make that harder than the sign-in itself.
Retention: the register cannot live forever, but it cannot vanish either
One of the more concrete requirements in the Rules is retention: personal data, along with traffic data and logs, has to be kept for at least one year after processing is complete, unless a longer period is required under some other law — and once the purpose for which the data was collected is served, it should be erased. That's a narrower window than most gates currently practise. A lot of registers, paper and digital, either get thrown away within weeks because nobody thought a visitor log mattered, or get kept indefinitely because nobody assigned an owner to clear them out.
Both extremes are a problem. Discarding visitor records too early can leave you without evidence during an incident investigation or an audit. Keeping them forever, with no erasure policy and no one accountable for it, is exactly the kind of indefinite retention the Rules are pushing back against. If your site is a factory or falls under labour and safety regulations, it's worth checking your obligations against guidance from bodies like DGFASLI, since factory registers sometimes carry separate statutory retention requirements that can run longer than the DPDP baseline — in which case the longer period applies.
We've written in more detail about how long different kinds of gate records should realistically be kept and why "forever" and "never" are both the wrong answer — worth a read if you haven't already settled your organisation's retention policy.
A workable retention approach
- Set a defined retention period for visitor records, document why you chose it, and make sure it aligns with any sector-specific requirement that runs longer.
- Separate "active" records (recent visits, useful for host follow-up or investigation) from records past their retention window, which should be queued for erasure.
- Assign a named owner — not "the IT team" in the abstract, but a specific role — responsible for making sure erasure actually happens on schedule.
When something goes wrong: breach notification and the stakes
The Rules require that personal data breaches be reported to the Data Protection Board and to the individuals affected. For a visitor register, a breach isn't necessarily a dramatic hack — it could be a lost tablet with visitor photos on it, a spreadsheet emailed to the wrong list, or a security guard's phone with the visitor app logged in, misplaced at a site handover. The obligation to notify doesn't disappear because the incident feels small.
The penalties attached to the Act are serious — up to ₹250 crore per instance for the most severe failures — and while a single misplaced gate register is unlikely to trigger the maximum penalty, the exposure is real enough that "we'll deal with it if it happens" is not a plan. Building basic incident response into your gate operations — who gets told, how fast, and what gets checked — is worth doing well before you need it.
An 18-month checklist for admin, HR and security teams
With 13 May 2027 as the deadline, most sites have time to do this properly rather than in a rush. A reasonable sequence looks like this:
- Audit every point where your site collects visitor personal data — main gate, delivery gate, contractor entry, event registration — and list what's collected at each.
- Rewrite your visitor notice in plain language, confirm it states purpose and retention, and make withdrawal of consent a real, working process.
- Fix your retention period in writing, and check it against any sector-specific rule that might require longer.
- Confirm who counts as your Data Fiduciary and who's your Data Processor for every vendor touching visitor data, and update contracts accordingly.
- Decide who owns breach response for gate data, and rehearse it once, on paper, before you need it for real.
Where technology can carry the weight, and where it can't
A visitor management platform can do a lot of the mechanical work here — showing a consistent privacy notice at check-in, recording when each visitor accepted it along with a hash of the exact wording so you can prove what they agreed to, and restricting who can see ID images or phone numbers based on role rather than leaving that data open to every reception screen. VizPass works this way: notices are set per organisation, acceptance is timestamped and hashed, exports are permission-controlled, and edits to a visitor record are reversed with a stated reason rather than silently deleted, preserving an audit trail. Data sits on servers based in Mumbai — you can read more about how that's structured on our data hosting and residency page.
It's worth being direct about what this doesn't cover. VizPass is not currently ISO 27001 or SOC 2 certified, and it does not yet have an automatic retention purge — if your compliance approach depends on records being deleted on a schedule without manual intervention, that's a gap to plan around today, not assume is handled. Software can enforce consistency and give you an audit trail; it cannot decide your retention policy or your legal position for you. For a broader look at how the platform handles roles, access and this kind of control, our security page and dpdp-visitor-data-management page go into more detail, and if you're still relying on a paper register, our piece on what a paper visitor book cannot tell you is a useful companion read on why that format makes this whole exercise harder.
Conclusion
The DPDP Rules give India's offices, factories, warehouses and campuses 18 months to turn visitor data handling from an afterthought into a documented, accountable process — and that clock is already running toward 13 May 2027. The practical first step is small: sit down with whoever runs your gate, list exactly what personal data you collect from visitors and why, check how long you keep it against what the Rules require, and decide who's accountable for consent, access and erasure. If you want to see how a purpose-built platform handles notice, consent records and role-based access without you having to build it from scratch, you can look through our features or book a walkthrough to see it against your own site's gate process.