Business Transformation & Technology Consulting · IT Risk & Technology Assurance
Data Privacy & Protection Advisory
Data Privacy & Protection Advisory helps UAE-based businesses map how they actually collect, use, store, and share personal data, then closes the gap between that reality and their obligations under UAE Federal Decree-Law No.
Chartered Accountants · Dubai · Since 1986
Data Privacy & Protection Advisory is the practice of assessing how a UAE entity collects, processes, stores, shares, and disposes of personal data, and then designing the policies, technical controls, and governance structure needed to bring that handling into line with applicable UAE data protection law. The UAE's core federal framework is Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (the PDPL), which came into effect in 2022 and applies broadly to the processing of personal data of individuals inside the UAE by entities established in the UAE or processing data of individuals in the UAE, regardless of the processing entity's own location, subject to specified exclusions (including government data processed for national security purposes and certain data already regulated under sector-specific health, banking, or financial data laws). Entities registered within the Dubai International Financial Centre (DIFC) fall instead under the DIFC Data Protection Law (currently DIFC Law No. 5 of 2020, as amended) and are supervised by the DIFC Commissioner of Data Protection; entities within Abu Dhabi Global Market (ADGM) fall under ADGM's own Data Protection Regulations, supervised by the ADGM Office of Data Protection. A group with entities across the mainland, a free zone, and a financial free zone can genuinely be subject to three different data protection regimes simultaneously — one of the most common points of confusion PNPC resolves at the start of an engagement.
At its core, UAE data protection law is built around a small set of recurring obligations that show up in every jurisdiction's version, even though the specific mechanics differ: a lawful basis for processing personal data (consent, contractual necessity, legal obligation, or legitimate interest, depending on the regime); transparency to the data subject about what is collected and why, typically through a privacy notice; data minimisation and purpose limitation, meaning data collected for one purpose should not be silently repurposed; reasonable technical and organisational security measures proportionate to the sensitivity of the data held; defined rights for data subjects — commonly access, correction, deletion, and objection to processing; restrictions or conditions on transferring personal data outside the UAE (or outside the relevant free zone, for DIFC/ADGM entities) unless an adequate safeguard is in place; and, for processing that carries higher risk or reaches a defined threshold, formal governance obligations including appointing a Data Protection Officer and conducting Data Protection Impact Assessments. The PDPL's implementing executive regulations, once issued and updated by the UAE Cabinet, and guidance from the UAE Data Office (the federal authority responsible for PDPL oversight) refine how these principles apply in practice — PNPC tracks these updates as part of every ongoing advisory relationship rather than treating the law as static from the point of initial registration.
The scope of what counts as personal data is broader than most businesses initially assume: names, Emirates ID numbers, passport details, contact information, employment records, financial data, IP addresses, device identifiers, and biometric data used for access control or time-and-attendance all typically qualify. Certain categories — health data, biometric data, data revealing racial or ethnic origin, religious beliefs, or criminal records — are commonly treated as sensitive personal data requiring a higher standard of protection and, in several regimes, explicit consent or a narrower set of lawful processing grounds. A retail business running a loyalty programme, an employer processing payroll and visa data for staff, a healthcare provider handling patient records, a marketing agency running targeted campaigns, and a SaaS platform storing customer data on behalf of clients are all processing personal data under this framework, even though none of them think of themselves primarily as a 'data business.'
PNPC's role is not to hand over a generic privacy policy template and call the engagement complete — a policy that does not match what the business's systems, forms, and vendors actually do is worse than no policy, because it creates a written record contradicting operational reality that a regulator, litigant, or breached customer can point to directly. Our engagement starts with an actual data-flow mapping exercise: what personal data is collected, through which channel, stored in which system, shared with which third party or processor, retained for how long, and disposed of how. From that map, we identify genuine gaps — missing consent mechanisms, undocumented cross-border transfers to a parent company or cloud provider outside the UAE, vendor contracts silent on data protection obligations, no defined breach-notification process, no one clearly accountable for a data subject access request — and build a remediation plan proportionate to the entity's size, sector, and actual risk, rather than importing a one-size-fits-all EU GDPR-style programme that over-engineers compliance for a business the PDPL does not require it for.
A further nuance PNPC clarifies at the start of nearly every engagement is that not every UAE free zone carries its own data protection law. Only the two financial free zones — DIFC and ADGM — operate independent data protection regimes with their own regulator (the DIFC Commissioner of Data Protection and the ADGM Office of Data Protection respectively). Non-financial free zones — JAFZA, DMCC, RAKEZ, IFZA, Meydan, RAK ICC, and Ajman Free Zone among them — do not have their own data protection statute; entities licensed in these free zones fall under the federal PDPL in the same way a mainland company does, even though they operate under a free-zone trade licence for company-law and ownership purposes. This distinction matters in practice because a group with a JAFZA logistics entity, a DMCC trading entity, and a DIFC advisory entity is not managing three separate free-zone privacy regimes — it is managing the federal PDPL twice (JAFZA and DMCC) and the DIFC Data Protection Law once, a materially different compliance map than the group's own legal team sometimes assumes. PNPC's regulatory scoping stage exists specifically to correct this kind of mis-mapping before any policy is drafted against the wrong regime.
A common misconception PNPC corrects early is equating UAE data protection law with the EU's GDPR, simply because both regimes share similar vocabulary — controller, processor, lawful basis, data subject rights. The PDPL, DIFC Data Protection Law, and ADGM Data Protection Regulations are each their own instrument, with their own supervisory authority, enforcement mechanics, and specific thresholds for obligations such as DPO appointment and DPIAs. A business that imports a GDPR-drafted policy wholesale, without checking it against the actual UAE instrument that applies, risks both under-compliance (missing a UAE-specific requirement GDPR does not have) and over-compliance (committing to obligations, timelines, or penalty exposure that do not actually apply here, which can itself create contractual or reputational risk if the business later cannot meet a self-imposed standard it never needed to adopt). What actually drives cost and timeline is rarely the law itself — it is the number of systems and vendors in scope, how many business functions need to be interviewed to build an honest data-flow map, whether the group spans more than one UAE jurisdiction or a cross-border data flow to a parent company, and how much of the underlying IT environment is already documented versus needing to be reconstructed from scratch during the engagement.
A second misconception is treating data privacy as a one-time deliverable rather than a living control. A privacy policy published once and never revisited drifts out of alignment the moment the business adds a new marketing tool, onboards a new payroll vendor, or launches a feature that collects a new category of data — none of which pause to wait for the next scheduled review. PNPC's engagements are structured to make this drift visible and manageable: a dated review cadence, a defined process for assessing new processing activity before it goes live, and a named internal owner accountable for flagging change, rather than leaving the programme to degrade silently until a regulator inquiry, a customer complaint, or a breach forces a reactive scramble.
UAE Data Protection Compliance Approaches Compared
| Feature | PNPC-Led Data Protection Programme | Generic Template Privacy Policy | In-House Ad Hoc Approach | No Formal Privacy Programme |
|---|---|---|---|---|
| Regime correctly identified (PDPL vs DIFC vs ADGM) | Confirmed at the outset against the entity's actual licence and registration | Rarely checked — template usually assumes one generic regime | Often assumed rather than verified | Not addressed |
| Data-flow mapping against actual systems | Full inventory of what is collected, stored, shared, and for how long | Not performed — policy is aspirational, not descriptive | Informal and undocumented, if it exists at all | None |
| Cross-border transfer basis documented | Reviewed transfer-by-transfer against applicable safeguard requirements | Usually silent or generic boilerplate | Rarely reviewed until a specific question forces it | Not considered |
| Consent and notice mechanisms matched to actual forms/apps | Verified against the live website, app, and intake forms | Policy text does not reflect what the form actually captures | Inconsistent across channels | Absent |
| Vendor / processor contract review | Data protection clauses checked in key vendor and cloud agreements | Not covered | Not reviewed unless a vendor raises it first | Not reviewed |
| Data subject rights process (access, deletion, correction) | Defined internal workflow with an accountable owner | Referenced in the policy text, no operational process behind it | Handled reactively and inconsistently | No process |
| Breach response plan | Documented, with roles, notification triggers, and a rehearsed workflow | Not included | Improvised if and when an incident occurs | None |
| DPO / privacy accountability | Structured — internal appointment supported or external advisory arranged | Not addressed | Diffuse — no single accountable owner | No ownership |
| Ongoing review as regulation and business evolve | Built into the engagement as a scheduled cadence | One-time document, never revisited | Revisited only after a problem surfaces | Never reviewed |
| Defensibility under regulator inquiry or litigation | Documentation matches actual practice and can be evidenced | Weak — written policy contradicts operational reality | Weak — little to show beyond informal intent | High exposure |
| Data retention and disposal schedule | Defined per data category, tied to actual legal and operational need | Not addressed | Ad hoc — data kept indefinitely by default | No schedule |
| Free-zone vs mainland vs DIFC/ADGM regime mapping across group entities | Confirmed entity-by-entity, not assumed uniform | Assumes one regime for the whole group | Rarely mapped at group level | Not considered |
| Employee monitoring and CCTV governance | Reviewed for lawful basis and proportionality alongside biometric access control | Not covered | Handled by IT/security team without privacy input | Not reviewed |
The right depth of programme depends on the entity's processing volume, data sensitivity, and applicable regime. A five-person professional services firm and a consumer app handling thousands of customer records need proportionately different programmes — PNPC scopes to the entity's actual risk rather than a fixed template.
| # | Stage & What PNPC Does | What a Generic Template Approach Misses | Typical Output |
|---|---|---|---|
| 1 | Regulatory Scoping — Confirming which data protection regime actually applies | We confirm whether the entity sits under the federal PDPL, the DIFC Data Protection Law, or ADGM's Data Protection Regulations based on its actual licence and registration — a mainland-registered entity with a DIFC branch, for instance, can be subject to more than one regime for different parts of its operation, a distinction generic templates never draw. | Regulatory scope memo confirming applicable law and supervisory authority |
| 2 | Data-Flow Mapping — Building the real inventory, not the assumed one | We interview the actual business functions — HR, sales, marketing, IT, finance — to map what personal data each collects, through which system, and where it goes next, rather than relying on what a policy document says should happen. | Data inventory / processing register |
| 3 | Data Retention Schedule Design | Working from the data-flow map, we define how long each category of personal data actually needs to be kept — driven by operational need and any applicable statutory retention period — rather than leaving retention undefined and data accumulating indefinitely by default. | Data retention and disposal schedule |
| 4 | Lawful Basis & Consent Review | For each category of processing identified, we confirm the lawful basis being relied on (consent, contract, legal obligation, legitimate interest) and check that the actual consent or notice mechanism on the live form, website, or app matches what the law requires for that basis. | Lawful-basis matrix mapped to each processing activity |
| 5 | Cross-Border Transfer Assessment | We identify every instance personal data leaves the UAE — group reporting, offshore payroll processing, a cloud provider hosted outside the UAE — and assess whether the transfer needs a specific safeguard, contractual clause, or documented justification under the applicable regime. | Cross-border transfer register with risk flags |
| 6 | Free Zone / Group Entity Reconciliation | For groups with entities across mainland, non-financial free zones, and DIFC/ADGM, we reconcile which specific regime governs which entity, correcting the common assumption that one group privacy policy or one free-zone licence status covers every entity uniformly. | Group entity-to-regime mapping schedule |
| 7 | Sensitive Data & DPIA Threshold Check | We flag processing involving sensitive categories (health, biometric, financial, data concerning minors) or otherwise higher-risk processing, and assess whether a Data Protection Impact Assessment is warranted before proceeding or continuing. | DPIA trigger assessment and, where warranted, a completed DPIA |
| 8 | Policy & Notice Drafting — Written to match the actual data flows, not a template | Privacy policy, internal data protection policy, and any data subject-facing notices are drafted directly from the data-flow map produced in Stage 2, so the published text accurately reflects what the business actually does. | Privacy policy, internal policy, and data subject notices |
| 9 | Vendor & Processor Contract Review | Key vendor, cloud hosting, and outsourced-processing agreements are reviewed for data protection clauses — processor obligations, breach-notification duties, sub-processor consent, and data return/deletion on termination — and remediated where missing. | Contract gap report with suggested clause language |
| 10 | Data Subject Rights Workflow Design | We design the internal process for handling access, correction, deletion, and objection requests — who receives the request, within what timeframe it is actioned, and how the response is documented — so a request does not land on an unprepared team. | Data subject request handling procedure |
| 11 | Employee Monitoring & CCTV Governance Review | Where the business uses email/internet monitoring, vehicle tracking, or CCTV covering work areas, we review the lawful basis and proportionality of that monitoring alongside the biometric access-control review already underway, and align it with the internal policy. | Employee monitoring governance note |
| 12 | Breach Response Plan | A documented incident-response plan is built covering detection, internal escalation, containment, assessment of notification obligations, and communication — walked through with the relevant team so it is not being read for the first time during an actual incident. | Data breach response plan and escalation matrix |
| 13 | DPO Structure & Governance | Where the entity's processing volume or risk profile warrants it, we advise on appointing an internal Data Protection Officer or arranging external DPO advisory support, and define the reporting line and authority the role needs to be effective. | DPO appointment recommendation and role charter |
| 14 | Staff Awareness Training | Practical training for staff who handle personal data day to day — what counts as personal data, how to recognise a data subject request, what not to do during a suspected breach — rather than generic, disconnected privacy awareness content. | Training session and completion record |
| 15 | Roll-Out & Sign-Off | Policies are published, internal processes go live, and the engagement closes with a written scope-boundary note confirming what was covered and what remains the entity's ongoing responsibility. | Programme go-live confirmation and scope memo |
| 16 | Periodic Review Cadence | A dated calendar is set for revisiting the data-flow map, policy text, and vendor contracts as the business, its systems, or the regulatory framework evolve — privacy programmes drift out of alignment quickly without a scheduled check. | Review calendar (typically annual, or triggered by material business change) |
| 17 | Ongoing Advisory | PNPC remains available for new processing activities, incident support, regulator inquiries, and updates as PDPL executive regulations, DIFC, or ADGM guidance evolve. | Ongoing advisory retainer, if agreed |
A proportionate data protection programme for a small-to-mid-sized UAE business — from initial scoping through go-live — typically runs a small number of weeks depending on how many systems and vendor relationships need to be mapped. Entities with multiple group jurisdictions, complex cross-border data flows, or sensitive-data processing (healthcare, biometric access control, financial services) should expect a longer, more layered engagement.
Trade licence confirming the entity's activity and licensing jurisdiction (mainland, specific free zone, DIFC, or ADGM)
Group structure chart showing any related entities in other UAE jurisdictions or overseas that share data
Existing privacy policy, internal data protection policy, or data governance documentation, if any exists
Any prior data protection gap assessment, audit, or regulator correspondence
List of core business systems handling personal data — CRM, HR/payroll, marketing automation, e-commerce platform, customer support tools
Description of website and app data collection points — forms, cookies/tracking tools, account registration flows
List of third-party vendors, cloud hosting providers, and outsourced processors with access to personal data
Details of any cross-border data flows — group reporting, offshore teams, overseas cloud hosting locations
Sample employment contract and HR onboarding documentation showing what employee data is collected
Details of any biometric access-control or time-and-attendance systems in use
Payroll and visa-processing data flow, including any third-party payroll provider involved
Sample customer intake, sign-up, or loyalty-programme forms
Marketing consent mechanism currently in use, if any (opt-in checkboxes, newsletter sign-up flow)
Any customer segmentation, profiling, or targeted-advertising activity currently undertaken
Name and role of whoever currently handles privacy-related questions internally, if anyone is designated
Record of any prior data security incident, near-miss, or customer complaint related to data handling
Any existing IT security policy, access-control policy, or data retention schedule
Key vendor and cloud-hosting agreements for review of data protection clauses
Any data processing agreement (DPA) already in place with a vendor or group parent
Details of software-as-a-service tools used that store customer or employee data outside the UAE
For groups with entities across more than one UAE jurisdiction, a schedule confirming each entity's specific free-zone or mainland licence and the data protection regime PNPC has confirmed applies to it
Any intra-group data-sharing arrangement or group privacy policy already circulated, so it can be checked against each entity's actual applicable regime rather than assumed uniform
Details of any joint-controller or joint-venture arrangement where personal data is shared with a partner entity outside the group
Existing data retention schedule or record-disposal practice, if any, across HR, customer, and financial records
Details of any employee monitoring in place — email/internet monitoring, vehicle tracking, or CCTV covering work areas — beyond biometric access control already captured elsewhere
Where the entity is also subject to a sector-specific data regime (health data under DOH/DHA rules, financial data under Central Bank rules), any existing sector compliance documentation relevant to how that overlaps with PDPL/DIFC/ADGM obligations
For a business preparing for fundraising, acquisition, or sale, the data room index or investor questionnaire section relating to data protection, so PNPC can identify exactly what an investor or acquirer's counsel expects to see
Any joint-controller, franchise, or joint-venture agreement involving shared customer or partner data, so the data-sharing terms can be reviewed alongside the general programme
Details of any prior transaction (a merger, acquisition, or carve-out) that transferred a personal data set into or out of the entity, and how that transfer's lawful basis was documented at the time
List of staff roles that routinely handle personal data (customer service, HR, sales, IT) who will need role-specific privacy awareness training
Any prior staff training record on data protection or information security, so PNPC can assess what already exists versus what needs to be built
Planned or recent business changes — a new product launch, a new market, a new system migration — that will introduce new processing activity requiring assessment before go-live
| Phase | Triggered By | PNPC Guidance | Risk If Ignored |
|---|---|---|---|
| Scoping & Regulatory Mapping | Engagement start | Confirm which data protection regime applies (PDPL, DIFC, or ADGM) and identify all group entities and jurisdictions in scope before any policy drafting begins. | A programme built against the wrong regime leaves the entity non-compliant with the law that actually applies to it, despite appearing to have 'done privacy'. |
| Data-Flow Mapping & Gap Assessment | Regime confirmed | Build the real data inventory across HR, sales, marketing, IT, and finance functions, and identify gaps against the applicable legal requirements. | Undocumented data flows mean the business cannot answer a data subject request, regulator inquiry, or breach investigation accurately. |
| Policy, Notice & Contract Remediation | Gaps identified | Draft or update the privacy policy, internal policy, data subject notices, and review vendor/processor contracts so documentation matches actual practice. | A published policy that contradicts operational reality is itself evidence of non-compliance if scrutinised. |
| Process & Governance Roll-Out | Documentation finalised | Stand up the data subject rights workflow, breach response plan, and DPO/governance structure, and train relevant staff on the live processes. | Rights requests and incidents handled ad hoc, without a defined process, routinely miss statutory timeframes and create inconsistent, undocumented responses. |
| Ongoing Operational Compliance | Day-to-day business activity | New processing activities (a new marketing tool, a new vendor, a new data category) are checked against the existing programme before go-live, not after. | Privacy debt accumulates silently as new systems and vendors are added without review, widening the gap between policy and practice over time. |
| Incident Response | Suspected or confirmed data breach | The documented breach response plan is activated — detection, containment, assessment of notification obligations, and communication — with PNPC available to advise through the process. | An unrehearsed response to a real incident wastes critical early time and increases the risk of an inadequate or late notification. |
| Periodic Review | Scheduled cadence or material business change | The data inventory, policy text, and vendor contract review are refreshed against current operations, and any regulatory updates from the UAE Data Office, DIFC Commissioner, or ADGM Office of Data Protection are factored in. | A programme that is never revisited drifts out of alignment with both the business's actual data handling and the current state of the law. |
| Business Change (New Product, Market, or M&A) | Expansion, new system launch, or corporate transaction | The data protection programme is extended to cover new processing activities, new jurisdictions, or data assumed as part of an acquisition, before the change goes live. | A programme calibrated for the original, smaller footprint becomes inadequate as the business scales into new data-intensive activity or jurisdictions. |
| Regulator Inquiry or Data Subject Complaint | UAE Data Office, DIFC Commissioner, ADGM Office of Data Protection, or an individual complaint | PNPC supports the entity in responding accurately and within any applicable timeframe, drawing on the documented data inventory and processes already in place. | An entity with no documented programme struggles to respond credibly, increasing the likelihood of an adverse finding or escalation. |
| Cross-Border Transfer Change | New offshore vendor, group restructuring, or change in hosting location | Each new or changed cross-border data flow is assessed against the applicable transfer safeguard requirements before data starts moving. | An undocumented or unassessed cross-border transfer is one of the most common and most visible compliance gaps found on review. |
| Data Retention & Disposal | Scheduled cadence or data category reaching end of retention period | Personal data no longer needed for the purpose it was collected for, or past the applicable retention period, is disposed of or anonymised according to the documented retention schedule. | Indefinite retention of personal data with no disposal process increases the volume of data exposed in any future breach and weakens the purpose-limitation defence if challenged. |
| Group Entity Change (New Free Zone Entity, DIFC/ADGM Expansion) | New entity incorporated or acquired in a different UAE jurisdiction | Confirm the regime applicable to the new entity (federal PDPL for a non-financial free zone or mainland entity, DIFC/ADGM law for those centres) before assuming the group's existing programme automatically extends to it. | A new entity assumed to be covered by the group's existing privacy policy may in fact sit under a different regulator with different specific requirements, leaving a real compliance gap. |
| Employee Monitoring Change | New monitoring tool or CCTV deployment introduced | Any new employee monitoring capability is reviewed for lawful basis and proportionality before deployment, and the internal policy and employee notice are updated to reflect it. | Monitoring introduced without a documented lawful basis or employee notice is one of the more common gaps a labour dispute or data subject complaint can surface. |
Drafting a privacy policy before the data-flow mapping is complete, producing a document that describes what the business intends to do rather than what its systems actually do
Assuming one group-wide privacy policy automatically covers every entity in the group, without checking whether a DIFC or ADGM entity actually sits under a different law and regulator
Treating a free-zone trade licence as evidence of a lighter or separate privacy regime, when only DIFC and ADGM carry their own data protection law — every other free zone follows the federal PDPL
Building the programme once and never revisiting it, so it drifts out of alignment as new systems, vendors, and marketing tools are added over time
Publishing a cookie banner that offers a genuine choice while the website's tracking scripts fire regardless of what the visitor selects, creating a direct contradiction between stated and actual practice
Bundling marketing consent into a general terms-of-service acceptance rather than seeking it as a distinct, specific choice, which weakens the lawful basis relied on for marketing communications
Continuing to market to a customer after they have withdrawn consent or unsubscribed, because the withdrawal was not actually propagated to every system holding that customer's data
Collecting more data on an intake form than the stated purpose requires, then relying on the privacy notice to retroactively justify the extra fields collected
Assuming a well-known international cloud provider is automatically compliant with UAE cross-border transfer requirements without checking the actual hosting location or the provider's data protection terms
Signing or renewing a vendor contract with no data protection clause at all, discovering the gap only when the vendor itself suffers a breach and the business has no contractual recourse or notification right
Appointing a Data Protection Officer in name only, with no real authority to pause a risky new system or escalate a concern to senior management
Leaving employee monitoring — email review, vehicle tracking, CCTV in work areas — outside the privacy programme entirely, treating it as purely an IT or security matter rather than personal data processing in its own right
Which UAE businesses are actually required to have a data protection programme in place?
Under Federal Decree-Law No. 45 of 2021 (the PDPL), obligations extend to any entity established in the UAE that processes personal data, and to entities outside the UAE that process personal data of individuals located in the UAE in specified circumstances, subject to defined exclusions. This covers the great majority of operating businesses — anyone with employees, customers, or website visitors is processing personal data. DIFC and ADGM-registered entities fall under those centres' own, separate data protection laws instead of the federal PDPL. PNPC confirms the applicable regime and scope for each specific business rather than assuming a default answer.
What is the difference between the federal PDPL, the DIFC Data Protection Law, and ADGM's Data Protection Regulations?
The PDPL is the federal law applying to mainland UAE and most free zones without their own dedicated data protection regime. DIFC and ADGM are financial free zones with their own independent legal systems, and each has enacted its own data protection law — the DIFC Data Protection Law and ADGM's Data Protection Regulations respectively — supervised by that centre's own regulator (the DIFC Commissioner of Data Protection and the ADGM Office of Data Protection). A group with a mainland trading entity and a DIFC-registered financial services arm can genuinely be subject to two different regimes for different parts of its operation. PNPC identifies which regime governs which entity at the outset of every engagement.
What counts as personal data under UAE law?
Personal data broadly means any information relating to an identified or identifiable natural person — names, Emirates ID and passport numbers, contact details, employment and financial records, IP addresses and device identifiers, and biometric data used for access control are all typically in scope. Certain categories — health data, biometric data, data revealing racial or ethnic origin or religious belief, and criminal record data — are commonly treated as sensitive personal data requiring a higher standard of protection and, in most regimes, a narrower set of lawful grounds for processing.
Do we need a Data Protection Officer, and can PNPC act as ours?
Whether a formal Data Protection Officer appointment is required depends on the applicable regime and the entity's processing volume, sensitivity of data handled, and risk profile — the specific threshold is set out in the applicable law and its implementing guidance. Where an appointment is warranted, PNPC advises on structuring the role, defining its reporting line and authority, and can provide external DPO advisory support under a specifically scoped retainer; this is distinct from a standing, in-house appointment with day-to-day operational authority, which the entity itself typically holds.
How do we know if a cross-border data transfer is permitted?
UAE data protection regimes generally restrict or place conditions on transferring personal data outside the UAE (or, for DIFC/ADGM entities, outside the relevant free zone) unless an adequate level of protection exists in the receiving jurisdiction or another recognised safeguard — such as appropriate contractual clauses or the data subject's explicit consent — is in place. PNPC reviews each actual transfer the business makes, including transfers to a group parent, an offshore team, or a cloud hosting provider, against the specific safeguard requirements of the applicable regime.
What is a Data Protection Impact Assessment (DPIA) and when do we need one?
A DPIA is a structured assessment of the privacy risks a specific processing activity creates, typically required or recommended before undertaking processing likely to result in higher risk to individuals — large-scale processing of sensitive data, systematic monitoring, or a new technology deployment with significant privacy implications, for example. PNPC assesses whether a given activity crosses the threshold warranting a DPIA under the applicable regime and, where it does, conducts the assessment before the activity goes live rather than as a retrospective exercise.
What rights do individuals have over their personal data under UAE law, and how should we handle a request?
UAE data protection regimes typically grant individuals rights including access to their personal data, correction of inaccurate data, deletion in specified circumstances, and objection to certain processing, among others defined by the applicable law. PNPC designs an internal workflow so a request reaching any part of the business — customer service, HR, a general email inbox — is recognised, routed to an accountable owner, and actioned within the relevant timeframe, with the response properly documented.
What should our breach response plan actually cover?
A functioning breach response plan defines how a suspected incident is detected and escalated internally, who is accountable for assessing its scope and severity, how containment is actioned, how the business determines whether a notification obligation to a regulator or affected individuals has been triggered under the applicable law, and how internal and external communication is managed. PNPC builds this plan around the entity's actual systems and team structure, and walks the relevant staff through it so the first time it is used is not during a live incident.
Does our privacy policy need to be published in Arabic as well as English?
UAE regulatory practice generally expects consumer-facing documentation, including privacy notices, to be accessible in a manner data subjects can genuinely understand, and Arabic-language availability is a common expectation for businesses serving UAE residents broadly, though the specific requirement can depend on the entity's sector, licensing authority, and audience. PNPC advises on the appropriate language approach for each specific business as part of the notice-drafting stage.
Can PNPC help if we already have a privacy policy but never checked whether it matches what we actually do?
Yes — this is one of the more common engagements we see. A business adopts a privacy policy, often based on a template or a group-standard document, and never verifies it against what its own website forms, CRM, and vendor relationships actually collect and share. PNPC runs a gap assessment comparing the published policy against actual data flows and remediates the mismatch, rather than starting the policy from scratch unnecessarily.
What penalties apply for non-compliance with UAE data protection law?
The PDPL and the equivalent DIFC and ADGM laws provide for administrative penalties for non-compliance, with the specific fine amounts and enforcement mechanics set out in implementing regulations and applied by the relevant supervisory authority based on the facts of each case. PNPC does not quote specific penalty figures in general advisory conversations, since enforcement practice and any prescribed amounts can be updated by regulation; we advise clients to treat proportionate compliance investment as materially lower-cost than remediation after a finding or breach.
How does data protection advisory interact with our IT security and cybersecurity measures?
Data protection law requires 'reasonable' or 'appropriate' technical and organisational security measures proportionate to the sensitivity of the data held, but does not itself prescribe specific technical controls — that is the domain of cybersecurity and IT risk management. PNPC's data privacy advisory identifies what needs to be protected and to what standard, and coordinates with (or refers into) technical cybersecurity work — access controls, encryption, network security — that implements the actual protection, rather than duplicating that technical scope itself.
Do employee records fall under the same data protection obligations as customer data?
Yes. Employee personal data — contracts, payroll, visa and Emirates ID details, performance records, and any biometric access-control data — is personal data like any other and is subject to the same lawful-basis, security, and rights obligations under the applicable regime, with employment-specific nuances (such as the basis for processing being tied to the employment relationship rather than standalone consent in most cases). PNPC's data-flow mapping specifically includes HR and payroll systems, which are frequently overlooked when a business focuses primarily on customer-facing data.
How does PNPC price a data privacy and protection advisory engagement?
PNPC charges a fixed, agreed advisory fee for the scoping, data-flow mapping, policy drafting, and roll-out phases, scoped to the entity's size, number of systems, and data complexity, and confirmed in writing before work begins. Ongoing retainer pricing for periodic review, new-processing assessments, and incident-response support is quoted separately once the initial scope is agreed.
What is the realistic timeline for building a data protection programme from scratch?
For a single-entity business with a moderate number of systems and no prior programme, PNPC's engagement — from scoping through policy roll-out — typically runs a small number of weeks, depending on how quickly internal stakeholders can be interviewed for the data-flow mapping stage. Groups with multiple jurisdictions, sensitive-data processing, or complex vendor relationships should expect a longer, phased engagement.
Can PNPC support us through a regulator inquiry or investigation related to data protection?
Yes. Where the UAE Data Office, the DIFC Commissioner of Data Protection, the ADGM Office of Data Protection, or another relevant authority raises an inquiry, PNPC supports the entity in responding accurately and drawing on the documented data inventory, policies, and processes already built — or, where no programme exists yet, helps assemble a credible response and remediation plan as quickly as the circumstances allow.
Does a non-financial free zone like JAFZA, DMCC, RAKEZ, or IFZA have its own data protection law, separate from the mainland?
No. Only the two financial free zones — DIFC and ADGM — have their own independent data protection law and regulator. Non-financial free zones such as JAFZA, DMCC, RAKEZ, IFZA, Meydan, RAK ICC, and Ajman Free Zone do not have a separate data protection statute; entities licensed in these free zones are governed by the federal PDPL in the same way a mainland entity is, even though their trade licence, ownership rules, and company law are administered by the free-zone authority.
What is the difference between a data controller and a data processor under UAE data protection law?
A controller is the entity that determines the purpose and means of processing personal data — typically the business collecting data from its own customers or employees. A processor is an entity that processes personal data on the controller's behalf and instructions, such as a payroll bureau, a cloud hosting provider, or an outsourced call centre. UAE data protection regimes place distinct obligations on each role, and a business acting as a processor for a client (a SaaS platform storing its customers' data, for example) has its own set of processor-specific obligations separate from its controller obligations for its own employee and vendor data.
If our data processor (a vendor) suffers a breach, is that our responsibility or theirs?
Both, in different ways. The processor typically has a contractual and, depending on the regime, statutory obligation to notify the controller promptly of any breach affecting the data it processes on the controller's behalf. The controller, however, generally retains the ultimate responsibility for assessing whether the breach triggers a notification obligation to a regulator or affected individuals and for managing that response, because the controller is the entity with the direct relationship to the data subject. A vendor contract silent on breach notification timelines leaves the controller unable to meet its own obligations promptly.
Does using WhatsApp Business or similar messaging apps to communicate with customers count as processing personal data?
Yes. Any collection, storage, or use of a customer's name, phone number, or conversation content through a messaging app used for business purposes is processing of personal data, and the same lawful-basis, security, and retention principles apply as they would to any other customer data channel. Businesses using messaging apps for order confirmations, customer service, or sales frequently treat the channel informally, but the data protection obligations do not change simply because the channel feels conversational rather than formal.
Are sole proprietorships and very small businesses exempt from PDPL obligations?
There is no blanket size-based exemption in the PDPL for sole proprietorships or small businesses as such — if the entity processes personal data of customers or employees, the same core obligations apply regardless of headcount. What does vary with size is the proportionate scale of the programme: a sole proprietorship with a handful of customers needs a materially lighter privacy notice, retention approach, and governance structure than a large retailer, but it is not exempt from the underlying obligation to handle personal data lawfully.
How does data privacy advisory interact with sector-specific rules like health data or banking data regulation?
Where a business's activity is also regulated by a sector-specific authority — health data under the relevant health authority's rules, financial and banking data under UAE Central Bank regulation — those sector rules typically layer on top of, and can be more specific than, the general PDPL, DIFC, or ADGM framework. PNPC's data-flow mapping identifies where sector-specific rules apply to a particular data category and coordinates the general privacy programme with any sector-specific requirement, rather than assuming the general framework alone is sufficient for regulated health or financial data.
Do we need a customer's explicit consent for every piece of data we collect, or can we rely on legitimate interest?
Not every processing activity requires explicit consent — UAE data protection regimes generally recognise multiple lawful bases, including contractual necessity, legal obligation, and legitimate interest, alongside consent. Which basis applies depends on the specific processing activity: fulfilling an order relies on contractual necessity, not consent; sending marketing communications typically does require a specific, freely given consent in most regimes. PNPC maps the correct lawful basis to each processing activity individually rather than defaulting to consent-for-everything, which both over-complicates the customer experience and misstates the actual legal basis being relied on.
Does a customer need to actively re-consent every time we update our privacy policy?
Whether re-consent is needed depends on the nature of the change. A clarifying update that does not change what data is collected or how it is used generally does not require fresh consent, though re-publishing the updated notice is good practice. A material change — a new category of data being collected, a new purpose, or a new third party the data is shared with — generally does require fresh notice and, where consent is the underlying lawful basis, fresh consent for the new activity specifically. PNPC reviews each policy update against this distinction before it is published.
How should we handle a data subject access request from a former employee?
A former employee's personal data — held for as long as the entity's retention schedule justifies, for example payroll and end-of-service records kept for a defined period after employment ends — remains subject to the same data subject rights as a current employee's data, including the right to request access. PNPC's data subject rights workflow is designed to route a request regardless of whether the individual is a current customer, current employee, or former employee, so a former staff member's request does not fall through a gap because no one is actively managing that relationship anymore.
Does the PDPL require personal data to be stored physically within the UAE (data localisation)?
The PDPL does not impose a blanket data-localisation requirement forcing all personal data to be stored on servers physically inside the UAE. What it does regulate is the conditions under which personal data can be transferred outside the UAE — requiring an adequate level of protection in the receiving jurisdiction or another recognised safeguard. Certain sector-specific rules (for example, some categories of banking or government-related data) can impose stricter localisation requirements separately from the general PDPL, which is why PNPC checks sector overlap alongside the general cross-border transfer analysis.
What does the UAE Data Office actually do, and how does it relate to sector regulators like the Central Bank or a health authority?
The UAE Data Office is the federal authority responsible for overseeing implementation of and compliance with the PDPL. Where a business's data processing also falls under a sector regulator's own rules — the UAE Central Bank for banking and financial data, or a health authority for patient data — that sector regulator's rules apply alongside the Data Office's general PDPL oversight, rather than one replacing the other. PNPC's scoping stage identifies which regulator(s) are actually relevant to a specific business's data processing, since more than one can be relevant simultaneously.
How does data privacy advisory work for a franchise or joint-venture arrangement where two businesses share customer data?
A franchise or joint-venture structure where two legally separate businesses both determine how shared customer data is used can create a joint-controller relationship, which typically requires the parties to have a clear, documented arrangement covering which party handles which obligation — who responds to a data subject request, who is responsible for the privacy notice, and how a breach affecting the shared data is managed. PNPC reviews the underlying franchise or joint-venture agreement specifically for this data-sharing dimension, which general commercial contract drafting frequently leaves unaddressed.
Does a mobile app that collects a user's location count as processing sensitive personal data?
Precise location data is generally treated as personal data requiring the same lawful-basis and security standard as other personal data, though it is not automatically classified in the narrower 'sensitive personal data' category (which typically covers health, biometric, racial/ethnic origin, religious belief, and criminal record data) unless the location data reveals something inherently sensitive, such as regular visits to a place of religious worship or a medical facility. PNPC's data-flow mapping specifically flags location data collection in any mobile app in scope, since it is one of the more commonly under-assessed data categories in app-based businesses.
What happens to customer and employee personal data during a merger, acquisition, or business sale?
Personal data transferred as part of a merger, acquisition, or business sale is still subject to the applicable data protection law, and the transfer itself needs a lawful basis — due diligence disclosure to a prospective acquirer typically relies on legitimate interest with appropriate safeguards (such as a confidentiality agreement and data minimisation during the due diligence phase), while the post-completion transfer of the full customer or employee database to the acquiring entity needs to be assessed against the applicable transfer and notice requirements. PNPC advises on structuring the data-handling terms of a transaction alongside the corporate and financial due diligence workstreams.
Should our business build its data protection programme before or after other compliance projects like AML/CFT or ESR?
There is no fixed universal sequence, but PNPC generally recommends confirming the entity's basic regulatory scope — which laws apply to which entity — as an early, shared step across data protection, AML/CFT, and other compliance workstreams, since the underlying group structure and licensing analysis overlaps. From there, the specific sequencing depends on which area carries the more immediate risk or deadline for a given business; a DNFBP facing an imminent AML/CFT inspection may need that workstream prioritised, while a business about to launch a new customer-facing app may need privacy addressed first.
Do we need to notify customers individually if we change our data hosting provider or move to a new cloud platform?
Whether individual notification is required depends on whether the change is material to how the business described its data handling in the existing privacy notice — moving to a materially different hosting location (particularly one outside the UAE where the prior notice specified UAE-based hosting) or a provider with different security or sub-processing arrangements would generally warrant an updated notice and, in some cases, a fresh assessment of the cross-border transfer basis. A like-for-like hosting change within the same jurisdiction and security standard is less likely to require individual notification, though updating the vendor list in the privacy notice is still good practice.
Can PNPC review our data protection programme as part of an investor or acquirer's due diligence process?
Yes. PNPC can conduct a data protection due diligence review specifically for a transaction context, assessing the target entity's data-flow mapping accuracy, policy-to-practice alignment, cross-border transfer documentation, vendor contract coverage, and breach history, and format the findings for inclusion in a due diligence report or data room. This is a distinct, typically faster-turnaround engagement from a full programme build, focused on identifying and quantifying gaps for the transaction rather than remediating every one of them before the deal closes.
Does PNPC's data protection advisory cover website accessibility or only backend data handling?
PNPC's engagement focuses on data protection compliance — what data a website collects, how it is used, and whether the notice and consent mechanisms match that collection — rather than website accessibility standards (readability for users with disabilities), which is a separate discipline. Where a client's accessibility work overlaps with privacy notice design (for example, ensuring a cookie consent banner is itself accessible), PNPC coordinates with the client's web team on that specific overlap rather than delivering accessibility compliance as part of the engagement scope.
What is the difference between a Data Protection Impact Assessment and a general data protection gap assessment?
A general gap assessment reviews the entity's overall data protection programme against applicable law — policies, consent mechanisms, vendor contracts, and governance — to identify where the existing programme falls short. A Data Protection Impact Assessment (DPIA) is narrower and forward-looking: it assesses the specific privacy risk of a single new or changed processing activity before it goes live, such as launching a new app feature or introducing a new monitoring tool. PNPC runs a gap assessment at the outset of most engagements and DPIAs specifically when a new higher-risk processing activity is being introduced or expanded.
How does PNPC handle a data protection engagement for a business with entities in both India and the UAE?
For groups with entities in both jurisdictions, PNPC's UAE data protection advisory focuses specifically on the UAE entity's obligations under PDPL, DIFC, or ADGM law as applicable, while coordinating — through PNPC's India offices where relevant — on how data flows between the Indian and UAE entities are structured. This is treated as two related but distinct compliance analyses rather than a single blended framework, since Indian and UAE data protection law are separate legal regimes with their own specific requirements.
If our business has no website and operates purely offline (a retail shop or a services office), do we still need a data protection programme?
Yes. Data protection obligations attach to the processing of personal data regardless of the channel — a retail shop collecting customer details for a loyalty programme, a services office keeping client files, or any business maintaining employee records is processing personal data whether or not it has an online presence. The absence of a website removes website-specific considerations like cookie consent, but does not remove the underlying obligation to handle customer and employee data lawfully, securely, and with an appropriate retention approach.
How does PNPC keep a client's data protection programme aligned as PDPL executive regulations and UAE Data Office guidance continue to develop?
PNPC's data privacy advisory team monitors updates to PDPL executive regulations, UAE Data Office guidance, and DIFC/ADGM data protection rule changes as part of the periodic review built into every ongoing advisory relationship. Where a regulatory development materially affects an existing client's programme — a new specific requirement for a particular sector, a clarified threshold for DPIAs, or an updated cross-border transfer mechanism — PNPC proactively flags the change and recommends the specific update needed, rather than waiting for the client's next scheduled review to raise it.
Can a business refuse a data subject access, correction, or deletion request, or is every request automatic?
No, a request is not automatic in every case — data protection regimes generally allow a controller to decline or limit a request in defined circumstances, such as where a statutory retention obligation requires the data to be kept, where the request is manifestly unfounded or excessive, or where fulfilling it would infringe another individual's rights. What is not acceptable is an undocumented, ad hoc refusal; PNPC's workflow requires every declined or partially fulfilled request to record the specific ground relied on, so the decision is defensible if the individual escalates it.
Do we need consent-management software, or can a simple cookie banner and a written policy be enough?
Whether dedicated consent-management software is warranted depends on the complexity of the business's tracking and marketing technology stack — a website running a handful of first-party cookies can often manage consent adequately through a well-built banner and clear notice, while a business running multiple third-party advertising pixels, retargeting tools, and cross-site tracking typically needs a consent-management platform to keep actual tracking behaviour in sync with what the visitor selected. PNPC assesses the technology stack first and recommends proportionate tooling rather than defaulting to a platform sale.
Does CCTV footage of customers in a retail store or office reception count as personal data?
Yes. CCTV footage that can identify an individual — a customer, visitor, or employee — is personal data, and its collection needs a lawful basis (typically legitimate interest for security purposes), proportionate retention (footage should not be kept indefinitely by default), and, in most regimes, visible signage informing individuals that recording is taking place. PNPC's employee monitoring and CCTV governance review covers customer-facing cameras as well as internal workplace monitoring, since both raise the same underlying obligations.
Can a business buy or rent a third-party marketing list and use it to contact new prospects in the UAE?
Using a purchased or rented contact list raises a lawful-basis question the business itself did not create — the individuals on that list gave whatever consent or notice they gave to the original collector, not to the business now contacting them, and that basis may not extend to a new, unrelated sender. PNPC reviews the provenance and terms of any third-party list before a client uses it for outbound marketing, since relying on someone else's undocumented consent is one of the more common and least defensible marketing practices we are asked to review.
Does sending marketing SMS or WhatsApp messages in the UAE also involve telecom regulator rules, not just data protection law?
Yes — commercial messaging in the UAE is also subject to telecommunications regulatory requirements administered by the UAE's telecom regulator, which layer on top of, rather than replace, the data protection lawful-basis analysis for using a customer's contact details for marketing. PNPC's marketing consent review checks both dimensions: whether the data protection basis for holding and using the contact detail is sound, and whether the messaging channel itself complies with the applicable telecom marketing rules.
If our business uses AI tools to score or profile customers automatically, does that raise different data protection obligations?
Automated processing that produces a decision with a significant effect on an individual — automated credit scoring, algorithmic pricing, or automated eligibility screening, for example — is typically treated as higher-risk processing warranting closer scrutiny, including consideration of whether a DPIA is required and whether the individual has a right to understand or contest the automated outcome. PNPC's data-flow mapping specifically flags any automated decision-making or profiling tool in use, since these are treated with more caution than routine data processing.
Is there a lighter-weight alternative to a full Data Protection Officer for a smaller business that still wants clear internal ownership?
Yes — where the formal DPO threshold is not reached, PNPC commonly recommends a named internal privacy owner or a small internal privacy committee with clearly defined responsibility for data subject requests, breach escalation, and reviewing new processing activity, without the full statutory DPO designation. This gives the business genuine accountability and a documented point of contact without over-engineering governance disproportionate to its size.
Does it matter where our cloud backup is stored if our primary system is already hosted in the UAE?
Yes. A cross-border transfer assessment needs to cover every location personal data is genuinely held, not only the primary production system — a UAE-hosted primary database with backups replicated to a data centre outside the UAE is still a cross-border transfer of that data, even though the business's day-to-day operational system appears to stay local. PNPC's data-flow mapping specifically asks about backup, disaster-recovery, and archival locations, which are frequently overlooked when a business describes its 'main' hosting location.
Do CVs and job applications from candidates who are not yet hired count as personal data we need to protect?
Yes. Recruitment data — CVs, interview notes, background-check results, and reference details — is personal data from the moment it is received, regardless of whether the candidate is ultimately hired, and is subject to the same lawful-basis, security, and retention obligations as employee data. A common gap is retaining unsuccessful candidates' CVs indefinitely with no defined retention period or purpose for keeping them.
What does a breach notification timeline actually look like in practice, once an incident is discovered?
Data protection regimes typically expect notification to a regulator, and in some cases to affected individuals, without undue delay once a breach is identified and its scope reasonably understood — in practice this means the first hours after detection matter far more than most businesses expect, since containment, initial scoping, and the decision on whether notification is triggered all need to happen quickly and in parallel, not sequentially. PNPC's breach response plan builds a realistic first-24-hours sequence, not just a policy statement that notification 'will occur promptly.'
Our overseas group parent wants a full export of our UAE employee data for a global HR system — what needs to happen first?
This is a cross-border transfer requiring the same assessment as any other — confirming the receiving jurisdiction's adequacy or an alternative safeguard, updating the internal privacy notice if employees were not previously told their data would be shared with an overseas parent system, and reviewing the group's data-sharing agreement for the specific obligations it places on each party. A request from a parent company does not itself provide a lawful basis; the transfer still needs to be properly assessed and documented like any other.
Does anonymising or pseudonymising customer data remove it from data protection obligations entirely?
Genuinely and irreversibly anonymised data — from which no individual can reasonably be re-identified — generally falls outside the scope of personal data protection obligations, but pseudonymised data (where identifying details are replaced with a code but the ability to re-link it to an individual still exists somewhere) remains personal data and stays fully in scope. PNPC reviews whether a business's claimed 'anonymised' analytics or reporting data is genuinely irreversible or merely pseudonymised before relying on that distinction.
How does data protection apply to an online marketplace seller operating through Amazon.ae, Noon, or a similar platform?
A UAE-based marketplace seller is typically a data controller in its own right for the customer order, contact, and delivery data the marketplace platform shares with it to fulfil orders, even though the platform itself also processes that data as a controller or processor for its own purposes. Sellers frequently assume the marketplace's own privacy policy covers them, when in practice the seller has its own separate obligations for how it stores, uses, and retains the customer data it receives through the platform.
What data protection considerations are specific to a UAE real estate brokerage or property management business?
Real estate businesses typically hold tenant and landlord personal data, Emirates ID and passport copies, financial and income information for tenancy applications, and Dubai Land Department or equivalent registration data, often shared with multiple third parties — mortgage providers, insurers, facility management companies — as part of a single transaction. PNPC's data-flow mapping for this sector pays particular attention to how many third parties a single tenancy or sale transaction actually passes personal data through, since the sharing chain is often longer than the business itself initially describes.
If our loyalty programme shares customer data with partner brands for joint offers, what needs to be documented?
Sharing loyalty-programme customer data with a partner brand for joint offers is a distinct disclosure requiring its own lawful basis and, in most cases, specific notice to the customer that their data may be shared with named partners for this purpose — a general 'we may share your data with partners' clause is weaker than a specific, transparent description of which partners and what data. PNPC reviews loyalty programme terms and consent flows specifically for this partner-sharing dimension.
If a customer asks us to delete their data, but Corporate Tax law requires us to keep records for seven years, which obligation wins?
A statutory retention obligation — such as the requirement under the Corporate Tax framework to retain relevant records for at least seven years — generally overrides a deletion request for the specific records that obligation covers, since data protection regimes typically permit a controller to decline deletion where retention is required by law. The correct response is not silent refusal, but a documented explanation to the customer that the specific financial or transaction records are retained under a defined statutory obligation, while any data outside that obligation's scope is still assessed for deletion on its own merits.
How should we respond if a customer publicly complains about our data handling on social media rather than contacting us directly?
A public complaint raising a genuine data protection concern — for example, an allegation that the business shared their data without consent — should be treated as triggering the same internal data subject rights or complaint-handling process as a direct request, routed to the accountable internal owner rather than handled purely as a reputational or customer-service matter on the social platform itself. PNPC's workflow design specifically includes social media and public channels as an intake point for this reason.
What does 'privacy by design and by default' mean in practice for a business building a new app or system?
Privacy by design and by default means considering data protection requirements at the point a new system, product, or feature is being designed — deciding what data actually needs to be collected, what the default privacy settings should be, and how long data will be kept — rather than building the system first and retrofitting privacy controls afterward. PNPC's DPIA and new-processing assessment stage exists specifically to apply this principle before launch, when design choices are still cheap to change.
Do we need explicit consent to take and use photos or videos of staff or customers at a company event?
Photography or video capturing identifiable individuals at a company event is personal data, and using it — for internal newsletters, social media, or marketing — generally needs either the individual's consent or a clearly communicated, proportionate basis (such as visible signage at the event stating that photography will occur and may be used for specified purposes) before publication, particularly for external-facing use. PNPC advises event organisers to build a simple notice-and-opt-out mechanism rather than assuming implied consent from attendance alone.
Do PDPL obligations still apply if the individual whose data we hold is a UAE resident who has since moved abroad?
The applicable data protection law generally continues to apply to personal data an entity established in the UAE holds, regardless of where the individual is currently located, since the obligation attaches to the processing entity and its handling of the data, not solely to the individual's current physical presence. PNPC treats a data subject's relocation as a reason to review whether continued retention still serves a genuine purpose, not as a basis to assume the obligation has lapsed.
Is a Data Protection Impact Assessment worth the cost for a business that is not sure it is legally required to do one?
Even where the formal DPIA threshold is genuinely borderline, PNPC often recommends conducting a lighter-form risk assessment before launching a new higher-risk processing activity, because the cost of the assessment is small relative to the cost of redesigning a live system that turns out to have a material privacy gap, or explaining after the fact why a foreseeable risk was never assessed. We scope the assessment's depth to the actual risk rather than defaulting to a full formal DPIA when a proportionate lighter review will do.
If two related family businesses share the same back-office IT system and staff, do they need two separate data protection programmes?
Generally yes, in substance if not always in every document — each licensed entity is typically its own controller for the personal data it processes, even where day-to-day IT infrastructure, HR administration, or back-office staff are shared across related businesses, and a single shared programme needs to clearly identify which entity is responsible for which data set and processing activity rather than treating the group as a single undifferentiated controller. PNPC's group entity reconciliation stage is designed specifically to draw this line clearly rather than let a shared back office blur legal accountability.
PNPC Data Privacy Advisory vs. a Typical Generic Approach
| Dimension | PNPC Data Privacy & Protection Advisory | Typical Generic / Template-Led Approach |
|---|---|---|
| Regime identification | Confirmed against the entity's actual licence, registration, and group structure | Often assumes one default regime without verification |
| Basis for the privacy policy | Drafted from an actual data-flow map of real systems and forms | Adapted from a generic template with minimal customisation |
| Cross-border transfers | Assessed transfer-by-transfer against the applicable safeguard requirement | Rarely addressed in specific, actionable terms |
| Vendor and processor contracts | Reviewed for data protection clauses and gaps remediated | Left unreviewed unless a vendor raises the issue first |
| Breach response readiness | Documented plan walked through with the actual team | A policy paragraph, never rehearsed |
| Data subject rights handling | Defined internal workflow with an accountable owner and timeframe | Referenced in text with no operational process behind it |
| Ongoing alignment | Scheduled review cadence and proactive regulatory-update monitoring | One-time document, rarely revisited |
| Independence | No referral ties to a specific software or consent-management vendor | Sometimes bundled with a vendor's own commercial product |
| Retention and disposal discipline | Documented schedule per data category, tied to actual need | Rarely addressed beyond a generic statement |
| Group / free-zone regime mapping | Entity-by-entity confirmation of which law actually applies | One group policy assumed to cover every entity uniformly |
| Employee monitoring and CCTV governance | Reviewed alongside biometric access control for lawful basis and proportionality | Left to IT/security with no privacy sign-off |
PNPC's advisory approach is built around defensibility — documentation and process that will actually hold up if a regulator, litigant, or breached customer asks to see it, not just a document that exists.
- 01
Regulatory scoping to confirm whether PDPL, DIFC Data Protection Law, or ADGM Data Protection Regulations apply to each entity in the group
- 02
Full data-flow mapping across HR, sales, marketing, IT, and finance functions
- 03
Lawful-basis review for each identified category of processing
- 04
Cross-border data transfer assessment and safeguard recommendations
- 05
Sensitive-data and DPIA threshold screening, with DPIAs completed where warranted
- 06
Privacy policy, internal data protection policy, and data subject notice drafting matched to actual practice
- 07
Vendor and processor contract review for data protection clause gaps
- 08
Data subject rights request handling workflow design
- 09
Documented, rehearsed breach response plan and escalation matrix
- 10
DPO structure advisory — internal appointment support or external advisory arrangement
- 11
Staff awareness training tailored to roles that actually handle personal data
- 12
Scheduled periodic review cadence to keep the programme aligned as the business and regulation evolve
- 13
Support through regulator inquiries, data subject complaints, and incident response
- 14
Coordination with technical cybersecurity resources where the gap identified is a technical control, not a policy or process gap
- 15
Group entity-to-regime reconciliation for businesses spanning mainland, non-financial free zone, and DIFC/ADGM entities, so no entity's obligations are silently assumed covered by another's programme
- 16
Data protection due diligence review formatted for a data room, investor questionnaire, or acquirer's counsel, distinct from a full remediation engagement
- 17
Joint-controller and franchise/joint-venture data-sharing clause review, allocating responsibility for notices, rights requests, and breach handling between parties
- 18
Named senior advisory contact accountable for the programme from initial scoping through to ongoing periodic review, not a rotating point of contact
- 19
Proactive flagging of material PDPL executive regulation, UAE Data Office, DIFC Commissioner, or ADGM Office of Data Protection updates relevant to the client's specific programme
Talk to PNPC before your privacy policy is tested by a regulator, a breach, or an investor's due diligence checklist — not after.
Jurisdiction
Free zone, mainland & offshore
Ready to get started?
Tell us about your requirement — a UAE specialist responds within 24 hours.