1. The Extraterritorial Reach

A common misconception is that PDPL only applies to companies physically located in Saudi Arabia.

• The Reality: If your SAP instance—regardless of where it is hosted—processes the personal data of a Saudi resident, you are legally bound by PDPL.
• Critical Risk: This includes global headquarters managing Saudi-based employee records in a centralized SAP SuccessFactors or HCM instance.

2. The 72-Hour Breach Notification Loop

Article 20 of the PDPL Implementing Regulations is non-negotiable: Any personal data breach that poses a risk to the data subject must be reported to SDAIA within 72 hours.

The SAP Gap: Most standard SAP configurations do not have “Privacy Alerting” active. If a breach occurs (e.g., an unauthorized export from SE16N), the time it takes for an IT team to discover, escalate, and report it often exceeds the 72-hour window.

Surgical Fix: 

1. Configure SAP Read Access Logging (RAL): Specifically monitor sensitive fields like National ID, Bank Account (IBAN), and Salary. 
2. Integrate with SIEM: Push these logs to a Security Information and Event Management (SIEM) tool or SAP Enterprise Threat Detection (ETD). 
3. Threshold Alerting: Set an automated alert for “Anomalous Data Extraction”—if a user downloads >50 sensitive records in 60 seconds, an incident is created instantly.

3. High-Stakes Penalties (2026 Scale)

By 2026, the cost of non-compliance has shifted from administrative friction to a business continuity threat:

• Sensitive Data Misuse: Unauthorized disclosure of sensitive data can lead to up to 2 years of imprisonment and fines up to SAR 3 million.
• General Violations: Administrative fines of up to SAR 5 million, which can be doubled for repeat offenses.

Mapping SAP to the CST Cloud Framework

In Saudi Arabia, data residency is not just a preference—it is a sovereign mandate managed by the Communications, Space and Technology Commission (CST). Their “Cloud Computing Regulatory Framework” dictates that your SAP hosting model must match the classification of the data you process.

1. The CST Classification Tiers (A, B, and C)

CST assigns “Classes” to cloud providers based on their security posture. For an SAP customer in 2026, the tiers break down as follows:

• Class A: Permitted for Public Data only. (Irrelevant for SAP ERP/HCM).
• Class B: Permitted for Restricted Data (includes Corporate PII, Financials, and sensitive commercial data). This is the “Gold Standard” for the Saudi private sector.
• Class C: The highest tier, mandatory for Government Data and Critical National Infrastructure.

Technical Guardrail: If you are a regulated entity (Banking, Healthcare, Gov) and your SAP instance is hosted on a provider without at least a Class C certification, you are in immediate breach of CST and SDAIA regulations.

2. SAP RISE & The “In-Country” Cloud

By 2026, SAP has fully localized its “Sovereign Cloud” strategy in the Kingdom.

• The Dammam/Riyadh Regions: SAP RISE is now natively hosted on Google Cloud KSA and STC Cloud, both of which hold CST Class C status.
• SAP BTP Localization: As of early 2025/2026, the SAP Business Technology Platform (BTP) is available locally. This is a critical win—it allows you to build side-by-side extensions and AI integrations (like your ZATCA e-invoicing connectors) without the data ever crossing the Saudi border.

3. The “Remote Access” Trap (Article 29)

Many Saudi enterprises still operate on “Global Tenants” (shared instances in Europe or the US).

• The 2026 Risk: Under PDPL Article 29, “Remote Access” to PII data stored abroad is legally treated as a Data Export.
• The Surgical Fix: If you cannot migrate to a local region immediately, you must conduct a SDAIA 4-Phase Risk Assessment. In 2026, these waivers are increasingly difficult to obtain. The only “Surgical” path to zero-risk compliance is a migration to a localized RISE with SAP environment.

4. The “Sovereign Cloud” Decision Matrix

Use this filter to audit your current 2026 landscape:

This section moves from where the data sits to how the data is shielded. In the 2026 landscape, a simple password is no longer considered a “Technical Safeguard” under Article 18.

Technical Safeguards (Encryption, Masking, and Anonymization)

Under PDPL, “Data Security” is a legal mandate. SDAIA requires technical measures that are proportionate to the risk. In an SAP environment, this necessitates a multi-layered defense that protects data from the database layer all the way to the Fiori tile.

1. UI Data Protection Masking (The “Need-to-Know” Filter)

Standard SAP authorizations (PFCG) are often too “all-or-nothing” for PDPL. A HR clerk might need access to an employee profile but has no legal basis to see their National ID or Salary unless they are performing a specific task.

• The Surgical Fix: Implement SAP UI Data Protection Masking. This allows you to dynamically mask sensitive fields (e.g., showing XXXXX-1234) on Fiori, GUI, and Web Dynpro screens without changing the actual database values.
• 2026 Audit Requirement: Use Attribute-Based Access Control (ABAC). This ensures that data is only unmasked if the user meets specific conditions (e.g., “User is in the Riyadh Office” AND “User is assigned to the Payroll Project”).
• Reveal on Demand: If a user must see the data, they click a “Reveal” button and enter a reason. This reason is logged in the SDAIA-ready audit trail.

2. SAP HANA Encryption (At-Rest and In-Transit)

Encryption is a non-negotiable baseline in 2026. If an auditor finds unencrypted volumes, the “Intent to Comply” argument fails.

• Encryption at Rest: You must enable HANA Volume Encryption for data and log volumes. This ensures that if physical disks or backups are compromised in a Saudi data center, the PII remains unreadable.
• Encryption in Transit: All communication between the SAP Application server, the HANA database, and the end-user must be secured via SNC (Secure Network Communications) and SSL/TLS 1.2+.
• The 2026 Audit Check: Root Keys must be stored in a CST-approved Key Management Service or a secure local HSM (Hardware Security Module).

3. Data Anonymization for Analytics (Article 17)

Organizations often want to use SAP data for AI training or “Big Data” trends. Article 17 states that the PDPL does not apply to Anonymized Data.

• The Surgical Fix: Use the SAP HANA Data Anonymization Engine. Instead of moving raw PII to an analytics platform (which would count as a “Transfer” or “Processing” event), you create “Anonymization Views” using techniques like k-Anonymity or Differential Privacy.
• The Result: You gain statistical insights (e.g., “70% of customers in Jeddah buy Product X”) without ever “processing” a single personal identity.

4. The “Non-Production” Data Trap

The biggest PDPL breach risk in 2026 is the “Refresh” process. Taking a copy of Production data and putting it into a Development or QA system exposes PII to developers and external consultants who lack the legal “Need-to-Know.”

• The 2026 Mandate: For RISE with SAP clients, data scrambling in non-production environments is now a contractual and legal necessity.
• The Surgical Fix: Use SAP TDMS (Test Data Migration Server) or specialized scrambling tools. In 2026, leaving unmasked Saudi resident PII in a Sandbox or Test environment is legally classified as Gross Negligence.

The DPO & The SAP Audit Trail (Reporting and Breach Notification)

The Saudi PDPL mandates that organizations designate a DPO and implement a “Record of Processing Activities” (RoPA). In an SAP landscape, this cannot be a manual spreadsheet—it must be a live, automated audit trail.

1. The 72-Hour Breach Notification Workflow (Article 24)

According to Article 24, the 72-hour clock starts the moment a breach is “discovered.” If your IT team takes 48 hours just to confirm an extraction, you have only 24 hours left to notify SDAIA via the National Data Governance Platform.

• The SAP Challenge: Standard logs show when data was changed, but not when it was viewed or exported by a malicious actor.
• The Surgical Fix: Integrate SAP Enterprise Threat Detection (ETD).
  • Phase 1 (0-6 hrs): ETD detects an “Anomalous Export” (e.g., a user downloading the entire PA0002 table).
  • Phase 2 (6-24 hrs): The DPO uses ETD Forensics to identify exactly which Saudi residents were affected.
  • Phase 3 (24-72 hrs): Automated report generation for direct submission to the SDAIA portal.

2. Read Access Logging (RAL) as Legal Evidence

SDAIA auditors require proof of who accessed what sensitive data. Standard SAP Change Logs (AUT10) are legally insufficient because they don’t capture “Read” actions.

• Audit Requirement: You must activate SAP Read Access Logging (RAL) for fields classified as “Sensitive” (Article 1), such as Health status, Biometrics, or Credit Data.
• The Evidence Loop: RAL logs the User ID, the Access Channel (Fiori vs. GUI), and the Data Subject ID. If SDAIA asks, “Who saw Citizen X’s health record on Tuesday?”, RAL provides the signed, timestamped answer in seconds.

3. Data Subject Rights (DSR) and SAP IRF

Under PDPL, residents have the Right to Access and the Right to Portability. You must provide a customer with a structured copy of their PII within 30 days.

• The Manual Nightmare: Searching for “User 123” across KNA1, ADR6, BSEG, and PA tables manually.
• The Surgical Fix: Use the SAP Information Retrieval Framework (IRF).
  • How it works: The DPO enters the “Data Subject Key.” The IRF then performs a cross-module “sweep” and generates a single, compliant JSON or PDF report of all stored PII across the entire landscape.

4. The Digital RoPA (SAP GRC & Data Custodian)

Article 31 requires you to maintain a Record of Processing Activities (RoPA) for at least 5 years. In 2026, SDAIA expects this to be digital and “always-on.”

• The Tool: SAP GRC (Governance, Risk, and Compliance).
• The Goal: GRC acts as the “Compliance Dashboard” for the DPO, mapping every SAP process (like Payroll or Vendor Management) to its legal basis, retention period, and residency status. It ensures that when you register on the National Data Governance Platform, your data is already mapped to the SDAIA-approved templates.

The “Right to Erasure” (SAP ILM & Data Destruction)

Under Article 15 of the PDPL, residents have the right to request the destruction of their personal data. However, for a Saudi enterprise, this creates a “Compliance Paradox”: SDAIA wants the data destroyed once the purpose ends, but ZATCA and the Saudi Labor Law require you to keep financial and employment records for up to 10 years.

1. Defining “End of Purpose” (EoP) in Saudi Law

You cannot satisfy Article 15 by simply hitting “Delete.” You must utilize SAP Information Lifecycle Management (ILM) to manage the transition from active use to legal retention.

• Residence Period: The time data remains active in your database for daily operations (e.g., 2 years after a contract ends).
• Retention Period: The time data is archived to satisfy ZATCA or Labor Law mandates (e.g., an additional 8 years).
• The Surgical Fix: Define specific ILM Residence and Retention Rules for each Saudi-specific data object (e.g., FI_ACCRECV for customers). This ensures that data is only destroyed when the longest legal mandate expires.

2. Simplified Blocking: The Middle Ground

When a data subject exercises their “Right to Erasure” but the legal retention period (10 years) hasn’t passed, you cannot destroy the data. Instead, you must Restrict Processing.

• The Technical Process: Use the SAP Business Partner (BP) Blocking tool.
• How it works: The system performs an EoP (End of Purpose) check. If the business is finished, the record is “Blocked.”
• The Result: A standard user searching for that customer will see a “Does Not Exist” error. Only a highly authorized user (like a Compliance Auditor) can unblock it for a formal investigation. This satisfies the PDPL requirement to restrict processing while honoring Saudi tax laws.

3. Managing the “Data Silo” Risk

PII doesn’t just live in master tables like KNA1. It “leaks” into technical silos. Under a 2026 audit, if SDAIA finds a deleted customer’s National ID sitting in an old background job log, you are still liable.

• The Surgical Fix: Your destruction strategy must include a “Landscape-Wide” sweep of:
  • Application Logs (BC-SRV-BAL): Configure automated deletion after 90 days.
  • Spool Files & IDocs: Ensure that technical “transports” of PII are purged after the communication is successful.
  • Change Documents (PCD): Scrub old values that were captured during updates.

4. The “Destruction Certificate”

Every time SAP ILM destroys data, it generates a Destruction Log.

• SDAIA Compliance: In 2026, these logs serve as your Certificate of Compliance for Article 15. They prove to auditors that your organization is proactively and legally managing the “death” of data.

The Path to “Sovereign SAP”

Compliance with ZATCA and PDPL in 2026 is no longer about isolated IT projects; it is about building a Sovereign SAP Architecture. By aligning your data residency with CST Class-B/C hosting, automating your 72-hour breach alerts, and mastering SAP ILM for precision destruction, you transform compliance from a legal risk into a competitive advantage.

In the Saudi “Vision 2030” economy, data sovereignty is the ultimate currency of trust.

This checklist is the “DPO’s Technical Bible” for a 2026 SDAIA inspection. It bridges the gap between legal requirements and the actual SAP technical objects that an auditor will ask to see.

SAP-PDPL Quick-Audit Checklist (2026 Edition)

1. Core PII Inventory (The “What”)

SDAIA auditors will start by asking for your Data Map. You must prove you know exactly which tables store Saudi resident PII.

SAP-PDPL Quick-Audit Checklist (2026 Edition)

1. Core PII Inventory (The “What”)

SDAIA auditors will start by asking for your Data Map. You must prove you know exactly which tables store Saudi resident PII.

2. RAL Configuration Blueprint (The “How”)

When the auditor asks, “How do you know who viewed a National ID?”, you must show your Read Access Logging (RAL) configuration.

• Transaction Code: SRALMANAGER
• Logging Purpose: Define a purpose named PDPL_SDAIA_COMPLIANCE.
• Audit-Ready Configuration:
  1. Channel: Configure for Web Dynpro (Fiori) and Dynpro (GUI).
  2. Field Grouping: Group fields like PERID and IBAN into a “Sensitive Data” log group.
  3. Log Context: Ensure the log captures the Subject ID (so you know whose data was accessed, not just that data was accessed).
  4. Thresholds: Set ETD (Enterprise Threat Detection) to flag any user reading >100 records from PA0002 in a single session.

3. The 3-Stage Audit Defense (The “Proof”)

Keep these three “Artifacts” ready in a dedicated compliance folder for the auditor.

A. The Prevention Evidence (UI Masking)

• Check: Open transaction BP (Business Partner) or PA20 (Display Employee).
• SDAIA Expectation: The National ID and Bank Account should be masked by default (e.g., XXXXX1234).
• Proof: Show the Technical Trace of the masking logic applied to the STRAS or PERID fields.

B. The Detection Evidence (72-Hour Breach Log)

• Check: Show a sample “Mock Breach” report.
• SDAIA Expectation: Can you produce a list of affected Data Subjects within 24 hours of a detected anomaly?
• Proof: A PDF export from SAP Enterprise Threat Detection (ETD) or your SIEM, showing an alert triggered by unauthorized access to sensitive tables.

C. The Destruction Evidence (ILM Logs)

• Check: Show a “Destruction Certificate” for a customer whose contract ended in 2015.
• SDAIA Expectation: Why is this PII still in the database? (If it’s there, you’re in breach).
• Proof: Run the ILM Destruction Log report. It should show that the PII was wiped, but the financial totals remain for ZATCA/Audit integrity.

4. Mandatory 2026 Admin Tasks

• [ ] DPO Registration: Ensure your DPO is officially registered on the National Data Governance Platform (DGP).
• [ ] RoPA Export: Generate a “Record of Processing Activities” from SAP GRC showing the legal basis (Contractual/Legal Obligation) for every PII-touching process.
• [ ] Non-Prod Scrambling: Provide a log from your last System Refresh (using TDMS or Data Secure) proving that PII was scrambled before it hit the QA environment.