Visitor Data Breach: First 72 Hours Under DPDP Act

A visitor's phone number, ID photo, and vehicle number sit in your gate register — paper or digital — the moment they sign in. If that register is copied, leaked, hacked, or simply misplaced by an employee who takes a photo of the sign-in sheet, you are now dealing with a personal data breach, not a security incident you can quietly close. Under India's Digital Personal Data Protection Act, 2023, and the DPDP Rules, 2025 notified in the Gazette on 14 November 2025, the organisation that collected that visitor's data — your company, not your software vendor — carries the legal responsibility for what happens next. The Rules give companies an 18-month runway to build compliant systems, ending 13 May 2027, but a breach doesn't wait for your compliance roadmap to finish.

This article is written for the person who actually owns the gate — the admin, HR head, or security manager who will get the 11 PM call when someone reports that visitor data has leaked. It walks through what needs to happen in the first 72 hours, in the order it needs to happen, using the kind of records most Indian offices, factories, and campuses actually keep: sign-in sheets, ID scans, phone numbers, host approvals, and gate camera footage. It also explains, plainly, who is legally on the hook and what a system like VizPass can and cannot do to help. For a broader look at how the DPDP framework applies to everyday visitor logging, see our companion piece on DPDP visitor data management.

Nothing here is legal advice — treat it as an operational checklist, and get your own counsel involved for anything you plan to file or announce.

Why the First 72 Hours Matter

Regulators, auditors, and courts don't judge a breach only on what leaked — they judge it on how fast and how honestly you responded. A gate that discovers a breach and spends a week deciding whether to say anything looks very different, on paper, from one that contained the exposure within hours and notified the right people within days.

What Counts as a Visitor Data Breach

A lost or stolen device (phone, tablet, laptop) that had the visitor app or exported visitor logs
A leaked spreadsheet export of visitor names, phone numbers, or ID numbers
Unauthorised access to the visitor management dashboard by someone outside their role
A photographed or copied paper register left at an unattended reception desk
A vendor or contractor's device syncing gate data to an unapproved cloud account

Any of these can trigger obligations under the Act, because visitor names, phone numbers, ID images, and vehicle numbers are all personal data.

Hour 0–4: Contain and Confirm

The first job is not paperwork — it's stopping the bleeding.

Immediate Actions

Revoke access for the affected login, device, or export immediately; change shared passwords for the gate terminal or kiosk
Physically secure the location — lock the reception desk, remove the paper register from view, retrieve any lost device if possible
Identify exactly which records are affected: one day's visitors, one contractor batch, or the entire historical log
Loop in your IT or security lead and, if the breach involves a vendor's platform, your account contact at that vendor within the hour

Do not wait for a "full picture" before containing. A partial fix now is worth more than a complete report tomorrow.

Preserve Evidence, Don't Delete

Resist the instinct to quietly delete the exposed records or edit the log to make the incident disappear. In a system like VizPass, records are never hard-deleted — they can only be reversed with a documented reason, which means the original entry, the correction, and the justification all stay in the trail. That audit history is exactly what you will need to show a regulator, or your own leadership, what actually happened and when.

Hour 4–24: Assess What Was Exposed

Once the immediate exposure is contained, you need a factual, written account of scope.

Questions to Answer

How many visitor records were exposed, and over what date range?
Did the exposure include ID images, phone numbers, or only names and company affiliations?
Was the data merely viewed, or was it copied, downloaded, or forwarded?
Was the exposure internal (an employee with excess access) or external (a hack, a lost device, a leaked link)?

This is where role-based access matters. If your platform restricts who can see ID images and phone numbers by role — reception versus security head versus HR — you can answer "who could have seen this" with a specific list of people rather than "everyone who ever logged in." That distinction changes both the severity of the incident and how you describe it to the Data Protection Board.

Check Your Export Trail

Most leaks don't come from the core system being hacked — they come from a report exported to Excel and forwarded over email or WhatsApp. Permission-controlled exports, where only specific roles can pull bulk visitor data out of the system, and every export is logged against a person and a timestamp, let you trace exactly which export matches the leaked file. Without that control, you're left guessing which of several possible exports caused the exposure.

Hour 24–48: Notify the Right People

The DPDP Act requires that breaches be reported both to the Data Protection Board and to the individuals affected — the visitors themselves, not just internal stakeholders.

Internal Notification First

Inform your CISO, legal counsel, or compliance officer immediately if you haven't already
Brief your leadership with facts only: what happened, what's confirmed, what's still being investigated
If the breach touches a factory or industrial site, note that visitor and contractor logs often overlap with safety documentation reviewed under frameworks referenced by DGFASLI, so your safety officer should be looped in too

External Notification

Draft a factual notice to affected visitors describing what data was exposed and what they should watch for
Prepare the Data Protection Board notification with your legal team, using confirmed facts rather than early estimates
Reference the Ministry of Electronics & IT for the current procedural guidance on how and where breach notifications are to be filed, since this is an evolving area and the exact process should be verified against the latest official instructions rather than assumed

Consent language matters here too. If your original visitor notice was vague — a generic "we may use your data" line — you have a weaker footing than a company that showed visitors a plain-language notice explaining exactly what was collected and why, and recorded that they accepted it. A gate check-in page that timestamps consent and stores a hash of the exact notice text shown at that moment gives you proof of what each visitor actually agreed to, which matters enormously when you're explaining scope to a regulator.

Hour 48–72: Document and Remediate

By hour 48, you should have a written incident report, not a verbal summary.

What the Report Should Contain

Timeline of detection, containment, and notification, with timestamps
Number and category of records affected
Root cause — human error, technical vulnerability, or third-party failure
Immediate fixes already applied
Planned structural fixes and their target dates

Structural Fixes to Consider

Tightening role-based visibility so fewer people can see ID images and phone numbers by default
Restricting export permissions to named roles rather than "anyone logged in"
Reviewing where your visitor data is hosted — data residency within India, such as servers based in Mumbai, is a factor regulators and auditors will ask about, and it's worth confirming with your vendor directly rather than assuming; see our note on data hosting and residency for what to check
Re-issuing the visitor privacy notice with clearer, plainer language if the original was legally sound but hard for a visitor to actually understand at a kiosk

What the Law Expects From a Data Fiduciary

Under the Act, your company is the Data Fiduciary — the party that decides why and how visitor data is collected. Your gate software vendor is a Data Processor, acting on your instructions. That distinction matters because liability for a breach sits primarily with you, not your vendor, even if the vendor's platform was technically involved.

Retention Is Part of Your Exposure

The DPDP Rules require personal data, traffic data, and access logs to be retained for at least one year after processing unless a longer period is mandated elsewhere, and then erased once the purpose they were collected for has been served. Holding visitor records forever, "just in case," is itself a compliance gap — it widens the blast radius of any future breach. Worth noting plainly: most gate platforms, including VizPass today, do not yet run automatic retention purges, so this is something your team needs to schedule and execute manually until that capability matures across the industry.

Penalties Are Not Symbolic

Penalties under the Act can run up to ₹250 crore per instance for the most serious failures. That figure alone should be reason enough to treat a visitor data breach as a board-level issue, not a reception-desk problem to be quietly resolved.

Building a Gate That Doesn't Put You Here Again

A breach response plan is only half the job — the other half is reducing how often you need one.

Practical Steps for Indian Sites

Replace paper registers with a system that logs consent, restricts visibility by role, and controls exports, as covered in our guide on what a paper visitor book cannot tell you
Review your current setup against the checklist in 6 visitor policies to keep your gate secure
If you manage contractors alongside visitors, revisit how their data and liability are handled separately, as discussed in contractors at the gate: who vouches
Check whether your platform's security posture — hosting, access control, audit trails — is documented anywhere you can hand to an auditor; see our security page for what to look for, and note that not every vendor, including VizPass at present, holds ISO 27001 or SOC 2 certification, so verify this directly rather than assuming

The full feature set that supports this — role-based access, consent capture, export controls, and reversible (not deletable) records — is outlined on our features page, and how different site types apply it is covered under use cases for factories, warehouses, and campuses across industries we serve.

Conclusion

A visitor data breach is a legal event with a clock attached, not just an operational embarrassment. The first 72 hours decide whether you look like an organisation that had a control failure and responded correctly, or one that had a control failure and made it worse by delaying. Contain first, assess honestly, notify both the Board and the affected visitors, and document everything with timestamps — then fix the structural gap that let it happen. If your gate is still running on paper or a system with no role-based access and no export controls, the next step is straightforward: book a walkthrough and see what a properly controlled visitor log looks like before you need one for a breach report instead of a routine audit.

This article is general information, not legal advice. For your own obligations under the DPDP Act and Rules, consult a lawyer.

Frequently Asked Questions

If visitor data leaks from our gate register, is VizPass liable or is our company?

Your company is legally liable, not VizPass or any other gate management software you use. Under the DPDP Act, 2023, the organisation that collects a visitor's phone number, ID photo, or vehicle number is the data fiduciary — the party the law holds responsible for that data, regardless of which system captured it. Software like VizPass functions as a processor: it stores the sign-in record, runs host approval workflows, and keeps a gate log, but it doesn't decide why the data was collected or who can see it — your organisation does. That distinction matters in the first 72 hours because it determines who actually has to act on a breach: your admin, HR head, or security manager, not a vendor's support desk. A well-organised system does make the underlying record easier to search — visitor pre-registration keeps host approvals and sign-in details in one searchable log rather than scattered across paper sheets — but it cannot take on your legal exposure or draft your breach response for you. If you're trying to work out exactly where liability sits across your current gate process, that's a conversation worth having with your compliance team before an incident forces the question.

Do we have to report a visitor data breach to a government authority, and how fast?

Yes — but the exact notification process sits with the DPDP Act, 2023, and the DPDP Rules, 2025, and it's worth checking the Ministry of Electronics & IT's own guidance at https://www.meity.gov.in rather than guessing at the steps. What the Rules do confirm is that this obligation doesn't wait for your organisation to finish building a fully compliant system — the 18-month runway they grant runs until 13 May 2027, but a breach discovered before that date still has to be handled on the day it's discovered, using whatever records your gate actually keeps: sign-in sheets, ID scans, phone numbers, host approvals, and camera footage. In practice, that means the first move is internal, not external — assembling exactly who signed in, who approved them, and what data was captured, so that whatever notification is eventually required can be filled in with facts rather than guesswork under pressure. Keeping that information in one searchable place instead of loose paper sheets makes the assembly step faster when you're already working against a clock. VizPass, for instance, timestamps host approvals alongside sign-in details, so pulling together a clean record of one day's visitor traffic doesn't mean digging through several separate logbooks after the fact.

Is losing a paper visitor sign-in sheet actually a data breach under DPDP?

Yes — if that sheet has a visitor's phone number, ID reference, or vehicle number on it, losing it is a personal data breach under the DPDP Act, 2023, regardless of whether the register was paper or digital. The law doesn't distinguish between a hacked database and a sign-in sheet left on a security desk or photographed by an employee — what matters is that personal data someone else is responsible for protecting is now out of their control. This is why many sites are moving away from a single physical register that sits at the gate all day, accessible to anyone walking past, toward systems where visitor pre-registration captures the same details digitally and restricts who can view them. That doesn't make a breach impossible, but it does reduce the number of ways a plain sheet of paper — with no access control, no log of who looked at it, and no way to know it's missing until someone notices — can end up copied or lost. If your current process is still a physical logbook at the gate, treating it as sensitive personal data in transit, not just an administrative formality, is the more accurate way to think about the risk it carries.

What should we actually pull together in the first hour after finding out visitor data leaked?

You need to gather the records that show exactly who was on site, when, and who approved them — sign-in sheets, ID scans, phone numbers, host approvals, and gate camera footage — before you do anything else. This matters because a breach response is only as accurate as the underlying record: if you don't know precisely which visitors' data was in the affected register, you can't scope the breach, and you can't work out who needs to be told anything. In most Indian offices, factories, and campuses, these records exist in different places — a logbook at the gate, ID photocopies in a drawer, camera footage on a separate DVR — which is exactly what makes the first hour slow. A system where visitor pre-registration and host approvals sit in one log means you can filter by date and location and see the affected records directly, instead of cross-referencing several separate sources under pressure. Once you know what data was actually exposed, the next steps — internal escalation, assessing legal exposure, and any required notification — depend entirely on getting this part right first. Treat this step as fact-finding, not paperwork; guessing at scope now creates bigger problems later.

Are we exempt from DPDP breach obligations until the 13 May 2027 compliance deadline?

No — the 18-month runway ending 13 May 2027 is time to build compliant systems, not a grace period that excuses you from responding to a breach that happens before then.

Tags: DPDP Act data breach response visitor management gate security compliance VizPass

← Back to blog

A visitor data breach: what a gate operator must do in the first 72 hours