askNiva Data Processing Addendum

> Notice. This DPA forms part of the askNiva Agreement (see §23.1 of the Terms of Service). It governs the processing of Personal Information by askNiva as an Operator (POPIA) / processor (GDPR) on the instructions of the User as Responsible Party (POPIA) / controller (GDPR). In a conflict between this DPA and the Terms or the Acceptable Use Policy on any data-protection matter, this DPA prevails (see §23.2 of the Terms).

---

1. Parties and scope

1.1 This DPA is entered into between:

  • (a) Mollo Innovations (Pty) Ltd (registration number 2026/275132/07), a private company incorporated in the Republic of South Africa, trading as "askNiva", having its registered office at Regus Business Centre, 1st Floor, Block B, North Park, Black River Park, 2 Fir Street, Observatory, Cape Town, Western Cape, South Africa, 7925 ("askNiva", the "Operator" under POPIA and the "processor" under GDPR); and
  • (b) you, the User of the askNiva Service, being the "Responsible Party" under POPIA and, where applicable, the "controller" under GDPR ("you", "your").

1.2 Scope. This DPA applies where, and only where, askNiva processes Personal Information on your behalf in connection with your use of the Service. It does not apply to:

  • (a) Personal Information that askNiva collects directly from you as Responsible Party for its own purposes (for example, account, billing, and metadata), which is governed by the Privacy Policy; or
  • (b) any independent processing by third-party AI Providers, Hetzner, Paystack, or Google, except to the extent those parties act as sub-processors of askNiva under §6 of this DPA.

1.3 Defined terms. Capitalised terms used but not defined in this DPA have the meaning given in the Terms of Service.

---

2. Definitions and role mapping

2.1 For the purposes of this DPA:

  • "Applicable Data Protection Law" means POPIA, the GDPR (where applicable to your processing), and any other data-protection law that applies to the processing under this DPA.
  • "Data Subject" means a natural person to whom Personal Information relates (POPIA) / data subject (GDPR, Article 4(1)).
  • "Personal Information" means Personal Information as defined in POPIA §1, and includes personal data as defined in GDPR Article 4(1).
  • "Processing" means any operation or set of operations performed on Personal Information, whether or not by automated means (POPIA §1; GDPR Article 4(2)).
  • "Responsible Party / Controller" means, as context requires, the Responsible Party under POPIA §1 or the controller under GDPR Article 4(7).
  • "Operator / Processor" means, as context requires, the Operator under POPIA §1 or the processor under GDPR Article 4(8).
  • "Sub-processor" means any third party engaged by askNiva to process Personal Information on behalf of you.
  • "Security Incident" means any confirmed or reasonably suspected unauthorised access to, or unauthorised destruction, loss, alteration, or disclosure of, Personal Information processed under this DPA (including a "compromise" under POPIA §22 and a "personal data breach" under GDPR Article 4(12)).

2.2 POPIA / GDPR role mapping.

| Role of party | POPIA term | GDPR term |

|---|---|---|

| You (the User) | Responsible Party | Controller |

| askNiva | Operator | Processor |

| Any third party askNiva contracts with | Sub-contracted Operator | Sub-processor |

2.3 Independent-controller scenarios. Where askNiva determines the purpose and means of any processing (for example, to satisfy its own legal obligations, for fraud prevention, or for billing), askNiva acts as an independent Responsible Party / controller in respect of that processing and this DPA does not apply to that processing.

---

3. Subject matter, duration, nature, and purpose

3.1 Subject matter. The subject matter of the processing governed by this DPA is Personal Information contained in Customer Data submitted to, stored on, or generated through your Instance during askNiva's operational handling of the Instance. For the avoidance of doubt, the subject matter does not include:

  • (a) inference traffic that travels directly from your Instance's Hetzner IP address to an AI Provider you configure using your own AI-Provider credential (for that traffic, you contract directly with the AI Provider; askNiva is not in the data path — see Privacy Policy §§9.5, 14.6 and DPA §§6.2, 6.2A); or
  • (b) Personal Information you (or any user of your Instance) voluntarily route outside your Instance (for example, by copying Customer Data into a support ticket with askNiva, in which case askNiva acts as an independent Responsible Party / controller in respect of the support ticket — see Privacy Policy §8 Purpose 5 and §2.3 of this DPA).

3.2 Duration. The processing continues for the term of the Agreement and any additional retention period permitted by §10 and by AUP §§16.8 and 16.9, and is subject to the POPIA §14 retention principles.

3.3 Nature of processing. The processing consists of the following routine technical operations required to make the Service available to you:

  • (a) provisioning and maintaining your Instance on Hetzner infrastructure (POPIA §§19, 20);
  • (b) storage of Customer Data on Instance volumes and, for continuity, in Hetzner's backup / snapshot rotation;
  • (c) transmission of Customer Data as directed by your configuration (including routing inference requests to AI Providers you configure — in transit from your Instance, not through askNiva's control plane);
  • (d) access control (access by askNiva personnel for provisioning, security, abuse response, and User-initiated support only, under the role-based access controls described in §7 of this DPA and in Privacy Policy §13);
  • (e) logging and telemetry at infrastructure, control-plane, and abuse-detection layers (the content of which is limited to Operational Telemetry and Service Logs as defined in the Privacy Policy — not prompt content or Output content);
  • (f) security and abuse response (preservation under AUP §§16.8 and 16.9, Security-Incident handling under §9 of this DPA, and cooperation with authorities under §18 of the Terms); and
  • (g) return or deletion of Customer Data under §10 on your instruction or on termination of the Agreement.

3.4 Purpose of processing. The sole purpose of the processing under this DPA is to provide the Service to you as specified in the Agreement, including the operations in §3.3. askNiva does not use Customer Data for any other purpose, including (for the avoidance of doubt) the training of any AI or machine-learning model, product analytics other than at aggregate non-identifying level under Privacy Policy §6.10, or onward disclosure except as permitted by §18 of the Terms and §§16.8 and 16.9 of the AUP. The corresponding askNiva obligations in respect of GDPR Article 28(3)(e) (assistance with Articles 12–22 Data Subject rights), Article 28(3)(f) (assistance with Articles 32–36), Article 28(3)(g) (return or deletion at end of processing), and Article 28(3)(h) (information and audit) are set out in §§8, 9, 10, and 11 of this DPA respectively; the corresponding POPIA obligations are set out in the same sections.

3.5 Categories of Personal Information. Personal Information processed under this DPA may include (as foreseeable at the date of this DPA):

  • (a) identifiers — names, Account identifiers, email addresses, usernames, device and session identifiers in Customer Data;
  • (b) contact information — email addresses, telephone numbers, postal addresses, messaging handles in Customer Data;
  • (c) communications content — prompts, messages, documents, attachments, email and chat bodies handled by your Instance (agent inputs and outputs);
  • (d) files and documents — files you or an authorised user of your Instance upload to, or cause to be stored on, your Instance;
  • (e) configuration metadata — agent configuration, tool definitions, workflow definitions, credentials (encrypted at rest per Privacy Policy §13 and DPA §7 and Annexe 1 — AI-Provider API keys held subject to envelope encryption);
  • (f) Instance usage metadata — timestamps, action logs, tool-invocation records, request / response sizes (metadata only; not prompt or Output content);
  • (g) IP addresses and device data of users of your Instance;
  • (h) Special Personal Information (POPIA §26; GDPR Article 9 — religion, race, trade union, political persuasion, health, sex life, biometrics, criminal behaviour) only to the extent you cause such information to be processed in breach of your warranty at Terms §9.5(d) and AUP §§5.1, 7.2; and
  • (i) any other Personal Information you cause to be processed through the Service.

You warrant and covenant that you will not cause Personal Information outside the reasonable scope of the Service to be processed, and that you will comply with your POPIA / GDPR obligations as Responsible Party / controller in respect of all categories you cause to be processed (see Terms §9.5).

3.6 Categories of Data Subjects. Data Subjects whose Personal Information may be processed under this DPA include:

  • (a) you and your personnel, contractors, and agents (to the extent you submit their Personal Information to your Instance);
  • (b) end users of any application you build on your Instance (including users you authorise to interact with the agent);
  • (c) counterparties of actions your agent performs (email recipients, addressees of messages, owners of third-party accounts the agent accesses on your instruction);
  • (d) third parties whose Personal Information appears in Customer Data you submit to your Instance (for example, Personal Information embedded in documents, databases, or message content);
  • (e) children only to the extent you permit children's information to be processed — in which case you warrant compliance with POPIA §§34–35 and any other applicable children's-data law (see Terms §2.1 and Privacy Policy §21); and
  • (f) any other Data Subject whose Personal Information you cause to be processed through the Service.

---

4. Processing instructions

4.1 askNiva shall process Personal Information only on your documented instructions. The Agreement (the Terms, this DPA, the AUP, and the Privacy Policy, together with any configuration you apply to your Instance) constitutes your documented instructions. Any other instruction must be given in writing and accepted by askNiva.

4.2 askNiva may also process Personal Information to the extent required by applicable law (including South African, German, EU, or US law binding on askNiva as Operator or on its sub-processors); in that case, askNiva shall inform you of the legal requirement before processing, unless the law prohibits that disclosure on important grounds of public interest. Where your processing instructions include Personal Information falling within GDPR Article 9 or POPIA §26 (Special Personal Information), you warrant that an appropriate Article 9(2) / POPIA §27 condition is in place, and you acknowledge that askNiva's technical and organisational measures in Annexe 1 are the measures it commits to in relation to such processing; askNiva is not required to implement additional measures beyond Annexe 1 unless the parties agree them in writing under §15.4.

4.3 askNiva shall promptly inform you if, in its opinion, an instruction from you infringes Applicable Data Protection Law.

---

5. Confidentiality

5.1 askNiva shall ensure that personnel authorised to process Personal Information are bound by appropriate confidentiality obligations, whether contractual or statutory, for the duration of their engagement and after it ends.

---

6. Sub-processors

6.1 General authorisation. You give askNiva general written authorisation to engage Sub-processors for the processing of Personal Information, subject to the conditions of this §6.

6.2 Current Sub-processors. At the date of this DPA, askNiva uses the following Sub-processors:

| Sub-processor | Role | Primary processing location | Legal basis for transfer | Art. 28 / §21 execution status |

|---|---|---|---|---|

| Hetzner Online GmbH | Hosting of Instance (infrastructure, storage, networking) | Germany (Nuremberg, Falkenstein) or Finland (Helsinki); where you select a non-EU region (US Ashburn / Hillsboro; Singapore), your selection constitutes your Article 49 GDPR derogation / POPIA §72 consent, and EU SCCs Module 2/3 as scheduled apply | Intra-EU by default; for non-EU regions, POPIA §72 / GDPR Art. 49 consent as above; GDPR Art. 28 DPA executed via Hetzner Robot | Hetzner Art. 28 GDPR AVV executed via Hetzner Robot on 2026-05-20; execution recorded in the Operator-Contract Register (§6.5); see launch-readiness register |

| Paystack Payments Limited | Subscription-fee processing | Nigeria (HQ), with payment-rails routing as configured by Paystack | POPIA §72(1)(b) contractual-provisions basis; GDPR Art. 46(2)(c) SCCs (Module 2 where askNiva is controller; Module 3 where askNiva is processor) | Paystack written processor agreement / DPA — execution pending; date to be recorded in the Operator-Contract Register (§6.5) upon execution; see launch-readiness register |

| Google LLC (OAuth) | Identity / authentication provider (Google OAuth profile data only) | United States | POPIA §72 adequacy / Data Privacy Framework; GDPR Art. 46 SCCs where applicable | Governed by Google API Services User Data Policy (Limited Use) as a "policy-based mandate" (Art. 28 not engaged for pure OAuth-only use; Google may act as independent / joint controller for identity-graph processing). DPF certification status checked at https://www.dataprivacyframework.gov/list before first use and annually |

| AI Providers (sub-processor role) | N/A — AI Providers are not sub-processors of askNiva for purposes of routing Inference requests | — | — | Split-role clarification: where you route inference requests to Anthropic, OpenAI, Google Gemini / Vertex AI, AWS Bedrock, Azure OpenAI, or another AI Provider using your own credential, you are the direct contractual counterparty of that AI Provider under Terms §§1.1, 6.2; askNiva's role is limited to routing and is not a processor of the resulting AI-Provider-side processing. Google is a sub-processor of askNiva only in its OAuth role above — not in its Vertex AI / Gemini role |

An up-to-date list is available at https://askniva.com/legal/sub-processors. Additional operational Sub-processors (email delivery, monitoring, CDN, DNS, analytics, support tool) engaged at or after launch are added to this table per the launch-readiness register before production processing begins.

6.2A AI Providers' own sub-processors. AI Providers' own sub-processors (for example, Google's sub-processors engaged for Gemini API / Vertex AI; Anthropic's infrastructure sub-processors; OpenAI's downstream sub-processors) are outside askNiva's control. You are the AI Provider's direct customer for those services; any objection, notification, or audit rights regarding an AI Provider's sub-processors must be exercised by you directly with the AI Provider under its own DPA.

6.3 New Sub-processors. askNiva shall give you at least thirty (30) days' prior notice of any new Sub-processor or any change of Sub-processor, by email or in-product notification. You may object to the new Sub-processor on reasonable data-protection grounds by written notice to dpo@askniva.com within the notice period. If the parties cannot resolve the objection in good faith, you may terminate the affected Subscription for convenience under §13.4 of the Terms.

6.4 Flow-down. askNiva shall enter into a written contract with each Sub-processor imposing data-protection obligations substantively equivalent to those in this DPA. askNiva remains liable to you for the acts and omissions of its Sub-processors as if they were askNiva's own. Where Personal Information includes data obtained from Google APIs subject to the Google API Services User Data Policy (including OAuth profile data), askNiva shall procure that each Sub-processor is contractually bound to the Limited Use restrictions on that data (no advertising, no AI training, no sale, no onward transfer except as permitted).

6.5 Register of processor agreements. askNiva maintains a register of its executed Sub-processor / processor-contract agreements (including dates of execution), available to you on written request to dpo@askniva.com.

---

7. Security of processing

7.1 Technical and organisational measures. askNiva implements the technical and organisational measures set out in Annexe 1 to this DPA ("TOM Annexe") to secure the integrity and confidentiality of Personal Information processed under this DPA, in accordance with POPIA §19 (read with §21(1)) and, where applicable, GDPR Article 32. The measures in the TOM Annexe are appropriate and reasonable having regard to the state of the art, the costs of implementation, the nature, scope, context and purpose of the processing, and the risks to Data Subjects. askNiva reviews and updates the TOM Annexe at least annually, upon any material change in processing or risk, and upon completion of any external certification or audit. Additional information about askNiva's security controls beyond the summary in Annexe 1 — including, as and when available, external audit reports, certification status, penetration-test summaries, and supplementary security documentation — is made available to Business Users upon written request to dpo@askniva.com, subject to the confidentiality obligations of §12 of the Terms and to any further confidentiality undertaking askNiva may reasonably require.

7.2 Residual risk. You acknowledge that no security measure eliminates all risk, and that the security posture of the Service depends on your own configuration, your Instance hardening, and your own credential management (see §12 of the AUP).

---

8. Data Subject requests

8.1 askNiva shall, taking into account the nature of the processing, assist you by appropriate technical and organisational measures, insofar as possible, to fulfil your obligations to respond to requests from Data Subjects to exercise their rights under Applicable Data Protection Law (including POPIA §23 access, §24 correction or deletion, and §11(3) objection; GDPR Articles 15–22).

8.2 If askNiva receives a request directly from a Data Subject relating to Personal Information processed on your Instance, askNiva shall, where lawful, forward the request to you without undue delay and shall not respond to the Data Subject except on your instruction or as required by law.

8.3 Cost. Where assistance in §8.1 requires materially more than routine effort by askNiva, the parties shall agree in writing on reasonable cost recovery.

---

9. Security incidents and breach notification

9.1 Notification to you. askNiva shall notify you of any Security Incident affecting Personal Information processed under this DPA without undue delay after becoming aware of it, and in any event no later than twenty-four (24) hours after reasonable awareness, so that you can meet your own 72-hour GDPR Article 33 / POPIA §22 obligation.

9.2 Content of notification. To the extent the information is available at the time of notification, askNiva shall provide:

  • (a) a description of the nature of the Security Incident, including (where possible) the categories and approximate number of Data Subjects and records concerned;
  • (b) the likely consequences of the Security Incident;
  • (c) the measures taken or proposed to address the Security Incident and to mitigate its possible adverse effects; and
  • (d) the name and contact details of askNiva's Data Protection / Information Officer.

9.3 Cooperation. askNiva shall reasonably cooperate with you to enable you to meet your notification obligations to the Information Regulator (POPIA §22) and, where applicable, to the competent supervisory authority under GDPR Article 33 and to Data Subjects under GDPR Article 34.

9.4 askNiva's direct obligations preserved. Nothing in this §9 limits askNiva's own notification obligations under POPIA or other law where askNiva acts as Responsible Party.

9.5 User-side notification to askNiva. You shall notify askNiva within twenty-four (24) hours of becoming aware of any Security Incident on your Instance that is or may be material to askNiva, its Sub-processors, or other Users, or that may trigger an upstream supplier's obligation to act (for example, a Hetzner abuse response, an AI Provider trust-and-safety review, or a payment-processor chargeback cascade).

---

10. Return and deletion of Personal Information

10.1 On termination or expiry of the Agreement, askNiva shall, at your choice made within the grace period specified in §13.5(c) of the Terms, return or delete all Personal Information processed on your behalf.

10.2 Deletion shall be performed within a reasonable period after the grace period, subject to:

  • (a) the evidence-preservation right in §13.7 of the Terms and §§16.8 and 16.9 of the AUP;
  • (b) any legal or regulatory obligation on askNiva to retain Personal Information; and
  • (c) backup and disaster-recovery copies, which shall be deleted in accordance with askNiva's routine backup retention cycle and which in the meantime remain subject to the security and confidentiality obligations of this DPA.

10.3 On written request, askNiva shall certify deletion to you.

---

11. Audit rights

11.1 Information provision. askNiva shall make available to you all information reasonably necessary to demonstrate compliance with this DPA.

11.2 Audits. Where required under Applicable Data Protection Law, askNiva shall allow for and contribute to audits — including inspections — conducted by you or an independent third-party auditor mandated by you and acceptable to askNiva (not to be unreasonably refused). Audits shall be:

  • (a) conducted on at least thirty (30) days' prior written notice (except in the case of a confirmed Security Incident);
  • (b) limited to once per calendar year (except following a Security Incident);
  • (c) conducted during normal business hours, subject to askNiva's security and confidentiality policies;
  • (d) at your cost, unless the audit reveals material non-compliance by askNiva; and
  • (e) satisfied, where reasonable and acceptable to you, by the provision of third-party certifications, SOC 2 Type II reports, or equivalent independent audit reports covering the relevant processing.

11.3 Audit-satisfaction package. For the purpose of §11.2(e), askNiva's current audit-satisfaction package comprises:

  • (a) Information response. On at least thirty (30) days' prior written notice to dpo@askniva.com (or immediate notice following a confirmed Security Incident), askNiva shall respond in writing to a reasonable documented questionnaire mapped to the controls in Annexe 1 (TOM Annexe). Responses are provided under the confidentiality obligations of §5 and the Agreement.
  • (b) Information Officer attestation. On written request, askNiva's Information Officer shall provide a written attestation that the TOM Annexe controls are implemented and effective at the date of the attestation, identifying any material exceptions and the remediation plan. The attestation is provided in discharge of the Information Officer's POPIA §56 duties.
  • (c) Inherited third-party evidence. askNiva shall make available, under appropriate confidentiality obligations, summaries or redacted reports of audits or certifications held by its Sub-processors (including Hetzner's TÜV Rheinland audit, Paystack's PCI DSS Level 1 attestation, and Google's ISO 27001 / SOC 2 reports) to the extent permitted by the relevant Sub-processor.
  • (d) Future askNiva certifications. Once askNiva has obtained a relevant third-party certification or audit report (including but not limited to SOC 2 Type I, SOC 2 Type II, or ISO 27001), askNiva shall make the report available under appropriate confidentiality obligations and the report shall, to the extent it covers the processing under this DPA, be the default audit-satisfaction vehicle for the scope it covers. On-site audits remain available under §11.2 for scope not covered.
  • (e) Post-Security-Incident audit. §11.2(b) one-per-year limit does not apply to an audit triggered by a confirmed Security Incident. The scope of such an audit is limited to the subject matter of the Incident.

---

12. International transfers

12.1 POPIA §72. Where Personal Information is transferred out of South Africa by askNiva or its Sub-processors, the transfer shall take place only on one of the legal bases in POPIA §72 (binding corporate rules substantially similar to POPIA, contractual provisions ensuring a similar level of protection, Data Subject consent, transfer necessity, or benefit-to-the-Data-Subject grounds).

12.2 GDPR Chapter V. Where the transfer falls within the scope of the GDPR (for example because the User is established in the EEA or the processing targets EEA Data Subjects), askNiva shall ensure that a valid transfer mechanism applies, including (as appropriate):

  • (a) the European Commission's Standard Contractual Clauses (Module 2 or Module 3 as relevant), incorporated by reference or signed as a schedule to this DPA;
  • (b) an adequacy decision of the European Commission;
  • (c) binding corporate rules; or
  • (d) another derogation permitted by Article 49 GDPR.

12.3 EU Standard Contractual Clauses (conditional incorporation).

  • (a) Where EU GDPR applies. Where you are established in the European Economic Area, or your processing under this DPA is subject to the GDPR by reason of Article 3(2) (the offering of goods or services to Data Subjects in the EEA, or the monitoring of the behaviour of such Data Subjects taking place within the EEA), the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021 (the "EU SCCs") are incorporated into this DPA by reference and apply to any transfer of Personal Information from you (as "data exporter") to askNiva (as "data importer") that is a transfer within the meaning of Article 44 GDPR. Module Two (controller to processor) applies where you act as controller, and Module Three (processor to sub-processor) applies where you act as processor on behalf of another controller. The Optional Docking clause (Clause 7) is included; Option 2 general authorisation of sub-processors in Clause 9 is selected (thirty (30) days' notice under §6.3); Option 1 in Clause 17 is selected with the law of the Republic of Ireland as governing law of the Clauses (this is the law of the Member State where the Clauses have effect, without prejudice to §15.1 governing law of this DPA generally); the competent supervisory authority in Clause 13 is the Irish Data Protection Commission (DPC) where the data exporter is not in the EEA; where the data exporter is in the EEA, the supervisory authority of the Member State of the exporter's establishment applies. Clause 18 court of choice is the Irish courts. Annex I (Parties; Description of transfer; Competent supervisory authority), Annex II (Technical and Organisational Measures), and Annex III (List of Sub-processors) to the EU SCCs are completed by reference to §§1.1, 3, 7.1 and Annexe 1, and 6.2 of this DPA respectively, as described in Schedule A below.
  • (b) Signature. The parties agree that the EU SCCs are deemed signed and incorporated by their electronic exchange of this DPA through the askNiva Account flow. Where a particular Sub-processor requires a separate back-to-back SCC set, askNiva executes those SCCs directly with the Sub-processor (the "onward transfer" limb under Clause 8.8 of the Module Two SCCs is implemented through the Module Three SCCs between askNiva and that Sub-processor).

12.3A UK IDTA / UK Addendum (conditional incorporation). Where you are established in the United Kingdom, or the processing under this DPA is subject to the UK GDPR by reason of its extraterritorial reach, the UK Addendum to the EU Standard Contractual Clauses published by the Information Commissioner's Office on 21 March 2022 (B.1.0, in force from 21 March 2022) is incorporated into this DPA by reference and applies to any restricted transfer within the meaning of the UK GDPR. Table 1 (Parties), Table 2 (selected EU SCCs), Table 3 (Appendix Information), and Table 4 (Ending the Addendum when the Addendum changes) are populated by reference to §§1.1, 3, 7.1 and Annexe 1, and 6.2 of this DPA, as described in Schedule A below. Table 4 selection: neither Party may end the Addendum when the Approved Addendum changes (as permitted by the Addendum). The UK Addendum is deemed signed by the exchange of this DPA through the Account.

12.3B Swiss FADP addendum (conditional incorporation). Where the Swiss Federal Act on Data Protection (FADP) applies to the processing under this DPA (including by reason of the Data Subject being in Switzerland or of the FADP's extraterritorial scope), the EU SCCs as incorporated under §12.3 apply with the following Swiss amendments (reflecting FDPIC guidance):

  • (a) references to the GDPR in the EU SCCs are read as including the FADP for Personal Information falling within the FADP's scope;
  • (b) the competent supervisory authority in Annex I.C is the Federal Data Protection and Information Commissioner (FDPIC);
  • (c) references to "Member State" and to "European Union" are read as including Switzerland for FADP-originating Personal Information, to avoid a conflict-of-laws restriction of Data Subject rights;
  • (d) the FADP applies to Personal Information of natural persons; to the extent the FADP (in any transitional provisions or as applied by the FDPIC) extends to Personal Information of legal persons, the EU SCCs apply to such information on the same terms; and
  • (e) the Swiss-US Data Privacy Framework applies only where the Sub-processor is US-established and DPF-certified; otherwise the EU SCCs with these Swiss amendments are the operative transfer instrument.

12.4 AI-Provider-tier data-residency variance. Data residency and transfer characteristics of the AI-Provider component of the processing vary by Provider and tier. In particular, free-tier Gemini API (Google AI Studio without billing) processes globally with no residency guarantee; Vertex AI Gemini permits regional selection by the customer; Anthropic, OpenAI, AWS Bedrock, and Azure OpenAI each have their own residency offerings and restrictions. You are responsible for selecting the AI-Provider tier and region consistent with your POPIA §72 and GDPR Chapter V obligations; askNiva does not independently warrant AI-Provider data residency (see ToS §6.8 and §9.7).

12.5 Sub-processor written-mandate execution.

  • (a) Pre-Effective-Date covenant. askNiva shall ensure that, at or before the Effective Date of this DPA, a written processing agreement meeting POPIA §21(1) (and, where applicable, GDPR Article 28(3)) is executed with each Sub-processor listed in §6.2. The Operator-Contract Register maintained under §6.5 records the execution date for each Sub-processor.
  • (b) Ongoing warranty. askNiva warrants that, as at the date of any User request under §11.1, each Sub-processor it uses to process Personal Information on the User's behalf operates under a currently-executed written processing agreement meeting POPIA §21(1) (and, where applicable, GDPR Article 28(3)). askNiva shall make the execution date and, on reasonable request, evidence of execution available under the confidentiality obligations of §5.
  • (c) Remediation. If a Sub-processor's written processing agreement lapses or is not executed when required by (a), askNiva shall (i) suspend that Sub-processor's processing of Personal Information on the User's behalf, (ii) notify the User without undue delay, and (iii) either re-execute the agreement or cease using that Sub-processor within a reasonable period.

---

13. Liability

13.1 Each party's liability under or in connection with this DPA is subject to the limitation of liability clause in §15 of the Terms (including the tiered cap in §15.2 and the carve-outs in §15.4). For the avoidance of doubt, no liability arising from breach of this DPA is excluded where the underlying liability cannot be excluded under POPIA, the CPA, or other Applicable Data Protection Law.

13.2 Nothing in this DPA limits or excludes a Data Subject's right to bring a claim directly against a Responsible Party or Operator under POPIA §99 or GDPR Article 82.

---

14. Data Protection Officer / Information Officer

14.1 askNiva's Information Officer for POPIA purposes is contactable at dpo@askniva.com. The Information Officer has been registered with the Information Regulator in accordance with POPIA §55 and the Information Regulator's registration directives.

14.2 Where GDPR applies and requires the appointment of a Data Protection Officer under Article 37, askNiva shall appoint one and publish the contact details.

---

15. General

15.1 Governing law. This DPA is governed by the law of the Republic of South Africa, consistent with §21 of the Terms.

15.2 Jurisdiction. §21 of the Terms governs.

15.3 Order of precedence. In a conflict between this DPA and the Terms or the AUP on any data-protection matter, this DPA prevails (see §23.2 of the Terms).

15.4 Variation. askNiva may amend this DPA on thirty (30) days' notice where the amendment is required by Applicable Data Protection Law or by a Sub-processor flow-down obligation. Other amendments require mutual agreement in writing.

15.5 Survival. §§5 (Confidentiality), 6 (Sub-processors, to the extent relevant to any post-termination processing), 8 (Data Subject requests, to the extent relevant to any Personal Information retained post-termination), 9 (Security incidents), 10 (Return and deletion), 11 (Audit), 12 (International transfers), and 13 (Liability) survive termination.

---

16. Contact

Mollo Innovations (Pty) Ltd (trading as "askNiva")

Companies and Intellectual Property Commission (CIPC) registration number: 2026/275132/07

Registered office: Regus Business Centre, 1st Floor, Block B, North Park, Black River Park, 2 Fir Street, Observatory, Cape Town, Western Cape, South Africa, 7925

Data Protection Officer / Information Officer (POPIA §55): dpo@askniva.com

Privacy / data-protection (POPIA): privacy@askniva.com

Legal notices: legal@askniva.com

---

Acknowledgement

By accepting the Agreement or using the Service, you acknowledge this DPA forms part of the Agreement where your processing of Personal Information through the Service engages askNiva as an Operator / processor, and you agree to be bound by it.

---

Schedule A — SCC / IDTA / FADP annex completion

The annexes required by the EU SCCs, the UK Addendum, and the Swiss amendments are completed as follows (operative only where the corresponding transfer mechanism applies):

| Annex | EU SCCs location | Completed by |

|---|---|---|

| Annex I.A — List of Parties | Module 2/3 | §1.1 of this DPA (data exporter = you; data importer = askNiva) |

| Annex I.B — Description of transfer | Module 2/3 | §3 of this DPA (subject matter; duration; nature; purpose; categories of PI; categories of Data Subjects) |

| Annex I.C — Competent supervisory authority | Module 2/3 | Irish Data Protection Commission (as representative Member State authority where data exporter is non-EEA; otherwise supervisory authority of exporter's Member State) — see §12.3(a) |

| Annex II — Technical and Organisational Measures | Module 2/3 | §7.1 and Annexe 1 to this DPA (TOM Annexe) |

| Annex III — List of Sub-processors (Module 2); Clause 9(a) authorisation (Module 3) | Module 2/3 | §6.2 of this DPA, read with §6.3 notice mechanism |

| UK Addendum Table 1 — Parties | n/a | §1.1 |

| UK Addendum Table 2 — Selected EU SCCs Version and Modules | n/a | Version dated 4 June 2021; Modules 2 and 3 as relevant per §12.3(a) |

| UK Addendum Table 3 — Appendix Information | n/a | §3, §7.1 + Annexe 1, §6.2 |

| UK Addendum Table 4 — Addendum updates | n/a | Neither party may end on Approved-Addendum change |

| FADP amendments | n/a | §12.3B(a)–(e) |

---

Annexe 1 — Technical and Organisational Measures (TOM)

The following describes askNiva's security measures at the date of this DPA. The measures are drafted as a standard-of-care schedule; the Information Officer confirms actual implementation before the Effective Date and records material exceptions (if any) in the Operator-Contract Register under §6.5. Where a control is subject to an external certification milestone, the target milestone is stated. The annexe is reviewed at least annually under §7.1.

Art. 32(1)(a) pseudonymisation. In the BYOK managed-hosting architecture, Customer Data is controlled by the User on the User's Instance, and askNiva cannot unilaterally pseudonymise Customer Data without altering the User's workload. askNiva therefore relies on encryption at rest (Row 1), encryption in transit (Row 2), and envelope encryption of credentials (Row 8) as the Art. 32(1)(a) / POPIA §19(1) confidentiality-preservation measures. Pseudonymisation is available to Users at the application tier on the User's Instance; this is a User-side Responsible Party / controller measure under GDPR Article 25, not an askNiva Operator / processor measure.

| # | Control area | POPIA §19 / GDPR Art. 32 element | Control at launch | Target certification / audit |

|---|---|---|---|---|

| 1 | Encryption at rest | §19(1) integrity / confidentiality | All Customer Data stored on Hetzner-backed Instance volumes is encrypted at rest using Hetzner-provided full-volume encryption with at least AES-256. AI-Provider API keys and other secrets are encrypted using envelope encryption (service master key + per-record data encryption key). Snapshots and backups inherit the underlying volume encryption. | ISO 27001 control A.8.24 alignment; SOC 2 CC6.1 |

| 2 | Encryption in transit | §19(1) confidentiality | TLS 1.2 or higher on all external endpoints (askNiva control plane, User-facing web and API, Instance management endpoints); modern cipher-suite policy excluding deprecated algorithms; HSTS on all User-facing web surfaces. | SOC 2 CC6.7 |

| 3 | Identity and access management — Users | §19(1) confidentiality; §19(2)(a)–(c) risk management | Google OAuth identity federation for User accounts (no askNiva-side password store); session binding; rate-limited login; suspicious-login alerting (see Privacy Policy §8.5 row (iv)). | SOC 2 CC6.1 / CC6.2 |

| 4 | Identity and access management — askNiva personnel | §19(1) confidentiality; §19(2)(b) safeguards | Role-based access control; multi-factor authentication on every administrative interface (control plane, cloud provider console, payment console, email / support); least-privilege grants; joiner-leaver procedure with 24-hour access-revocation SLO. | SOC 2 CC6.1; ISO 27001 A.5.15 |

| 5 | Network segmentation and firewalls | §19(2)(b) safeguards | Control plane on segregated network; Instances placed behind per-Instance firewalls; egress filtering where appropriate; no flat network exposure between Instances. | SOC 2 CC6.6 |

| 6 | Logging and audit | §19(1) integrity; §21(2) compromise-detection | Centralised access, authentication, administrative-action, and abuse-signal logging; tamper-evident storage; minimum 12-month security-log retention (Privacy Policy §11.2(f)); alerting on anomalous access patterns. | SOC 2 CC7.2; ISO 27001 A.8.15 / A.8.16 |

| 7 | Backup and disaster recovery | §19(1) availability | Automated daily snapshots of Instance volumes on Hetzner's snapshot cycle; backup encryption as per control 1; documented restore procedure tested at least quarterly; offsite / cross-region disaster-recovery for control plane. | SOC 2 A1.2 / A1.3 |

| 8 | Key management | §19(1) confidentiality | Service master keys held in a dedicated key-management service; separation of duties between encryption-key and data access; documented key rotation (at least annually for master keys; per-access for short-lived data keys); no unencrypted long-term retention of AI-Provider credentials in logs, support tooling, or ticketing. | SOC 2 CC6.1; ISO 27001 A.8.24 |

| 9 | Vulnerability and patch management | §19(2)(d) continual update | Monthly vulnerability scan cadence on askNiva-managed components; emergency patch SLO of 72 hours for critical vulnerabilities on internet-exposed components; 14-day patch-duty flow-down applied to User-configured Instance components (ToS §4.3). | SOC 2 CC7.1 |

| 10 | Incident response | §19(2)(d); §21(2); §22 | Documented incident-response playbook with roles, escalation paths, and internal triage SLO of 1 hour for critical signals; 24-hour notification SLO to Users from reasonable awareness (DPA §9.1); 72-hour compromise notification to the Information Regulator and affected Data Subjects under POPIA §22. | SOC 2 CC7.3 / CC7.4 |

| 11 | Personnel confidentiality | POPIA §20(b); GDPR Art. 29 / Art. 32(4) | Written confidentiality undertakings from all personnel on appointment, surviving termination (§5.1); role-based confidentiality training at onboarding and annually. | SOC 2 CC1.4 |

| 12 | Supplier assessment | §19(2)(b); §21(1) | Pre-engagement security assessment of new Sub-processors; reliance on third-party certifications where available (Hetzner TÜV Rheinland; Paystack PCI DSS Level 1; Google ISO 27001 / SOC 2); DPA execution before any production processing (tied to launch-readiness checklist). | ISO 27001 A.5.19–A.5.22 |

| 13 | Secure software development | §19(2)(b) safeguards | Code review of material changes; automated dependency-vulnerability checks; separation of development / staging / production environments; change-management log. | SOC 2 CC8.1 |

| 14 | Physical security | §19(1) integrity / confidentiality | Reliance on Hetzner's ISO 27001 / TÜV Rheinland-audited data-centre controls (Nuremberg, Falkenstein, Helsinki by default). askNiva does not operate its own physical infrastructure. | Hetzner attestation reliance |

| 15 | Effectiveness review | §19(2)(c) verification | Annual internal review of each control row; readout to the Information Officer; remediation plan for any control rated "deficient". | ISO 27001 A.5.35 |

External certifications. askNiva is pre-certification at launch. The target milestones are (a) SOC 2 Type I within twelve (12) months of launch, (b) SOC 2 Type II within twenty-four (24) months, and (c) ISO 27001 within thirty-six (36) months, subject to business scale and auditor availability. The target milestones are aspirational and not a contractual obligation to achieve certification by a specific date; §11 audit rights apply regardless of certification status.

Change management. Updates to this annexe follow §15.4 — non-material changes may be made at any time; material changes (including any downgrade of a control or any addition of a new risk surface) are notified to Users under §15.4 and Privacy Policy §22.