Describe your business, leave with a checklist you can assign

Keep a written justification for each export flow: (i) it falls within a purpose permitted by PDPL Article 29(1) or one of the three “other purposes” specified in Article 2 of this Regulation (necessary central processing, providing a service or benefit to the data subject, scientific research and studies); (ii) it does not prejudice national security or the Kingdom’s vital interests; (iii) an adequate level of protection exists outside the Kingdom, at least equivalent to that under the Law and Regulations; and (iv) it is limited to the minimum personal data needed. Article 29(3) disapplies the three conditions in cases of extreme necessity to preserve the life or vital interests of the data subject or to prevent, examine or treat disease.

Evidence: Export flow register (purpose, legal basis, recipient, data categories, volume); Minimisation reasoning and field-level evidence (pre- and post-transfer field comparison); Internal review note on national security and vital interests; Adequacy assessment conclusion and supporting material

Open tool: Transfer Matrix

Article 4(1) requires a controller relying on an exemption to implement one of: standard contractual clauses, binding common rules, or a certificate of accreditation. Article 4(2) sets out five exemption cases and their requirements: transfers between public bodies to implement an agreement to which the Kingdom is a party or to serve its interests must include standard personal data protection provisions in the relevant agreements or memoranda; non-recurring or time-limited transfers involving a limited number of data subjects must comply with the standard contractual clauses, or go to a recipient holding an approval certificate from an entity licensed by the Competent Authority with non-sensitive data; transfers necessary for central operations within a group of multinational entities require the controller and its affiliates to comply with binding common rules or the standard contractual clauses, or the recipient to hold an approval certificate; transfers to provide a service or benefit directly to the data subject without violating their expectations or interests must go to a certified recipient with non-sensitive data; and transfers necessary for scientific research and studies must be limited to the minimum data required and comply with the standard contractual clauses or go to a certified recipient with non-sensitive data. Article 4(3) requires the safeguards to ensure compliance with the Law and Regulations and to protect data subjects’ rights, including the right to complain to the Competent Authority and to seek compensation.

Evidence: Executed SDAIA standard contractual clauses or approved binding common rules; Recipient’s accreditation certificate and evidence the issuing body is licensed (where the certification route is used); Memo classifying each flow against the five cases in Article 4(2); Verification that the safeguards operate (access control, complaint and compensation channel, exercise of audit rights)

Open tool: Transfer Matrix

Article 7(1) requires a risk assessment before transfer in two cases: transfers or disclosures made under the Article 4 exemptions, and continuous or widespread transfer or disclosure of sensitive data outside the Kingdom. Article 7(2) requires the assessment to cover at least six elements: the purpose and legal basis for the transfer; a description of its nature, including the processing activities involved and their geographical scope; the appropriate safeguards implemented and their adequacy in ensuring a level of protection not less than that prescribed by the Law and Regulations; the measures used to limit the transfer to the minimum data required, in cases not exempted under Article 29(2)(c); the potential material or moral effects of the transfer and the likelihood of their occurrence; and the measures or controls to prevent potential risks or mitigate their effects. SDAIA’s Risk Assessment Guideline should be the baseline for the template.

Evidence: Transfer risk assessment report covering the six elements of Article 7(2); Analysis of the destination’s legal environment relied on in the assessment; Risk mitigation control list and implementation evidence; Re-assessment trigger rules and the history of re-assessments (changes of recipient, data category or legal environment)

Open tool: Transfer Matrix

PDPL Article 20 requires the controller to notify the Competent Authority upon becoming aware of any breach, damage or illegal access to personal data, and to notify the data subject where the incident would cause damage to their data or prejudice their rights and interests. Article 24(1) of the Implementing Regulation adds that, where the incident potentially causes harm to the personal data or to the data subject or conflicts with their rights or interests, the controller must notify the Competent Authority within no more than 72 hours of becoming aware; Article 24(2) allows supplementary filing in stages where not all required information can be provided within that window. In practice, fix the definition of “aware”, the cross-time-zone on-call and escalation path, and the notification templates in advance.

Evidence: Breach response plan with the definition of “aware” and a 72-hour clock chart; Competent Authority notification template and submission records; Data subject notification text and proof of delivery; Post-incident review report and corrective action tracker

AI incident and serious incident reporting record (register plus report drafts)

Under PDPL Article 30(4)(c) and Article 34 of the Implementing Regulation the Competent Authority maintains a national register of controllers. Article 2 of the National Register Rules requires registration on the National Data Governance Platform where any of the following applies: the controller is a public entity; its main activity is based on personal data processing; it processes sensitive data; or an individual processes personal data for purposes exceeding personal or family use. Registration requires appointing a representative (for private entities, through the Platform by the authorised person), completing entity and representative details, and determining during the process whether a personal data protection officer must be appointed under Article 32 of the Implementing Regulation and the DPO Appointment Rules; where one is appointed, their details must be entered on the Platform. The Platform issues a registration certificate bearing a registration serial number, which may be made available to the public.

Evidence: Registration certificate from the National Data Governance Platform with its serial number; Representative designation document and authorisation chain; Memo determining whether a personal data protection officer is required; Change log and annual review record for the registered particulars

Article 32(1) of the Implementing Regulation and Article 5 of the DPO Appointment Rules set three mandatory cases: a public entity providing services involving large-scale processing; core activities based on processing operations that by their nature require regular and systematic monitoring of data subjects; and core activities based on processing sensitive personal data. The Rules add criteria: large scale is judged on the number of data subjects, volume and type of data, geographical scope and categories of data subjects; “regular” means continuous, at set intervals or periodic, and “systematic” means carried out through technological systems, following a specific methodology, or as part of an overall strategy or plan — with examples including health and fitness data from wearables, behavioural analytics for risk assessment, location tracking, cookies and surveillance cameras. Activities are core where the controller cannot provide its products or services without processing personal data. The DPO may be an executive, an employee or an external contractor, and is responsible for acting as the direct contact point with the Competent Authority, supervising impact assessments and audit reporting, enabling data subjects to exercise their rights, notifying the Competent Authority of breaches, handling requests and complaints, monitoring and updating the records of processing activities, and handling violations and corrective actions.

Evidence: Determination memo against the three cases and the large-scale / regular / systematic / core-activity criteria; DPO appointment document, role description and qualifications; Record of the DPO details entered on the National Data Governance Platform; DPO activity records (impact assessment oversight, breach notifications, request and complaint handling)

PDPL Article 22 requires the controller to conduct an impact assessment of personal data processing in relation to any product or service, based on the nature of its activity and in accordance with the Regulations. Unlike the EU DPIA, the trigger is tied to the product or service, so an AI company should reassess whenever it launches a feature, swaps models, widens data sources or changes how outputs are used, rather than treating it as a one-off. Article 32(3)(b) of the Implementing Regulation makes supervising impact assessment procedures, audit and control reporting, documenting the results and issuing recommendations an express duty of the personal data protection officer.

Evidence: Impact assessment reports organised by product or service; Trigger rules for reassessment (new feature, model swap, data source change, change of output use); DPO oversight notes and recommendations on each assessment; Verification records that mitigation measures were implemented

PDPL Article 19 requires the controller to implement all necessary organisational, administrative and technical measures to protect personal data, including during transfer, in accordance with the controls set out in the Regulations. Article 41 adds that any person engaged in processing personal data must protect its confidentiality even after their occupational or contractual relationship ends. Practically, confidentiality undertakings and access-revocation workflows for outsourced labelling teams, departing engineers and temporary contractors must be evidenced, and the duty survives termination.

Evidence: Security control catalogue and implementation evidence (encryption, access control, transport protection, logging); Confidentiality undertakings for staff and subcontractors, with post-termination survival clauses; Account and access revocation workflow records; Periodic security assessment and remediation records

PDPL Article 31 requires controllers to maintain records of personal data processing activities for the period prescribed by the Regulations, based on the nature of their activity, and to make them available whenever the Competent Authority requests. The record must contain at least the controller’s contact details, the purpose of processing, a description of the categories of data subjects, any other entity to which personal data has been or will be disclosed, whether personal data has been or will be transferred outside the Kingdom or disclosed to an entity outside it, and the expected retention period. For AI companies the “outside the Kingdom” field must reflect where training datasets, inference request logs, vector stores and model checkpoints actually reside and are accessed from, not merely the nominal contracting counterparty.

Evidence: Record of processing activities covering the six elements of Article 31; Inventory of where data is stored and accessed from (training sets, logs, vector stores, model checkpoints); Retention policy and evidence of deletion at expiry; Procedure and history for producing the record to the Competent Authority

Before entering the Saudi market, tier each AI system against the “Scope” section of the AI Ethics Principles: little or no risk, limited risk, high risk, unacceptable risk. For systems assessed as high risk the document requires pre- and post-conformity assessments and compliance with the relevant statutory requirements in addition to ethics. Uses falling into the unacceptable tier — social profiling, exploitation of children, likely distortion of behaviour — must not be deployed. Record the tiering conclusion and reasoning in the product compliance file and re-assess on functional change.

Evidence: Risk tiering worksheet (system, use case, tier, reasoning); Pre-deployment conformity assessment report for high-risk systems; Post-deployment monitoring and post-conformity assessment records; Excluded-use list for the unacceptable tier and technical evidence of enforcement in the product

ISO/IEC 42001 AI management system implementation and certification readiness checklist

Map the seven principles — Fairness, Privacy & Security, Humanity, Social & Environmental Benefits, Reliability & Safety, Transparency & Explainability, and Accountability & Responsibility — onto concrete controls in the four lifecycle stages: plan and design, prepare input data, build and validate, deploy and monitor. Under Humanity the document requires the model to be designed and built on fundamental human rights and Saudi cultural values, and requires designers to define how the system and its outcomes align with them. Under Fairness it requires fairness-aware design to start at the beginning of the lifecycle as a collaborative effort. Under Privacy & Security it sets the specific controls described above (no personally identifying characteristics as automated decision criteria; profiling only with compliance-officer approval or under a sector regulator’s code; data classification and profiling planned at the data architecture stage; de-identification planned for sensitive or personal data with group-based read/write/update authorisation). Each control needs an owner, execution evidence and a review cycle.

Evidence: Control mapping from the seven principles to the four lifecycle stages, with owners and review cycles; Fairness assessment reports and bias mitigation records; Compliance approval record for profiling use cases (compliance officer sign-off or reference to a sector regulator’s code); De-identification design, data classification output and the group-based authorisation matrix

ISO/IEC 42001 AI management system implementation and certification readiness checklist

The Generative AI Guidelines for the Public apply to all stakeholders designing, developing, deploying, implementing, using or affected by GenAI systems within the Kingdom. They distinguish “Users” (any natural or legal person consuming or making use of goods or services produced by GenAI systems, covering companies, NGOs and individuals) from “Developers” (any natural or legal person developing GenAI systems to achieve certain goals, including AI developers, data scientists and researchers), and set out GenAI principles, risks and potential mitigations. Build a Saudi-facing GenAI risk register on that basis: map each risk the guidance lists onto your product, state the mitigations adopted and the residual risk, and reflect them in user terms and in-product notices. SDAIA also publishes a government edition of the GenAI guidance and a deepfakes document; align to those as well when delivering to government customers.

Evidence: GenAI risk register (risk, mitigation, residual risk, owner); Technical note and test records for content safety and abuse prevention; User terms, acceptable use policy and in-product notices; Alignment note against the government edition of the guidance for public-sector deliveries

Model CardISO/IEC 42001 AI management system implementation and certification readiness checklist