Introduction
Security teams are on the front line of visitor data collection every day β and they are often the last to be consulted on data privacy compliance.
The security officer who checks IDs at the gate, the supervisor who reviews visitor logs after an incident, the system administrator who manages access control records β all of these roles handle personal data. Under India’s Digital Personal Data Protection Act, 2023 (DPDP Act), all of these roles now operate within a legal framework that governs exactly what they can collect, how they can use it, how long they can keep it, and who else can see it.
This article is written specifically for security managers, facility security teams, and enterprise risk and physical security professionals. It maps the DPDP Act’s requirements to the realities of building security, access control, visitor management, and incident investigation β and gives you a practical compliance framework for your team.
Why Security Operations Are High-Priority Under DPDP
Security functions typically process some of the most sensitive personal data in any organisation:
- Government-issued ID numbers (Aadhaar, passport, PAN) collected at gates for identity verification
- Biometric data (fingerprint, face recognition) used for access control
- Surveillance footage captured by CCTV at entry and exit points
- Vehicle registration data from gate logs
- Watchlists and threat assessments containing personal information about flagged individuals
- Incident reports linking personal data to specific events
Each of these data categories triggers DPDP obligations β and security teams that are unaware of those obligations are their organisation’s highest data compliance risk.
The Personal Data Your Security Function Holds: A Full Audit
Before any compliance programme can be built, security managers need to understand exactly what data their function collects and where it lives.
Entry Gate / Reception Desk
- Visitor name, company, purpose, host (check-in record)
- Mobile phone number (OTP verification or manual entry)
- Government ID type and number (for high-security access)
- Face photo or biometric capture (for badge or access control)
- Vehicle registration number (for vehicle-based access or parking)
- Check-in and check-out timestamps
Access Control System
- Employee access card or biometric records (which individual accessed which door, at what time)
- Visitor temporary access credentials linked to check-in record
- Access denial logs (when someone was denied entry and why)
- Alarm events linked to specific credential holders
CCTV / Surveillance
- Video footage capturing individuals β employees, visitors, contractors β at entry/exit points and throughout the facility
- Timestamps and location metadata linked to footage
Security Incident Records
- Incident reports naming individuals involved (visitor, employee, contractor)
- Witness statements
- Investigation notes and correspondence
Watchlists and Threat Intelligence
- Names, descriptions, photos of individuals flagged as security concerns
- Source information and justification for flagging
Each of these is a personal data store requiring legal basis, notice, defined retention, access controls, and a deletion workflow.
Legal Basis for Security Data Processing
This is the most important question for security teams: what legal basis authorises you to collect and process this data?
For Employees
Processing employee access data β which door they accessed, when, what areas they can enter β is generally covered under Section 7’s “legitimate use for employment purposes.” Building access management is operationally necessary for the employment relationship, and employees have a reasonable expectation that their employer manages access to the workplace.
However:
- Employees must be informed via a privacy notice (even when consent is not the legal basis, notice is still required)
- The employment legitimate use covers access management β it does not cover secondary analytics (mapping employee movement patterns for performance assessment or behaviour profiling) without consent
- Biometric access control (fingerprint, face recognition) for employees is a higher-risk processing activity β assess whether consent should be obtained even if the employment legitimate use technically applies
For Visitors
Processing visitor data for building access management is typically justified under consent β the visitor’s explicit agreement at check-in to have their data processed for security and access control purposes.
For high-security government or regulated facilities, there may be a legal mandate for specific access controls that provides its own legal basis. Document the specific regulation.
For Gate Pass / Vehicle / Goods Records
Inward and outward movement records β truck drivers, delivery personnel, goods descriptions β have a dual legal basis:
- Contractual necessity (the driver is entering as part of a commercial delivery contract)
- Legal compliance (GST documentation, customs records for certain goods types)
For the driver’s personal data specifically (name, phone, vehicle number), the primary basis is contractual necessity. For the goods-related commercial data, legal compliance may be the applicable basis.
For CCTV Surveillance
CCTV footage in India’s pre-DPDP era was almost entirely unregulated beyond general proportionality. Under DPDP:
- Recording individuals in public-facing areas of a facility (lobby, reception, parking) captures personal data
- The legal basis is most naturally legitimate use for security purposes β recording at a reception or entry point for safety and security is a generally recognised and proportionate purpose
- Notices are required: CCTV warning signs visible at entry points qualify as the privacy notice for surveillance (similar to GDPR practice in the EU)
- Footage must be retained only as long as necessary for the security audit purpose β standard practice is 30β90 days
For Watchlists
This is the highest-risk category for security teams. A watchlist of individuals flagged as security concerns contains personal data β and the legal basis for maintaining it is not straightforward.
- If the watchlist was built from information provided by law enforcement or a regulatory body β the legal compliance or public safety legal basis may apply
- If the watchlist was built from internal incident records β the security necessity basis may apply, but requires careful documentation
- If the watchlist contains individuals who were flagged based on behaviour at your facility β document the specific reason for each entry and review each entry periodically for continued justification
- Indefinite watchlist retention without periodic review is non-compliant; each entry should have a review date
DPDP Compliance Framework for Security Teams
Framework Pillar 1: Notice at the Point of Data Collection
Every point where your security function collects personal data must have a visible, accessible privacy notice.
Entry gate / reception kiosk:
The check-in privacy notice (deployed by the facilities/HR team) should explicitly cover security purposes: “Your visit details and ID will be used for building access management and security purposes. Your data will be retained for [X days] and then deleted.”
CCTV zones:
Standard “CCTV in operation” signage is the notice mechanism for surveillance data. Signs should be visible before entry into surveilled areas. Consider including the data retention period and contact details: “CCTV monitoring is active in this area for security purposes. Footage is retained for 30 days and then deleted. For queries: [contact].”
Access control enrollment (for contractors / long-term visitors):
When enrolling a contractor’s biometric for building access, a specific privacy notice for that enrollment is required before data capture begins.
Gate entry for vehicles:
A notice board at the gate entry point β visible before the driver provides details β should explain what data is collected, for what purpose, and how long it is retained.
Framework Pillar 2: Data Minimisation in Security Operations
Security teams naturally tend toward comprehensive data collection β the more information available, the better the security picture. DPDP’s data minimisation principle creates a productive tension with this instinct.
Government ID: Do you need to record the full Aadhaar number for every visitor? Or does recording the ID type and last four digits, plus a verification confirmation, achieve the same security purpose while holding less sensitive data?
Gate pass data: For a routine goods delivery, do you need the driver’s personal phone number, date of birth, and home address? Or does name, vehicle number, company, and delivery reference serve the security purpose?
CCTV resolution: Higher-resolution footage enables better identification β but also creates more sensitive data. For areas where identification is not the primary security goal (general corridors, parking lots), lower resolution serves the security purpose adequately with less privacy impact.
Access logs: Do you need to retain every door access event for every employee, or do you need to retain events only at secure perimeter points? Defining the minimum data set that serves the security audit purpose reduces both storage costs and breach exposure.
Framework Pillar 3: Role-Based Access to Security Data
Who on your security team should have access to which security data? The DPDP Act’s security safeguards requirement (Rule 6) mandates that access to personal data be limited to those who genuinely need it.
Recommended role structure for security data:
| Role | Access Level |
| Reception / front desk | Current day’s visitor log; check-in/check-out; on-premises count |
| Security officer on duty | On-premises list; access control status; CCTV live feed for monitored zones |
| Security supervisor | Recent visitor logs (90 days); access control logs; incident reports for their area |
| Security manager | Full access to visitor logs (within retention period); access control system admin; incident management |
| IT/system administrator | System maintenance access β all access events logged and reviewable |
| HR (for employee attendance) | Employee access logs relevant to attendance; not visitor logs |
| Legal / compliance | Access to specific records when handling data rights requests or DPBI matters |
No role should have bulk export access to visitor or employee access data without a documented business justification that is reviewed and approved.
Framework Pillar 4: Retention and Deletion for Security Records
| Security Data Type | Retention Period | Rationale |
| Visitor check-in records | 90β180 days | Security audit window; delete after |
| Face photos (badge/access) | 30β90 days or on check-out | Limited security purpose beyond visit |
| Government ID verification record | 90β180 days | Security audit; minimise beyond visit window |
| CCTV footage | 30β90 days | Standard security practice; delete unless actively needed for incident |
| CCTV footage linked to an active incident | For duration of investigation + legal proceedings | Legal hold applied; documented |
| Access control logs (employee) | 90β180 days (standard); 5 years for high-security regulated zones | Legal and regulatory requirements for certain facility types |
| Gate pass records | 90β180 days for personal data; statutory period for commercial record | GST/customs for goods; personal data minimised |
| Incident reports (containing personal data) | 3 years from incident date | Limitation period for civil/legal claims |
| Watchlist entries | Review every 6 months; delete when justification no longer exists | Active purpose required for each entry |
| Audit / processing logs | Minimum 1 year | Mandatory under Rule 8 |
Framework Pillar 5: Security Data Breach Response
Security teams are often the first to detect a security breach β including data breaches. Under the DPDP Act:
- All personal data breaches must be reported to the DPBI β without delay for initial intimation; within 72 hours for the full report
- Simultaneously, affected Data Principals must be notified
- CERT-In must be notified within 6 hours for cybersecurity incidents β this clock runs concurrently with the DPBI clock
For security teams, the breach response protocol must include:
- Clear escalation path: Security officer detects anomaly β Security manager assesses β Legal/Compliance notified β DPBI notification drafted β IT confirms scope β Affected individuals notified
- Documentation at every step: Every decision, every action, every notification must be documented with timestamp
- Chain of custody for evidence: If the breach involves physical security (unauthorised access, ID forgery), preserve evidence β but do not allow evidence preservation to delay required notifications
Build and test a 72-hour DPBI notification drill annually. The first time your security team runs through a breach response should not be during an actual breach.
Framework Pillar 6: Handling Data Principal Rights from Visitors
Visitors who have had their data processed by your security systems can exercise their rights:
Access request: A visitor can ask what security data is held about them β access control records, CCTV footage, incident mentions. You have 90 days to respond with a summary.
Erasure request: A visitor can request deletion of their security records before the automatic deletion date β provided no legal hold or active investigation requires retention.
Correction request: If a visitor’s details were recorded incorrectly in a security incident report (wrong name, wrong time), they can request correction.
Grievance: If a visitor believes your security function mishandled their data β retained it too long, shared it inappropriately, denied an access request β they can escalate to the DPBI if you do not resolve their grievance.
Security managers must know that these rights exist and have a process to route rights requests to the appropriate team for fulfilment within 90 days.
Security Team DPDP Training: What Every Officer Needs to Know
The best compliance framework is undermined by untrained personnel. Every member of the security team who handles personal data needs to understand, at minimum:
- What counts as personal data in the security context (name, phone, ID, face photo, vehicle number, access log β all personal data)
- Why you need the data β articulate the specific security purpose before collecting anything
- Do not collect more than you need β minimisation is a legal obligation, not just good practice
- Do not share visitor data casually β not with other visitors, not with colleagues who don’t need it, not on personal devices
- Report anomalies immediately β if you suspect a data breach (unauthorised access to systems, stolen device, visible security log accessed by an unauthorised person), escalate within the hour
- Respect data rights requests β if a visitor asks about their data, do not refuse; route the request to the data contact
Annual training should be documented, with sign-off from each security team member. This documentation demonstrates good-faith compliance to the DPBI if your practices are ever reviewed.
The Bottom Line
Security and data privacy are not opposites. They are allies. The same principles that make a security programme rigorous β knowing what data you have, controlling who accesses it, responding quickly to incidents, and cleaning up records that are no longer needed β are the same principles that make a DPDP compliance programme robust.
The DPDP Act does not ask security teams to collect less data than their legitimate security function requires. It asks them to collect exactly what is needed, protect it rigorously, retain it only as long as necessary, and give the individuals whose data they hold a clear, accessible path to understand and exercise their rights.
That is not a constraint on good security practice. It is a definition of it.
This article is for informational purposes only and does not constitute legal advice. Consult a qualified data protection professional for specific compliance guidance.
Onfra’s platform includes security-specific features β gate pass management, watchlist integration, role-based access to visitor logs, and CCTV-compatible visitor records β all built with DPDP compliance in mind. Explore Onfra’s security features β