Saudi PDPL for Contractors: What Systems Must Handle

In short, any data in your operations that identifies a person — a subscriber’s name, mobile number and address, site photos, technicians’ phone numbers and field locations — is governed by binding rules. You need to know where that data sits, who can see it, and how you would handle a request from the person concerned or a breach.

This guide is for operations and IT managers at electrical contractors. It covers the law and its dates, where personal data lives in the work order journey, data subject rights, breach response, practical controls, questions for your vendor and what ELX provides.

Saudi PDPL for contractors: what is the law, and when did it become binding?

The Personal Data Protection Law (PDPL) is Saudi Arabia’s law on collecting, processing and protecting personal data. It was approved by Royal Decree No. M/19 dated 9/2/1443H and came into force on 14 September 2023, followed by a one-year grace period that ended on 14 September 2024. Full compliance has been expected since then.

Council of Ministers Decision No. 98 made the Saudi Data and Artificial Intelligence Authority (SDAIA) the competent authority for two years, during which a transfer of supervision to the National Data Management Office was to be considered. DLA Piper describes SDAIA as the current regulator, so watch SDAIA’s official site for any change. The law covers processing of personal data such as names, ID numbers, contact details and images, and applies both to processing inside the Kingdom and to processing of residents’ data by parties outside it.

It is not a law for banks and telecoms alone: a contractor holding subscriber mobile numbers and staff accounts processes personal data every day. Whether you act as the controller of a given dataset, or as a processor handling it for the utility under contract, is for your legal adviser to confirm, because it defines what you owe.

Where does personal data live in an electricity contractor’s operations?

A work order looks like a technical record about transformers, excavations and meters, yet it carries personal data from registration onward: the site survey adds coordinates, execution and quality add photos and attachments, and alerts reach staff phone numbers through messaging apps.

Data also moves in and out. It often arrives in Excel files, and it leaves through the full work order report as a PDF, bundled ZIP downloads of attachments, emails that include the site address and messaging-app alerts. Each exit needs a clear owner and a clear permission.

Which data subject rights must you respect?

The PDPL gives every data subject — subscriber or technician — six core rights. The hard part is acting on them when one person’s data is spread across work orders, attachments and messages.

Destruction requests and soft deletion

Many operations systems use soft deletion: the record leaves the lists but stays in the database, traceable. That helps with audits and disputes, but it is not destruction.

Agree a written procedure with your legal adviser and your vendor: how the requester’s identity is checked, who decides, whether other obligations require keeping certain records, how the data is actually destroyed, and how that is documented.

What should you do after a data breach?

Article 20 of the law requires a controller to notify the competent authority on learning of a leak of, damage to or unlawful access to personal data, and to notify the data subject where the incident could harm their data or conflict with their rights or interests, as the regulations specify. According to DLA Piper’s summary, where SDAIA must be notified, the report goes through the National Data Governance Platform within 72 hours of becoming aware of the breach, and affected individuals who must be told are to be told without undue delay.

On penalties, Article 36 provides for a warning or a fine of up to SAR 5 million for administrative violations, and the fine may be doubled for repeat violations. The law’s text and its implementing regulations, as last published by SDAIA, remain the reference.

Seventy-two hours is short if you start from scratch, and a contractor breach can be mundane: a spreadsheet of subscriber numbers sent to the wrong group chat, a leaver’s account still active, or a lost phone full of site photos.

1. Contain it at once

   Suspend the affected account, withdraw access, and ask recipients to delete anything sent in error.

2. Establish what leaked

   Which data, whose, via which channel and since when — system logs and message logs help here.

3. Preserve the evidence

   Keep a copy of the relevant logs before anything changes, and record the timeline.

4. Report within the window

   Decide with your legal adviser whether the incident must be reported to SDAIA; if it must, report through the National Data Governance Platform within 72 hours of becoming aware.

5. Decide on telling those affected

   If the breach could harm the individuals concerned or affect their rights, agree with your legal adviser how to inform them without delay, and what to say.

6. Fix the cause

   Review the permissions, accounts and export paths involved, and update the procedure.

Which practical controls reduce risk inside your system?

Much of this risk starts with access broader than the job requires. These controls, built on least privilege and need-to-know, address it inside the operations system itself:

• Give each role only the screens and actions it needs; keep viewing apart from editing, deleting and importing.
• Scope every user to their branches and districts, so no supervisor sees another branch’s subscribers.
• Let only the assigned user open a work order, and keep “show others’ data” for supervisors.
• Use named accounts, never shared logins; reassign leavers’ orders, then close their accounts as soon as they leave.
• Restrict report screens and bundled attachment downloads to the people who need them.
• Review the audit log regularly, especially deletions and manual stage changes.
• Keep personal data in alerts to a minimum, and switch off notifications nobody needs.
• Define the purpose of field location tracking and who may see it, and tell technicians.
• Document how destruction requests are handled; a soft delete is not destruction.

For building the role matrix, see our guide to user permissions and audit trail; for the wider technical picture, see our guide to the NCA Essential Cybersecurity Controls.

Which questions should you ask your system vendor?

Once a system holds your subscribers’ and employees’ data, its vendor joins your data protection chain. Get written answers, and put the important ones in the contract:

1. Where is our data hosted and processed, and is any of it processed outside the Kingdom?
2. How is our company’s data kept separate from other customers’ data?
3. Who at the vendor can access our data, for what purpose, and is that access logged?
4. What does the audit log record, and what does it not record? Are views and downloads logged?
5. Is deletion soft or permanent, and how would a verified destruction request be carried out, backups included?
6. Which data leaves the system in alerts, through which channels and third parties, and what do those third parties keep?
7. How are field-team locations stored, who can see them, and for how long are they kept?
8. How quickly would you tell us about an incident affecting our data?
9. How do we gather everything held on one person or one work order when an access request arrives?

A straight “we don’t offer that” beats a vague promise of compliance. Compliance remains your organisation’s obligation; a vendor supports it with controls you can verify.

How can ELX’s access controls help?

ELX is a bilingual (Arabic/English) cloud (SaaS) service hosted and operated by Matrix. It runs in the browser with no servers needed on your side, and it is built for electricity-network contractors in Saudi Arabia to carry each utility work order from registration to archive. That makes Matrix part of your data protection chain, so every question in the previous section is one you can put to Matrix. ELX holds no PDPL compliance certification and makes no compliance claim, but it provides access and traceability controls that support your own policies:

• Permission matrix: in the permissions and settings module, an administrator sets each user’s rights per screen — show, add, update, delete, change status, show others’ data, relay and Excel import — and users see only permitted screens.
• Scoping: users are linked to branches, cities and districts, so their lists and dashboard stay within scope; administrators see everything.
• Order ownership: only the assignee, or someone holding “show others’ data”, can open a work order.
• Audit log: adds, edits, deletes and status changes in master data and key operational records are logged with the user, date and a record snapshot, with full per-record history; manual stage changes are logged separately with a mandatory note. It is a log of changes: if your policy also requires tracking who viewed or downloaded data, raise it in the demo.
• Controlled deletion: work order management has a deletion screen with its own permission, and work orders, stock documents and material estimates are soft-deleted and stay traceable — which keeps the trail but does not replace a procedure for destruction requests.
• Company isolation: each company runs its own web instance, with a separate database per company; our security and data governance page sums up all of these controls.
• Accounts: each user signs in with their own user code and password, linked to their branches, districts and screens; administrators can reset passwords, and forgotten passwords are reset with a code sent by email.
• Alerts: each user’s Telegram notifications can be switched on or off, administrators can turn the WhatsApp channel (sent through an external messaging gateway) on or off, and messages are logged with the recipient number and whether sending succeeded or failed (see instant notifications).
• Field work: ELX provides a mobile-ready API for field apps. Users sign in with their username and password and receive a signed token, and they see only the screens and districts their permissions allow. The API also accepts GPS points sent by the app and updates the user’s last known location — data that needs a stated purpose and limited access.
• Locating records: the unified attachments screen gathers a work order’s files from every stage, with each file’s source, and downloads them as one ZIP; the full work order report shows every stage and downloads as a PDF — useful when a request arrives.

For the field side, read our guide to field engineer mobile apps. To see these controls mapped to your team’s roles, and to ask about data location, backups and how long location points are kept, request a demo.