Blog Overview
A portal brings identity, documents, and invoices into one place. Here are ten compliance areas, the engineering decisions behind them, and a pre-launch checklist.
A client portal is not just a polished interface. It is where identity, documents, invoices, tickets, and sign-in history come together. A mistake in permissions, backups, or retention becomes a data incident, not a passing technical glitch.
The Personal Data Protection Law has been fully enforceable since September 2024. On 6 October 2026, SDAIA published draft amendments to the Implementing Regulation, including an explicit move toward storing personal data inside the Kingdom and broadening breach notification. That means hosting and retention must be decided before the first line of code.
Why a portal concentrates personal data
One system can bring together data that rarely sits in one place: name, identity number, address, mobile number, uploaded documents, invoice history, support tickets, and sign-in logs. Each type has a different purpose, a different retention period, and a different access level.
That variety is why classification matters. Do not start with “are we compliant?” Start with “what data do we process, why, who sees it, and when do we delete it?”.
Five questions before any code
Who is the controller and who is the processor? The entity that sets the purpose and method is the controller. A vendor processing on its behalf is the processor. That distinction decides who carries the obligation and who signs the agreement.
Where is the data map? One table: data type, source, purpose, storing system, who can access it, and retention period. Without a map, every later answer is a guess.
What is the lawful basis for each purpose? Consent, contract performance, or a legal obligation. “Because we need it” is not an answer. The basis must be specific to each purpose, not to the whole system.
How long do we keep the data, and why? Retention is not “until we need it”. It is a written decision, with a deletion or archive function, and a test that deletion works.
Does the data leave the Kingdom? Hosting, backups, support, analytics, email, and any AI provider are all possible paths. Map them before asking a vendor whether it is “compliant”.
The compliance checklist: ten areas
This is not an exhaustive legal checklist, but it covers what we see repeatedly in client portals. Each area has a direct engineering consequence; it is not just a document saved in a folder.
1. Inventory and classify. Start with a data map covering every field, its source, and its purpose. Mark sensitive data — identity, health, financial — because it raises the control level and triggers an impact assessment.
2. Lawful basis and notice. Every purpose needs a clear basis and a privacy notice in plain language, in Arabic and English, explaining what you collect, why, and who you disclose it to.
3. Data minimisation. Do not collect a field because “we might need it later”. Every extra field increases your liability without increasing your value. Review forms before launch, not after.
4. Permissions and access. Role- and record-level permissions, checked on the server, following least privilege. An employee sees only what the job requires, and the audit log proves who saw what.
5. Encryption and key management. TLS in transit, encryption at rest, and keys that never live in the repository. Backups must be encrypted too.
6. Retention and deletion. A defined period for each data type, a deletion or archive function, and a log proving it ran. Keep what the law requires, not everything forever.
7. Incident notification. A written plan: who detects, who classifies, who notifies, and when. Notify SDAIA within 72 hours where harm is met, and notify individuals without undue delay when required.
8. Individual rights. A clear path for access, correction, deletion, and consent withdrawal. A request needs identity verification, a handling deadline, and a log. Do not make it depend on one employee’s inbox.
9. Cross-border transfer and vendors. A transfer map, a lawful basis, contractual safeguards, and a data processing agreement with every vendor. A vendor storing a backup in another region is a transfer path, even if the contract does not say so.
10. Governance and training. A data protection officer where the conditions apply, a processing record, periodic access reviews, and team training. Compliance is not a project that ends; it is an operation.
How compliance becomes an engineering decision
Compliance is not a layer added on top of the system. It shows up in the schema, the permissions, the deletion job, and the backup. This table translates each requirement into a decision you can review in code.
| Requirement | Engineering decision | How to verify |
|---|---|---|
| Data minimisation | Remove unnecessary fields from the form and database | Review every field: who uses it and why |
| Retention | A scheduled deletion or archive job | A test run and an execution log |
| Permissions | RBAC + server-side checks + audit log | Test two accounts against one document |
| Encryption | TLS, storage encryption, keys outside the code | Inspect settings and backups |
| Notification | Alerts, logs, and a response runbook | Simulate an incident and measure the time |
| Individual rights | Export, correction, deletion, consent withdrawal | A test request from a user account |
| Cross-border transfer | Choose the hosting region and keep a transfer log | A data map that includes vendors |
| Vendors | A processing agreement and audit right | A vendor list updated annually |
The October 2026 draft: what may change
On 6 October 2026, SDAIA published draft amendments to the Implementing Regulation for public consultation until 5 November 2026. They are a draft, not binding law. But they signal the direction of regulation and are worth reading before a hosting decision.
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
Storage inside the Kingdom. The proposed Article 23 says the controller shall store personal data within the Kingdom, while permitting transfers abroad under the law. The meaning of “store” is still under discussion.
Broader breach notification. The draft removes the harm test for notifying SDAIA, so any breach or unauthorised access would be notifiable within 72 hours.
Registration in the National Register of Controllers. The draft makes registration mandatory in defined cases, including any transfer or disclosure outside the Kingdom.
Expanded data protection officer rules. Clearer appointment criteria, documented details, and updates when the person changes.
If adopted, the amendments take effect 60 days after publication in the Official Gazette. That leaves a short gap between publication and enforcement, and means the hosting decision must be changeable rather than built on one assumption.
Recurring mistakes in client portals
- A shared account used by several employees, so nobody knows who did what.
- Documents in a public folder or behind a direct link with no permission check.
- Sending documents as email attachments instead of a short-lived signed link.
- Permissions checked only in the interface, bypassable with a direct request.
- An audit log that can be edited or deleted.
- Indefinite retention of everything “because deletion is risky”.
- A backup in another region that is absent from the data map.
- No data processing agreement with the hosting or support provider.
- No incident response plan and no named decision-maker.
- One penetration test before launch, then no review after changes.
Pre-launch checklist
This list is not a substitute for legal review, but it is the minimum the team should answer before opening the portal to real clients.
- An up-to-date data map covering every field, its source, and its purpose.
- A privacy notice in Arabic and English, in plain language.
- A defined lawful basis for each processing purpose.
- Server-side permissions, least privilege, and a pre-launch review.
- Multi-factor authentication for employee accounts.
- Encryption in transit and at rest, with keys outside the repository.
- An immutable audit log, with its own retention period.
- A retention and deletion policy, with a scheduled job that actually runs.
- A path for access, correction, deletion, and consent withdrawal requests.
- An incident response plan with the 72-hour window and a named owner.
- A data processing agreement with every vendor that touches personal data.
- A cross-border transfer map, including backups and support.
- Encrypted backups, and a restore test that was actually performed.
- An access review after launch, then on a schedule.
- Team training on escalation and on keeping data inside approved channels.
Who is responsible for what
Confusing the roles is a common cause of a gap that starts with “who approves this?”. The table shows the minimum split of responsibility in a portal project.
| Role | Responsibility | What it needs from the team |
|---|---|---|
| Controller (your business) | Set purpose, basis, and retention | Data map, notice, processing record |
| Processor (vendor) | Execute on instructions, securely | Agreement, logs, breach notice |
| Data protection officer | Monitor, coordinate, notify | Access, time, escalation channel |
| Engineering | Permissions, encryption, logs | Written requirements and acceptance tests |
| Operations | Monitoring and response | Incident runbook and regular drills |
The bottom line
Compliance is not a file uploaded before an audit. It is a set of small decisions: a field you do not collect, a permission you do not grant, a log you do not allow to be edited, a backup whose location you know. A portal built with those decisions is cheaper than one repaired after an incident.
Sources
- Personal Data Protection Law — rights, obligations, and penalties.
- Implementing Regulation — 72-hour notification and cross-border transfer.
- Personal data breach guide — notification and containment steps.
- Clyde & Co: October 2026 draft amendments — a summary of the proposed changes.
- SDAIA public consultation — the source for drafts and consultations.
