Data Processing Agreement

Customer is the Controller of personal data uploaded into Customer’s tenant or otherwise processed by OperaFO on behalf of Customer (the “Customer Personal Data”). OperaFO is the Processor of Customer Personal Data.

For the avoidance of doubt, OperaFO acts as Controller in respect of: account credentials of named personnel we engage with directly (e.g. invoicing contact), visitor / prospect data on the marketing site, and operational telemetry that does not contain Customer Personal Data — those processing activities are governed by the Privacy Policy, not this DPA.

Joint controllership. The parties do not intend to act as joint controllers within the meaning of GDPR Article 26, PDPL Article 21, or the analogous DIFC / ADGM provisions. Where a particular processing activity is reasonably argued by either party or by a supervisory authority to constitute joint controllership, the parties will negotiate in good faith a written joint-controller arrangement that allocates transparency, data-subject-response, and supervisory-authority-engagement responsibilities. Until such an arrangement is signed, OperaFO continues to process Customer Personal Data only as a Processor on Customer’s documented instructions.

Customer’s advisors as separate Controllers. Where Customer engages an external advisor (e.g. an independent investment manager, Sharia scholar, succession-planning lawyer, family accountant) and that advisor is granted Authorised User access to the tenant, OperaFO continues to treat Customer as the sole Controller of all data within the tenant for the purposes of this DPA. The advisor’s separate Controller status (if any, in respect of advisor-side records held outside the tenant) is a matter between Customer and the advisor and is not governed by this DPA.

Authorised Users acting in their own Controller capacity. If an Authorised User contacts OperaFO directly to exercise rights in respect of personal data that relates to that Authorised User personally (e.g. their own email address, login history, audit-trail entries), OperaFO will treat that request under §11 — i.e. acknowledge, advise the individual to raise the request through Customer where Customer is the Controller of the relevant data, and notify Customer’s tenant administrator. Where the request relates to data for which OperaFO is the Controller (e.g. marketing-site cookies set on the individual’s browser before they became an Authorised User), OperaFO responds directly under the Privacy Policy.

This DPA applies for as long as Customer subscribes to the Service plus the export-and-deletion grace period in §13, and survives termination to the extent necessary to give effect to Customer’s post-termination rights, audit rights, and any outstanding deletion-confirmation obligations.

Subject matter. The processing of Customer Personal Data uploaded or generated within the Customer tenant in the course of Customer’s use of the Service — including, without limitation, account provisioning, holdings ingestion, analytics computation, AI-augmented narrative generation, Sharia / Faraid / Zakat calculation, audit logging, document storage (Tier 3+), report rendering, and billing administration.

Duration. The Subscription Term, plus up to thirty (30) days post-termination for export and deletion (and up to ninety (90) additional days for routine backup ageing — see §13). Audit-log retention continues for the period set in §16 (default seven (7) years) regardless of Subscription end-date, except where Customer has opted into a shorter retention configured in the tenant settings.

Nature of processing operations. OperaFO performs the following discrete categories of processing operation against Customer Personal Data:

• Collection — receipt of data via authenticated UI form submissions, authenticated API endpoints, file uploads, OAuth-mediated sign-in, and scheduled connector pulls (Tier 3+).
• Recording and structuring — normalisation into the Postgres tenant schema, application of currency / instrument / counterparty reference data.
• Storage — persistence in the primary Postgres tenant database hosted on Hetzner EU-Central, plus object storage for uploaded documents and search-index storage where Document RAG is enabled.
• Retrieval and consultation — read operations on behalf of Authorised Users to render dashboards, briefings, lineage explainers, reconciliation views, and AI Analyst answers.
• Computation — derivation of analytics outputs (risk metrics, performance, attribution, Faraid shares, Zakat base, what-if scenarios). Computation is deterministic and runs inside Customer’s tenant boundary unless expressly noted as AI-augmented.
• AI augmentation — transmission of scrubbed prompt context to Anthropic under the zero-day-retention enterprise terms, exclusively where Customer has activated the relevant AI feature.
• Disclosure / transmission to sub-processors — onward routing of the minimum necessary data to billing (Stripe), observability (GlitchTip Sentry-protocol sink), product analytics (PostHog), and email transactional delivery, as listed in the Privacy Policy.
• Alignment / restriction / erasure — application of corrections, restrictions, and deletions instructed via the in-product tools or via written instruction from Customer.
• Deletion — removal from production database, search indexes, AI prompt caches, and age-out from backups under §13.

Purpose. Solely to deliver the Service to Customer and to comply with applicable law. OperaFO shall not process Customer Personal Data for any other purpose, and in particular shall not (a) sell Customer Personal Data, (b) use Customer Personal Data to train generally-available machine-learning models, or (c) combine Customer Personal Data with that of other tenants for cross-tenant insights, in each case without Customer’s prior written consent.

Categories of personal data.

• Account / contact data of Customer’s Authorised Users (full name, business email, telephone where voluntarily provided, role within the family office, language and locale preference).
• Authentication and session data — hashed password digest (bcrypt), OAuth subject identifier where Google sign-in is enabled, session token identifiers, IP address at the time of session establishment, user-agent string, last-seen timestamp.
• Authorisation metadata — role assignment within a tenant (owner / admin / member / viewer / service), tenant memberships, feature-flag entitlements per Tier (Tier 1 Free, Tier 2 Starter, Tier 3 Professional, Tier 4 Agentic).
• Free-text fields entered by Customer (notes, decision rationales, AI Analyst questions, briefing annotations, reconciliation comments). These pass through the PII scrubber before any external transmission to LLM, observability, or analytics endpoints.
• Beneficiary and family-tree data in the Faraid / succession-planning module (full name, relationship, date of birth, optional ID-document reference, jurisdiction of residence, predeceased status, Sharia-relevant attributes such as religion and marital status where Customer chooses to record them).
• Counterparty contact data — natural-person contact names at custodians, brokers, banks, asset managers, and external advisors, where Customer chooses to record them in the relationship registry.
• Uploaded documents (KYC packs, Articles of Association, Investment Policy Statements, mandate letters, trust deeds, custody statements) where Customer uses the Document RAG (Tier 3+) features — these may incidentally contain personal data of signatories, witnesses, and named individuals.
• Holdings, transaction, and cash-flow data attributed to a named natural-person beneficial owner (where Customer’s ledger is structured at that level).
• Audit-trail records — actor identifier, action, resource identifier, timestamp, request identifier, source IP, and outcome, for every authenticated event within the tenant.
• Support-ticket content — text and attachments exchanged between Customer’s Authorised Users and the OperaFO support team, which may contain personal data the Authorised User chooses to include.
• Billing-related data limited to the natural-person invoicing contact; cardholder data is processed by Stripe and not received in plaintext by OperaFO.
• Optionally — Zakat / charitable-distribution recipient data (beneficiary name, relationship, amount, date) where Customer uses the Zakat calculator’s distribution-tracking feature.
• Optionally — Sharia-screen review notes attributable to a named scholar where Customer records scholar attribution.
• Telemetry attributable to an Authorised User — feature usage events captured by PostHog under the Authorised User’s tenant-scoped pseudonymous identifier.
• AI Analyst conversation history (Tier 3+) — scrubbed prompt and response content stored in the tenant for reuse, audit, and rerun under Customer control.

Data subjects.

• Customer’s Authorised Users (employees, family-office staff, contracted operators).
• Beneficial owners, settlors, and beneficiaries of the family-office structure where Customer records them.
• Heirs, successors, and other natural persons named in Faraid / succession-planning models.
• External advisors granted Authorised User access (investment advisors, Sharia scholars, succession lawyers, accountants, auditors).
• Counterparty contact persons (natural-person representatives at custodians, brokers, banks, managers).
• Signatories, witnesses, and other named individuals appearing incidentally in uploaded documents.
• Zakat / charitable-distribution recipients where Customer records distribution events.
• Family members named in genealogy or relationship trees who are not themselves Authorised Users.
• OperaFO support correspondents — i.e. data subjects voluntarily named in support tickets raised by Customer.

Special categories. The Service is designed not to require special-category data (biometric, health, religious-belief, political-opinion data, data revealing trade-union membership, or criminal-conviction data) for its operation. Where Customer chooses to upload such data into a tenant — for example, religion or sect attributes used as inputs to the Faraid engine — Customer is solely responsible for the lawful basis and any additional safeguards required under PDPL Article 5 / GDPR Article 9 / equivalent provisions. OperaFO treats any such data with the same TOMs set out in §16 and does not apply additional automated processing to it beyond what is necessary to render the requested calculation.

Customer’s documented instructions to OperaFO are set out in (a) the Terms of Service, (b) this DPA, (c) Customer’s configuration of its tenant (settings, user roles, access policies, retention overrides, feature toggles), and (d) any further instructions Customer provides in writing in the ordinary course (including via support tickets or signed letter).

Channels through which documented instructions are issued.

• Tenant settings UI — for standing configuration choices such as enabling AI features, setting retention overrides, configuring SSO, appointing tenant administrators, granting and revoking Authorised User access, and toggling cross-border transfer-dependent features. Each such change is logged in the audit trail with actor and timestamp.
• Authenticated API calls — for programmatic instructions issued via Customer’s service-role tokens, including bulk export, scheduled deletion, and integration management. API calls carrying personal-data-relevant instructions are treated as documented instructions.
• In-product action flows — for discrete acts such as deleting a user, exporting a user’s data, restricting an account, or initiating tenant deletion. Each flow is recorded in the audit log and counts as a documented instruction.
• Support tickets to support@operafo.ae — for instructions that cannot be issued through the UI or API. OperaFO confirms receipt and scope before acting.
• Privacy / DPA correspondence to privacy@operafo.ae — for data-protection-specific instructions, sub-processor objections, audit requests, and breach-related correspondence.
• Signed written letter on Customer’s letterhead delivered to the OperaFO registered office — accepted for high-impact instructions such as legal-hold, full tenant destruction, or named-individual access restriction outside the standard product flows.

Conflict between instructions and applicable law. If OperaFO reasonably believes that an instruction infringes applicable data-protection law, or another applicable law to which OperaFO is subject, OperaFO will (a) notify Customer in writing of the concern, (b) suspend execution of the instruction pending Customer’s response, except where immediate execution is necessary to prevent harm, and (c) decline to execute the instruction if, after reasonable discussion, Customer maintains the instruction. Where applicable law requires OperaFO to process Customer Personal Data otherwise than on Customer’s instruction, OperaFO will inform Customer of that legal requirement before processing unless the law prohibits such notice on grounds of public interest.

Customer warrants that:

• Customer has all necessary lawful bases, notices, consents, and authorisations under applicable law to upload the Customer Personal Data into the tenant and to instruct OperaFO to process it.
• Customer has provided each data subject with the privacy notices required of a Controller under the applicable data-protection law, including notice of the cross-border transfers described in §8 and the sub-processors described in §7.
• Customer’s instructions to OperaFO comply with applicable law, and OperaFO is entitled to rely on them as documented instructions of the Controller.
• Customer will not use the Service to process special- category personal data for sensitive automated decision-making with legal or similarly significant effects, except with explicit consent and a documented assessment.
• Customer will keep its tenant administrator list, Authorised User list, and privacy-contact details up to date so that OperaFO has a reliable point of contact for instructions, breach notifications, and data-subject-rights coordination.

OperaFO will:

• process Customer Personal Data only on Customer’s documented instructions (including with regard to cross-border transfers), unless required to do so by applicable law (in which case OperaFO will inform Customer of that legal requirement before processing, unless the law prohibits such notice);
• ensure that all personnel authorised to process Customer Personal Data are bound by appropriate written confidentiality obligations of no less protective scope than this DPA, and complete documented data-protection awareness training within thirty (30) days of joining and annually thereafter;
• implement and maintain appropriate technical and organisational measures (TOMs) to ensure a level of security appropriate to the risk — see Annex 1 (§16) — and review the TOMs at least annually and after any material change to the Service, sub-processor landscape, or threat model;
• taking into account the nature of processing, assist Customer with appropriate technical and organisational measures, insofar as possible, in fulfilling Customer’s obligation to respond to data-subject rights requests — including by providing the in-product export tools at /account/export/csv and /account/export/json that include all stored fields for a single user, including audit-log entries, AI Analyst transcripts, and uploaded-document metadata;
• provide a self-service deletion flow at /account/delete that removes the named user from the tenant Authorised User list, revokes outstanding sessions, and queues the user’s data for scheduled deletion under §13;
• provide a tenant-wide export flow accessible to the tenant owner that produces a structured archive of the tenant’s data in machine-readable format, fulfilling portability requests at the tenant level;
• assist Customer in ensuring compliance with the obligations relating to security, breach notification, data-protection impact assessments (DPIAs), and prior consultation, in each case taking into account the nature of processing and the information available to OperaFO;
• on Customer’s written choice at termination, delete or return all Customer Personal Data, and delete existing copies, except to the extent applicable law requires storage (and in such case retain only for the period required by law and only for that purpose);
• make available to Customer all information necessary to demonstrate compliance with this DPA and with applicable data-protection law, and allow for and contribute to audits in accordance with §10;
• maintain a written record of processing activities (RoPA) covering Customer Personal Data, in the form required of a Processor under applicable data-protection law, and make it available on request to a competent supervisory authority;
• notify Customer without undue delay of any binding legal request (subpoena, court order, regulator demand) for Customer Personal Data, except where prohibited by law from doing so, and challenge overbroad or unlawful requests where reasonable grounds exist;
• notify Customer without undue delay if OperaFO can no longer comply with this DPA (for example, because of a change in applicable law that conflicts with the required obligations), and cooperate with Customer to agree appropriate steps including, where necessary, suspension or termination of the affected processing;
• ensure that no Customer Personal Data is used to train generally-available machine-learning models or improve cross-tenant features, and that AI inference uses sub-processors operating under zero-data-retention terms where reasonably available;
• apply the principles of data minimisation, storage limitation, and purpose limitation in the design of product features, including by routing free-text fields through the PII scrubber before any external transmission;
• segregate Customer Personal Data from other tenants’ data using Postgres FORCE ROW LEVEL SECURITY pinned to the operafo_app role, and verify that segregation on every deploy via the automated check at api/scripts/verify_rls_isolation.py;
• log every authenticated action against Customer Personal Data with actor, tenant, timestamp, request identifier, and event type to an immutable audit log retained per §16;
• manage sub-processors in accordance with §7, including imposing equivalent data-protection obligations and monitoring their performance;
• cooperate with Customer in good faith on any reasonable request for information about OperaFO’s compliance posture, including by completing industry-standard data-protection questionnaires within thirty (30) days;
• not subcontract any processing of Customer Personal Data to a sub-processor that has not been notified to Customer under §7;
• return or destroy Customer Personal Data upon termination per §13 and provide written confirmation of deletion on request.

OperaFO restricts access to Customer Personal Data to personnel who need such access to perform their duties. Each such person is informed of the confidential nature of the data and is bound by written confidentiality obligations that survive the end of the personnel relationship.

Joiners-movers-leavers (JML).

• Joiners. A new engineer or operator receives production-system access only after (a) signing the OperaFO confidentiality agreement, which expressly extends to all Customer Personal Data and survives termination, (b) completing data-protection awareness training, (c) being added to the production access register by the engineering lead, and (d) being provisioned with role-scoped credentials with the minimum privilege required for the role.
• Movers. When a person changes role internally, access is reviewed within five (5) business days. Access that is no longer required is revoked. Any new access required by the new role is granted under the same provisioning controls applied to joiners.
• Leavers. When a person leaves OperaFO, all production access (database, console, cloud provider, sub-processor admin consoles, observability, source repositories, ticket system) is revoked on the leaver’s last working day, confirmed by the engineering lead through a documented checklist. Long-lived secrets known to the leaver are rotated within seventy-two (72) hours. Confidentiality obligations continue indefinitely.

Quarterly access review. The engineering lead conducts a documented review of the production access register at least once per calendar quarter. The review confirms (a) every account is still required, (b) every account is still scoped to the minimum necessary privilege, (c) MFA is enforced on every account with production-console access, (d) no shared accounts exist, and (e) the leaver process has been correctly applied since the last review. The review record is kept for at least three (3) years.

MFA and session controls. Multi-factor authentication is required for all production-console access, all source-repository access, and all sub-processor administrative consoles. Idle sessions time out after a documented threshold. Production bastion access is logged and routed through a single channel that records the actor, command, and outcome.

Confidentiality agreement scope. The written confidentiality template binds personnel personally to: (i) not disclose Customer Personal Data to anyone outside OperaFO, (ii) not use Customer Personal Data for any purpose other than performing their assigned duties, (iii) report any suspected breach of confidentiality without delay, and (iv) comply with all applicable data-protection laws. The obligations survive termination of employment or engagement.

Customer authorises OperaFO to engage the sub-processors listed in the Privacy Policy “Sub-processors” section, as updated from time to time. Each sub-processor is bound by written terms imposing the same data-protection obligations as those set out in this DPA (or, in the case of sub-processors whose own terms are more protective, the more protective set).

Notification mechanism. OperaFO will give Customer at least thirty (30) days’ advance notice of any new sub-processor or replacement of an existing one through each of the following channels, applied in parallel: (i) email to each tenant’s designated privacy / administrator contact, (ii) in-product banner shown to tenant administrators on next sign-in, and (iii) update to the Privacy Policy “Sub-processors” section with a dated changelog entry. The notice describes the new sub-processor, the categories of personal data that will be transferred to it, the location of processing, the purpose, and the transfer mechanism (where cross-border).

Objection process. Customer may object to such engagement on reasonable data-protection grounds within fourteen (14) days of receipt of notice by writing to privacy@operafo.ae. The objection must set out the data-protection grounds with reasonable particularity. If Customer does not object within the fourteen-day window, the engagement is deemed authorised.

What happens if Customer objects. The parties will engage in good-faith discussion for up to thirty (30) days from the date of objection. The possible outcomes are:

• Negotiated mitigation. Customer withdraws the objection following additional contractual or technical safeguards (e.g. configuration-level disable of the sub-processor, additional SCC modules, pseudonymisation of the data flow).
• Alternative provider. OperaFO identifies an alternative sub-processor for the affected feature, where commercially and technically reasonable.
• Partial termination. Customer terminates the affected portion of the Service without penalty and OperaFO continues to provide the unaffected portion. OperaFO refunds any prepaid Fees attributable to the unused portion of the affected feature on a prorated basis.
• Full termination. Where the sub-processor is essential to the Service and no workable alternative is available, Customer may terminate the Subscription in full without penalty and OperaFO refunds any prepaid Fees attributable to the unused portion.

Material change. A change is “material” for the purposes of this section if it (a) introduces a new sub-processor not previously listed, (b) changes the geographic location of an existing sub-processor’s processing in a way that changes the applicable transfer mechanism, (c) materially expands the categories of personal data disclosed to a sub-processor, or (d) materially expands the purposes of the sub-processor’s processing. Re-affiliation or re-naming of an existing sub-processor without functional change is not material but will still be reflected in the Privacy Policy changelog.

Emergency replacement. Where a sub-processor must be replaced on shorter notice for security or continuity reasons (e.g. the sub-processor ceases operation, fails a security review, or is determined to be non-compliant with applicable law), OperaFO will give as much advance notice as circumstances permit and will document the reasons in the changelog. The objection process applies on a shortened reasonable timeline.

OperaFO remains liable to Customer for the performance of each sub-processor’s obligations to the same extent as OperaFO would be liable if performing the services itself.

Hosting region. The primary hosting region as of the Effective Date is Hetzner Helsinki / EU-Central. The staging environment at webapp.operafo.ae operates in the same region. [Counsel to confirm before binding execution.]

Cross-border transfers occur for the following discrete data flows:

• AI Analyst inference — scrubbed prompt context to Anthropic at its US data centres under the enterprise zero-day-retention terms. Mechanism: EU-to-US transfers rely on the EU SCCs Module 2 (Controller to Processor) plus the European Commission adequacy decision for the EU-US Data Privacy Framework where the receiving entity is certified, with the SCCs as fallback. UK-origin transfers rely on the UK International Data Transfer Addendum to the EU SCCs. PDPL-origin transfers rely on the PDPL Standard Contractual Clauses where issued by the UAE Data Office, and on adequacy or alternative safeguards where SCCs are not yet published, until then. DIFC and ADGM transfers rely on the standard data-export-permits or equivalent under the respective Commissioner’s rules.
• Billing — invoicing-contact and payment-method-token data to Stripe (US/EU). Mechanism: EU SCCs Module 3 (Processor to Processor) where applicable, with the EU-US Data Privacy Framework as primary mechanism for US-side processing where Stripe entity is certified. UK IDTA addendum applied to UK-origin flows.
• Error / exception telemetry — to a Sentry-protocol observability sink (GlitchTip hosted in EU; vendor-specific addendum confirms region). Mechanism: intra-EEA transfer where source and destination are in the EEA — no transfer mechanism required. Where a fallback US sink is used during regional outage, EU SCCs Module 3 apply.
• Product analytics — pseudonymised feature-usage events to PostHog (region per the Privacy Policy). Mechanism: EU SCCs Module 3 where the destination is outside the EEA; UK IDTA addendum for UK-origin flows.
• Hosting — primary database, object storage, and search index on Hetzner EU-Central / Helsinki. Mechanism: intra-EEA — no transfer mechanism required. PDPL-origin flows to EEA hosting rely on the standard cross-border transfer permission mechanisms under PDPL Article 22 / Article 23.
• Transactional email — outbound delivery of operational emails (verification, audit digests, billing notices) through the email provider listed in the Privacy Policy. Mechanism: as applicable per the provider’s region; SCCs / IDTA / DPF as required.

Where regulator-issued Standard Contractual Clauses are published by the UAE Data Office, the DIFC Commissioner of Data Protection, or the ADGM Office of Data Protection, OperaFO will adopt them within a reasonable transitional period and update the Privacy Policy accordingly. Customer may request a copy of the relevant executed mechanism, redacted as necessary to protect commercial confidences, by writing to privacy@operafo.ae.

Transfer impact assessment. OperaFO maintains a written transfer impact assessment for each cross-border data flow that considers the laws of the destination jurisdiction, the technical and contractual safeguards applied, and the practical likelihood of government access. The assessment is reviewed at least annually and on any material change to the flow or to the destination jurisdiction’s laws.

Following becoming aware of a Personal Data Breach (as defined in applicable data-protection law) affecting Customer Personal Data, OperaFO will notify Customer without undue delay, and in any event within seventy-two (72) hours of becoming aware, unless applicable law sets a stricter window — in which case the stricter window applies.

Required content of the initial notification.

• A description of the nature of the breach, including where possible the categories and approximate number of data subjects concerned, the categories and approximate number of personal-data records concerned, and the geographic location of the affected data.
• The identifier of the affected tenant(s) and, where applicable, the affected feature, integration, or sub-processor.
• The name and contact details of OperaFO’s Data Protection contact and the on-call incident commander, including telephone for out-of-hours escalation.
• A description of the likely consequences of the breach for the affected data subjects.
• A description of the measures already taken or proposed to be taken to address the breach, contain it, and mitigate its possible adverse effects.
• Whether the breach is believed to be ongoing or contained, and the timestamp at which OperaFO became aware.
• A reference identifier for tracking subsequent updates.

Format and delivery. The initial notification is delivered by email to the tenant’s designated privacy contact and (for tenants on Tier 3+ with a designated incident-call channel) by direct call or secure-messaging follow-up. The email includes a signed PDF summary in a layout designed for forwarding to a supervisory authority. Where the tenant has designated an emergency telephone contact, OperaFO attempts contact in parallel.

Timeline of subsequent updates.

• Within twenty-four (24) hours of the initial notification — confirmation of containment status, refined estimates of affected data subjects and records, and details of any temporary mitigations in place.
• Within seventy-two (72) hours of the initial notification — refined description of the nature and likely consequences, sub-processor involvement (if any), and whether any data subjects must be notified directly by Customer.
• Within seven (7) days of the initial notification — preliminary post-incident review identifying the contributing factors, a remediation plan with target dates, and confirmation of any permanent mitigations deployed.
• Within thirty (30) days of containment — final post-incident review including root cause, full remediation status, and changes to the TOMs.

Where information is not available within the seventy-two-hour window, OperaFO will provide the available information and supplement as further information becomes available, without further undue delay. OperaFO will not include in the breach notification speculative root-cause assertions; root cause is established through the post-incident review and shared with Customer once available.

Cooperation. OperaFO will provide reasonable cooperation and information as Customer requires to fulfil Customer’s own notification obligations to supervisory authorities (including the UAE Data Office, the DIFC Commissioner of Data Protection, the ADGM Office of Data Protection, and EEA / UK supervisory authorities as applicable) and to affected data subjects. OperaFO will retain all breach-related records for at least seven (7) years from containment.

Once per twelve-month period, and at no charge, Customer may audit OperaFO’s compliance with this DPA by either (a) submitting a written data-protection questionnaire to which OperaFO will respond within thirty (30) days, or (b) reviewing OperaFO’s most recent third-party assurance report (e.g. SOC 2 Type II, ISO 27001) where one exists.

Accepted questionnaire formats. OperaFO accepts industry-standard questionnaires including the CAIQ (Cloud Security Alliance Consensus Assessments Initiative Questionnaire), the SIG (Shared Assessments Standardised Information Gathering) questionnaire (full or lite), and the equivalent Customer-supplied questionnaire of comparable scope. Custom-format questionnaires are accepted but may be consolidated into the CAIQ baseline for response efficiency. Each response is signed by an OperaFO officer and is provided under written confidentiality.

Accepted assurance reports. Customer may rely on (i) the latest SOC 2 Type II report once published, (ii) ISO 27001 certificate and Statement of Applicability once obtained, (iii) penetration-test executive summaries from independent testers, redacted to protect attack-relevant detail, and (iv) any other third-party assurance report OperaFO publishes from time to time. Where such reports are not yet available because of OperaFO’s current programme phase, the questionnaire route applies and OperaFO will indicate target dates for the corresponding certification.

On-site audit procedure. If a questionnaire response or assurance report is not sufficient to satisfy a regulatory request applicable to Customer, Customer may, on at least sixty (60) days’ advance written notice, conduct an on-site audit of OperaFO’s production environment at Customer’s expense, subject to:

• Notice — written, addressed to privacy@operafo.ae, identifying the regulatory basis for the audit, the proposed scope, the proposed duration, the proposed dates, and the identity and qualifications of the auditor.
• Scope — limited to those controls, records, and personnel reasonably necessary to evidence OperaFO’s compliance with this DPA in respect of Customer’s data. Reasonable granularity, no fishing expeditions.
• Duration — typically up to two (2) business days on-site, extendable by mutual agreement where scope warrants.
• Attendees — the independent auditor and a reasonable number of Customer-side observers, each subject to written confidentiality. OperaFO is entitled to have its DPA contact and an engineering representative present throughout.
• Independence — the auditor must be a reputable independent third party (or a Customer internal auditor of equivalent independence) and must not be a competitor of OperaFO.
• NDA — entry is subject to written confidentiality obligations no less protective than §8 of the Terms of Service. Audit findings, working papers, and any data observed during the audit are Customer Confidential Information and OperaFO Confidential Information jointly.
• Frequency — limit of one (1) on-site audit per twelve-month period (more if required by Customer’s regulator with documented evidence of the requirement, or following a Personal Data Breach).

Out-of-scope items. The following are expressly out of scope for any audit: (i) personal data of other tenants; (ii) OperaFO source code beyond the portions reasonably necessary to evidence a specific control (and then only under structured walkthrough, not extraction); (iii) OperaFO financial records unrelated to data-protection compliance; (iv) commercial arrangements with sub-processors beyond what is required to evidence the existence and substance of their data-protection obligations; (v) employee personal records beyond evidence of confidentiality obligations and access-review records.

Following any audit, the parties will meet promptly to discuss findings and any remediation plan. OperaFO will, in good faith, propose remediation timelines proportionate to the criticality of any findings, and will report progress against the plan to Customer at reasonable intervals until closure.

OperaFO will, taking into account the nature of the processing, assist Customer by appropriate technical and organisational measures, insofar as possible, in fulfilling Customer’s obligation to respond to requests from data subjects exercising their rights under applicable data-protection law. Where a data subject contacts OperaFO directly with a request relating to Customer Personal Data, OperaFO will (a) advise the data subject to contact Customer, (b) notify Customer of the request without undue delay, and (c) not respond substantively without Customer’s instruction.

In-product tools by right. The following tools are provided in-product to enable Customer’s tenant administrators to respond to each principal right without OperaFO intervention:

• Right of access (subject access). In-app per-user export at /account/export/csv and /account/export/json includes profile, role assignments, session history, audit-log entries, AI Analyst transcripts, support-ticket associations, uploaded-document metadata, and any free-text fields attributable to the user. The export bundle is accompanied by a structured field dictionary.
• Right to rectification (correction). Authorised Users update their own profile fields (name, language, contact email) at /account/profile. Tenant administrators correct beneficiary, family-tree, counterparty, and document-metadata fields through the relevant module’s edit flow. Each correction is recorded in the audit trail.
• Right to erasure. Tenant administrators delete a named user via /account/delete (which removes the user from the Authorised User list, revokes sessions, and queues data for scheduled deletion under §13). Tenant-wide deletion is initiated by the tenant owner via the tenant-management flow and triggers the §13 procedure for the entire tenant.
• Right to portability. Per-user CSV and JSON exports plus tenant-wide structured archive exports satisfy portability in machine-readable form. Customer receives a documented field dictionary on request.
• Right to restriction of processing. Tenant administrators flag a named user as restricted, which suspends inclusion of that user’s data in computed analytics and AI Analyst context while preserving the underlying records. Restriction is recorded in the audit trail and reversible by the tenant administrator.
• Right to object. Where the controller-level lawful basis depends on legitimate interests, Customer may use the restriction tool above to give effect to a successful objection. Where the objection relates to processing for which OperaFO is the Controller (e.g. marketing-site cookies), OperaFO responds directly.
• Rights related to automated decision-making. The Service does not make fully-automated decisions producing legal or similarly significant effects on data subjects; AI Analyst output is decision support, not decision automation. Customer should ensure human review of any output before action.
• Right to withdraw consent. Where Customer has relied on consent for a specific processing operation, Customer can give effect to withdrawal through the relevant feature toggle or data-removal flow. OperaFO supports Customer in identifying the affected data on request.

Where a request requires assistance beyond the in-product tools, Customer raises a ticket to privacy@operafo.ae. OperaFO acknowledges within five (5) business days and proposes a course of action with timing.

OperaFO will, taking into account the nature of the processing and the information available to OperaFO, provide reasonable assistance to Customer with any data-protection impact assessments (DPIAs) and prior consultations with supervisory authorities that Customer is required to conduct under applicable law.

Pre-built DPIA inputs. OperaFO makes available, on request, the following pre-built inputs for Customer’s use in completing a DPIA:

• Description of TOMs — the latest version of the Annex 1 (§16) TOMs, including any control-evidence references that Customer can cite in its DPIA.
• Sub-processor list — the current list with categories of personal data, region of processing, purpose, and transfer mechanism per §7 and §8.
• Cross-border transfer mechanism summary — the table of mechanisms in §8, with executed-copy references on request.
• Data-flow diagram — a one-page architecture diagram showing the path of Customer Personal Data through the Service, including ingress, storage, computation, AI augmentation, observability, billing, and egress.
• Retention schedule — the deletion cadence per data category as set out in §13 and §16.
• Audit-log specification — the immutable-event schema and retention policy.
• Breach history — a written statement of any reportable Personal Data Breaches affecting Customer’s tenant in the preceding twelve (12) months. As of the Effective Date of this DPA: none.
• Roles and responsibilities matrix — the allocation of data-protection responsibilities between OperaFO as Processor and Customer as Controller.
• Tenant-isolation evidence — description of the Postgres FORCE ROW LEVEL SECURITY configuration on the application database role and the output of the latest automated isolation verification run.
• Sub-processor due-diligence summary — high-level summary of the security and data-protection posture of each sub-processor as reviewed by OperaFO.

Where a supervisory authority requires prior consultation under PDPL Article 21 / GDPR Article 36 / equivalent provisions, OperaFO cooperates with Customer to provide additional information, attend joint calls with the supervisory authority where useful, and propose mitigations responsive to the authority’s concerns.

On termination or expiration of the Subscription, and at Customer’s written choice, OperaFO will either (a) return Customer Personal Data to Customer in a structured, commonly used, machine-readable format using the in-product export tools, or (b) delete Customer Personal Data from production systems within thirty (30) days, except to the extent applicable law requires retention.

Detailed deletion procedure by system.

• Production database (Postgres tenant tables). Tenant rows in every tenant-scoped table are deleted on the agreed deletion date. Foreign key cascades resolve in dependency order. Deletion is immediate and irreversible from production.
• Object storage (S3-compatible cold storage). Uploaded documents and rendered exports are tagged for deletion on the agreed deletion date. Delete markers are placed within thirty (30) days; lifecycle policy ages out the underlying objects within a further sixty (60) days, for a total maximum window of ninety (90) days from the deletion date.
• Search indexes (OpenSearch / equivalent index). Tenant-scoped index documents associated with the tenant are deleted within twenty-four (24) hours of the agreed deletion date. Index segments are merged on the next maintenance cycle.
• AI prompt caches. Any provider-side prompt cache entries are subject to the zero-day-retention enterprise terms with Anthropic. Internal cache entries (where used) carry a maximum twenty-four-hour TTL and are not refreshed for a deleted tenant.
• Operational telemetry (Sentry-protocol / GlitchTip; PostHog). Sentry-protocol events are aged out on the rolling event-retention window configured at the sink (typically 30 days). PostHog events for the deleted tenant are deleted on request via the provider’s tenant-deletion API. Both systems receive scrubbed payloads only.
• Audit logs. Audit-log entries are retained for the retention period set in §16 (default seven (7) years) regardless of Subscription end-date, in line with the immutability principle and the legitimate-interest basis for retaining a financial audit record. Customer may request a shorter retention by written instruction; OperaFO will consider and respond.
• Backups. Daily VPS-level snapshots and database-level pg_dump backups age out under the routine backup-retention cycle (currently up to ninety (90) additional days). During the aging-out period, no personnel will access Customer Personal Data on backups except as necessary to comply with a binding legal request. Backups are encrypted with a separate key and are not selectively edited (deletion is by full age-out only, in keeping with backup integrity).
• Source-control / build-system metadata. Any tenant-identifying metadata accidentally emitted to build logs or CI artefacts is reviewed and redacted on request.
• Support tickets. Tickets referencing the deleted tenant are retained for the standard ticket-retention window (typically two (2) years from closure) for warranty and continuous-improvement purposes; tickets are scrubbed of free-text personal data on request.

Confirmation of deletion. On request, OperaFO will provide a written confirmation of deletion within thirty (30) days of completing the production-database deletion, with a follow-up confirmation within ninety (90) days covering backup age-out completion. The confirmation identifies the tenant, the systems within scope, the deletion date, and the retention exceptions (audit log, backup age-out window, statutory retention).

Statutory retention. Where applicable law requires retention of specific records (e.g. financial-records-retention rules, tax law, anti-money-laundering record-keeping), OperaFO retains the minimum necessary data for the period required and segregates it from active production processing. Such retention is documented and is released on the expiration of the legal requirement.

Each party’s aggregate liability arising out of or in connection with this DPA is subject to the limitation of liability provisions of the Terms of Service. Notwithstanding the foregoing, each party’s liability for breach of its data-protection obligations under this DPA is not capped where applicable law prohibits such cap.

Interaction with regulatory fines. Administrative fines imposed by a supervisory authority directly on a Controller or Processor for a breach of applicable data-protection law are not, of themselves, excluded from recoverability between the parties. In particular:

• PDPL. Administrative fines under UAE Federal Decree-Law No. 45 of 2021 (and the related Cabinet Resolutions, including Article 60 of the PDPL framework on penalties) imposed on Customer for a breach attributable to OperaFO’s fault remain recoverable from OperaFO to the extent of that fault and subject to applicable law.
• GDPR / UK GDPR. Administrative fines under GDPR Article 83 (and its UK equivalent) imposed on Customer for a breach attributable to OperaFO’s fault remain recoverable from OperaFO to the extent of that fault and subject to applicable law.
• DIFC. Administrative penalties under the DIFC Data Protection Law No. 5 of 2020 imposed on Customer for a breach attributable to OperaFO’s fault remain recoverable from OperaFO to the extent of that fault and subject to applicable law.
• ADGM. Administrative penalties under the ADGM Data Protection Regulations 2021 imposed on Customer for a breach attributable to OperaFO’s fault remain recoverable from OperaFO to the extent of that fault and subject to applicable law.

For the avoidance of doubt, neither party may recover under this DPA the same loss that has already been recovered under the Terms of Service, and the limitation-of-liability and exclusion-of-indirect-loss provisions of the Terms of Service apply in construction.

In the event of a conflict between contractual instruments in respect of personal data processing, the following order of precedence applies (highest first):

• 1. Order Form / signed Subscription Agreement — only to the extent of expressly-negotiated bilateral data-protection terms that name this DPA and override a specific clause.
• 2. This DPA — including its Annex 1 (§16) TOMs.
• 3. Terms of Service — for all matters not specifically governed by this DPA.
• 4. Privacy Policy — operative description of OperaFO’s data practices, the sub-processor list, and the cookie inventory.
• 5. Documentation, knowledge base, and in-product help — descriptive content helpful to interpret feature behaviour but not, of itself, a binding contractual instrument.

Modifications. We may update this DPA from time to time to reflect changes in applicable law, sub-processor relationships, or our security posture. Material changes are notified at least thirty (30) days in advance through the same parallel channels as a sub-processor change (email to the tenant’s designated privacy / administrator contact, in-product banner on next sign-in by a tenant administrator, and dated changelog entry on the public page). Non-material clarifications or typographical corrections may be applied without advance notice but are still recorded in the changelog. Continuing to use the Service after the change takes effect is acceptance of the updated DPA. Where Customer reasonably objects to a material change on data-protection grounds within the thirty-day notice window, the parties will engage in good-faith discussion under the same approach described in §7 (sub-processor objection).

The following technical and organisational measures (TOMs) are implemented to ensure a level of security appropriate to the risk. They are reviewed at least annually and after any material change to the Service, sub-processor landscape, or threat model. Each category sets out the principal sub-controls and, where relevant, the specific evidence reference in the rebuild’s codebase.

1. Tenant isolation.

• Postgres ROW LEVEL SECURITY enabled on every tenant-scoped table, with FORCE ROW LEVEL SECURITY applied so that the policy is honoured even by table owners.
• Application database access pinned to the least-privileged operafo_app role; superuser / bypass-RLS roles are reserved for migrations and are not used by application code paths.
• Tenant context set per-request via session-scoped GUC and validated against the authenticated session. No tenant identifier is taken from client-controllable input without server-side re-resolution.
• Operational verification by an automated check at api/scripts/verify_rls_isolation.py that confirms an operafo_app session pinned to tenant A cannot read tenant B’s rows on representative tables. The check runs on every deploy and gates the release.
• ADR 0001 SECURITY DEFINER charter test blocks any new database helper from being merged without a pinned search_path, eliminating a common RLS-bypass vector. Pinned in the platform's release-gate test suite.
• Object-storage prefixes are scoped per tenant, with IAM policies that prevent cross-tenant listing or retrieval.
• Search-index documents carry a tenant identifier on every document, with query-time filters applied unconditionally at the application layer.

2. Encryption.

• TLS 1.3 (with TLS 1.2 fallback only as required for older-client compatibility) for all in-transit data between client and edge, edge and application, application and database, and application and sub-processors.
• AES-256-GCM at rest for the primary database volume, for object storage, and for backup volumes, provided by the hosting platform.
• Bcrypt-hashed passwords with cost factor 12; password-handling code paths are reviewed under the SECURITY DEFINER charter where applicable.
• Backup encryption keys are managed separately from primary-volume keys, so that exposure of a primary key does not by itself enable decryption of backups.
• Sub-processor connections use the strongest TLS profile each sub-processor supports; certificate pinning is applied for high-value egress where feasible.
• Key rotation cadence: TLS certificates per the hosting and CDN provider rotation; password hashes rotated transparently on next successful sign-in when the cost-factor or algorithm baseline changes.

3. Authentication.

• httpOnly + Secure + SameSite=Strict session cookies, short-lived with rolling refresh on activity.
• Same-origin gating on the login endpoint to block CSRF-leveraged credential submission.
• Rate-limited failed-login lockout per account and per source IP, with exponential backoff and a documented unlock procedure for legitimate users.
• Optional Google OAuth where Customer enables it, with strict subject / hosted-domain checks.
• Idle-session timeout configured at the application layer; absolute-session timeout enforced regardless of activity.
• Multi-factor authentication is required for all OperaFO production-console access. A Customer-facing optional MFA enrolment is on the product roadmap; in the interim, Customers can enforce SSO-side MFA via Google OAuth where used.

4. Authorisation and RBAC.

• Role-based access control within each tenant with five roles: owner (one per tenant, full administrative authority), admin (delegated administration, cannot delete the tenant or transfer ownership), member (write access scoped to assigned modules), viewer (read-only access to assigned modules), and service (machine-to-machine, scoped to specific API routes).
• Scoping rules enforced at the route handler and at the data-access layer; viewer accounts cannot trigger write paths or AI Analyst submissions outside read-only flows.
• Service tokens are scoped per service (no general superuser tokens), are rotated on a documented cadence, and are revocable from the tenant settings.
• Privileged actions (role changes, tenant deletion, data export) require a re-authentication step proportionate to the impact.

5. PII scrubber.

• Free-text fields headed for any external transmission (LLM, observability sink, analytics) pass through a regex scrubber documented at api/common/pii_scrubber.py and api/common/observability.py.
• Denylist coverage includes: email addresses, international phone numbers, IBANs and account-number patterns, credit-card-shaped digit sequences with Luhn validation, Emirates ID patterns, passport-number patterns, and tokens shaped like API keys, bearer tokens, or JWTs.
• Scrubber output is pinned by contract tests so that regressions in coverage block CI.
• Scrubbed payloads carry a content-hash so that downstream consumers can detect and report unscrubbed fields.
• Periodic review (at least annually) of the denylist against newly-observed personal-data patterns, driven by sample audit of telemetry.

6. Audit logging.

• Every authenticated action is logged with actor (user identifier), tenant, timestamp (ISO-8601 with timezone), request identifier, source IP, normalised event type drawn from a committed enum, target resource identifier, and outcome (success / failure / partial).
• Logs are immutable and append-only at the storage layer; modification or deletion is blocked at the database role level.
• Default retention is seven (7) years from event timestamp, in line with financial-record retention expectations applicable to family-office customers. Customer may instruct a shorter retention in writing.
• Log integrity is supported by daily summary records and a counter check that detects gaps or out-of-order writes.
• Logs are available to Customer’s tenant administrators through the in-product audit-trail views and through the per-user export described in §11.

7. Vulnerability management.

• Dependencies pinned with renewable upper bounds in the application manifest; transitive dependencies resolved against a lockfile.
• CI pipeline includes a CVE gate that blocks builds on known-CVE detection above an agreed severity threshold; exemptions are time-bounded and recorded.
• ADR 0001 SECURITY DEFINER charter test blocks any new database helper from being merged without a pinned search_path, removing a class of privilege escalation through search-path injection.
• Static analysis runs on every pull request for Python, TypeScript, and SQL surfaces.
• Container images are rebuilt on a documented cadence to absorb base-image security updates; out-of-band rebuilds are triggered by high-severity advisories.
• Penetration testing by an independent third party is on the programme roadmap and will be repeated annually once initiated.

8. Incident response.

• Documented runbook covering, at minimum: RLS leak, mid-demo crash, partial migration commit, full deploy revert, sub-processor outage, secret leak, and Personal Data Breach.
• On-call rotation among named engineers with out-of-hours coverage; an incident commander is designated at the start of every Severity 1 / 2 incident.
• Tenant owners notified of any customer-impacting incident within seventy-two (72) hours, with shorter windows where applicable law requires (per §9).
• Post-incident review is mandatory after every Severity 1 / 2 incident, with a documented blameless-review template that produces remediation actions tracked to closure.
• Annual table-top exercise of the runbook to confirm on-call competence and runbook accuracy.

9. Backups and disaster recovery.

• Daily VPS-level snapshots with seven-day retention; database-level pg_dump on a separate cadence; both are encrypted under a separate key from the primary volume.
• Disaster-recovery objectives: RTO ≤ four (4) hours, RPO ≤ twenty-four (24) hours.
• Semi-annual disaster-recovery test that performs a full restore into an isolated environment and confirms application bring-up against a smoke-test suite.
• Backup integrity verified through periodic restore drills and through automated checksum comparison on pg_dump artefacts.

10. Personnel security.

• Production-data access limited to a small number of named engineers under written confidentiality, per §6.
• Joiners-movers-leavers process documented and followed on every personnel change, per §6.
• Quarterly access review of the production access register, per §6.
• Principle of least privilege applied at provisioning time and reaffirmed at each access review.
• Annual data-protection awareness training; new joiners complete training within thirty (30) days of start.

11. Vendor and sub-processor management.

• Each sub-processor contracted under written terms imposing data-protection obligations equivalent to this DPA, per §7.
• Initial due-diligence covers the sub-processor’s certifications, regional footprint, breach history, data-protection terms, and operational maturity.
• Annual review of each sub-processor with reference to any updated assurance reports, regulatory actions, and material business changes.
• Sub-processor list maintained in the Privacy Policy and updated as relationships change, with a dated changelog.
• AI sub-processors operate under zero-data-retention enterprise terms (Anthropic) where reasonably available.

12. Physical security.

• Production systems are hosted on Hetzner Helsinki / EU-Central. Hetzner data centres are operated under ISO 27001 certification and operate the industry-standard physical access controls (biometric / badge access, CCTV, environmental monitoring).
• No OperaFO personnel hold physical access to the hosting facility; physical security is provided by the hosting sub-processor.
• Office environments where OperaFO personnel work do not store production data; Customer Personal Data is not downloaded to local devices except as transiently necessary for support tickets, in which case it is deleted on ticket closure.

13. Network security.

• Default-deny firewall rules at the network and host level; only required ingress ports are exposed.
• Egress is restricted to the documented sub-processor endpoints; outbound to unexpected destinations is alerted.
• Rate limiting on authentication endpoints and on expensive analytical endpoints, with abuse-detection heuristics.
• DDoS mitigation provided at the edge tier; abuse patterns trigger automated blocks.
• Administrative access to the production environment is gated behind MFA and a single bastion channel that records actor, command, and outcome.

14. Secure software development lifecycle.

• Mandatory peer code review before merge; no direct pushes to protected branches.
• Automated unit, integration and contract test suites must pass on every pull request; the suite includes the tenant-isolation verification, the SECURITY DEFINER charter test, and the PII-scrubber contract test.
• Threat modelling applied to material new features — e.g. AI Analyst, Document RAG, agentic flows (Tier 4) — with documented mitigations recorded against the feature design.
• Secrets stored in a managed secret store, never in source; secret-scanning runs on every pull request.
• Production releases follow a documented promotion path with rollback procedure recorded.

15. Business continuity.

• Documented business-continuity plan covering loss of hosting region, loss of a critical sub-processor, and prolonged loss of key personnel.
• Multi-region restore option available within the hosting provider’s footprint, exercised periodically.
• Sub-processor contingency arrangements documented for AI inference (alternative provider on zero-retention terms), billing (alternative processor), and observability (self-hosted fallback).
• Annual review of the business-continuity plan with documented updates against changes in the Service or the regulatory environment.
• Customer-facing status page at /status communicates incident state in plain language during continuity events.