Definition

The KSA Personal Data Protection Law (PDPL, Royal Decree M/19, 2021) Implementing Regulations, issued by SDAIA and effective September 2023, operationalise the framework's requirements for controllers and processors including lawful-basis selection, Record of Processing Activities (ROPA) maintenance, cross-border transfer conditions, and mandatory breach notification to SDAIA. Controllers must align internal policies and technical controls to the Implementing Regulations within SDAIA's enforcement timeline.

Why it matters

The pressure on Regulatory (UAE/GCC) programmes is shifting in specific, observable ways:

• SDAIA's enforcement division began investigating complaints in Q1 2024; controllers without a documented lawful basis per KSA PDPL Article 6 have received formal enquiry notices — the first enforcement cycle prioritised consent and transfer violations.
• KSA PDPL Implementing Regulation Article 29 requires a documented Data Protection Impact Assessment for high-risk processing; controllers using AI profiling or large-scale sensitive-data processing without a DPIA face penalties up to SAR 5M (Article 35 PDPL).
• Cross-border transfer rules under KSA PDPL Article 30 require either SDAIA approval, adequacy determination, or contractual safeguards — multinationals routing KSA data through global cloud regions without a valid mechanism are materially exposed.
• KSA PDPL Article 20 requires ROPA maintenance for all controllers processing personal data; SDAIA inspection requests for ROPA records have increased following 2024 enforcement campaign announcements.

Evidence sources to capture

What an auditor or reviewer will sample for — wire each source into your evidence repository before the next review cycle:

• ROPA (Record of Processing Activities) — processing activity name, controller/processor, data categories, lawful basis (KSA PDPL Article 6), retention period, transfer destination.
• DPIA records — processing description, necessity assessment, risk score, mitigating measures, DPO/legal sign-off, review date.
• SDAIA breach notification log — incident ID, discovery date, SDAIA notification timestamp (72-hour window), notification content, SDAIA reference number.
• Cross-border transfer register — data destination country, transfer mechanism (SDAIA adequacy / contractual safeguards), agreement reference, review date.
• Consent management platform records (e.g. OneTrust) — consent timestamp, version, purpose, withdrawal log.
• Controller registration submission — SDAIA registration reference, date, data categories declared, DPO contact details.

Recommended next actions

A 90-day plan, sequenced so each step produces evidence the next step depends on:

• Day 0–30: Privacy Counsel maps all processing activities to SDAIA Implementing Regulation requirements; builds ROPA template aligned to Article 20; identifies high-risk processing activities requiring DPIA.
• Day 31–60: Data Protection Officer completes DPIAs for high-risk processing activities (AI profiling, sensitive data at scale); presents findings to senior management; implements recommended mitigations.
• Day 61–60: Legal team audits cross-border data flows; executes contractual safeguards or SDAIA-approved transfer agreements for all international data transfers; updates data-processing agreements with processors.
• Day 90+: Controller completes SDAIA registration where required; configures breach-notification workflow with 72-hour alert trigger; trains incident-response team on SDAIA notification format.
• Ongoing: Privacy team reviews ROPA quarterly; updates DPIAs annually or on material process change; monitors SDAIA enforcement decisions and guidance for interpretation updates.

Example metrics

Instrument these and report them monthly to the executive sponsor; sustained adverse trends become board-level conversations:

• ROPA completeness: 100% of processing activities documented within 90 days; reviewed and updated at least annually.
• DPIA coverage: 100% of high-risk processing activities (per SDAIA criteria) have a completed and approved DPIA.
• SDAIA breach notification SLA: 100% of reportable breaches notified within 72 hours; zero late notifications.
• Cross-border transfer coverage: 100% of international transfers documented with a valid transfer mechanism before data flow commences.
• Consent withdrawal SLA: ≥95% of consent withdrawals actioned (processing ceased, data deleted where applicable) within 30 days.

What the rule actually says

Read against CBUAE, SAMA, DFSA, FSRA-ADGM, CMA-KSA, TDRA / NESA / SIA / DESC, RBI, SEBI, IRDAI, MeitY (cross-border programmes), the operative text lands in three places: India DPDP Act 2023 and RBI Master Direction on IT Governance; SAMA CSF v1.1; CBUAE Consumer Protection Regulation and Cyber Standards.

Where the regulator has chosen prescriptive language, the room for interpretation is narrow — the safer position is to mirror the language in policy. Where the language is outcome-based, the practice has to evidence the outcome, not the activity.

• Scope. Confirm which entities, systems and data are in the regulated population. Most disputes begin here.
• Required artefacts. Identify the documents the regulator expects to exist and the cadence on which they must be refreshed.
• Evidence of operation. Map each requirement to a control owner, an evidence source and a review frequency before the next supervisory cycle.

Pitfalls we keep seeing

Across MAST Consulting Group's Regulatory (UAE/GCC) portfolio, the same recurring failure modes show up cycle after cycle. None are exotic; all are expensive when they reach the audit report.

• Pattern: evidence packs that are unique to each regulator instead of harmonised. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: controls listed against the regulator but not operating consistently. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: thematic-review responses prepared in the week of the visit. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.
• Pattern: no single source of truth across multiple supervisors. What good looks like: the same control evidenced inside the workflow it governs, not separately for the audit.

Tooling we actually reach for

MAST Consulting Group is deliberately tool-agnostic, but in practice the same shortlist keeps appearing on Regulatory (UAE/GCC) engagements because the integrations are cheap and the evidence is defensible:

• evidence repository with regulator tagging — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• data extracts from core systems on a fixed cadence — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.
• a unified control framework (UCF) in a GRC tool or curated spreadsheet — used not because it is fashionable, but because the audit trail it generates is one the reviewer accepts on the first ask.

How MAST Consulting Group can help

MAST Consulting Group runs Regulatory (UAE/GCC) programmes for banks, insurers, healthcare networks, payments providers, telcos and government entities across the UAE, KSA, India and the wider GCC. We bring Lead Practitioners, sector specialists, and a working library of policies, risk methodologies and evidence templates that have passed audit at firms recognisable to your board.

If anything in this regulatory note is relevant to a programme you are scoping or rescuing, the fastest next step is a 30-minute working session with the practice lead. We will look at your specific situation, share what we have seen work for Regulatory (UAE/GCC) programmes at similar scale, and tell you honestly if the work is something you should bring to us or run in-house.