prompt-pack-privacy-policy

Category: General Risk: High risk ★ 3.9 · Rating 3.9/5 (8) sboghossian/mini-claude-for-legal MIT

Rating is derived from the repo's GitHub stars and shown for reference.

credential_access

name: prompt-pack-privacy-policy
description: Use when a lawyer or compliance officer needs to draft a comprehensive privacy policy for a company operating across one or more jurisdictions. Covers data collection, legal bases, retention, individual rights, international transfers, cookies, and privacy contact information. Particularly useful for MENA-operating businesses navigating UAE Federal Decree-Law No. 45 of 2021, Saudi PDPL, Lebanese data-protection norms, DIFC/ADGM Data Protection Law, and EU GDPR as applicable.
license: MIT
metadata:
id: prompt-pack.privacy-policy
category: prompt-pack
practice_area: privacy-data-protection
jurisdictions: [UAE, DIFC, ADGM, KSA, LB, EG, EU, UK]
priority: P2
intent: [drafting, privacy-policy]
related: [prompt-pack-cookie-policy, prompt-pack-data-processing-agreement, prompt-pack-regulatory-change-impact-assessment, heuristic-always-state-jurisdiction-first]
source: Louis — HAQQ Legal AI (github.com/sboghossian/mini-claude-for-legal)
version: "1.0"

Privacy Policy

When to use this

Use this skill when a client needs to publish or update a privacy policy for:

  • A new product, website, or mobile application going live in one or more jurisdictions.
  • An existing company responding to a new data-protection law (e.g., UAE PDPL, Saudi PDPL, DIFC DP Law 2020) that creates a fresh compliance obligation.
  • A cross-border SaaS or fintech platform whose users are spread across MENA, EU, and UK and whose policy must satisfy multiple regulators simultaneously.
  • An internal compliance gap: the company already processes personal data but has no adequate public-facing notice.

Do not use this skill as a substitute for full legal advice on complex data-sharing arrangements, data breach notification obligations, or regulatory registration requirements — it generates a strong first draft; a qualified privacy lawyer must review before publication.

Required inputs

Input Why it matters Sensible default if omitted
Company name and entity type Determines the legal controller identity and any local registration obligations Ask before drafting
Description of the business and data flows Defines what categories of personal data are collected, from whom, and why Ask: "What data do you collect, from which individuals, and what do you do with it?"
Jurisdictions of operation Each jurisdiction triggers different legal bases, rights, and disclosure obligations If omitted, draft for UAE (onshore) + DIFC as the minimum MENA baseline
Data retention periods Required by GDPR Art. 13, UAE PDPL, and DIFC DP Law Default: "as long as necessary for the stated purpose, and no longer than [X years]" with a note to specify
Contact details for privacy inquiries Required disclosure in every major data-protection law Ask; placeholder "[privacy@company.com]" if not provided

Optional inputs

  • Cookie and tracking technologies inventory — if present, enables a dedicated cookies section; otherwise use a high-level notice.
  • Third-party processors list — allows naming key processors (cloud hosts, analytics, payment processors) rather than generic reference.
  • Data Protection Officer (DPO) identity — mandatory for certain GDPR and DIFC-regulated entities.
  • Age restrictions / children's data — triggers COPPA-style or DIFC/UAE age-verification language.
  • Cross-border transfer mechanisms — Standard Contractual Clauses, adequacy decisions, DIFC Art. 27 approved transfers, KSA PDPL rules.

Document structure

  1. Introduction and controller identity — who is responsible for the data, registered address, regulatory context.
  2. Scope — what personal data, which individuals (customers, employees, website visitors), which services.
  3. Categories of personal data collected — identification data, contact data, financial data, usage/behavioral data, special categories (health, biometrics) if applicable.
  4. Purposes and legal bases for processing — table pairing each purpose with its legal basis (consent, contract, legitimate interests, legal obligation). This section is the most jurisdiction-sensitive.
  5. Data retention — specific periods per category, or criteria used to determine them.
  6. Disclosure to third parties — categories of recipients, processor vs. controller distinction.
  7. International data transfers — mechanisms used; specific language for each applicable jurisdiction (see Jurisdictional notes).
  8. Individual rights — access, rectification, erasure, portability, objection, restriction, withdrawal of consent; how to exercise them and response timescales.
  9. Cookies and tracking — types used, purposes, how to opt out; link to cookie policy if separate.
  10. Security — technical and organizational measures (keep general to avoid commitment to specific controls).
  11. Children's data — if the service is not directed at minors, a brief disclaimer; if it is, specific consent and parental approval language.
  12. Changes to this policy — how users will be notified of material changes.
  13. Contact and complaints — privacy team contact, right to lodge complaints with the applicable supervisory authority.

Jurisdictional notes

UAE — onshore (Federal Decree-Law No. 45 of 2021 on Personal Data Protection)

  • Applies to processing of personal data of UAE residents by entities in the UAE.
  • Requires a clear legal basis; consent must be explicit, informed, and withdrawable.
  • Cross-border transfers allowed only to countries with adequate protection or with specific safeguards (regulations still evolving as of 2026 — verify current status of the UAE Data Office implementing decisions).
  • Sensitive data (health, biometric, financial, genetic, etc.) requires additional protections.
  • Individual rights include access, correction, erasure, and restriction.

DIFC (Data Protection Law, DIFC Law No. 5 of 2020 as amended)

  • Applies to controllers and processors established in the DIFC.
  • Closely modeled on GDPR; six lawful bases; DPO mandatory for certain controllers.
  • Cross-border transfers under Art. 27: adequacy decision by the Commissioner, or contractual safeguards, or explicit consent.
  • 72-hour breach notification to the DIFC Commissioner of Data Protection.

ADGM (Data Protection Regulations 2021)

  • Administered by the ADGM Registration Authority; GDPR-equivalent structure.
  • DPO required for large-scale processing or special-category data.
  • Follows adequacy decisions closely aligned with UK GDPR post-Brexit list.

KSA — Saudi PDPL (Personal Data Protection Law, Royal Decree M/19 of 2021, effective September 2023)

  • Arabic-language policy copy may be required when directed at Saudi residents.
  • Requires explicit consent for sensitive data; purpose limitation strictly enforced.
  • Cross-border transfers require SDAIA approval or adequacy finding.
  • Penalties: up to SAR 5 million for violation; imprisonment for aggravated breaches.

Lebanon

  • No comprehensive data protection law in force as of 2026 (draft law pending); fallback to general privacy principles in Civil Code and specific sector rules (banking, telecom).
  • For MENA-facing businesses, DIFC or GDPR standards are recommended as the practical compliance baseline.

EU / GDPR (Regulation 2016/679)

  • Applies extraterritorially when targeting or monitoring EU residents.
  • Legal bases: Art. 6 (general), Art. 9 (special categories).
  • Data subject rights response: one month standard, extendable to three months.
  • SCCs (2021 version) or BCRs for transfers to third countries lacking adequacy.

UK GDPR (post-Brexit)

  • Substantially equivalent to EU GDPR; UK SCCs (IDTA) for transfers out of UK.
  • ICO is the supervisory authority.

Drafting standards

  • Write in plain language accessible to a non-lawyer reader; avoid unexplained legal jargon.
  • Use active voice and short sentences for the rights and contact sections — these are the parts users actually read.
  • Do not use [INSERT X] placeholders in the published draft; resolve every placeholder before handing to the client.
  • State the effective date and "last updated" date prominently.
  • Where multiple jurisdictions apply, structure the policy so the jurisdiction-specific supplement is clearly demarcated (e.g., an addendum for EU/UK users, another for DIFC users).
  • Avoid overly broad retention language ("we keep data as long as necessary") without tying it to specific periods — regulators treat vagueness as non-compliance.

Common mistakes

  • Asserting "legitimate interests" as a legal basis without a balancing test. In GDPR and DIFC contexts, document the balancing test separately; don't just cite the basis in the policy.
  • Ignoring the UAE PDPL cross-border transfer requirements. Companies often replicate GDPR SCCs wholesale without checking whether UAE-specific conditions are met.
  • No Arabic version for KSA-directed services. SDAIA expects a policy accessible to Arabic-speaking data subjects.
  • Children's data handled silently. Even if minors aren't the target audience, the policy must state the minimum age and what happens if an underage user is identified.
  • Generic "security measures" language. Avoid listing specific technical controls in the policy itself — this creates liability if controls change; say "appropriate technical and organizational measures" and point to your security documentation.
  • [[prompt-pack-saas-terms-of-service]]
  • [[prompt-pack-data-processing-agreement]]
  • [[prompt-pack-regulatory-change-impact-assessment]]
  • [[prompt-pack-regulatory-filing-checklist]]
  • [[heuristic-always-state-jurisdiction-first]]
  • [[heuristic-no-us-style-boilerplate-in-civil-law-jx]]