AI Video Analytics Under Saudi PDPL: The SDAIA Framework in Practice

Compliance under Saudi PDPL is not a translation exercise from European law, it is a separate regime with its own logic, its own regulator, and its own carve-outs.

Operators who arrive in the Kingdom with a GDPR template assume that the heavy lifting is done. They are wrong by a margin that the first SDAIA inquiry will make visible. The Personal Data Protection Law issued under Royal Decree M/19, amended in 2023, and supplemented by implementing regulations from the Saudi Data and Artificial Intelligence Authority, sets a framework that resembles the European one in its surface vocabulary and diverges from it in substance. The divergence becomes operational the moment a camera with analytics is mounted on a perimeter. What the lens captures is personal data. What the model infers can be biometric data. What the system stores becomes a regulated asset under a regulator that has shown, since the law took full effect in September 2024, an appetite for enforcement that should be taken at face value.

This article addresses the operator who deploys AI video analytics on Saudi soil, whether on a construction site in Riyadh, a logistics yard in Jeddah, or an industrial complex along the eastern coast. The argument is technical where it needs to be, legal where the law leaves no alternative, and practical throughout. The frame is the one developed in BOSWAU + KNAUER. From Building to Security Technology: a manufacturer's perspective, where the question is never what a system can do in a brochure, but what it does in a field that bites back.

The PDPL as a regime with its own gravity

The Saudi Personal Data Protection Law treats personal data as a category broader than most operators initially recognise. It covers any data that identifies, or could identify, a natural person, including images that show a face clearly enough to permit recognition. A perimeter camera that captures recognisable faces processes personal data under PDPL from the first frame. This is not a contested reading. It follows directly from Article 1 of the law and from the SDAIA guidance that has been issued since.

What distinguishes PDPL from GDPR is the architecture of consent and the role of the regulator. SDAIA is not an arm's length supervisory authority modelled on European data protection commissioners. It is the national authority for data and artificial intelligence, with rulemaking power, registration authority, and enforcement competence concentrated in a single body. The implementing regulations published in September 2023 set out the practical obligations: lawful basis assessment, data protection impact assessment for high risk processing, registration with the National Data Governance Platform for certain controllers, and breach notification within seventy-two hours where the breach causes harm to the data subject or to the data itself.

Operators who deploy video analytics in the Kingdom are processing personal data on a continuous basis, often at scale, often without the explicit consent of the persons captured. The lawful basis cannot rest on consent in most security deployments, because the persons walking past a perimeter camera have not consented in any meaningful sense. The lawful basis must therefore rest on either a legitimate interest argument, which PDPL recognises in narrower form than GDPR, or on a contractual or legal obligation. Each of these grounds requires documentation that survives regulatory inspection. A general statement that cameras protect property is not documentation. A risk register that names the threats, the measures, the necessity, and the proportionality is documentation. The difference is the difference between a passed audit and an open file.

SDAIA enforcement in practice

SDAIA has been operational as the lead authority since the law took full effect. Its enforcement posture is calibrated, but the calibration should not be mistaken for leniency. The pattern that has emerged in the first eighteen months is one of inquiry letters, structured information requests, and, where deficiencies are confirmed, administrative penalties that scale with the gravity of the breach. PDPL provides for fines that can reach five million Saudi riyals for certain violations, with doubling possible for repeat offences, and criminal penalties for disclosure of sensitive data with intent to harm. Compared to the GDPR ceiling of four percent of global turnover, the absolute numbers may seem lower, but the reputational consequence in a market where the regulator has direct access to the Council of Ministers is not lower at all.

The enforcement that matters for video analytics operators is not the headline fine. It is the operational disruption that follows an inquiry. SDAIA has the power to request documentation, to order the suspension of processing, and to require remediation within stipulated timeframes. An operator who cannot produce, within forty-eight hours, a data protection impact assessment for an analytics deployment is not in a defensible position. An operator who can produce the assessment, the lawful basis analysis, the retention schedule, the access log, and the breach response plan, in Arabic where the regulator requests it, is. The difference is preparation that begins before deployment, not after the letter arrives.

There is a second axis of enforcement that operators tend to underestimate. SDAIA coordinates with sectoral regulators, including the Communications, Space and Technology Commission for telecommunications and connected devices, and the National Cybersecurity Authority for systems classified as part of critical infrastructure. A video analytics platform that runs on a cellular backhaul, integrates with a building management system, and stores footage in a regional cloud is touching three regulatory perimeters at once. The compliance architecture must therefore be designed to satisfy each perimeter without contradiction. Operators who treat compliance as a single-axis problem will find the contradictions surface during the first audit. The book BOSWAU + KNAUER. From Building to Security Technology develops the manufacturer's view that compliance architecture is a design decision, not a paperwork exercise added at the end.

The biometric question

PDPL treats biometric data as a category of sensitive data under Article 1, alongside health data, genetic data, credit data, and data revealing racial or ethnic origin, religious or political beliefs, and criminal records. Sensitive data carries elevated obligations: explicit consent in most cases, restricted grounds for processing without consent, and tighter security requirements. The implementing regulations clarify that biometric data includes data resulting from specific technical processing relating to the physical, physiological, or behavioural characteristics of a natural person, where that processing allows or confirms the unique identification of the person.

This definition has consequences for AI video analytics that operators frequently miss. A camera that records video without facial recognition processes personal data, but not biometric data. A camera that runs a model extracting facial embeddings for the purpose of identifying or verifying a person processes biometric data, even if the embeddings are not stored. A camera that runs a model classifying behaviour, gait, or other physiological signals in a way that permits identification of the individual processes biometric data. The technical threshold is identification or the capacity for identification, not the storage of a template.

The carve-outs are narrow. PDPL permits the processing of sensitive data without explicit consent in limited circumstances, including the protection of vital interests, the performance of a legal obligation, and processing necessary for the public interest as defined by competent authorities. Private security deployments rarely fit cleanly into these carve-outs. An operator who runs facial recognition on a construction site perimeter to identify trespassers is processing biometric data without explicit consent, and the legal basis for doing so requires a serious analysis. The analysis is not a formality. It is the document that the operator will hand to SDAIA when the question is asked. Where the analysis cannot be sustained, the operational answer is to disable the facial recognition function and rely on detection without identification, which keeps the deployment in the personal data category without crossing into biometric processing. This downgrade is technically straightforward in modern analytics platforms. It is contractually and operationally significant. The IEC 62443 framework for industrial automation security, while not directly applicable, provides useful structure for documenting the technical controls that distinguish identification from detection.

What the documentation file must contain

A defensible deployment of AI video analytics under PDPL rests on a documentation file that exists before the first camera is energised. The file is not a single document. It is a set of artefacts, each addressing a specific obligation, each maintained as a living record. The structure that has emerged across deployments in the Kingdom follows roughly the logic that NIST CSF 2.0 uses for cybersecurity programmes, adapted to the data protection context.

The first artefact is the data processing inventory. It lists every category of personal data processed, every purpose, every retention period, every recipient, every transfer outside the Kingdom. For a video analytics deployment, this inventory will name the camera locations, the analytics models running on each stream, the data extracted, the storage architecture, and the access roles. The second artefact is the lawful basis analysis. It states, for each processing purpose, the legal ground relied upon, the necessity of the processing for that purpose, the proportionality of the means, and the alternatives considered and rejected. The third artefact is the data protection impact assessment, required for high risk processing including most video analytics at scale. The assessment follows a structured methodology: description of the processing, assessment of necessity and proportionality, identification of risks to the rights and freedoms of data subjects, and identification of measures envisaged to address those risks.

The fourth artefact is the consent and transparency record. Where consent is the basis, the record shows when consent was obtained, in what form, with what information provided. Where consent is not the basis, the record shows the transparency measures: signage at perimeters, notices to workers, language versions, placement. The fifth artefact is the security and access control documentation, aligned with ISO 27001 controls where the operator runs a certified information security management system, and with the National Cybersecurity Authority's Essential Cybersecurity Controls where the deployment touches critical national infrastructure. The sixth artefact is the breach response plan, with named roles, escalation paths, notification templates in Arabic and English, and a tested procedure for meeting the seventy-two hour deadline. The seventh artefact is the cross-border transfer assessment, required wherever personal data leaves the Kingdom, including transfers to cloud regions outside Saudi Arabia. PDPL restricts transfers to jurisdictions that offer adequate protection or to recipients subject to appropriate safeguards, and the assessment must show which ground is relied upon. Operators who run analytics in a hyperscaler cloud must check whether the cloud region is inside the Kingdom or outside, and adjust the documentation accordingly.

Manufacturer obligations versus operator obligations

PDPL distinguishes between controllers and processors in a manner familiar from European law, with some Saudi-specific refinements. The controller determines the purposes and means of processing. The processor processes on behalf of the controller. In a typical video analytics deployment, the operator who installs and runs the system on its premises is the controller. The manufacturer who supplies the cameras, the analytics platform, and the maintenance service is the processor, where it has access to personal data, and a mere supplier where it does not. The distinction matters because the obligations cascade.

A controller cannot escape responsibility by claiming that the manufacturer should have built compliance into the product. A manufacturer cannot escape responsibility by claiming that the controller should have configured the product correctly. The data processing agreement between the two parties is the document that allocates the responsibilities, and PDPL requires such an agreement in writing wherever a processor handles personal data on behalf of a controller. The agreement specifies the subject matter, duration, nature, and purpose of the processing, the types of personal data, the categories of data subjects, and the obligations and rights of the controller. It must include commitments by the processor to process only on documented instructions, to ensure confidentiality, to implement appropriate security measures, to assist with data subject requests and breach notifications, and to delete or return personal data at the end of the engagement.

Manufacturers serving the Saudi market have adjusted their standard terms to meet these requirements, but the adjustment is uneven across the industry. Operators who procure analytics platforms without scrutinising the data processing terms inherit the gaps. The first question for any procurement is whether the supplier offers a PDPL-compliant data processing agreement, in Arabic where required, with clear allocation of responsibilities for the seven documentation artefacts described above. Where the supplier does not, the operator carries the risk alone, and the risk is not theoretical. ASIS International guidance on physical security contracting, while developed in a different jurisdiction, provides a useful checklist for the procurement conversation.

What holds

The deployment of AI video analytics in the Kingdom of Saudi Arabia is governed by a framework that is legible, demanding, and enforced. Operators who treat PDPL as a less rigorous version of GDPR will find that the differences cut against them. Operators who treat PDPL as its own regime, with its own regulator, its own carve-outs, and its own enforcement logic, will build deployments that survive inspection and serve the operational purpose for which they were procured.

The work begins before the cameras are mounted. It continues through the lifecycle of the deployment. It is documented in artefacts that can be produced on demand. It is reviewed against the evolving guidance from SDAIA and the implementing regulations as they mature. What holds is the discipline of treating compliance as part of the system architecture, not as a layer added after the fact.

Operators who recognise themselves in this description and want to test their current posture against the framework outlined here have three paths to a conversation. The first is a sixty-minute confidential exchange in which the operator describes the deployment and the manufacturer's perspective is offered without obligation. The second is a structured audit of three to five days at the site or sites in question, with a written report and a remediation roadmap. The third is a ninety-day pilot in which an analytics deployment is configured for PDPL compliance from the ground up, with documentation produced in parallel to the technical work. Each path stands on its own. Each is described so that the operator knows what is delivered and what is not.

Frequently asked questions

What is the Saudi PDPL?

The Saudi Personal Data Protection Law was issued under Royal Decree M/19 of 2021, amended in 2023, and took full effect on 14 September 2024. It governs the processing of personal data within the Kingdom and, in some circumstances, processing of data of persons residing in the Kingdom by controllers outside it. The law is supplemented by implementing regulations issued by SDAIA, which set out the operational obligations. It applies to all sectors, with sectoral overlays for healthcare, finance, and critical infrastructure. The structure resembles GDPR in vocabulary but diverges in substance, particularly on consent, sensitive data, and cross-border transfers.

How does SDAIA enforce?

SDAIA enforces through inquiry letters, information requests, on-site inspections, orders to suspend processing, and administrative penalties up to five million Saudi riyals, with doubling possible for repeat offences and criminal penalties for intentional disclosure of sensitive data. Enforcement coordinates with sectoral regulators including the National Cybersecurity Authority and the Communications, Space and Technology Commission. The pattern since September 2024 has been calibrated but consistent, with documentation requests being the most common opening move. Operators who can produce the required artefacts within stipulated deadlines move quickly out of the enforcement queue.

Are biometrics treated specially?

Yes. PDPL classifies biometric data as sensitive data, alongside health, genetic, credit, religious, and ethnic origin data. Processing of biometric data generally requires explicit consent, with narrow carve-outs for vital interests, legal obligations, and public interest as defined by competent authorities. Facial recognition, gait analysis, and other identification techniques fall within the biometric category when they permit identification of the individual, even if templates are not stored. The downgrade to detection without identification keeps a deployment in the personal data category without crossing into biometric processing. The technical and contractual distinction must be documented.

What documentation is needed?

A defensible deployment maintains seven artefacts: a data processing inventory, a lawful basis analysis, a data protection impact assessment, a consent and transparency record, security and access control documentation aligned with recognised frameworks such as ISO 27001 and the National Cybersecurity Authority controls, a tested breach response plan meeting the seventy-two hour deadline, and a cross-border transfer assessment where data leaves the Kingdom. The artefacts must be current, available in Arabic where the regulator requests, and consistent with the actual deployment. They are produced before deployment begins, not after a regulatory letter arrives.