1. Description of the processing
- What: visitor name, phone, email, company, host, purpose, timestamps, vehicle number (where enabled), and facial/photo data (where the tenant enables it and the visitor consents at check-in).
- Why: to register visitors, issue passes, notify hosts, and maintain an access audit log.
- How: captured via kiosk / pre-invite / security desk; stored in Google Cloud Firestore (asia-south1) and Firebase Storage; processed by Entrifie as Processor on the tenant’s behalf.
- Who has access: the tenant’s authorised admins and the relevant host; Entrifie personnel on a least-privilege, need-to-know basis.
- Retention: per-tenant configurable, 30–365 days (default 90); photos deleted with the visit record at period end.
2. Necessity and proportionality
Each data element serves the stated purpose of secure visitor management; no element is collected for advertising or profiling. Facial capture is off by default and used only where a tenant has a legitimate access-control need and the visitor consents. Retention is bounded and configurable. Lawful bases: consent (visitors), contract/legitimate interests (tenant accounts), and legal obligation (workplace visitor logs).
3. Risk identification
We identify risks to data subjects (visitors), to their rights and freedoms, and to the organisation. The principal risks are catalogued in the register below.
4. Risk severity and likelihood
Each risk is scored for inherent severity and likelihood (low / medium / high), with the residual rating after mitigation.
| Risk | Affects | Severity | Likelihood | Residual |
|---|---|---|---|---|
| Collection and storage of visitor facial/photo data (special-category-adjacent) | Visitors | High | Medium | Low |
| Cross-border transfer of EU/UK visitor data to asia-south1 (Mumbai) | EU/UK data subjects | High | Low | Medium |
| Unauthorised access to visitor records (cross-tenant or external) | Visitors, tenants | High | Low | Low |
| Retaining personal data longer than necessary | Visitors | Medium | Medium | Low |
| Re-identification of a subject from a data-subject request or audit data | Visitors | Medium | Low | Low |
5. Mitigation measures
For each risk, technical, organisational, and legal mitigations:
Collection and storage of visitor facial/photo data (special-category-adjacent)
Technical: Feature off by default; capture only with explicit at-kiosk consent; AES-256 at rest; photo deleted with the visit record at retention end.
Organisational: Per-tenant opt-in; documented capture purpose; no facial recognition / no biometric template generated.
Legal: Consent recorded per capture (visitor_checkin photo_capture); DPA + this DPIA on file.
Cross-border transfer of EU/UK visitor data to asia-south1 (Mumbai)
Technical: Primary datastore in India; TLS in transit; minimal sub-processor footprint.
Organisational: Sub-processor list maintained and disclosed; data-residency documented.
Legal: EU Standard Contractual Clauses (Module 2) referenced at /legal/sccs; transfer mechanism per sub-processor.
Unauthorised access to visitor records (cross-tenant or external)
Technical: Tenant isolation enforced at the database-rule layer; role-based access; managed auth; audit logging.
Organisational: Least-privilege access; breach-response process.
Legal: Breach notification clause in the DPA; audit-log retention.
Retaining personal data longer than necessary
Technical: Automated retention-bound deletion sweep; per-tenant configurable window (30–365 days).
Organisational: Retention period chosen at onboarding and surfaced in settings.
Legal: Retention disclosed in the privacy policy; DSR erasure honoured.
Re-identification of a subject from a data-subject request or audit data
Technical: DSR matching keys on a salted subjectHash; status checks return aggregate-only (no per-tenant detail).
Organisational: Admin contact display masked to last 3 characters.
Legal: DSR audit subject stored as a pseudonymous hash, not raw PII.
6. Residual risk assessment
After mitigation, residual risk is low for most identified risks, with cross-border transfer assessed as medium pending completion of the SCC arrangements (see Standard Contractual Clauses). No residual high risks remain that would require prior consultation with a supervisory authority; this is to be confirmed at legal sign-off.
7. Consultation record
Where a Data Protection Officer is appointed, their advice is recorded here. In the absence of a DPO, the responsible person (the founder / grievance officer named in the privacy policy) records the assessment and any stakeholder input. [To be completed at sign-off.]
8. Review schedule and responsibility
This DPIA is reviewed at least annually, and whenever the processing changes materially (new data category, new sub-processor, new transfer, or a new feature affecting visitor data). The responsible person owns the review. The DPIA version is bumped on each material revision.