PRIVACY POLICY

Doorkee www.doorkee.co

Effective Date: 19 March 2026 Last Updated: 13 July 2026

1. Introduction

1.1. This Privacy Policy ("Policy") explains how DoorKee FZ-LLC ("Doorkee," "we," "us," "our," or the "Company"), a Free Zone Limited Liability Company registered in the Ras Al Khaimah Economic Zone (RAKEZ), United Arab Emirates, with registered office at FOAM0424, Compass Building, Al Shohada Road, Al Hamra Industrial Zone-FZ, Ras Al Khaimah, collects, uses, stores, discloses, and protects your personal data when you access or use our website at www.doorkee.co, our mobile applications, and any related services (collectively, the "Platform").

1.2. Doorkee is the UAE's first outcome-driven rental platform, connecting property owners and tenants to facilitate residential rental transactions. By using the Platform, you agree to the collection and use of your information in accordance with this Policy.

1.3. This Policy has been prepared in compliance with:

• UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data (the "UAE Data Protection Law");
• Applicable regulations issued by the UAE Data Office;
• Where applicable, the principles of the General Data Protection Regulation (EU) 2016/679 ("GDPR"), for users who may be residents of the European Economic Area.

1.4. If you do not agree with this Policy, you should not use the Platform.

2. Information We Collect

We collect different categories of personal data depending on how you interact with the Platform.

2.1. Account Registration Data

When you create an account, we collect:

• First name (required) and last name (optional);
• Email address (required);
• Password (never stored in plaintext; processed through Supabase Auth with bcrypt hashing);
• Phone number (collected during registration or identity verification);
• Login provider information, if you register via Google OAuth or Apple OAuth (we receive your name and email from the OAuth provider; we never receive or store your Google or Apple password).

2.2. Identity Verification (KYC) Data

When you perform certain actions on the Platform (such as shortlisting a property, scheduling a visit, placing an offer, or listing a property), you are required to complete identity verification. We collect:

• User type (owner or tenant);
• Nationality;
• Verification method selected (Emirates ID or passport)

• An image of your selected ID document. One file, JPG, PNG, or PDF, up to 5 MB. Stored encrypted at rest. Only authorised Doorkee staff can view them.

• Document details extracted during verification, including document ID number, full name as it appears on the document, and date of birth;
• Phone verification status (verified via one-time password sent to your email);
• Verification status (not started, in progress, pending, verified, or rejected).

2.3. Property Data

If you are a property owner listing a property, we collect:

• Property details: name, address, square footage, bedroom count, bathroom count, property type, furniture type, category, and description;
• Financial information: rental amount (annual rent in AED), preferred cheque count;
• Location data: latitude and longitude coordinates (if provided);
• Property documents: Ejari registration document, title deed, tenancy contract, and RERA permit number (all optional);
• Property images (uploaded to Supabase Storage);
• Amenity selections;
• Visit schedule: available dates and time slots for property viewings;
• Property management data: tenant type preferences, pet policy, tour approval type, community information, possession start date, and lease end date.

2.4. Offer and Transaction Data

When you place or receive rental offers, we collect:

• Offer details: offer amount, cheque count, preferred move-in date, offer change count, expiry time, and optional personal note (free-text message you may attach to your offer);
• Negotiated Offer details: negotiated offer amount and negotiated cheque count;
• Offer status history (decision pending, accepted, rejected, renegotiated, expired, not selected, withdrawn).

2.5. Payment Data

When you make payments on the Platform (e.g., reserve payments for fourth or subsequent offer changes):

• Payment processing: All payment card details are processed directly by Stripe, our PCI DSS-compliant payment processor. We never receive, access, or store your full card number, CVV, or PIN.
• Transaction records we store: transaction type, amount, currency (AED), Stripe payment intent ID, Stripe charge ID, Stripe payment method ID (a tokenised reference), transaction status, failure reason (if applicable), refund amounts, and refund dates.

2.6. Visit and Scheduling Data

When you book property viewings, we collect:

• Visit details: property visited, date, time slot, visit status (scheduled, completed, cancelled);
• Visit notes (if provided);
• Reminder status: when the last visit reminder was sent.

2.7. AI Concierge (Dara) Data

Our AI-powered rental concierge, Dara, collects and processes the following data to provide personalised assistance:

• Conversation history: all messages exchanged between you and Dara, including your questions, requests, and Dara's responses;
• User preferences learned from interactions: bedroom count preferences, budget range, preferred areas/communities, furniture preferences, and desired amenities;
• Journey stage: your current stage in the rental process (browsing, comparing, viewing scheduled, offered, accepted, rented, renewal window);
• Behavioural signals: shortlisted properties, rejected properties, objections raised (e.g., "too expensive," "too far"), positive signals (e.g., "looks good," "interested"), sentiment indicators;
• Relationship data: conversation count, relationship tier (stranger, acquaintance, regular, VIP), first interaction date, and deal completion date;
• Discussed topics: a record of up to 20 recent topics discussed with Dara;
• Tool usage: records of actions Dara performs on your behalf (property searches, pricing lookups, offer placements, viewing bookings), including the parameters used and results returned;
• Alert subscriptions: alert type, criteria, and preferred notification channel;
• Feedback: any upvotes or downvotes you provide on Dara's responses, along with context about the message being evaluated;
• Handoff request data: when you ask to speak to a Doorkee specialist (or accept a system-card offer to do so), we persist the handoff request, a short PII-redacted reason summary, the conversation ID, the routing lane, a 5-minute idempotency dedupe key, and (if applicable) the SLA-breach timestamp to the AI Concierge audit log. We also persist the offer-card surface state — when a card was shown to you (handoff.offered), when you dismissed it (handoff.dismissed), when the server's rate limiter prevented a re-offer (handoff.ratelimited), and when Dara asked the ambiguous-target clarifier (handoff.clarifier_asked) — so we can honour the rate-limit caps that prevent us from interrupting you with the same card repeatedly and so the clarifier is asked at most once per conversation;
• Frustration-target classification: when your message expresses frustration in a way that requires routing triage, Dara classifies whether the frustration target is Doorkee/Dara or an external entity (the rental market, a landlord, visa rules, etc.). We record only the classification outcome and which §15.10 rule fired, not a profile of you. The classification is used to decide whether to surface the offer card and is retained alongside the audit-log row above.

2.8. Search and Usage Data

We collect information about how you use the Platform:

• Search logs: search filter parameters and result counts (linked to your user ID if logged in, anonymous if not);
• Shortlist activity: properties you save to your shortlist;
• Analytics events: event type, associated metadata, and timestamps for actions such as searches, property views, offers, and conversation starts.

2.9. Lease and Property Management Data

If you have an active lease managed through the Platform, we collect:

• Lease details: lease type (new or renewal), start date, end date, monthly rent, security deposit, lease status, and lease document URL;
• Maintenance requests: issue type, description, notes, attachments, cost breakdowns (total, tenant, owner), resolution details, and dates;
• Invoices: invoice type (rent, service, maintenance), service description, amount, currency, billing date, due date, payment status, and receipt URL.

2.10. Technical Data

We automatically collect certain technical information when you use the Platform:

• IP addresses: collected for rate limiting purposes (to prevent abuse such as brute-force login attempts) and security monitoring. IP addresses are also logged in AI Concierge audit logs for security purposes;
• Device and browser information: collected via standard HTTP headers;
• Authentication cookies: Supabase session cookies required for login functionality (see Section 7 for details).

2.11. Company Data

If you represent a company on the Platform, we may collect:

• Company details: company name, email, phone number, and logo.

2.12. Broker Verification Data

If you register as a Broker through Doorkee's self-serve broker path (as defined in Section 2 of our Terms of Service), you must complete individual broker verification before you may publish any listing in that broker capacity. During this process we collect:

• An image of your RERA broker card (one file: JPG, PNG, or PDF, up to 5 MB);
• Your Broker Registration Number (BRN) — the individual broker identifier issued by the Real Estate Regulatory Agency (RERA), read from your card;
• Your office or brokerage name;
• Your brokerage trade licence number;
• The issue date and expiry date shown on your broker card.

Your BRN and brokerage trade licence number are read from the RERA broker card image you upload, so the source of those fields is your own RERA-issued document.

Storage and access. Your broker card image is held in a private storage bucket. It is not public and is not reachable through a public link; it is served only through short-lived signed links. Doorkee reviewers who hold the broker-verification permission can view the card in order to carry out the verification. Other Platform users do not see your broker card image, your trade licence number, or your card dates. A reviewer either marks you as verified — which lifts the suspension on publishing — or rejects the submission. If your broker card expires, your ability to publish as a broker is automatically suspended until you provide current details.

Cross-border transfer. Your broker card image and details are stored on Supabase, our database, authentication, and storage provider, in its Mumbai, India region (ap-south-1). Uploading your broker card therefore transfers a government-issued identity document outside the UAE. This transfer is made under the safeguards described in Section 10 (International Data Transfers), consistent with PDPL Article 22 on cross-border transfers. No new processor is introduced; Supabase already appears in the Section 10.1 table.

Lawful basis. We process your Broker Verification Data on the following bases under the UAE Data Protection Law:

• Contractual necessity (PDPL Art. 6(1)(b)): verification is a necessary step in providing the broker listing service you requested when you registered as a Broker;
• Legitimate interest (PDPL Art. 6(1)(f)): preventing unlicensed persons from advertising property through the Platform and protecting tenants and owners from dealing with an unverified broker. We balance this interest against your rights by limiting the data to what verification requires, holding the image privately, restricting access to verification reviewers, and honouring your right to object (see Section 8.6);
• Legal obligation (PDPL Art. 6(1)(c)): applies only to the retention of a transacting broker's records, under the RERA broker-licence retention obligation in Dubai Law No. 85 of 2006 (see Section 15.5).

We do not rely on legal obligation to collect your broker card; the RERA licensing duty falls on you as the broker, not on Doorkee as a platform.

Retention. If you do not complete broker verification, or you are verified but never complete a brokered transaction, your broker verification records are retained for as long as your account exists (including while it is dormant) and are not deleted on a fixed timer. An inactive account is kept in a dormant state and is reactivated when you next sign in. During dormancy we retain these records on the basis of our legitimate interest (PDPL Art. 6(1)(f)) in account security, identity re-verification on reactivation, and the prevention of fraudulent or recycled broker credentials. We delete your broker card image and the fields read from it when you delete your account or exercise your right to erasure (Section 8.3). If you are a verified Broker who completes at least one brokered transaction, your broker verification records are retained for five years after the broker relationship ends — treated as the later of your account closure or your last completed deal — under the RERA broker-licence retention obligation in Dubai Law No. 85 of 2006. The canonical statement of this five-year period is Section 15.5, which this section follows.

Deletion of images. When your broker card image is erased — on account deletion, on an erasure request, or at the end of the statutory retention window — it is deleted outright from storage, because an identity-document image cannot be reduced to a non-identifying form while the image is kept. We retain only non-identifying audit facts, for example that a verification check occurred and its outcome and date.

Your rights. You may object to the legitimate-interest processing described above and exercise your other rights under Section 8. To object, see Section 8.6 and contact the Data Protection Officer at dpo@doorkee.co.

Agency-Sourced Listings. This Section 2.12 describes the individual broker verification path. Agency-Sourced Listings (Section 5.3.7 of our Terms of Service) are governed by a separate agency arrangement, under which the agent contact and licence data arriving in a data feed is supplied by the Agency rather than collected through individual RERA broker-card verification; the full disclosure for how that agency-supplied data is processed will be added when that arrangement goes live.

3. How We Use Your Information

We use the personal data we collect for the following purposes:

3.1. Providing the Platform Service

• Creating and managing your account;
• Facilitating property listings, searches, and comparisons;
• Processing rental offers and Negotiated Offers between tenants and owners;
• Scheduling and managing property visits;
• Managing leases, maintenance requests, and invoices;
• Sending visit reminders and offer expiry notifications.

3.2. Payment Processing

• Processing reserve payments through Stripe for fourth and subsequent offer changes;
• Managing refunds for unsuccessful offers;
• Reconciling payment records;
• Maintaining transaction history for your records and our legal obligations.

3.3. AI Concierge Personalisation

• Powering Dara, our AI concierge, to provide personalised rental recommendations;
• Learning your preferences from conversations and tool interactions to improve suggestions over time;
• Tracking your journey stage to provide contextually relevant assistance;
• Generating proactive insights such as price drop alerts and new listing matches;
• Providing market data, pricing intelligence, and negotiation guidance based on Dubai Land Department (DLD) data;
• Routing handoff requests to a Doorkee specialist when you ask to speak to one or accept a system-card offer to do so, including classifying whether a frustration signal points at Doorkee/Dara or at an external target so we can decide whether to surface the offer card.

3.4. Identity Verification and Fraud Prevention

• Verifying user identities before allowing sensitive actions (offers, listings, visits);
• Preventing duplicate accounts and fraudulent activity;
• Rate limiting login attempts, registration, and password reset requests to prevent brute-force attacks;
• Auditing AI Concierge tool executions for security review.

3.5. Communications

• Sending transactional email notifications via Resend for events including: new offers received, offer status changes, visit confirmations, visit reminders, verification status updates, and property approval decisions;
• Sending alert notifications based on your subscriptions (price drops, new listings matching your criteria, renewal reminders, market shifts).

3.6. Analytics and Service Improvement

• Analysing search patterns and user behaviour to improve Platform features;
• Monitoring AI Concierge quality through feedback aggregation and response scoring;
• Running A/B experiments on AI Concierge prompts to improve response quality;
• Generating market intelligence from aggregated, anonymised usage patterns;
• Monitoring errors and Platform health through Sentry.

3.7. Legal Compliance

• Complying with UAE laws and regulations, including anti-money laundering requirements;
• Responding to lawful requests from government authorities and law enforcement;
• Establishing, exercising, or defending legal claims;
• Maintaining records as required by applicable law.

3.8. Legal Basis for Processing

We process your personal data on the following legal bases under the UAE Data Protection Law:

• Contractual necessity: Processing required to provide the Platform services you have requested (Sections 3.1, 3.2, 3.5), including routing your handoff requests to a Doorkee specialist when you ask to speak to a human or accept a system-card offer to do so. The handoff request, a short PII-redacted reason summary, the conversation ID, the routing lane, and the SLA-breach timestamp are persisted to ConciergeAuditLog for the audit retention period (Section 6.8). Legal basis: PDPL Art. 6(1)(b);
• Legitimate interest: Processing for security, fraud prevention, analytics, and service improvement (Sections 3.4, 3.6), including classifying whether a frustration expression points at Doorkee/Dara or at an external target for operational triage (we record only the classification outcome, not a profile; we balance this against your interests by not using the outcome for advertising or third-party sharing and by honouring objection requests via the DPO contact in Section 12). Legal basis: PDPL Art. 6(1)(f);
• Legal obligation: Processing required to comply with applicable laws (Section 3.7);
• Consent: Processing of optional data and AI Concierge personalisation (Section 3.3). You may withdraw consent at any time (see Section 8).
• Broker verification (split basis): Collecting and verifying Broker documents (Section 2.12) is processed under contractual necessity (PDPL Art. 6(1)(b)) for the broker listing service you requested, together with our legitimate interest in platform integrity and in preventing unlicensed advertising (PDPL Art. 6(1)(f)), balanced as described in Section 2.12. The five-year retention of a transacting Broker's records is processed under a legal obligation (PDPL Art. 6(1)(c)) per Dubai Law No. 85 of 2006, and applies only at the retention stage, not at the point of collection.

4. Information Sharing and Disclosure

We share your personal data only in the following circumstances:

4.1. Between Platform Users

• Tenants and owners: When you place an offer on a property, the property owner can see your first name and offer details (amount, cheque count, preferred move-in date). Full property addresses are visible on listings. Contact details are shared only after a deal is accepted.
• Visit scheduling: When you book a visit, the property owner is notified of the scheduled date and time.

4.2. Payment Processor — Stripe

We share necessary transaction data with Stripe, Inc. (headquartered in the United States) to process payments. Stripe is PCI DSS Level 1 certified. Stripe's handling of your data is governed by Stripe's Privacy Policy. Data shared includes: transaction amounts, currency, and payment method tokens. We never share your full card details with Stripe through our systems; those are collected directly by Stripe's secure payment elements.

4.3. Email Provider — Resend

We share your email address and notification content with Resend to deliver transactional emails (offer notifications, visit reminders, verification updates). Resend processes this data solely for email delivery on our behalf.

4.4. AI Service Providers

To power Dara, our AI concierge, we transmit conversation data to the following AI model providers:

• Anthropic (Claude models) — headquartered in the United States;
• OpenAI (GPT models) — headquartered in the United States;
• Google (Gemini models) — headquartered in the United States.

The data sent to these providers includes: your conversation messages, relevant context about your preferences and journey stage, and the results of tool calls. These providers process the data to generate AI responses and do not use your data to train their models (per our enterprise agreements). Conversations are routed to different providers based on complexity (simple queries, complex analysis, or image-based requests).

4.5. Cloud Infrastructure — Supabase

All Platform data is stored on Supabase infrastructure, which provides our PostgreSQL database, user authentication, and file storage services. Supabase data is hosted in our Mumbai, India region (ap-south-1).

4.6. Error Monitoring — Sentry

We use Sentry for error monitoring and application performance tracking. When errors occur, Sentry may receive technical context including: error messages, stack traces, request URLs, and anonymised user identifiers. Sentry does not receive your personal content or conversations.

4.7. Rate Limiting — Upstash Redis

We use Upstash (Redis-based) for rate limiting to prevent abuse of authentication endpoints. Upstash stores only rate limit counters keyed by hashed IP addresses. No personal content, names, or email addresses are sent to Upstash.

4.8. Hosting — Vercel

The Platform is hosted on Vercel. Vercel processes HTTP requests and may have access to IP addresses and request headers as part of standard hosting infrastructure.

4.9. Law Enforcement and Legal Requirements

We may disclose your personal data to law enforcement agencies, regulatory authorities, or other third parties if required to do so by law, court order, or legal process, or if we believe in good faith that such disclosure is necessary to:

• Comply with applicable law or regulation;
• Protect our rights, property, or safety, or that of our users or the public;
• Investigate or prevent suspected fraud or illegal activity.

4.10. Business Transfers

In the event of a merger, acquisition, reorganisation, or sale of all or a portion of our assets, your personal data may be transferred to the acquiring entity. We will provide notice before your personal data becomes subject to a different privacy policy.

4.11. No Sale of Personal Data

We do not sell your personal data to third parties. We do not share your personal data with third parties for their independent marketing purposes.

5. Data Security

We implement the following technical and organisational measures to protect your personal data:

5.1. Encryption

• All data transmitted between your device and our servers is encrypted using HTTPS/TLS;
• Data at rest in our database is encrypted by Supabase's infrastructure.

5.2. Database Security

• Row Level Security (RLS): Our PostgreSQL database enforces row-level security policies, ensuring that users can only access data they are authorised to view. RLS policies are enforced at the database level, independent of application code;
• Parameterised queries: All database queries use Prisma ORM with parameterised inputs to prevent SQL injection attacks.

5.3. Authentication Security

• Password hashing: Passwords are hashed using bcrypt via Supabase Auth. We never store plaintext passwords;
• Account enumeration prevention: Login, registration, and password reset responses are designed to prevent attackers from determining whether an account exists;
• Rate limiting: Authentication endpoints (login, register, forgot password) are rate-limited to 6 attempts per minute per IP address to prevent brute-force attacks;
• Secure session management: Authentication sessions are managed via Supabase with HTTP-only, secure cookies;
• OAuth security: Google and Apple OAuth flows use validated redirect URLs with origin checking to prevent open redirect attacks.

5.4. Access Controls

• Role-Based Access Control (RBAC): Administrative access is controlled through a granular permission system with roles, modules, and permissions;
• Admin portal separation: The admin login portal is separated from the user login portal, with server-side enforcement;
• Deactivated account enforcement: Deactivated accounts cannot log in, even with valid credentials.

5.5. AI Concierge Security

• Prompt injection protection: Dara includes defences against prompt injection attacks;
• Tool execution auditing: All actions Dara performs on behalf of users are logged to an audit trail with user ID, IP address, tool name, parameters, and results;
• Access control: User conversations are private; authenticated users can only access their own conversation history;
• Message role validation: Conversation messages loaded from the database are validated to prevent instruction injection;
• Input sanitisation: User inputs are sanitised before storage to prevent cross-site scripting and injection attacks.

5.6. Infrastructure Security

• Rate limiting: All API endpoints are protected by rate limiting via Upstash Redis, with per-process fallback keys;
• CRON job authentication: Scheduled background tasks (offer expiry, payment reconciliation, conversation cleanup) are protected by timing-safe secret verification;
• Origin validation: Email redirect URLs are validated against an allowlist of trusted origins.

6. Data Retention

We retain your personal data for the following periods:

6.1. Account Data

Your account data (name, email, phone, user type) is retained for as long as your account remains active. You may request deletion of your account at any time (see Section 8).

6.2. Identity Verification Data

Verification documents and identity information are retained for as long as your account remains active and for any additional period required by UAE anti-money laundering or know-your-customer regulations.

6.3. Conversation History

• Anonymous conversations (from users who are not logged in): Automatically deleted after 30 days by our scheduled cleanup process;
• Authenticated user conversations: Retained until you request deletion of your account.

6.4. AI Concierge Memory

User preferences, journey state, behavioural patterns, and relationship data are retained until you:

• Request a preference reset (clears search preferences but preserves relationship data); or
• Request full account deletion (complete data erasure compliant with privacy regulations).

6.5. Soft-Deleted Records

When certain records are "deleted" on the Platform (properties, offers, shortlists, visits, leases, maintenance requests, invoices), they are soft-deleted — marked with a deletion timestamp but retained in the database for audit and legal compliance purposes. Soft-deleted records are hidden from the user interface.

6.6. Payment and Transaction Records

Payment transaction records are retained in accordance with UAE financial record-keeping requirements, which may require retention for a minimum period after the transaction date even after account deletion.

6.7. Search Logs and Analytics

Search logs and analytics events are retained for platform improvement purposes. These may be anonymised after 12 months.

6.8. Audit Logs

Doorkee maintains two categories of audit logs in the ConciergeAuditLog table: AI Concierge tool-execution records (every tool call Dara makes on your behalf) and cookie-choice records (every notice dismissal, opt-out, or opt-in action you take through the first-visit cookie notice or the Cookie preferences page).

These rows are retained for 5 years (1,825 days) and then anonymised in place — your userId, IP address, user-agent string, and any personal data carried inside the audit row's toolArgs payload are set to NULL. The tool name, timestamp, and outcome remain so we can investigate security incidents, fraud patterns, and AML flags after the fact. The right_to_erasure_executed action carries a 7-year retention window before anonymisation, in line with the audit-trail requirements of UAE Federal Decree-Law No. 20 of 2018 (Anti-Money Laundering).

Effect on Right to Erasure (Art. 17): when you exercise your right to have your personal data erased (described in §8.3), Doorkee removes your identifying information from the audit rows but does not delete the rows themselves. After anonymisation the rows are reduced to a form that no longer reasonably identifies a natural person under PDPL Art. 1 (the definition requires that the data identify, or be reasonably capable of identifying, a natural person), so their retention is consistent with both Art. 14 (data minimisation satisfied by anonymisation) and Art. 26 (retention for compliance with a legal obligation — here, AML/CFT and cybercrime investigation).

This is one of a small number of narrowly-scoped Art. 17 retention carve-outs Doorkee asserts, alongside the KYC retention described in §6.2 and the financial-record retention described in §6.6. All other personal-data fields tied to your account — including profile data, KYC documents, property listings, offers, transactions, and lease records — are erased or anonymised on the schedule described elsewhere in §6.

6.9. Broker Verification Data

Broker verification data (Section 2.12) is retained for as long as your account exists, including while the account is dormant; it is not deleted on a fixed timer. An inactive account is kept dormant and reactivated when you next sign in, and during dormancy the records are held under our legitimate interest (PDPL Art. 6(1)(f)) in account security, re-verification, and fraud prevention. The broker card image is deleted when you delete your account or exercise your right to erasure. A verified Broker who completes at least one brokered transaction has their broker verification records retained for five years after the broker relationship ends (the later of account closure or last completed deal), under the RERA broker-licence retention obligation in Dubai Law No. 85 of 2006. On erasure or at the end of the statutory window, the broker card image is deleted outright rather than anonymised in place, because an identity-document image cannot be made non-identifying while the image survives. The canonical retention statement is Section 15.5.

7. Cookies and Tracking Technologies

7.1. Cookie Categories and How They Are Governed

Doorkee uses four categories of cookies and similar technologies. We tell you about them through a first-visit notice and the always-available Cookie preferences page (linked in the footer). We do not ask you to "accept" analytics before you can use the site. Instead we give you clear notice and an easy way to opt out.

• Strictly necessary — always on. Required for authentication, payment processing, CSRF protection, session management, security, and error monitoring. This category includes Sentry (error monitoring), which runs on every visit to keep the Platform secure and working. You cannot disable this category while using authenticated features of the Platform. Legal basis: processing necessary to perform the contract and to protect the security and integrity of the Platform, which does not require your consent (PDPL Art. 6(1)(b) together with the Article 4 grounds for processing without consent).
• Analytics — on by default, opt out any time. Product analytics (Google Analytics 4, Google Tag Manager, and PostHog Inc.) measure how the Platform is used so we can fix problems and improve the product and Dara. This category is enabled by default. You can turn it off at any time on the Cookie preferences page in the footer, and the scripts stop loading on your next page load. Legal basis: our legitimate interest in operating and improving the Platform, balanced against your rights and paired with clear notice and a one-click opt-out (PDPL Art. 6(1)(f)).
• Session recording — off by default, opt in. Session recording (Microsoft Clarity and PostHog session recording) captures how you move through the site, such as clicks, scrolls, and page navigation. Anything you type is masked by default. This category is separate from analytics, so turning analytics on does not turn session recording on. It stays off until you explicitly turn it on. Legal basis: your explicit consent (PDPL Article 6 consent conditions).
• Marketing — off by default, opt in. Reserved. Reserved for future ad-campaign measurement. We do not currently run any paid ad campaigns, and no tool is active in this category today. It stays off until you explicitly turn it on. Legal basis: your explicit consent for marketing (PDPL Article 9).

The dk_pdpl_v1 cookie that records your choice is itself a strictly necessary cookie and is set with HttpOnly=false so the in-page notice and the Cookie preferences page can read it directly without an extra round-trip to the server. The cookie carries no identifiers, no tracking value, and no personal data — only the booleans analytics, session_replay, marketing, a timestamp, and a version. The authoritative copy of the choice (with your user ID and IP) lives in the server-side record described in §7.2; the cookie is the read-only mirror.

7.2. How Your Choice Is Recorded

When you dismiss the first-visit notice or change a setting on the Cookie preferences page, your choice is stored in two places:

• A first-party cookie dk_pdpl_v1 on your device (12-month expiry). This is the client-side gate that enables or disables the analytics, session-recording, and marketing scripts.
• A server-side record (a ConciergeAuditLog entry) including the timestamp, your user ID (if signed in, otherwise null), IP address (for anti-abuse), and your per-category choice. We keep this record so we can demonstrate, under our PDPL Article 5 accountability duty, that you were given notice, that we honoured any opt-out, and that any opt-in you gave for session recording or marketing was recorded (PDPL Art. 6 proof-of-consent, for the opt-in categories).

7.3. Default Posture

Analytics (Google Analytics 4, Google Tag Manager, PostHog Inc.) is on by default. Session recording (Microsoft Clarity, PostHog session recording) and marketing are off by default and load only if you explicitly turn them on. Error monitoring (Sentry) and the other strictly necessary cookies are always on. Until you interact with the first-visit notice, analytics runs and session recording and marketing stay off. Dismissing the notice records this default posture so we do not show the notice again.

7.3a. Cross-Border Transfers from Cookie and Messaging Providers (PDPL Art. 22)

The following providers receive limited usage or messaging data and may process it outside the UAE. Analytics providers run by default under the notice-and-opt-out model in §7.1; session-recording providers run only if you opt in. We disclose the controllers and processing locations here so you are informed:

• Google Tag Manager and Google Analytics 4 — operated by Google Ireland Limited (controller for users in the EEA, the UK, and Switzerland) on behalf of Google LLC (US). Tag Manager is a script-loading container; the tags it loads are limited to product analytics (Google Analytics 4 and PostHog Inc.) and, where you have opted in, session recording (Microsoft Clarity). Google Analytics 4 is configured in analytics-only mode: Google Signals, Google advertising features, and data-sharing with Google advertising products are turned OFF in the GA4 configuration, so no behavioural advertising tags are loaded. Data transferred via Google's infrastructure is processed in the United States and the European Union under Google's cross-border transfer mechanisms (EU Standard Contractual Clauses, the EU-US Data Privacy Framework, and equivalent UK/Swiss safeguards). Reference: https://policies.google.com/privacy.
• Microsoft Clarity — operated by Microsoft Ireland Operations Limited (controller for users in the EEA, the UK, and Switzerland) on behalf of Microsoft Corporation (US). Clarity is part of the session-recording category and loads only if you opt in (§7.1). It records interaction metadata (clicks, scrolls, page navigation) and builds aggregated heatmaps, with text you type masked by default. Data is processed in the United States and the United Kingdom under Microsoft's Data Protection Addendum, EU Standard Contractual Clauses, and the EU-US Data Privacy Framework. Reference: https://privacy.microsoft.com/privacystatement.

• PostHog Inc. — operated by PostHog Inc. (United States), the analytics processor for both server-side and in-browser product analytics events. Doorkee is the controller; PostHog Inc. is the processor under a Data Processing Addendum. Data minimisation: server-side events transmit a one-way truncated pseudonymous identifier in place of the raw user ID (see §7.3b); the identifier is a 16-character hex digest produced by keyed HMAC-SHA-256 using the server-side TELEMETRY_HASH_SECRET. On production deployments this keying is mandatory and fail-closed: if the secret is missing or invalid, the platform refuses to emit the event at all and the misconfiguration is tagged in our internal monitoring (Sentry alert_category: hash_salt_rotation) — no unkeyed identifier is transmitted from production. The digest is one-way and is not reversible without prior knowledge of the original user ID and the server-side secret. In-browser analytics events fire by default and stop when you opt out of analytics (§7.1); PostHog session recording is part of the separate opt-in session-recording category and fires only if you opt in, with typed input masked by default. Retention: configured to honour the $delete_user Personal Data API on DSAR completion (see §15.6). Cross-border safeguards: EU Standard Contractual Clauses + EU-US Data Privacy Framework. Reference: https://posthog.com/privacy.
• Meta WhatsApp (Cloud API) — operated by Meta Platforms Ireland Limited (controller for users in the EEA, the UK, and Switzerland) on behalf of Meta Platforms, Inc. (US). Doorkee is the controller for the conversation content; Meta is the processor for delivery and Cloud-API metadata. Data minimisation: Doorkee transmits only the recipient phone number, message body, and template ID required to deliver the message; no PostHog identifier or other analytics data is shared. Retention: subject to Meta-side platform retention floors (described in §15.6 row "Meta WhatsApp") that Doorkee cannot override. Cross-border safeguards: EU Standard Contractual Clauses + EU-US Data Privacy Framework. Reference: https://www.whatsapp.com/legal/business-data-transfer-addendum.
• Resend Inc. — operated by Resend Inc. (United States), the transactional and lifecycle email delivery processor. Doorkee is the controller; Resend Inc. is the processor under a Data Processing Addendum. Data minimisation: only recipient email address, subject, body, and delivery-status metadata are transmitted. Retention: 30 days for delivery logs (see §15.6 row "Resend"). Cross-border safeguards: EU Standard Contractual Clauses + EU-US Data Privacy Framework. Reference: https://resend.com/legal/privacy-policy.

These transfers are made under the safeguards described in §10 (International Data Transfers). Analytics providers run by default under the notice-and-opt-out model; session-recording providers run only after you opt in. Turning a category off (see §7.4) stops the corresponding scripts from loading on subsequent page loads. Server-side analytics events operate under a PDPL Art. 4 lawful basis rather than the cookie toggle, as described in §7.3b.

7.3b. Server-Side Analytics Identifiers (PDPL Art. 4 lawful-basis processing)

Some analytics events fire from server contexts that have no cookie or consent state available — for example, payment-processor webhooks (Stripe), background jobs (Inngest), and admin actions. These events are processed under PDPL Art. 4 lawful-basis grounds (fraud prevention, contract performance, and operational reliability) rather than under the consent regime in §7.3.

For these events, Doorkee transmits a one-way truncated pseudonymous identifier — derived from your user ID — as the analytics distinctId, in place of the raw user ID. The identifier is a 16-character hex digest produced by keyed HMAC-SHA-256 using the server-side TELEMETRY_HASH_SECRET. On production deployments this keying is mandatory and fail-closed: if the secret is missing or invalid, the platform refuses to emit the event rather than fall back to a weaker digest, and the misconfiguration is tagged in our internal monitoring (Sentry alert_category: hash_salt_rotation) so the operations team can restore the secret. The digest is one-way and is not reversible without prior knowledge of the original user ID and the server-side secret. PostHog Inc. cannot recover your identity from it. For server-side payment events emitted from payment-processor webhooks (for example payment succeeded, payment failed, and refund events), internal record identifiers in the event payload — offer, transaction, and payment-processor reference IDs — are likewise transmitted only as keyed 16-character truncated digests produced with the same secret, never as raw values.

In-browser analytics scripts continue to honour the cookie consent toggle described in §7.3 above. PostHog Inc. is the analytics processor for both server-side and in-browser events; cross-border safeguards are addressed in §7.3a.

7.4. Changing Your Choice

You can change your cookie settings at any time:

• Via the "Cookie preferences" link in the Platform footer.
• By clearing your browser cookies (which removes dk_pdpl_v1 and re-shows the first-visit notice on your next visit).
• By contacting the Data Protection Officer at dpo@doorkee.co.

Turning off analytics, session recording, or marketing stops the corresponding scripts (Google Analytics 4, Google Tag Manager, PostHog Inc., Microsoft Clarity) from loading on subsequent page loads. Scripts already loaded into the current page continue running until you navigate or refresh; you can force immediate effect by reloading the page.

7.5. No Third-Party Advertising Cookies

We do not currently use behavioral advertising cookies, tracking pixels, or programmatic ad-retargeting technologies. If this changes, the privacy policy will be updated and a new consent prompt will be issued before any new category is activated.

7.6. Data Protection Officer

Questions about cookies, data processing, or your PDPL rights: dpo@doorkee.co.

8. Your Rights

Under the UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data, and where applicable under the GDPR, you have the following rights regarding your personal data:

8.1. Right of Access

You have the right to request confirmation of whether we process your personal data and to obtain a copy of that data. Much of your data is directly accessible through your Platform account (profile, offers, visits, conversations, shortlists).

8.2. Right to Rectification

You have the right to request correction of inaccurate or incomplete personal data. You can update your profile information directly through the Platform. For corrections to verification data, please contact us.

8.3. Right to Erasure (Right to Be Forgotten)

You have the right to request deletion of your personal data, subject to our legal obligations to retain certain records. When you request account deletion:

• Your profile identity data is anonymised (name, email, phone, and profile photo);
• Your AI Concierge memory is permanently erased;
• The free-text personal data you authored on records we must keep is scrubbed, including any personal note on an offer, your property listing descriptions and internal notes, your maintenance-request descriptions, notes, and attachments, your viewing-visit notes, and any invitee email you captured through a referral;
• Uploaded identity and verification documents are removed, including any broker RERA card image and office name, and on our primary erasure path the stored files are deleted;
• Certain records are retained where the law requires it, with the personal-data columns minimised: your financial and transaction records (UAE AML/CFT, Federal Decree-Law No. 20 of 2018), your lease and broker-licence records (RERA, Dubai Law No. 85 of 2006), your KYC nationality attribute (AML customer-identification), and a property's address as a commercial-asset record (Federal Decree-Law No. 32 of 2021). The completion notice you receive names which categories were anonymised and which were retained on a legal basis;
• The audit-trail record proving your erasure took place is itself retained under our legal-obligation basis (PDPL Art. 24) and is not deleted by the erasure.

8.4. Right to Data Portability

You have the right to request your personal data in a structured, commonly used, and machine-readable format. You request an export through the account data-rights form, and we deliver a JSON file of the data we hold about you. The export includes your profile, your verification status and nationality, your properties (including their address and description), your offers (including any personal note), your viewing visits (including any note), your transactions, your leases, your maintenance requests, your saved shortlist, your search history, your alert subscriptions, the referrals you sent (including the invitee email you provided), a summary of your Dara conversations (channel and message count), and, if you are a broker, your broker professional identity (broker and company name, office name, and licence number).

For security and to protect other people, the export deliberately excludes a few categories. It does not re-export your uploaded identity documents or the identity fields extracted from them (you already hold your own ID). It does not include document image files such as the lease PDF, the broker RERA card, or maintenance attachments. It does not include internal security or audit logs, and it does not include data about other people (for example another party to a lease or another broker's listings). The full contents and exclusions are recorded in the DPO disposition memo.

8.5. Right to Restrict Processing

You have the right to request restriction of processing of your personal data in certain circumstances, such as when you contest the accuracy of the data or object to its processing.

8.6. Right to Object

You have the right to object to processing of your personal data based on our legitimate interests. If you object, we will cease processing unless we demonstrate compelling legitimate grounds that override your interests.

8.7. Right to Withdraw Consent

Where we process your data based on consent (such as AI Concierge personalisation), you may withdraw your consent at any time. Withdrawal of consent does not affect the lawfulness of processing carried out before the withdrawal. You can:

• Reset your AI Concierge preferences through a conversation with Dara;
• Request full data erasure by contacting us;
• Discontinue use of the Platform.

8.8. Exercising Your Rights

To exercise any of these rights, contact us at:

• Email: support@doorkee.co
• Subject line: "Data Privacy Request — [Your Right]"

We will respond to your request within 30 days. We may request verification of your identity before processing your request to protect your data from unauthorised access.

8.9. Right to Lodge a Complaint

If you believe your data protection rights have been violated, you have the right to lodge a complaint with the UAE Data Office or, if applicable, a supervisory authority in the European Economic Area.

9. Children's Privacy

9.1. The Platform is not intended for use by individuals under the age of 18. We do not knowingly collect personal data from children under 18.

9.2. If we become aware that we have collected personal data from a child under 18, we will take immediate steps to delete that data from our systems.

9.3. If you are a parent or guardian and believe your child has provided personal data to us, please contact us at support@doorkee.co so we can take appropriate action.

10. International Data Transfers

10.1. Doorkee is based in the United Arab Emirates. However, your personal data may be transferred to and processed in countries outside the UAE, including the United States, in connection with our use of the following service providers:

| Service Provider | Purpose | Location | | ----------------- | -------------------------------------------- | ------------------------- | | Stripe | Payment processing | United States | | Anthropic | AI Concierge (Claude models) | United States | | OpenAI | AI Concierge (GPT models) | United States | | Google | AI Concierge (Gemini models) | United States | | Supabase | Database, auth, storage | Cloud (India, ap-south-1) | | Resend Inc. | Transactional and lifecycle email delivery | United States | | Sentry | Error monitoring (always-on, necessary) | United States | | PostHog Inc. | Product analytics + session recording | United States | | Google Analytics 4 / Google Tag Manager | Product analytics (analytics-only mode) | United States / EU | | Microsoft Clarity | Session recording (opt-in, input masked) | United States / UK | | Twilio | SMS delivery and WhatsApp transport | United States | | Meta WhatsApp | WhatsApp messaging (Cloud API) | United States / EU | | Inngest | Background event queue (cron + DSAR cascade) | United States | | Upstash | Rate limiting (Redis) | Cloud | | Vercel | Application hosting | Global edge network |

10.2. When transferring data outside the UAE, we ensure appropriate safeguards are in place, including:

• Contractual obligations with our service providers requiring them to protect your data to a standard equivalent to UAE law;
• Use of service providers that maintain industry-standard security certifications (e.g., SOC 2, PCI DSS);
• Data minimisation — we transfer only the minimum data necessary for each service provider to perform its function.

10.3. For users in the European Economic Area, transfers are made in compliance with GDPR Chapter V, using standard contractual clauses or adequacy decisions where applicable.

11. Changes to This Policy

11.1. We may update this Privacy Policy from time to time to reflect changes in our practices, technology, legal requirements, or other factors. The "Last Updated" date at the top of this Policy indicates when the most recent changes were made.

11.2. For material changes to this Policy, we will notify you by:

• Posting a prominent notice on the Platform;
• Sending an email to the address associated with your account;
• Requiring acknowledgement of the updated Policy on your next login (for significant changes).

11.3. Your continued use of the Platform after the effective date of any changes constitutes your acceptance of the revised Policy.

11.4. We encourage you to review this Policy periodically to stay informed about how we protect your data.

11.5. Internal re-validation log (held-text discipline). As an internal compliance practice, Doorkee re-validates regulator-readable text in this Policy that describes a surface still under active implementation, to ensure the disclosed processing matches the live code path. The most recent re-validation: 2026-07-13 — Section 7 (Cookies and Tracking Technologies) was rewritten to match the notice-and-opt-out cookie model that has now been implemented. Material changes: (a) analytics (Google Analytics 4, Google Tag Manager, PostHog) is now on by default with a one-click opt-out, replacing the prior strict opt-in banner; (b) Google Analytics 4 was newly disclosed, in analytics-only mode (Google Signals, advertising features, and advertising data-sharing off); (c) session recording (Microsoft Clarity and PostHog session recording) was disclosed as a separate opt-in, input-masked-by-default category; (d) Sentry error monitoring was reclassified from the analytics category to strictly necessary / always-on, matching the implemented code path, on a security-and-service-integrity legal basis; (e) the §10.1 cross-border transfer table was extended with Google Analytics 4 / Google Tag Manager (US/EU) and Microsoft Clarity (US/UK). Prior re-validation: 2026-07-05 — the two HELD:S6-PR1e-LEGAL-MID-1 markers in §7.3a and §7.3b were retired per their own cleanup gate: the transitional unkeyed SHA-256 fallback was closed for production deployments in the same change (Fix Phase F7 PR4 — the identifier-hashing code now fails closed on production rather than emitting a weaker digest; the legacy branch survives only in non-production builds that never serve users), so §7.3a/§7.3b were rewritten to describe the now-mandatory fail-closed keyed HMAC-SHA-256 behaviour on production deployments, and a sentence was added to §7.3b disclosing that identifiers in webhook-emitted payment event payloads are transmitted only as keyed truncated digests. Prior re-validation: 2026-05-02 — three held markers in §2.4 and §7.3a/§7.3b were reviewed against current implementation; the §2.4 disclosure of optional offer notes was confirmed accurate against the data model and its marker retired, and the §7.3a/§7.3b disclosures were rewritten to describe both the keyed path and the then-live transitional fallback.

12. Data Protection Officer

DoorKee FZ-LLC has appointed an internal Data Protection Officer responsible for UAE PDPL duties under Article 24, including breach response, data-subject request (DSAR) handling, annual audit coordination, and liaison with the UAE Data Office.

• Data Protection Officer: Hemanth [last name]
• Primary contact: dpo@doorkee.co
• Secondary contact (alias): privacy@doorkee.co
• Response SLA: 30 days (per UAE PDPL).

For urgent breach notifications or data-subject requests, please email the primary contact with the subject line "PDPL — [Your Right / Issue]".

13. Contact Information

If you have any questions, concerns, or requests regarding this Privacy Policy or our data practices, you may contact us at:

DoorKee FZ-LLC FOAM0424, Compass Building, Al Shohada Road Al Hamra Industrial Zone-FZ, Ras Al Khaimah, United Arab Emirates

• General Support: support@doorkee.co
• Privacy Contact: privacy@doorkee.co
• Website: www.doorkee.co

For data privacy requests, please include:

• Your full name and email address associated with your account;
• A clear description of your request;
• Any relevant details to help us locate your data.

We will acknowledge your request within 5 business days and provide a substantive response within 30 days.

14. Definitions

For the purposes of this Policy:

• "Personal data" means any data relating to an identified or identifiable natural person, as defined by UAE Federal Decree-Law No. 45 of 2021;
• "Processing" means any operation performed on personal data, including collection, storage, use, disclosure, transfer, or deletion;
• "Controller" means DoorKee FZ-LLC, which determines the purposes and means of processing personal data;
• "Processor" means any third party that processes personal data on our behalf (e.g., Stripe, Resend, Supabase);
• "Platform" means the Doorkee website (www.doorkee.co), mobile applications, and all related services.

15. Right to Erasure (DSAR Procedure)

The data-subject-request (DSAR) surface described in this section is on Doorkee's near-term roadmap (Sprint 5 of the Doorkee Dara Remediation Program). We are publishing this policy in advance of the live rollout for transparency, so that users and regulators can review the intended procedure before it ships. Verbs throughout this section are written in the future-conditional tense to reflect that posture; once the surface is live, this Policy will be amended to present-tense and re-dated.

15.1. Under UAE Federal Decree-Law No. 45 of 2021 on the Protection of Personal Data ("PDPL") Article 17, you will have the right to request the erasure of your personal data held by Doorkee, subject to the statutory retention obligations described in §15.5. This section explains how you will exercise that right and what will happen after you submit a request. The procedure will be implemented in compliance with PDPL Article 17, the data-subject-request response window in PDPL Articles 18–22, and (for self-declared residents of the European Economic Area) the equivalent rights under GDPR Articles 15–22.

15.2. How to submit a request. You will sign in to your Doorkee account and go to /account/data-rights. You will be asked to re-authenticate by entering your password (or by re-confirming your OAuth identity if you signed in via Google or Apple) within a five-minute confirmation window. After re-authentication, you will submit the request form. We will acknowledge every valid request by email within twenty-four hours.

15.3. Soft-delete grace window. From the moment your request is acknowledged, your account will enter a seven-day soft-delete grace window. During this window, your data will be hidden from all Platform surfaces but will not yet be erased from our database. If you change your mind, you will be able to cancel the request at any time during the seven days by signing back in (we will accept your password during this window) and clicking "Cancel Erasure Request" in the same /account/data-rights screen. A confirmation email containing a cancellation link will also be sent at acknowledgement.

15.4. Hard-erasure SLA. If the request is not cancelled within the seven-day grace window, Doorkee will proceed to hard-erase your data on the eighth day. We will complete the full erasure (including the third-party processor cascade described in §15.6 below) within thirty days of the original submission, in line with PDPL Article 18's statutory thirty-day response window.

15.5. AML / Commercial-Code carve-out. Certain financial and commercial records are subject to statutory retention obligations that override an erasure request:

• Financial records (payment transactions, refund events) — retained for five years under UAE Federal Decree-Law No. 20 of 2018 (AML-CFT) Article 16 and UAE Federal Decree-Law No. 32 of 2021 (Commercial Companies Law) Article 26;
• Identity verification records (KYC) — retained for five years after the business relationship ends, under UAE Federal Decree-Law No. 20 of 2018 Article 16;
• Lease and rental-transaction records — retained for five years under UAE Federal Decree-Law No. 26 of 2007 and Dubai Law No. 85 of 2006 (RERA broker-licence retention obligation).

For these records, your text personal-data fields (name, email, phone, document numbers) will be anonymised in place — we will replace them with non-identifying sentinels so that the row cannot be re-linked to you — but the row itself will be retained for the statutory window. Identity and verification document images — including your KYC document image (§2.2) and your broker card image (§2.12) — cannot be anonymised in place, because an image cannot be reduced to a non-identifying form while it is retained; these images are deleted at the end of the retention window (or earlier on an erasure request) rather than anonymised, and only the non-identifying record that a verification took place is kept. The non-personal fields (transaction amount, status, dates) will be kept as required for audit. You will receive a final email confirming what was deleted, what was anonymised, and which records remained under the carve-out.

15.6. Third-party processor cascade. When your request is hard-erased, Doorkee will signal deletion to the third-party services we use to deliver the Platform. The cascade will cover eleven processors:

| Processor | Purpose | Erasure mechanism | | ------------------- | -------------------------------- | ----------------------------------------------------------------------------------------------------------- | | Stripe | Payment processing | Customer record retained 5 years per AML/CFT floor; non-financial PII anonymised via Doorkee database scrub | | Anthropic | AI Concierge (Claude models) | No-op — system-prompt-only architecture; no PII transmitted | | OpenAI | AI Concierge (GPT models) | No-op — system-prompt-only; no PII transmitted | | Google (Gemini) | AI Concierge (Gemini models) | No-op — system-prompt-only; no PII transmitted | | PostHog Inc. | Product analytics | Distinct-id deletion via Personal Data API ($delete_user) | | Sentry | Error monitoring | User-deletion API call; remaining events expire under 90-day default retention | | Resend | Transactional email delivery | Per-recipient contact deletion across audiences; transactional log purge | | Inngest | Background event queue | Event-log scrub via Inngest user-deletion API | | Twilio | SMS delivery | Message-log deletion via Messages API | | Meta WhatsApp | WhatsApp messaging | Conversation deletion via Cloud API; subject to Meta-side retention floors that we cannot override | | Supabase Auth | Authentication and session store | Auth-user deletion via service-role client; cascades to identities and sessions |

Where a processor has a statutory or platform-side retention floor that we cannot override (Stripe AML, Meta WhatsApp metadata floor), we will record this in our internal cascade audit trail and disclose it in the final confirmation email. We will not claim erasure for data we cannot reach.

15.7. Cooperation and escalation. If a third-party processor fails to comply with our deletion request after five retry attempts, we will escalate the matter to the UAE Data Office on your behalf, in line with PDPL Article 23's regulator-cooperation obligation. You will be informed of any such escalation in the final confirmation email.

15.8. Right to object, restrict, and access. This section will also cover requests under PDPL Articles 15 (right of access), 16 (right to rectification), 19 (right to object), and 20 (right to data portability). Self-declared EEA residents will additionally be able to request a structured, machine-readable export of their data under GDPR Article 20; the export will be delivered as a JSON file via a single-use download link emailed to the account address. All such requests will be handled through the same /account/data-rights form and the same thirty-day SLA.

15.9. Contact for DSARs. You will submit erasure, access, rectification, objection, and portability requests through /account/data-rights after signing in. For escalations or for requests that cannot be made through the in-product form (for example, if you have lost access to your account), you will contact the Data Protection Officer at dpo@doorkee.co with the subject line "PDPL — [Your Right]". The DPO will acknowledge within five business days and will provide a substantive response within thirty days.

16. Regulatory-Update Monitoring

The regulatory-update monitoring surface described in this section is on Doorkee's near-term roadmap (Sprint 5 of the Doorkee Dara Remediation Program). We are publishing this policy in advance of the live rollout for transparency, so that users and regulators can review the intended posture before it ships. Verbs throughout this section are written in the future-conditional tense to reflect that posture; once the surface is live, this Policy will be amended to present-tense and re-dated.

16.1. To ensure that Doorkee's policies and platform rules stay aligned with UAE regulatory updates, we will operate a regulatory-update monitoring surface. This section explains what the surface will do, what data it will process, and (importantly) what data it will not process.

16.2. Legal basis. We have chosen a hash-only architecture for this surface to keep regulator content outside our processing scope. UAE Federal Decree-Law No. 38 of 2021 (Electronic Transactions and Trust Services) is the regime under which the integrity of cryptographic fingerprints is generally regulated in the UAE; PDPL Article 1 is satisfied because the SHA-256 hash is pseudonymised and unrecoverable.

16.3. Procedure. Once per week, an automated job will fetch the public response body of a fixed allowlist of five UAE regulatory pages (currently: the Dubai Land Department, the Real Estate Regulatory Agency (RERA), the Real Estate Dispute Settlement Centre (RDSC), the Ejari electronic-tenancy-contract registry, and the DLD eServices portal). For each fetched page, we will compute and store a SHA-256 hash of the response body — the hash only. We will not store the response body itself, we will not parse the body for personal data, and we will not transmit the body to any third party.

16.4. Hash-diff alerts. When the weekly hash differs from the previous week's hash, an internal admin notification will fire. A Doorkee staff member will then manually review the regulatory page, decide whether the change affects Doorkee's policies or platform rules, and (if so) update the relevant Doorkee internal documentation. No automated rule deployment will occur as a result of a hash diff — every policy change will be human-reviewed.

16.5. No personal data, no user data shared. This surface will not process personal data and will not share any user data with regulators. It will be a one-way, read-only fetch of public government pages. Because we will store only the SHA-256 hash of each fetched response body, the hash will be unrecoverable for plaintext content under standard cryptographic assumptions, and the surface will fall outside the identifying-data scope of PDPL Article 1. We disclose this surface in this Policy purely for transparency about our intended regulatory-monitoring posture.

17. Lifecycle Email and WhatsApp Messaging (M27)

The lifecycle email and WhatsApp messaging surfaces described in this section are on Doorkee's near-term roadmap (Sprint 6 of the Doorkee Dara Remediation Program). We are publishing this policy in advance of the live rollout for transparency, so that users and regulators can review the intended posture before it ships. Verbs throughout this section are written in the future-conditional tense to reflect that posture; once each surface is live, this Policy will be amended to present-tense and re-dated.

17.1. Scope. This section discloses two communication surfaces that will ship in Sprint 6: (a) lifecycle email — periodic, marketing-class email sent to users who have granted explicit marketing consent; and (b) WhatsApp messaging — inbound and outbound conversational messaging via the WhatsApp Business Cloud API. Both surfaces operate within the existing eleven-processor cascade (see §15.6) and do not introduce a twelfth processor.

17.2. Lifecycle email — lawful basis. Lifecycle email will be sent under UAE Federal Decree-Law No. 45 of 2021 ("PDPL") Article 9 (explicit consent for marketing communications). Recipients who have not granted marketing consent — that is, who have left the marketing category off (its opt-in default) in the Cookie preferences page described in §7.1 — will be excluded from the lifecycle send list at the handler level. The marketing toggle is the single, authoritative gate; it is enforced by joining the EmailPreference and PdplConsentRecord records before any send.

17.3. Lifecycle email — sender identity and signature. Lifecycle emails will carry the signature "— Dara at Doorkee Concierge" as the closing line above the unsubscribe footer. This signature distinguishes lifecycle communications (consent-based, marketing-class) from transactional communications (legitimate-interest, contract-performance), which retain the existing "— The Doorkee Team" sign-off. The signature is fixed by the handler and cannot be customised per-message.

17.4. Lifecycle email — opt-out. Three independent opt-out paths will be available, in line with PDPL Article 13 (right to object to processing for direct marketing purposes):

• One-click unsubscribe via the List-Unsubscribe HMAC-tokenised header in every lifecycle email.
• In-product preference toggle at /account/communications, which flips your PdplConsentRecord.marketing flag to false and takes effect on the next handler run (within twenty-four hours).
• DPO email at dpo@doorkee.co — see §12.

Withdrawing marketing consent does not affect transactional emails (payment receipts, KYC confirmations, offer notifications), which we will continue to send under the contract-performance lawful basis described in §3.8.

17.5. WhatsApp messaging — operator and lawful basis. Outbound and inbound WhatsApp messages will be transported via Twilio and the Meta WhatsApp Business Cloud API. Doorkee will operate from a UAE-licensed Meta WhatsApp business number for messages directed to UAE users. Inbound user messages and Doorkee replies will be processed under PDPL Art. 4 lawful-basis grounds (contract performance and operational reliability — the user has initiated a conversation about a Doorkee transaction). Outbound transactional notices (offer status, visit reminders) will be processed under the same Art. 4 contract-performance basis. Outbound WhatsApp messages that fall in the marketing class (currently none in v1) would require Art. 9 explicit consent.

17.6. WhatsApp messaging — Meta-side retention floor. Meta retains WhatsApp message metadata (timestamps, delivery status, message identifiers) on its platform for periods that Doorkee cannot override. On a verified DSAR, Doorkee will issue the Cloud API conversation-deletion call and record the result in the cascade audit trail; where Meta declines to honour the deletion within Meta's own retention floor, Doorkee will disclose the floor to you in the final DSAR confirmation email (per §15.6).

17.7. WhatsApp messaging — opt-out. You may opt out of all WhatsApp communications from Doorkee at any time by replying STOP, UNSUBSCRIBE, or the Arabic equivalents (إيقاف, إلغاء, توقف) to any Doorkee WhatsApp message. You may also contact the DPO at dpo@doorkee.co to request opt-out. Acknowledgements are sent in the language of your opt-out message (English or Arabic). Any of these keywords will write a tombstone to the User.channelOptOuts JSON field and suppress all future Doorkee-originated WhatsApp messages to your number until you re-opt-in by replying START, SUBSCRIBE, بدء, or اشتراك.

17.8. DSAR cascade reach. Lifecycle email and WhatsApp transmissions are inside the eleven-processor cascade described in §15.6. On a verified DSAR for erasure, the cascade will signal deletion to Resend Inc. (transactional + lifecycle email logs) and to Meta WhatsApp (Cloud API conversation history) per the row-by-row mechanisms in §15.6. No new processor will be added by M27.

18. DLD-Comparables Surface — Defensive-Internal Posture (M28)

The DLD-comparables surface described in this section is on Doorkee's near-term roadmap (Sprint 6 of the Doorkee Dara Remediation Program). We are publishing this policy in advance of the live rollout for transparency, so that users and regulators can review the intended posture before it ships. Verbs throughout this section are written in the future-conditional tense to reflect that posture; once the surface is live, this Policy will be amended to present-tense and re-dated.

18.1. Scope. Sprint 6 will introduce a Dubai Land Department (DLD) comparables ladder that Dara will consult internally when generating valuation responses to owners and tenants. This section discloses what the surface will do and (importantly) what it will not do.

18.2. Internal-only in v1. The DLD-comparables ladder will be internal to Doorkee in version 1. The user-facing valuation response will not name DLD as a source, will not include a DLD permit number, will not include a DLD URL or hyperlink, and will not contain prose such as "per Dubai Land Department". If a user asks where a valuation comes from, Dara will respond with the existing fallback disclosure (verifiable transactions on Doorkee plus RERA-published rent indices). DLD will not be named in v1 user-facing copy.

18.3. Why internal-only. UAE Federal Decree-Law No. 38 of 2021 governs electronic transactions and digital trust. The DLD eServices Terms of Service have not yet been legally cleared by external counsel for read-and-cite use in a third-party rental platform. Until counsel clearance is obtained, Doorkee will preserve the wedge value of better internal valuations while deferring the citation surface — a defensive posture analogous to the hash-only architecture used for regulatory-update monitoring (§16).

18.4. No automated scraping. Doorkee will not scrape DLD eServices. The DLD-comparables corpus will be ingested out-of-band by a Doorkee staff member from publicly published DLD transaction summaries. The Dubai Land Department's public response bodies will not be persisted; only derived fingerprints (community, unit type, beds, area band) and a SHA-256-truncated hash of each comparable will be retained. This preserves the zero-scraping posture required by Decree-Law 38/2021.

18.5. No personal data transmitted. The DLD-comparables surface will not transmit personal data to DLD or to any other third party. The internal lookup that informs Dara's valuation will key on a property fingerprint hash, not on the user's identity. Telemetry events emitted by the lookup (concierge.dld_comparables_lookup — see spec.md §10.8.1) will carry the hash only, never a DLD URL, permit number, or raw address.

18.6. Sprint 7 deferral path. If external counsel clears the DLD eServices Terms of Service for read-and-cite use by Sprint 7 open, Doorkee will ship M28 v2 with a citation surface — user-facing prose will name DLD as a source, will include a permit number when available, and will add a "verify on dld.gov.ae" link. This Policy will be amended to disclose the citation surface before any user-facing change ships. Until that amendment lands, the v1 internal-only posture above is binding.

This Privacy Policy is effective as of 19 March 2026.

Doorkee -- UAE's first outcome-driven rental platform.