A visitor log is personal data
Every question in this section is one your procurement team or your data protection officer will ask. The answers are built into the product, not promised in a policy document.
Security and compliance
Data separation enforced at the database layer.
Tenant boundaries aren’t left to application code or user behaviour. They are enforced where the data lives so each company sees only its own records, even when a query gets it wrong. Our database is built to maintain confidentiality, integrity and availability.
No biometric data, by design and by policy.
The system rejects biometric connectors by design. Face matching and template storage are blocked at installation and not merely prohibited by policy.
Privacy starts with collecting less.
Full ID numbers stay hidden by default unless enabled to view. Document images are only read, never stored in the database, thereby complying with privacy laws.
Keep the record. Remove the identity.
When the retention period ends, personal identifiers are automatically anonymised while visit counts remain intact. Legal holds can pause anonymisation for specific records.
Every role can be protected by two-factor authentication.
From Two Factor authentication to Time bound OTP, server-side authorisation and a locked-down kiosk role, access is enforced in code not by what the interface chooses to show.
Audit evidence that cannot be altered.
Every admin action is permanently recorded. Who did what, to which record, when, and from where. There is no update or delete option for audit logs recorded. Even revealing an ID number creates its own audit record.
Infrastructure
Secure cloud – Microsoft Azure
Built on Microsoft Azure and hosted within UAE-based cloud infrastructure, our visitor management platform is designed to keep your building’s visitor data securely within the region. From identity verification and visitor records to host notifications and immutable audit trails, every layer is protected with enterprise-grade security controls, giving residential buildings and other entities greater control, visibility and confidence over how visitor information is stored and accessed.
Private by Design
Azure Database for PostgreSQL and storage are accessible only through the private network, with no public endpoints exposed to the internet. This keeps critical data services isolated from direct external access and reduces the attack surface.
Secure Web Access
All external traffic is routed through Azure Front Door with a Web Application Firewall (WAF), providing an additional layer of protection before requests reach the application. TLS (Transport Layer Security) terminates at the edge, while the application origin is not directly addressable from the internet, reducing exposure and strengthening the overall security posture.
35-Day Point-in-Time Recovery
Azure Database for PostgreSQL retains 35 days of point-in-time backups, so if data is accidentally changed, deleted, or corrupted, you can restore the database to a previous point in time and quickly get back to a known-good state.
Azure Role Based Access Control
Everyone gets only the access they need. Owners, administrators, security teams, reception staff and hosts have separate roles and permissions, keeping sensitive visitor information limited to the people who need it. Access is enforced on the server, not simply hidden from the screen.
Data residency
Where your data sits today
vizAI runs on Microsoft Azure, in the UAE North region. The database and object storage sit behind private endpoints, never on the public internet. The application is fronted by Azure Front Door with a web application firewall.
We put that first because it is the thing most often assumed about vizAI instead of checked. A Dubai company is not automatically a Dubai database, and procurement should never discover the difference after signing. Ask us for the region in writing and we will give it to you in writing.
If you carry a UAE residency obligation, have it written into the contract naming the region. The Azure deployment will keep 35 days of point-in-time restore, retention and anonymisation run on the schedule you set, and every administrative action against your data is recorded in an append-only audit log. Residency without those three is a location, not a control.
Retention
Records that go anonymous, not records that vanish
Keeping everything forever is the most common data protection failure in visitor management, and it usually happens by default instead of by decision.
When a record passes its retention period, a scheduled job anonymises it. The name in both scripts, phone, email, ID type, last four characters, full ID number, expiry date, date of birth and photograph are all cleared. Nationality and sex stay on purpose: with the names gone they identify nobody, and reports group by them. Deleting the row instead would quietly corrupt every visit count you have already reported to a landlord or an auditor.
- Retention set per organisation and per tenant company. Where both apply, the longer period wins
- Visitor photographs are removed from storage at the same time
- Legal holds pause it for named records, and a paused deletion is counted and visible
- The Azure deployment will give 35-day point-in-time restore
The full ID number
The field with the strictest control in the system
Capturing full ID numbers is off by default, so for most sites the column is empty. Where you switch it on, an ordinary signed-in session cannot read it. Every other column on that table is granted one by one, so PostgreSQL itself withholds this one rather than application code remembering to leave it out. It appears in no export, scheduled or manual. The only sanctioned way to see a number is a reveal, one at a time, that writes its own audit row.
This control was broken until August 2026. The original attempt used a column-level revoke, which in PostgreSQL cannot subtract from a grant already made on the whole table, so it did nothing for six weeks while the code claimed otherwise. An internal review found it, and it was corrected by granting every other column individually. We publish this because a security page that lists only strengths is not much use to the person relying on it.
Ready to see it on your own building?
Tell us how many entrances you run and roughly how many visitors you see in a day. We will show you the exact check-in your reception would use.