Oman’s PDPL Is Now Enforceable: Requirements, Risks and a Practical 2026 Compliance Roadmap
TL;DR
- Oman’s extended PDPL transition period ended on 5 February 2026, meaning affected organizations should now be operating their compliance controls rather than treating the law as a future project.
- Controllers and processors may need documented consent, privacy notices, processing records, a designated data protection officer, rights-request procedures, security controls and cross-border transfer assessments.
- Processing certain sensitive categories requires a Ministry permit, while qualifying personal-data breaches may trigger notification to the Ministry and affected individuals within 72 hours.
Oman’s Personal Data Protection Law is no longer in a transition phase.
The framework consists principally of the Personal Data Protection Law issued under Royal Decree No. 6/2022 and its Executive Regulation issued under Ministerial Decision No. 34/2024. The original adjustment period under the Regulation was later extended, with the extended transition period ending on 5 February 2026.
This matters because Oman’s requirements go beyond publishing a privacy notice.
Organizations may need to prove that they:
- know what personal data they process;
- have obtained the required consent;
- can respond to individuals within the prescribed period;
- have designated a qualified privacy officer;
- have assessed overseas data transfers;
- have applied for permits before processing specified data categories;
- can detect, assess and report relevant breaches within 72 hours; and
- maintain evidence showing that these activities operate in practice.
This article provides general compliance information and is not legal advice. Applicability, permit requirements and final interpretations should be confirmed with qualified Omani legal counsel and, where necessary, the Ministry of Transport, Communications and Information Technology.
Table of contents
- What changed in February 2026?
- Who is subject to Oman’s PDPL?
- How foreign SaaS and cloud companies may be affected
- The main PDPL compliance areas
- Consent and lawful processing
- Privacy notices and transparency
- Data-subject rights and the 45-day response period
- The data protection officer requirement
- Sensitive-data permits
- Children’s data
- Processing records and retention
- External privacy audits
- Personal-data breach notification
- Cross-border transfers
- Marketing communications
- Penalties and enforcement exposure
- A practical 90-day compliance roadmap
- Evidence organizations should retain
- Common compliance mistakes
- Practical checklist
- Frequently asked questions
What changed in February 2026?
The PDPL itself was issued in February 2022, while the Executive Regulation was issued in January 2024 and took effect following publication in February 2024.
The Executive Regulation originally required affected parties to adjust their practices within one year. That compliance period was extended by Ministerial Decision No. 6/2025, moving the end of the transition period to 5 February 2026.
The practical distinction is important:
Before February 2026, an organization could describe its work as a compliance implementation project.
After the transition period, the organization should be able to demonstrate that applicable controls are already operating.
The Ministry’s Personal Data Protection Department states that it is responsible for receiving complaints and breach reports, deciding permit applications and carrying out judicial enforcement activities in coordination with relevant authorities. The Ministry has also made complaint, breach-reporting, permit and self-assessment channels available.
Who is subject to Oman’s PDPL?
The Ministry’s current guidance states that every company, institution or other entity processing personal data is subject to the Law and Executive Regulation unless the processing falls within an exemption under Article 3.
Article 3 contains several exclusions, including processing connected with:
- national security or public interest;
- legal obligations imposed by law, court judgment or decision;
- vital interests of the data subject;
- crime detection or prevention based on a formal request;
- performance of a contract with the data subject;
- personal or family activity;
- specified research activities; and
- data lawfully available to the public.
State administrative units and public legal entities are excluded from the PDPL in relation to their legally prescribed functions, but government entities are subject to a separate personal-data protection policy.
Do not treat every Article 3 exclusion as a general GDPR-style lawful basis
Organizations should be careful when interpreting the exclusions.
The structure of Oman’s PDPL differs from the GDPR’s familiar list of lawful bases. The law generally requires explicit consent, while Article 3 identifies processing circumstances to which the PDPL does not apply.
It remains prudent to obtain local legal interpretation before relying on an Article 3 exclusion as the basis for a major processing activity, particularly where the activity involves profiling, marketing, employee monitoring, sensitive information or data transfers.
How foreign SaaS and cloud companies may be affected
Oman’s PDPL does not expressly contain a broad extraterritorial rule equivalent to Article 3 of the GDPR.
Current commentary from practitioners in Oman notes that no regulator guidance has clearly established that a foreign organization becomes directly subject solely because it offers services to, or monitors, people in Oman.
That does not mean foreign technology providers can ignore the PDPL.
A foreign company may still be affected where it:
- carries out processing operations in Oman;
- has an Omani establishment;
- processes data on behalf of an Omani controller;
- receives personal data transferred from Oman;
- hosts sensitive Omani data overseas;
- supports an Omani customer’s rights or breach obligations; or
- accepts contractual obligations requiring PDPL compliance.
An Omani customer may request evidence concerning:
- hosting and backup locations;
- subprocessors;
- administrator access;
- data deletion;
- encryption;
- breach-notification timing;
- data-subject request support;
- transfer protections; and
- security assurance reports.
A foreign vendor should therefore be able to provide a clear data-flow and subprocessor explanation rather than relying only on a general ISO 27001 certificate or global privacy policy.
The main Oman PDPL compliance areas
The main Oman PDPL compliance areas
Compliance area
Main operational requirement
Typical evidence
Identify personal data, purposes, recipients, locations and access.
Data inventory, processing record, data-flow map
Obtain clear and provable explicit consent where required.
Consent wording, system logs, withdrawal records
Provide an accessible personal-data protection policy before processing.
Arabic/English privacy notice, version history
Receive, verify, track and answer requests within 45 days.
Request form, ticket log, response templates
Designate a qualified privacy officer and publish contact details.
Appointment record, role description, contact channel
Obtain a Ministry permit before processing Article 5 categories.
Permit application, approval, renewal tracker
Obtain guardian consent and apply minimization safeguards.
Age/guardian workflow, child-friendly notice
Protect confidentiality, restoration and control effectiveness.
Access controls, testing, backup and recovery evidence
Assess and report qualifying incidents within 72 hours.
Incident plan, decision record, notification form
Obtain consent where required and assess overseas protection.
Transfer inventory, risk assessment, contracts
Obtain written consent and stop messages immediately on opt-out.
Marketing-consent log, suppression list
Maintain and update processing records.
Processing register, audit evidence, policy approvals
The central compliance challenge is evidence.
A business may have a privacy notice and security policy but still be unable to show:
- which systems rely on consent;
- whether consent can be withdrawn;
- who receives rights requests;
- whether the DPO has authority;
- which data is stored abroad;
- whether a Ministry permit was required; or
- how a breach is escalated within the first few hours.
Consent and lawful processing
Article 10 of the PDPL states that personal data must be processed transparently, honestly and with respect for human dignity, after obtaining the data subject’s explicit consent.
The controller must be able to prove the data subject’s written consent. The Executive Regulation further provides that consent may be written, electronic or collected through another method determined by the controller, provided it is clear and given by a competent person without coercion. (Decree)
What a defensible consent mechanism should show
A useful consent record should allow the organization to demonstrate:
- who consented;
- when consent was obtained;
- which notice and wording were displayed;
- the processing purpose;
- which data categories were covered;
- whether marketing or overseas transfer was included;
- how consent was communicated;
- whether consent was later withdrawn; and
- when processing linked to the withdrawn consent stopped.
Avoid bundled consent
A single checkbox covering account creation, analytics, advertising, third-party sharing, overseas transfers and promotional messages creates avoidable ambiguity.
Where purposes are meaningfully different, separate choices provide clearer evidence and allow individuals to withdraw one consent without unnecessarily terminating the entire service.
Review existing customer and employee forms
Common risk areas include:
- website registration forms;
- mobile application permissions;
- recruitment forms;
- employee onboarding documents;
- loyalty programs;
- CCTV notices;
- health or insurance forms;
- biometric attendance systems;
- recorded customer-service calls; and
- lead-generation forms.
The operational question is not merely whether a document contains the word “consent.” The organization should determine whether the consent is sufficiently clear, specific, provable and connected to the actual processing activity.
Privacy notices and transparency
The Executive Regulation requires controllers or processors, as applicable, to place a personal-data protection policy in a visible location that allows the individual to review it before processing begins.
At minimum, the policy should explain how individuals can exercise their rights. Ministry guidance also identifies transparency concerning the entity, collection reasons, processing purposes and available rights as a core obligation.
What an Oman-facing privacy notice should include
A practical notice should address:
- the identity and contact details of the controller;
- the DPO’s name and contact details where required;
- the personal-data categories collected;
- the purpose of each processing activity;
- how consent is collected;
- relevant Article 3 exclusions, where relied upon;
- data sources;
- processors and recipients;
- overseas transfers and destinations;
- retention criteria;
- individual rights;
- how to withdraw consent;
- how to submit a complaint;
- marketing preferences;
- security and breach information at an appropriate level; and
- the notice’s effective date and version.
Arabic and English notices
The law does not appear to establish a universal rule that every private-sector privacy notice must be bilingual.
However, where services are offered to Arabic-speaking individuals, an Arabic notice will often be necessary to demonstrate that information and consent wording were clear and understandable.
For international businesses, a controlled bilingual notice is usually safer than relying on English alone. The Arabic text should be professionally reviewed rather than generated through unverified machine translation.
Data-subject rights and the 45-day response period
The PDPL gives individuals rights to:
- withdraw consent;
- request correction, updating or blocking;
- obtain a copy of their data;
- transfer data to another controller;
- request erasure; and
- receive notification of certain personal-data breaches.
The Executive Regulation allows individuals to submit written requests without charge and requires controllers to decide the request within 45 days of receipt. An individual may also request suspension of processing while the request is being considered.
A controller may reject a request in whole or part where it is unjustifiably repetitive or requires extraordinary effort. A refusal should be reasoned and communicated within the same response period. Erasure may also be refused where processing is needed to comply with a legal obligation or where an active dispute exists.
A practical rights-request workflow
- Receive the request through a published channel.
- Record the receipt date and calculate the deadline.
- Verify identity without collecting excessive additional data.
- Clarify scope where the request is unclear.
- Search relevant systems, including archived and processor-held data.
- Review third-party information before disclosure.
- Apply relevant exceptions with legal review.
- Respond securely in a readable format.
- Record the decision and supporting evidence.
- Update or erase data across downstream systems where required.
Systems commonly missed during rights requests
Organizations often search the primary customer database but overlook:
- CRM notes;
- support tickets;
- call recordings;
- email inboxes;
- spreadsheets;
- archived systems;
- HR platforms;
- access-control logs;
- marketing platforms;
- cloud backups;
- shared drives; and
- processor systems.
The processing inventory should identify these locations before the first complex request arrives.
The data protection officer requirement
Article 20 requires the controller to identify a personal data protection officer.
The Executive Regulation states that the person should be qualified, familiar with the Law, the Regulation and the organization’s data-protection practices, and professionally capable of handling privacy matters.
The DPO’s responsibilities include:
- advising the controller or processor;
- following implementation of privacy policies;
- monitoring compliance with the Law and Regulation; and
- coordinating with the Ministry on personal-data matters.
The controller must publish the DPO’s name and contact information so individuals can contact the officer regarding the processing of their data.
Does the DPO need to be a full-time employee?
The available provisions require the controller to identify or designate a qualified officer but do not clearly require every organization to recruit a separate full-time employee.
The Ministry’s FAQ indicates that the role may be assigned to a new employee or an existing employee.
Before combining the role with legal, IT, compliance or HR responsibilities, the organization should consider:
- conflicts of interest;
- available time;
- direct access to management;
- technical competence;
- ability to investigate incidents;
- independence when challenging processing decisions; and
- availability during Ministry inquiries.
DPO evidence to prepare
- formal appointment or designation;
- role description;
- competency record;
- training history;
- escalation rights;
- contact details;
- annual work plan;
- compliance-monitoring reports;
- rights-request oversight records; and
- incident involvement.
The Ministry currently provides a DPO appointment form among its official guidance templates.
Sensitive-data permits
One of the most important Oman-specific requirements is the permit regime under Article 5.
A Ministry permit is required before processing personal data relating to:
- genetics;
- biometrics;
- health;
- racial origin;
- sex life;
- political opinions;
- religious opinions or beliefs;
- philosophical beliefs;
- criminal convictions; and
- security measures.
This can affect more organizations than expected.
Examples include:
- biometric employee attendance;
- facial-recognition access systems;
- private hospitals and clinics;
- health insurance;
- employee medical records;
- fitness and wellness applications;
- identity-verification systems;
- security-screening records;
- criminal-background checks; and
- products inferring political or religious preferences.
What the permit application may need to contain
The Executive Regulation identifies information including:
- DPO details;
- the processing purpose;
- the categories and classification of data;
- processor information;
- third-party recipients;
- processing and storage locations;
- data-management and protection systems; and
- additional information requested by the Ministry.
The controller should also attach its personal-data protection policy and precautionary measures for responding to personal-data breaches.
The Ministry has up to 45 days to decide a completed permit application. The Regulation states that a permit may be issued for up to five years and may be renewed. Changes to permit information should be notified within 15 days.
Practical permit-assessment questions
- Do we collect fingerprints for attendance?
- Do we use facial recognition?
- Do we store medical certificates?
- Does our application process health or wellness metrics?
- Do we perform criminal-background screening?
- Does an overseas provider process this information?
- Has processing already started without a permit?
- Does the permit cover the current purpose, system and processor?
- Have storage locations or vendors changed?
- Is renewal tracking in place?
Because Article 5 violations may carry substantial penalties, organizations should not assume that security measures or employee consent remove the permit requirement.
Children’s personal data
The PDPL prohibits processing a child’s personal data without the guardian’s approval unless the processing is in the child’s best interest.
The Executive Regulation requires explicit guardian consent and permits the organization to collect the minimum guardian information needed to verify identity and obtain approval. Processing should have a clear, direct and safe purpose, avoid deception and be limited to the minimum necessary data.
The guardian should also have mechanisms to access, update and correct the child’s data. Disclosure or sharing of a child’s data generally requires the guardian’s explicit consent.
Organizations that should review child-data controls
- schools and educational platforms;
- gaming companies;
- social or community applications;
- healthcare providers;
- family subscription services;
- delivery or mobility services used by minors;
- sports and membership clubs; and
- identity or age-assurance providers.
A child-data review should cover
- how the user’s age is determined;
- how guardian authority is verified;
- how much guardian data is collected;
- whether advertising or profiling is performed;
- whether third-party SDKs receive child data;
- whether location tracking is necessary;
- default privacy settings;
- data-retention periods; and
- how access and deletion requests are handled.
Processing records and retention
Controllers and processors are required to retain processing documentation in line with defined periods and procedures.
The Executive Regulation requires a dedicated processing-activity record containing information such as:
- DPO details;
- personal-data categories;
- authorized persons;
- processing period, limits and scope;
- deletion, modification and processing mechanisms;
- purposes;
- disclosure recipients;
- transfer recipients;
- cross-border processing;
- technical and organizational security measures; and
- breach details and corrective actions.
The register should be continuously updated and provided to the Ministry when requested.
The record should not be a one-time spreadsheet
A processing record becomes unreliable when it is completed once and never connected to operational changes.
Updates should be triggered when:
- a new SaaS platform is purchased;
- a new marketing campaign starts;
- employee monitoring changes;
- a processor is replaced;
- data begins to be stored abroad;
- new sensitive categories are collected;
- retention periods change;
- a merger or acquisition occurs;
- an AI feature is deployed; or
- a security incident reveals an undocumented data flow.
Retention
The Regulation does not impose one universal retention period for every personal-data category.
Instead, the reason for retaining processing documents should be specific and legitimate, the duration should be proportionate to the processing purpose, and technical systems should protect retained records.
A defensible retention schedule should identify:
A defensible retention schedule should identify
Retention triggerAccount closure
Retention ruleBased on legal and contractual needs
Deletion methodSecure system deletion
OwnerCustomer operations
Retention triggerConsent withdrawal or inactivity
Retention ruleDefined marketing period
Deletion methodCRM deletion or suppression
OwnerMarketing
Retention triggerHiring decision
Retention ruleEmployment-law and dispute period
Deletion methodHR-system deletion
OwnerHR
Retention triggerLog creation
Retention ruleSecurity and sector requirement
Deletion methodAutomated expiry
OwnerIT/security
Retention triggerEnd of care or employment
Retention ruleApplicable legal requirement
Deletion methodRestricted archival or deletion
OwnerHR or clinical owner
Retention triggerConsent or withdrawal
Retention rulePeriod needed to demonstrate compliance
Deletion methodControlled archival
OwnerPrivacy owner
Final durations should be validated against applicable employment, healthcare, financial, commercial and sector-specific rules.
External privacy audits
A notable provision in the Executive Regulation requires controllers and processors to appoint an external auditor who is accredited and licensed by the Ministry and independent from the audited organization.
The controller or processor must allow the auditor to examine relevant records, processing systems and data. A copy of the external auditor’s report must be supplied to the competent department within 60 days from the auditor’s appointment.
This provision raises practical implementation questions, including:
- which auditors are currently accredited;
- how frequently the appointment is expected;
- whether the requirement applies uniformly to every organization;
- the required report scope;
- how audit access should be controlled; and
- how audit duties interact with security, confidentiality and sector restrictions.
Organizations should not invent their own interpretation. They should confirm the current implementation process with the Ministry or qualified local counsel.
Preparing for an external privacy audit
An audit-ready organization should have:
- an updated processing record;
- approved privacy policies;
- consent evidence;
- DPO appointment evidence;
- rights-request logs;
- breach records;
- transfer assessments;
- Article 5 permits;
- processor contracts;
- retention schedules;
- access-control evidence;
- security testing;
- staff training records; and
- corrective-action tracking.
Personal-data breach notification
Oman’s breach regime contains two related notification tests.
Notification to the Ministry
The controller must notify the competent Ministry department within no more than 72 hours after becoming aware of a breach where the breach may create a risk threatening the rights of data subjects.
The report should include, at minimum:
- the nature and details of the breached data;
- resulting consequences;
- controller or contact-point information;
- likely effects;
- planned corrective and mitigation measures; and
- measures already taken before notification.
Notification to affected individuals
The controller must notify the affected individual within 72 hours after awareness where the breach may cause serious harm or high risk.
The notification should identify:
- the type and nature of the breach;
- the personal data affected; and
- recommendations to reduce or mitigate harm, where needed.
Not every security incident is automatically a reportable personal-data breach
The organization should distinguish between:
- a cybersecurity event;
- a confirmed security incident;
- a personal-data breach;
- a breach creating risk to rights;
- a high-risk breach requiring individual notification; and
- an incident triggering another sector regulator or contractual notice.
A practical breach decision matrix
A practical breach decision matrix
01
Was personal data involved?
Evidence needed
Systems, files and data categories affected
02
Was there unauthorized access, disclosure, alteration or destruction?
Evidence needed
Logs, forensic findings and access records
03
Which individuals were affected?
Evidence needed
User, employee or customer population
04
Could the event threaten their rights?
Evidence needed
Identity, financial, employment, medical or reputational impact
05
Could serious harm or high risk result?
Evidence needed
Sensitivity, volume, exposure, encryption and misuse likelihood
06
When did the organization become aware?
Evidence needed
Incident chronology and escalation timestamps
07
Is Ministry notification required?
Evidence needed
Documented risk assessment
08
Is individual notification required?
Evidence needed
High-risk assessment
09
Are other notices required?
Evidence needed
Sector rules, contracts and cyber obligations
Practical point: the assessment should start early. A team
should not wait for every forensic detail before deciding whether the
72-hour notification workflow may be triggered.
Build the process around the 72-hour deadline
A privacy team cannot wait for the technical investigation to be fully complete before beginning the notification assessment.
The incident procedure should define:
- who records the awareness time;
- who determines whether personal data is involved;
- who assesses risks to individuals;
- who contacts the Ministry;
- who approves individual communications;
- how incomplete information is handled;
- how follow-up information is submitted; and
- how the breach is documented in the processing record.
The Ministry provides an official breach-reporting form and reporting service.
Cross-border transfers
Before transferring personal data outside Oman, the controller generally must obtain the individual’s explicit consent and ensure that the transfer does not prejudice national security or the state’s higher interests.
Consent is not required where the transfer implements an international obligation under a treaty to which Oman is a party or where the data has been anonymized so that the person cannot be identified.
The controller must ensure that the overseas recipient provides a level of protection no lower than that required by Oman’s Law and Regulation.
The controller must also assess the overseas recipient’s protection level and the risks of the transfer. The assessment should address:
- the nature and volume of the data;
- sensitivity;
- processing purpose and scope;
- recipients;
- processing duration;
- whether the transfer is occasional or recurring;
- transit countries;
- final destination; and
- potential consequences for individuals.
The Ministry may request a copy of the assessment.
Sensitive personal data stored or processed abroad
The Ministry’s current FAQ states that approval from Oman’s Cyber Defence Centre is required where sensitive personal data will be stored or processed outside Oman.
This should be assessed separately from:
- the Article 5 Ministry permit;
- the individual’s transfer consent;
- the overseas protection assessment; and
- the agreement with the receiving processor.
One approval or document should not automatically be treated as satisfying all four issues.
SaaS and cloud transfer review
Organizations should map:
- the primary hosting region;
- backup locations;
- disaster-recovery regions;
- email and collaboration systems;
- support-access locations;
- analytics and advertising providers;
- identity and authentication services;
- subprocessors;
- content-delivery networks;
- log-management platforms; and
- AI model or API providers.
A statement that “the data is hosted in the GCC” is not enough if technical support, backups, analytics or subprocessors operate elsewhere.
Transfer assessment checklist
- Personal-data categories are identified.
- Sensitive data is flagged separately.
- The transfer purpose is documented.
- Every destination and transit country is known.
- Every recipient and subprocessor is identified.
- Consent has been assessed and recorded.
- The recipient’s legal and technical protection has been reviewed.
- Contractual safeguards are documented.
- Access, encryption, retention and deletion are covered.
- Cyber Defence Centre approval has been assessed.
- The assessment is approved and reviewable.
- Changes in provider or hosting location trigger reassessment.
Marketing communications
Article 22 requires written consent before sending advertising or marketing material of a commercial nature.
The Executive Regulation further requires the controller to:
- obtain written consent;
- tell the individual how marketing will be delivered;
- provide a mechanism to stop it; and
- stop sending marketing immediately and without charge after receiving an opt-out request.
Practical implications
Organizations should review:
- purchased marketing lists;
- pre-ticked consent boxes;
- bundled account and marketing consent;
- SMS campaigns;
- WhatsApp promotions;
- referral campaigns;
- event attendee lists;
- lead imports;
- abandoned-cart messaging;
- suppression lists; and
- consent synchronization between CRM and campaign tools.
A working unsubscribe link is not enough when one system continues sending messages after the user opts out through another channel.
The suppression process should cover every connected marketing platform.
Processor and supplier management
Controllers may appoint processors, but outsourcing does not remove accountability.
The Executive Regulation states that the processor acts on behalf of the controller regarding civil and administrative responsibility in relation to its service, without removing the processor’s criminal responsibility for its own violations.
The Ministry has also issued guidance specifically addressing controller responsibilities when contracting processors.
Processor agreements should address
- documented processing instructions;
- permitted purposes;
- data categories;
- confidentiality;
- personnel access;
- technical and organizational controls;
- subprocessors;
- overseas transfers;
- sensitive-data handling;
- rights-request assistance;
- incident reporting;
- audit and evidence access;
- retention and deletion;
- return of data on termination; and
- cooperation with the Ministry.
Contractual breach deadlines should be shorter than 72 hours
The controller’s regulatory clock may begin before the processor has completed its investigation.
A processor contract requiring notice only after a fully confirmed breach can make the controller’s 72-hour obligation difficult to meet.
A more operational approach is to require prompt notice of suspected incidents involving customer data, followed by staged updates.
Security requirements
The Executive Regulation requires controllers to protect confidentiality through electronic systems designed to prevent unauthorized access, leakage, tampering and misuse.
Controllers should also have systems capable of restoring personal data after physical or technical incidents and processes for testing the effectiveness of technical safeguards.
This creates a clear connection between privacy compliance and cybersecurity operations.
Practical security measures
The appropriate measures will depend on risk, but commonly include:
- access control and least privilege;
- multi-factor authentication;
- encryption;
- secure configuration;
- vulnerability management;
- endpoint protection;
- logging and monitoring;
- data-loss prevention;
- secure backups;
- restoration testing;
- supplier security;
- segregation of sensitive data;
- secure deletion;
- incident-response exercises; and
- staff awareness.
A policy stating that data is “securely protected” is not equivalent to evidence that access, restoration and control effectiveness are regularly tested.
Penalties and enforcement exposure
The PDPL contains different penalty bands depending on the provision breached.
Examples include:
- OMR 1,000–5,000 for violations involving obligations such as DPO designation, processing documentation and commercial-marketing consent;
- OMR 5,000–10,000 for failures involving required processing controls and procedures;
- OMR 15,000–20,000 for violations involving sensitive-data permits, children’s data, breach notification or confidentiality; and
- OMR 100,000–500,000 for unlawful cross-border transfers under Article 23.
A legal person may also face a fine between OMR 5,000 and OMR 100,000 where an offence is committed in its name or for its account by specified senior persons, including through approval, concealment or gross negligence.
Separately, the Ministry may impose administrative penalties, including warnings, permit suspension, administrative fines of up to OMR 2,000 per violation and permit cancellation.
Avoid reducing compliance to the maximum fine
The larger operational risks may include:
- interruption of data processing;
- permit suspension or cancellation;
- customer contract disputes;
- inability to use overseas systems;
- incident-notification failures;
- reputational damage;
- mandatory remediation;
- external-audit findings; and
- difficulty proving that consent was valid.
Oman PDPL versus GDPR: practical differences
Oman PDPL versus GDPR: practical differences
Consent
Explicit consent has a central role.
Several lawful bases may be available.
Sensitive data
Specified categories require a Ministry permit.
Processing may rely on an Article 9 condition.
DPO
Controller must identify a privacy officer.
Required only in specified circumstances.
Rights deadline
Generally 45 days under the Regulation.
Generally one month.
Breach reporting
72 hours where risk threatens rights.
72 hours where risk to rights and freedoms exists.
Overseas transfer
Consent and protection assessment are central.
Adequacy, safeguards or derogations.
External auditor
Regulation includes an accredited external-auditor mechanism.
No universal GDPR external-auditor requirement.
Marketing
Written consent is expressly required for commercial marketing.
Rules depend on GDPR and e-privacy legislation.
Extraterritoriality
No clear GDPR-equivalent express rule.
Expressly applies in several non-EU scenarios.
A GDPR program provides a useful starting point, but it should not be copied into Oman unchanged.
The largest localization gaps are likely to involve:
- the Article 5 permit;
- DPO designation;
- written commercial-marketing consent;
- transfer consent and assessments;
- Cyber Defence Centre approval;
- Ministry forms;
- external-auditor requirements; and
- Oman-specific complaint and breach procedures.
A practical 90-day compliance roadmap
Organizations that missed the February 2026 transition deadline should prioritize material risk rather than attempting to rewrite every document simultaneously.
Days 1–15: Determine scope and stop high-risk gaps
Objectives
- appoint a program owner;
- designate an interim or permanent DPO;
- identify Article 5 data;
- identify sensitive data stored abroad;
- review recent or unresolved breaches;
- stop clearly non-compliant marketing activity; and
- assess whether urgent permit or regulator engagement is needed.
Outputs
- scope statement;
- governance appointment;
- urgent-risk register;
- sensitive-data inventory;
- cross-border system list;
- initial permit assessment;
- breach and complaint review; and
- executive remediation decision.
Days 16–30: Build the data inventory
Objectives
- identify processing activities;
- map controllers and processors;
- document purposes;
- identify consent mechanisms;
- record storage and transfer locations;
- identify data-subject groups; and
- document retention.
Outputs
- processing-activity register;
- data-flow maps;
- system and vendor inventory;
- consent inventory;
- transfer register;
- sensitive-data register; and
- retention-gap report.
Days 31–45: Fix public-facing compliance
Objectives
- update privacy notices;
- publish DPO contact details;
- implement rights-request channels;
- correct marketing consent;
- update child and guardian workflows;
- ensure bilingual communication where appropriate.
Outputs
- privacy notice;
- employee notice;
- cookie or tracking notice where relevant;
- marketing-consent text;
- rights-request form;
- DPO contact page;
- child-data notice; and
- consent evidence standard.
Days 46–60: Formalize processors and transfers
Objectives
- prioritize critical processors;
- update contract terms;
- assess subprocessors;
- complete transfer-risk assessments;
- obtain required approvals;
- verify deletion and incident support.
Outputs
- processor agreement;
- supplier questionnaire;
- transfer-assessment template;
- completed high-risk assessments;
- approval tracker;
- subprocessor list; and
- contract-remediation plan.
Days 61–75: Prepare security and incident response
Objectives
- align cybersecurity and privacy escalation;
- establish the awareness-time rule;
- build a 72-hour decision process;
- validate backup restoration;
- review access to sensitive data;
- test notification drafting.
Outputs
- personal-data breach plan;
- breach decision matrix;
- Ministry notification template;
- individual-notification template;
- incident register;
- contact tree;
- tabletop exercise report; and
- corrective actions.
Days 76–90: Test and demonstrate compliance
Objectives
- run a mock rights request;
- test consent withdrawal;
- test deletion;
- review the processing record;
- assess external-audit readiness;
- report residual risks to management.
Outputs
- testing results;
- evidence register;
- updated risk register;
- management report;
- unresolved-gap plan;
- external-audit preparation file; and
- annual compliance calendar.
Evidence organizations should retain
Governance
- DPO appointment;
- management approvals;
- privacy roles and responsibilities;
- training records;
- legal-scope assessments;
- compliance plan;
- risk register;
- Ministry correspondence.
Transparency and consent
- privacy notices;
- notice version history;
- consent wording;
- consent logs;
- withdrawal records;
- marketing suppression records;
- guardian consent.
Processing activities
- data inventory;
- processing record;
- data-flow maps;
- retention schedule;
- access lists;
- deletion records;
- system ownership.
Sensitive data
- Article 5 assessment;
- permit application;
- permit decision;
- renewal date;
- change notifications;
- Cyber Defence Centre assessment;
- additional security controls.
Individual rights
- request register;
- identity-verification records;
- search evidence;
- response and refusal templates;
- decision records;
- processor correspondence;
- completion evidence.
Suppliers and transfers
- supplier register;
- processing agreements;
- subprocessor lists;
- hosting locations;
- transfer-risk assessments;
- consent evidence;
- audit reports;
- deletion confirmations.
Breach management
- incident chronology;
- awareness timestamp;
- risk assessment;
- Ministry report;
- individual notification;
- forensic findings;
- corrective actions;
- lessons learned.
Security
- access reviews;
- encryption evidence;
- vulnerability testing;
- backup restoration;
- logging;
- security training;
- incident exercises;
- control-effectiveness testing.
Common implementation mistakes
Treating consent as a paragraph in the privacy policy
A policy does not prove that a person made an informed and explicit choice.
Consent should be connected to the interface, form or process through which data is collected.
Missing the Article 5 permit requirement
Biometric attendance, health information and background checks are common business processes, not unusual edge cases.
Organizations should assess them before assuming the permit regime is relevant only to hospitals or large technology companies.
Assuming GDPR documents are automatically sufficient
A GDPR privacy notice may not explain Oman-specific consent, permit, transfer, DPO and complaint arrangements.
Appointing a nominal DPO
Publishing an employee’s name without training, authority, time or access to management creates limited practical value.
Discovering overseas transfers too narrowly
Hosting is only one part of the transfer map.
Support teams, subprocessors, backups, analytics, email systems and AI services may also involve overseas processing.
Starting the 72-hour clock too late
The regulatory assessment should not wait until every technical fact is confirmed.
The organization needs a documented definition of when it became aware of a personal-data breach.
Using one inbox for rights requests without a workflow
A published email address is not a complete process.
Requests need identity verification, search ownership, deadline tracking, legal review and secure response.
Failing to synchronize opt-outs
A person who opts out through customer support should not continue receiving campaigns because the CRM and messaging platform were not updated.
Leaving processor contracts unchanged
A processor’s general privacy terms may not provide the notification timing, transfer transparency, deletion assistance or audit evidence needed by the controller.
Practical Oman PDPL readiness checklist
Governance and scope
- We have documented which entities and processing activities are within scope.
- We have assessed Article 3 exclusions with local legal input where necessary.
- A qualified DPO has been designated.
- The DPO’s contact information is published.
- Management receives regular privacy-compliance reporting.
Processing inventory
- We maintain an updated processing-activity record.
- Each activity has a documented purpose.
- Personal-data categories and individuals are identified.
- Systems, recipients and processors are recorded.
- Retention periods and deletion methods are documented.
- Overseas processing is visible.
Consent and transparency
- Consent is clear, explicit and provable.
- Different purposes are separated where appropriate.
- Consent withdrawal is operational.
- Privacy information is provided before processing.
- Arabic communication is available where needed for clarity.
- Notice versions are retained.
Sensitive and children’s data
- Article 5 data categories have been identified.
- Required Ministry permits have been assessed or obtained.
- Permit changes and renewal dates are tracked.
- Overseas sensitive-data processing has been reviewed.
- Guardian consent is obtained where required.
- Child-data collection is minimized.
Individual rights
- A clear request channel is available.
- The 45-day deadline is tracked.
- Identity verification is proportionate.
- Processors can assist with searches and deletion.
- Refusals are documented and reasoned.
- Responses are delivered securely.
Marketing
- Written marketing consent is retained.
- The delivery channel is disclosed.
- Every message provides an opt-out mechanism.
- Opt-outs are applied immediately and without charge.
- Suppression is synchronized across platforms.
- Purchased and legacy lists have been reviewed.
Suppliers and international transfers
- Processor agreements are in place.
- Subprocessors and locations are known.
- Transfer consent has been assessed.
- Overseas protection assessments are documented.
- Sensitive-data approval requirements are assessed.
- Contracts cover incidents, rights and deletion.
- Material vendor changes trigger reassessment.
Security and breaches
- Access to personal data is restricted.
- Recovery systems are tested.
- Security controls are periodically tested.
- The breach plan uses a 72-hour workflow.
- Awareness time is documented.
- Ministry and individual notification tests are separate.
- Breaches and corrective actions are recorded.
- A tabletop exercise has been completed.
Assurance
- Ministry self-assessment materials have been reviewed.
- Evidence is indexed by obligation.
- External-auditor requirements have been assessed.
- Compliance gaps have owners and deadlines.
- Management accepts or remediates residual risks.
- The program has an annual review calendar.
Frequently asked questions
Is Oman’s PDPL currently enforceable?
Yes. The extended transition period concluded on 5 February 2026. Organizations processing personal data in Oman should now be able to demonstrate operational compliance with the PDPL and its Executive Regulation.
Does every company need a DPO?
The Law requires controllers to identify a personal data protection officer, and the Ministry’s FAQ states that controllers must appoint one in line with the Regulation.
The role may be assigned to an existing employee, provided the individual is qualified and capable of performing the duties.
Does the DPO need to be Omani or based in Oman?
The provisions reviewed specify qualifications, knowledge, professional capability and publication of contact details, but do not clearly establish a universal nationality requirement.
Organizations should verify whether current Ministry forms or implementation practices create local identification or residency expectations.
Do we need a permit to process employee fingerprints?
Biometric data is included among the Article 5 categories requiring a Ministry permit before processing.
An organization using fingerprint or facial-recognition attendance should assess the permit requirement rather than relying only on employee consent.
How long do we have to respond to a data-subject request?
The Executive Regulation generally requires a controller to decide a written request within 45 days of receiving it.
Must every personal-data breach be reported?
The Ministry should be notified within 72 hours where a breach could create a risk threatening the rights of data subjects.
Affected individuals should be notified within 72 hours where serious harm or high risk may result. The organization should document its assessment even where it concludes that notification is not required.
Can personal data be stored outside Oman?
Cross-border processing is possible, but the controller generally needs explicit consent, must assess the overseas recipient’s protection and should document the risks and destination.
Sensitive data stored or processed outside Oman may require Cyber Defence Centre approval.
Does an ISO 27001 certificate prove Oman PDPL compliance?
No.
ISO 27001 can support security, risk, supplier and incident controls, but it does not by itself demonstrate compliance with Oman-specific consent, permit, DPO, rights, marketing and transfer requirements.
Does the PDPL automatically apply to every foreign website with Omani users?
The law does not clearly contain a GDPR-equivalent extraterritorial provision.
A foreign organization may still be directly or indirectly affected through processing in Oman, an Omani establishment, service-provider relationships, overseas transfers or customer contracts. Applicability should be assessed case by case.
Is there a general data-localization requirement?
The PDPL does not appear to impose a universal rule that all personal data must remain in Oman.
However, cross-border conditions apply, and sensitive personal data stored or processed abroad may require additional approval.
Are government entities covered?
State administrative units and other public legal entities are exempt from the PDPL in relation to their prescribed public functions, but a separate government personal-data protection policy applies to them.
Conclusion
Oman’s 2026 enforcement milestone changes the practical question from:
“Do we have a privacy policy?”
to:
“Can we demonstrate that our privacy controls operate?”
For many organizations, the most urgent gaps will involve:
- undocumented processing;
- weak consent evidence;
- missing sensitive-data permits;
- unassessed cloud transfers;
- nominal DPO appointments;
- incomplete processor contracts;
- untested rights procedures; and
- breach-response processes that cannot meet 72 hours.
The most effective approach is to build one operational privacy system that connects the processing record, consent evidence, notices, vendors, transfers, rights requests, incidents and security controls.
Policies should describe that system—not substitute for it.
Not sure how your current privacy and security program compares with Oman’s PDPL?
A structured gap assessment can identify which GDPR, ISO 27001 or internal controls can be reused, where Oman-specific requirements remain, and which gaps should be addressed first.
Sources