Privacy by design in visitor management: how Orb maps to DPDP, ISO 27001 and PCI DSS

Privacy by design in visitor management: what a reviewer tests

A reviewer asks three things of any visitor register: what is collected and why, who can see it, and when it goes and how you prove it. Section 8(1) of the DPDP Act makes the organisation running the lobby responsible for processing done “on its behalf by a Data Processor”, “irrespective of any agreement to the contrary”.

Most duties apply from 13 May 2027 (Rule 1(4), eighteen months after publication); some firms, including Cyril Amarchand Mangaldas, give 14 May 2027. A proposal to shorten the timeline was floated in January 2026 (Business Standard); as of 12 October 2026 no change had been notified (S.S. Rana & Co.). See our DPDP guide.

Notice before the first question, consent item by item

What the law asks. Section 5(1) says every request for consent “shall be accompanied or preceded by a notice”. Rule 3 requires it to be “understandable independently of any other information”, with “an itemised description of such personal data”, the purpose, and a way to withdraw, exercise rights and complain to the Board. Section 6(1) asks for consent that is “free, specific, informed, unconditional and unambiguous with a clear affirmative action”, and section 6(4) makes withdrawal as easy as giving it.

What Orb does. Before any question on their own phone, visitors see a notice in their language: what is collected, why and for how long. Consent is item by item, nothing pre-ticked, and the record keeps the notice version and language shown. A visitor who says no is signed in at the desk, and nothing from their phone is saved. They can withdraw from their pass or verified WhatsApp, and at check-out get a receipt with the date each detail will be erased.

Why it matters. Under section 6(10), if consent is questioned, “the Data Fiduciary shall be obliged to prove that a notice was given”. One “I agree” for everything is hard to defend as specific, a pre-ticked box is hard to call a clear affirmative action, and consent is hard to call free if declining means no meeting.

Data minimisation by default: five typed details and a photo

Section 6(1) limits consent to “such personal data as is necessary for such specified purpose”. By default Orb asks for five typed details (name, mobile number, company, host and purpose) and a photo; extra fields appear only where you add them. ID verification runs only for the visitor types your policy says need it, such as contractors. Three smaller choices stop data spreading:

• The host’s copy of the photo is sent view-once in WhatsApp.
• Staff phone numbers never reach the gate: visitors find hosts by name and team.
• Each visitor sees only their own check-in, never earlier entries.

Retention clocks per detail, and a signed record of each erasure

Section 8(7) requires erasure on withdrawal of consent or “as soon as it is reasonable to assume that the specified purpose is no longer being served”, including by the processor, unless another law requires retention. Rule 8(3) is read as such a requirement: personal data, associated traffic data and processing logs are kept for at least one year “for the purposes as specified in the Seventh Schedule” (State purposes), then erased. Cyril Amarchand Mangaldas and Lakshmikumaran & Sridharan read it as binding every data fiduciary. ISO 27001 control 8.10, “Information deletion”, expects information to be deleted once it is no longer required, and auditors look for deletion records (TCSA).

In Orb, each detail has its own clock. Photos and mobile numbers are erased after seven days by default, the visit record after the period you set, and every clock is configurable; afterwards only an anonymous count stays. Erasure runs nightly on every plan, and on the plan with signed erasure reports (pricing) each run leaves a signed record of what was erased and when.

Our advice: keep the visit record and its logs for one year, and photos and mobile numbers for days, as a written decision your DPO and counsel sign off, because Rule 8(3) speaks of personal data generally.

> Snapshot: the DPO’s erasure request on day 9. (Illustrative.) Sneha Kulkarni visits a Bengaluru office on 2 June 2027 and on 11 June asks for erasure. Ritu Agarwal, the DPO, opens the visit: the photo and mobile number went on the night of 9 June, and that night’s signed erasure record lists them. The visit record is held under Rule 8(3), which section 12(3) allows where retention “is necessary ... for compliance with any law”. Ritu replies the same morning with what was erased and when, what is kept, until when, and why.

Audit trail for visitor management: every look logged, nothing rewritten

Rule 6(1)(c) asks for “visibility on the accessing of such personal data, through appropriate logs, monitoring and review”. ISO control 8.15, “Logging”, expects logs that show who did what, protected against tampering; controls 5.15, “Access control”, and 5.18, “Access rights”, expect access granted on authorisation, removed when no longer needed, and an expiry on emergency access (TCSA).

In Orb, every look at a visitor record is logged: who opened it, and when. That includes our support team, who open visitor details only in a time-limited window you grant, or in a logged security emergency.

Records that cannot be quietly rewritten. ISO control 5.33, “Protection of records”, expects records protected against falsification, loss and unauthorised access; consultants name restricted edit rights and write-once storage (TCSA). In Orb, consent, approval and erasure records are append-only: a misspelt company name is fixed with a logged correction beside the original.

Role-based views: the guard sees today, not the archive

Guards in Orb see only today’s visitors: name, photo, host and status, never staff phone numbers or emails. Each guard signs in with their own PIN; the guard’s phone holds only the current shift’s list, encrypted, and clears it at shift end. That is what ISO controls 5.15 and 8.3, “Information access restriction”, and Rule 6(1)(b) look for, applied at the gate.

A pass code that changes every minute

PCI DSS v4.0.1 requirement 9.3.2 covers visitor access to the cardholder data environment (CDE): visitors are “authorized before entering”, “escorted at all times” and “clearly identified and given a badge or other identification that expires”, which must visibly set them apart from staff. Requirement 9.3.3 asks that visitor badges or identification are “surrendered or deactivated before visitors leave the facility or at the date of expiration”, so they cannot be reused. Neither changed in v4.0.1 (PCI SSC Summary of Changes).

In Orb, the visitor’s phone becomes the pass, with a valid-until time. The code changes every minute, so a screenshot is useless, and the guard’s scan shows photo, name, host and approval. The pass covers approval before entry and identification that expires; escort, and a badge others can see inside the CDE, stay with your own procedures. Sites that want a physical token can add the self-service kiosk by Orb, which gives out use-and-throw tags that are never reused.

> Snapshot: a forwarded screenshot of a pass. (Illustrative.) At 9:12 am at a Hyderabad fintech office, Arjun Reddy forwards a screenshot of his pass to Karan Malhotra, who was not invited. At 9:20 the code is eight minutes old, the scan fails, and the photo on the guard’s screen is Arjun’s anyway. Karan is sent to check in and wait for his own approval.

Visitor management data security: where data lives and what sits on site

Where it lives. Visitor records are stored in the region named in your agreement, which also names every provider that handles visitor data and where each runs; WhatsApp messages pass through WhatsApp’s own servers. Section 16(1) lets the Central Government restrict transfers abroad, so get the location in writing. Control 5.23, “Information security for use of cloud services”, asks you to assess a cloud service before use, including where data sits and which subprocessors touch it (TCSA).

How it is protected. Visitor data is encrypted in transit and at rest, the first safeguard Rule 6(1)(a) lists and the subject of ISO control 8.24, “Use of cryptography”. Each customer’s data is walled off from every other company’s and tested with every update. Orb acts only on your instructions, as your processor; section 8(2) requires a contract with your processor and Rule 6(1)(f) asks for security terms in it, so read our data processing terms against both.

What sits on site. Nothing to install or maintain: visitors use the browser, hosts WhatsApp, Microsoft Teams, Slack or email, and guards a phone you already own, so Orb adds no lobby box to patch under control 8.8, “Management of technical vulnerabilities”. A kiosk, tags and turnstile links can be added later.

How the design turns into evidence for ISO 27001, PCI DSS and DPDP audits

For ISO 27001 Annex A 7.2, each record holds the host approval and the entry and exit times auditors trace (our ISO 27001 guide). For PCI DSS 9.3.4, v4.0.1 says “Visitor logs are used to maintain a physical record of visitor activity both within the facility and within sensitive areas”, with name and organisation, date and time, the person authorising access, and at least three months’ retention unless the law restricts it. Each Orb entry carries those details for the period you set; a server room or other sensitive area still needs its own record.

> Snapshot: the auditor’s date sample. (Illustrative.) At an ISO 27001 surveillance audit on a Pune campus, the auditor picks 14 March and three entries from it. Neha Bhatt, the ISMS owner, opens each: notice version, consent, approval by a named host with the time, admission at Gate 2 against the guard’s PIN, and check-out. The access log shows who has opened them since; one shows a corrected company name beside the original. The March photos are gone, and the signed erasure records show when.

Where Orb fits

Orb is built for the DPDP Act 2023 and Rules 2025 and supports ISO 27001 Annex A 7.2 and PCI DSS 9.3.4 audits (how Orb works, security).

Orb is priced per entry point a month by monthly visits, never per host or floor, from ₹1,499 (pricing). Bring your reviewers to a demo and we will open a visit line by line.

Questions buyers ask