Why the ERP Is the System to Protect First
An ERP holds more of a company's sensitive information in one place than any other system. Employee files with national ID and iqama numbers, salaries and bank accounts. Customer records with contact details and credit limits. Supplier bank details. Every invoice, payment and journal entry. Purchase prices and margins that competitors would like to see. If an attacker or a careless insider gets broad access to the ERP, they get the company.
In Saudi Arabia, two developments have made ERP security a board-level subject. The Personal Data Protection Law (PDPL) came into force in September 2023, with enforcement starting after a one-year grace period in September 2024, so personal data held in HR, payroll and customer modules now carries legal obligations and penalties. And the National Cybersecurity Authority (NCA) has built a body of controls, including the Essential Cybersecurity Controls (now ECC-2:2024) and the Cloud Cybersecurity Controls (CCC-2:2024), that set the benchmark for what good practice looks like.
This guide explains what the PDPL requires in terms that matter to ERP owners, maps those requirements to concrete system controls, and gives a practical checklist that finance, HR and IT can work through together.
PDPL Essentials for ERP Owners
The PDPL applies to processing of personal data relating to individuals in the Kingdom, including processing by entities outside the Kingdom. The Saudi Data and Artificial Intelligence Authority (SDAIA) is the competent authority. For an ERP, the points below are the ones that translate directly into configuration and procedure.
Lawful basis and purpose
Personal data must be collected for a specific, clear purpose and processed only as needed for that purpose. In practice, this means asking why each personal field exists in your ERP. Does the sales module really need a customer's national ID, or only a commercial registration number for business customers?
Data subject rights
Individuals have rights to be informed, to access their data, to request correction and, in certain cases, destruction. Your ERP should let authorised staff find every record about a person, export it, correct it and, where retention rules allow, delete or anonymise it.
Breach notification
Where notification is required, the controller must notify SDAIA through the National Data Governance Portal within 72 hours of becoming aware of a breach, and notify affected individuals without undue delay where required. You cannot meet a 72-hour clock if you cannot tell what was accessed, so logging becomes a legal necessity, not just a technical one.
Transfers outside the Kingdom
Transfers of personal data abroad are allowed under conditions, including adequacy decisions or appropriate safeguards such as standard contractual clauses, and a transfer risk assessment is required in some cases. This affects where your ERP and its backups are hosted and who can reach them for support.
Data protection officer
SDAIA rules require certain controllers to appoint a data protection officer, including public entities processing personal data at large scale, controllers whose core activities involve regular, large-scale monitoring of individuals, and controllers whose core activities involve sensitive data.
Penalties
Disclosing or publishing sensitive data in violation of the law, with intent to harm the individual or to gain a personal benefit, can lead to up to two years' imprisonment, a fine of up to SAR 3 million, or both. Other violations can bring a warning or a fine of up to SAR 5 million, and a court may double fines for repeat offenders. Individuals harmed may also claim compensation.
What Personal Data Sits in a Typical ERP
| Module | Typical personal data | Sensitivity |
|---|---|---|
| HR and payroll | Name, ID or iqama, date of birth, nationality, salary, bank account, family members, medical leave records | High; health data is sensitive data under the PDPL |
| Recruitment | CVs, certificates, references | Medium to high |
| Sales and CRM | Contact names, phone numbers, emails, delivery addresses, sometimes ID for individual customers | Medium |
| Point of sale | Loyalty members' phone numbers and purchase history | Medium |
| Purchasing | Sole-trader suppliers' personal and bank details | Medium |
| Property management | Tenants' IDs, contracts, payment records | Medium to high |
Building this table for your own system is the first real compliance task. Many companies discover personal data in places nobody expected: free-text notes, attachments, exported spreadsheets saved on shared drives.
Seven Protection Layers for an ERP
1. Role-based access and least privilege
Most ERP data leaks are not sophisticated hacks. They come from users who can see more than their job requires. Define roles by job, not by person, and give each role only the screens, actions and data it needs. A branch storekeeper does not need to see payroll. A payroll accountant does not need to approve supplier payments. Review role membership at least quarterly, and remove access on the day someone leaves or changes job.
2. Segregation of duties
Segregation of duties is both a fraud control and a privacy control. The same person should not create a supplier, change its bank account and approve payment to it. Configure multi-level approvals so sensitive changes, such as bank details for employees or suppliers, require a second person. Our article on accounting challenges discusses the internal control side.
3. Strong authentication
Require strong passwords and multi-factor authentication, at least for administrators, finance approvers and anyone with access to HR data. Set session timeouts so an unattended screen in a branch does not stay open all afternoon. Block shared accounts; every action must trace to one person.
4. Encryption in transit and at rest
All traffic between users and the ERP should be encrypted, and so should the database and backups. In cloud ERP the provider usually handles this; ask how keys are managed. On-premise, it is your responsibility, including backups stored on external disks or tapes, which are a common weak point.
5. Audit trails
Log who viewed, created, changed, exported or deleted sensitive records, when and from where. Logs must be protected from alteration, including by administrators. Without good logs you cannot investigate an incident, cannot meet the 72-hour notification requirement with confidence and cannot show an auditor that controls work.
6. Data minimisation and masking
Do not collect what you do not need, and do not show what users do not need to see. Mask fields such as ID and bank account numbers so most users see only the last digits. Restrict bulk exports of personal data to named roles, because a single spreadsheet export can undo every other control.
7. Backup, recovery and incident response
Ransomware turns availability into a security issue. Keep backups that attackers cannot reach from the production network, test full restores at least twice a year, and write an incident response plan that names who decides, who contacts SDAIA if needed, who talks to staff and customers, and how the ERP is restored.
Mapping Requirements to Controls
| Requirement | ERP control | Owner |
|---|---|---|
| Purpose limitation and minimisation | Field review, removal of unnecessary personal fields, masking | Data owner per module with compliance |
| Access rights of individuals | Search and export of all records about a person | HR and customer service, supported by IT |
| Security of processing | Roles, MFA, encryption, approvals | IT and system administrator |
| Breach notification within 72 hours | Audit logs, alerts on unusual exports or logins, incident plan | IT security with management |
| Cross-border transfer conditions | Hosting location, support access rules, contract clauses | Procurement, legal and IT |
| Retention | Retention rules per record type, archiving and deletion | Finance and HR with legal |
Retention: Where Privacy Meets Tax and Commercial Law
The PDPL expects data not to be kept longer than needed, but other laws require you to keep records for years. VAT rules require most records to be retained for at least six years, with longer periods for certain capital assets and real estate, and the Commercial Books Law has required commercial books to be kept for ten years. Employment records are also needed for end-of-service calculations and disputes.
The answer is a written retention schedule by record type. Keep what the law requires for as long as it requires, restrict access to old records to a small group, and delete or anonymise personal data once every retention period has passed. An ERP that can archive closed years while keeping them readable makes this practical.
A Hypothetical Incident, Walked Through
At 4 p.m. on a Thursday, an alert shows that a sales coordinator's account exported the full customer list with phone numbers, followed by a login from an unfamiliar location an hour later. The employee says they did not perform the second login.
- Contain: disable the account, end its sessions and reset credentials. Check whether the export file was emailed or uploaded.
- Assess: use the audit trail to list every record viewed or exported by the account in the past 30 days.
- Decide on notification: management, with legal advice, decides whether the incident requires notification to SDAIA and to customers, keeping the 72-hour window in mind.
- Fix the cause: in this example, the role allowed bulk export without approval and MFA was not enforced for sales users. Both are corrected.
- Document: record facts, decisions and timings. This record is what you will show if the regulator asks.
The steps are only possible if the ERP logged the export, showed the login location and allowed the account to be disabled at once. That is the practical case for the controls above.
Cloud or On-Premise: Who Does What
In a SaaS ERP, the provider normally handles physical security, infrastructure patching, encryption at rest and backups. You remain responsible for user accounts, roles, approvals, what data you enter and who can export it. On-premise, everything is yours. Neither model is secure by default. Ask a cloud provider where data and backups are hosted and how support staff access customer environments; ask an on-premise team when the last restore test happened. For the wider comparison, see cloud versus on-premise ERP.
Integrations and Third Parties
An ERP rarely works alone. It exchanges data with banks for salary files, with ZATCA for e-invoices, with e-commerce stores, delivery companies, recruitment agencies and external payroll or audit firms. Each connection is a door. Three habits keep those doors under control:
- One integration, one credential: give every API connection its own key with only the permissions it needs, so a leaked key exposes one flow, not the whole database. Rotate keys when a vendor relationship ends.
- Contracts that match the data: when an external firm processes personal data on your behalf, such as an outsourced payroll bureau, the agreement should cover purpose, security measures, breach reporting to you and deletion at the end of the engagement.
- Files are data too: salary transfer files and customer exports sent by email sit outside every ERP control. Prefer direct integrations, and where files are unavoidable, protect them and delete them after use.
A 30-Day Starter Checklist
- List every module and the personal data it holds, including attachments and notes.
- Remove shared accounts and disable accounts of people who have left.
- Turn on MFA for administrators, approvers and HR users.
- Restrict bulk export of personal data to named roles.
- Require a second approval for changes to bank details.
- Confirm audit logging is active and protected.
- Test a full restore of the ERP from backup.
- Write a one-page incident plan with names and phone numbers.
- Draft a retention schedule for HR, customer and financial records.
How Tranquil Supports This Work
Tranquil is a cloud ERP whose HR, payroll, sales, purchasing and accounting modules sit in one system, so personal data is held in one place rather than spread across spreadsheets. The team can configure screens, reports and multi-level approvals, which helps you apply segregation of duties to sensitive changes. Employees can view their own information through employee self-service instead of requesting printed documents, and HR and payroll data stays within the system's access controls. Discuss your security requirements with the team before go-live so roles are designed in, not added later.
Frequently Asked Questions
Does the PDPL apply to employee data in our ERP?
Yes. Employee data is personal data, and health information such as sick leave details is sensitive data. HR and payroll modules are usually the most sensitive part of an ERP.
Who must we notify after a data breach?
Where notification is required, the controller notifies SDAIA within 72 hours of becoming aware of the breach and notifies affected individuals without undue delay where required. Sector regulators may impose additional reporting duties.
Do the NCA's Essential Cybersecurity Controls apply to every private company?
Their scope covers government entities, their companies, and private organisations that own, operate or host critical national infrastructure. Other companies are not formally in scope but often use the controls as a benchmark.
Can we host our ERP outside Saudi Arabia?
For private companies it can be possible, but personal data transfers abroad must meet PDPL conditions, and sector rules may be stricter. Government data may not be hosted outside the Kingdom.
What is the single most effective ERP security measure?
Tight, regularly reviewed user roles with multi-factor authentication. Most leaks come from excessive access rather than advanced attacks. Contact the Tranquil team to review role design for your company.