Visitor logs are personal data. What you may collect, how long you may keep it, and what your vendor must guarantee.
A visitor log holds names, phone numbers, ID references, employers, arrival times and movement patterns. Under Saudi Arabia's Personal Data Protection Law, that is not an operational record — it is personal data, and it carries obligations.
Most facilities discover this during an audit rather than during procurement. This guide covers what the law asks of a visitor system and what to require from a vendor. It is a practical overview to review with your own compliance advisors, not legal advice.
Processing needs a legitimate basis, and for visitor management the realistic candidates are:
| Basis | Typical use |
|---|---|
| Legitimate interests of the controller | Site security and safety records |
| Legal or regulatory obligation | Sector-specific record-keeping duties |
| Consent | Optional extras such as marketing follow-up |
| Contract performance | Contractor access under an agreement |
The distinction that matters operationally: if entry depends on it, consent is not the right basis — because consent must be freely given, and a visitor who cannot enter without agreeing has not given it freely. Security-based collection generally rests on legitimate interests instead, with consent reserved for genuinely optional items.
The principle is that collection should be limited to what the stated purpose requires. Translated into a registration form, it becomes a single question per field: which decision or action depends on this?
Fields that usually fail the test:
The second is the most common: hardware that can scan an ID does not create a basis for storing the image. Verification and retention are separate decisions, and only the first is usually necessary.
The law does not publish a universal number, because the answer depends on purpose. What it requires is that you define a period tied to that purpose and delete when it ends.
A defensible approach:
Different categories often warrant different periods: routine visit records, incident-related records and contractor documents each serve different purposes and should not inherit one blanket retention setting. Confirm the specific periods with your compliance team.
Cross-border transfer of personal data is regulated rather than simply prohibited, and the applicable conditions depend on the data, the destination and your sector. Some regulated sectors carry additional residency expectations beyond the general framework.
What to establish with any vendor, in writing:
The second point catches most facilities: data hosted locally with backups abroad is data abroad. A residency claim that covers only the primary database is incomplete.
Individuals are entitled to know what is collected and why, at the point of collection — which for visitor management means the gate, not a policy page nobody visits.
A workable notice is short and placed where it will be seen: on the kiosk screen before the first field, in the pre-registration form, and on a sign at the reception desk. It should state what is collected, the purpose, how long it is kept, and how to contact the facility about it — in both Arabic and English.
Length is the enemy here. A three-line notice that is read beats a two-page one that is scrolled past.
When a vendor processes visitor data on your behalf, responsibility does not transfer with the data. Your agreement should address:
| Clause | What it must establish |
|---|---|
| Roles | You are the controller; the vendor is a processor |
| Purpose limitation | Data used only for the agreed service |
| Secondary use | Whether anonymised data may be used, or not at all |
| Sub-processors | Disclosure and notice before changes |
| Security measures | Encryption, access control, audit logging |
| Breach notification | A defined number of hours, not "promptly" |
| Deletion on exit | Certified deletion within a stated period |
The breach clause deserves specific attention: an undefined notification window means you may learn about an incident from a third party, which is the worst way to find out about your own data.
Individuals have rights over their data, and a visitor system should make them operable rather than theoretical. In practice you need to be able to, for a named individual:
Test this before you need it. A system that cannot locate all records for one person within minutes cannot support a request within a deadline — and this is a product capability question, not a policy one.
In Haseen, retention periods are configurable per data category with automatic deletion, identity verification is separated from image retention as an explicit choice, permissions restrict what each role can see, and access to visitor records is logged. Hosting and residency arrangements are defined to match your facility's requirements.
See PDPL-ready visitor management and the registration mechanics in how visitor registration works.
Yes. A visitor record identifies a specific individual, which makes it personal data, and collection, storage, access, sharing and deletion all fall within scope. Collecting it for security purposes does not create an exemption — it shapes which lawful basis applies rather than removing the obligation.
There is no universal number; the period must be tied to the purpose and deletion must happen when it ends. Identify the purpose per data category, set a period that purpose justifies, configure automatic deletion rather than a manual task, document the reasoning, and review periodically. Routine visits, incident records and contractor documents usually warrant different periods.
Cross-border transfer is regulated rather than simply prohibited, and conditions depend on the data, destination and sector — with some regulated sectors carrying additional residency expectations. Establish in writing where production data and backups are hosted, whether support staff abroad can access production, and which sub-processors are involved. Data hosted locally with backups abroad is data abroad.
Not usually as the basis for security-related collection, because consent must be freely given and a visitor who cannot enter without agreeing has not given it freely. Security collection generally rests on legitimate interests, with consent reserved for genuinely optional items such as marketing follow-up. Confirm the basis for your specific case with your compliance advisors.
Your vendor agreement should define a notification window in hours from discovery rather than "promptly", specify what the notification must contain, name contacts on both sides, and require cooperation in your investigation as well as theirs. Regulatory notification duties then follow the applicable framework — which is why learning about an incident quickly matters operationally, not just contractually.
It justifies collecting what the security purpose actually requires, which is a narrower test than it sounds. Each field still has to answer which decision or action depends on it. Scanning and storing ID images because the kiosk hardware supports it is the clearest example of a practice that a security justification does not automatically cover.
Open your visitor registration form and mark every field whose purpose you cannot state in one sentence. That list is where a compliance review will start — so it is worth starting there first.
Configurable periods per data category, verification separated from image retention, and logged access to every record.