Data processing agreement

Last updated: 2026-04-25 · Public summary · pre-launch

A public summary of the Data Processing Agreement attached to a Jubi customer engagement. The DPA itself is a separate document, signed with the master service agreement. What's below is the shape of it; the signed version is what binds.

1. Roles and definitions

• For customer data processed by Jubi on the customer's behalf, the customer is the data controller (PDPA: data user) and Jubi is the data processor.
• For prospect data and customer account-contact data, Jubi is the data controller. See the privacy notice.
• "Customer data" means data the customer or its authorised users submit to, or that Jubi accesses on the customer's behalf via, the platform — including queries, query results, and tenant audit logs.
• "Personal data", "data subject", "processing", "controller", and "processor" have the meanings given in the GDPR; "data user" and "personal data" have the meanings in the PDPA, as applicable.

2. Subject matter, duration, and purpose

Provision of the Jubi platform — Studio surfaces, Guardian gating, Atlas semantic layer — to the customer's authorised users for the term of the engagement. Processing is for the purpose of delivering the platform, providing support, securing the service, and meeting legal obligations.

3. Customer instructions

Jubi processes customer data only on the customer's documented instructions, except where required to do so by law. The customer's instructions include the engagement, the configuration of the customer's tenant, and any subsequent written instructions to Jubi privacy@jubi.my. Jubi will inform the customer if it considers an instruction to violate applicable data-protection law, before complying or declining.

4. Subprocessors

• The customer authorises Jubi to engage subprocessors to process customer data, subject to the conditions in this section.
• The current list of subprocessors is published at subprocessors.html (Annex C).
• Jubi will give the customer at least 30 days' prior written notice of any new subprocessor with access to customer data. The customer may object on reasonable data-protection grounds within the notice period; if the parties cannot resolve the objection, the customer may terminate the affected services with a pro-rated refund of any prepaid fees attributable to the unused remainder.
• Jubi imposes data-protection obligations on its subprocessors that are no less protective than those in this DPA, and remains liable to the customer for the acts and omissions of its subprocessors as if they were its own.

5. Confidentiality

Jubi ensures that personnel authorised to process customer data are bound by appropriate confidentiality obligations and have completed security awareness training relevant to their role.

6. Security measures

Jubi implements appropriate technical and organisational measures to protect customer data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure, or access, taking into account the state of the art, the costs of implementation, the nature, scope, context, and purposes of processing, and the risk of varying likelihood and severity for the rights and freedoms of natural persons. The current measures are described in Annex B (TOMs).

7. International transfers

Where customer data leaves the customer's home jurisdiction (for example, when AI inference routes to a provider region outside that jurisdiction, or when subprocessors operate in another country):

• The transfer relies on a permitted mechanism — Standard Contractual Clauses (where the customer is in the EU/EEA), the UK addendum (where the customer is in the UK), or an applicable adequacy decision.
• Jubi has assessed the transfer destination at the time of integration and will reassess if material legal or factual changes occur.
• The customer is responsible for assessing whether its own use case requires further transfer-impact analysis on its side.

8. Data subject requests

Jubi notifies the customer without undue delay of any request received directly from a data subject seeking to exercise their rights in respect of customer data, and refers the data subject to the customer (the controller) unless the customer instructs otherwise. Jubi assists the customer, taking into account the nature of the processing, by appropriate technical and organisational measures, insofar as possible, in fulfilling the customer's obligation to respond to data subject requests.

9. Personal data breach notification

• Jubi notifies the customer's designated security contact without undue delay after becoming aware of a personal data breach affecting customer data. The notification provides the information then known to Jubi and supplements as further information becomes available.
• "Becoming aware" means Jubi has confirmed that a personal data breach has occurred. Investigation of suspected events does not by itself trigger notification.
• The customer is responsible for keeping the designated security contact current. Jubi may treat communications to the most recently provided contact as effective notice.
• The notification obligation is subject to lawful instructions from competent authorities directing Jubi to delay notification.
• Jubi cooperates with the customer in good faith to investigate and remediate; the parties' respective rights, obligations, and liability for the breach are governed by the master agreement.

10. Term and termination

This DPA runs for the duration of the master agreement and survives to the extent and for so long as Jubi continues to process customer data. On termination, Jubi returns or deletes customer data in accordance with the customer's written instruction, subject to legal retention obligations and to backups ageing out of retention in the ordinary course.

11. Audit rights

The customer (or its independent third-party auditor bound by appropriate confidentiality obligations) may audit Jubi's compliance with this DPA, subject to:

• Reasonable advance written notice (not less than 30 days, unless the customer reasonably believes a breach is in progress);
• Frequency limited to once per twelve-month period, unless required more frequently by a regulator or by applicable law, or following a confirmed personal data breach;
• Scope limited to information reasonably necessary to verify Jubi's compliance with this DPA, conducted in a manner that minimises disruption to Jubi's operations and to other customers;
• The auditor signing a non-disclosure agreement reasonably acceptable to Jubi;
• The customer bearing its own costs and the auditor's costs;
• No access to other customers' data, to Jubi's pricing or financial information, or to Jubi-confidential information unrelated to compliance with this DPA.

To the extent available, Jubi may satisfy audit requests by providing recent third-party audit reports (e.g. SOC 2 Type II), penetration test summaries, or completed industry-standard questionnaires (CAIQ, SIG-Lite) under NDA in lieu of an on-site audit.

12. Liability

Each party's liability arising out of or in connection with this DPA is subject to the limitation of liability set out in the master agreement. Nothing in this DPA is intended to expand the parties' liability beyond what the master agreement provides.

13. Order of precedence

If there is a conflict between this DPA, the master agreement, and any Standard Contractual Clauses incorporated by reference, the order of precedence is: (i) the Standard Contractual Clauses, (ii) this DPA, (iii) the master agreement.

14. Changes

Jubi may update this DPA only to the extent necessary to reflect changes in applicable law, in subprocessor arrangements, or to clarify provisions. Material changes adverse to the customer require the customer's consent, not to be unreasonably withheld.

Annex A · Description of processing

Annex B · Technical and organisational measures (TOMs)

Jubi maintains technical and organisational measures consistent with the state of the art and the risk profile of the processing. The measures listed below are descriptive of Jubi's current implementation and may be enhanced or substituted with measures of equivalent or greater protection. The measures must, in aggregate, meet the standard set out in clause 6.

B.1 Pseudonymisation and encryption

• Encryption in transit: TLS 1.2 or higher for customer-facing traffic, with HSTS and modern cipher suites.
• Encryption at rest: AES-256 for persisted customer data, audit logs, and backups.
• Tenant-scoped key derivation. Customer-managed encryption keys are available on the roadmap for VPC-isolated and on-prem deployments.

B.2 Confidentiality, integrity, availability, and resilience

• Logical tenant isolation across storage and inference layers; physical isolation available in VPC-isolated and on-prem deployments.
• Identity-bound requests: every request authenticated via the customer's IdP and authorised against Atlas/Guardian policy.
• End-to-end audit log of AI requests, policy decisions, data access, and responses; replayable and exportable to a customer-side SIEM.
• Backups for stateful services on a regular cadence; backup encryption keys separated from service-account credentials; periodic restore testing.

B.3 Restoration of availability and access

• Recovery objectives are documented in the engagement-specific SLA.
• Documented runbooks for common incident classes; periodic tabletop exercises.
• Cross-region failover is on the roadmap.

B.4 Process for testing, assessing, and evaluating effectiveness

• Static analysis on pull requests with severity-driven gating.
• Software-composition analysis with CVE alerting; SBOM generated per release.
• Periodic third-party penetration testing of the application surface and Guardian's policy enforcement.
• Periodic AI-specific red teaming covering prompt injection, jailbreaks, and Atlas-bypass attempts.
• Review of TOMs at least annually and on material change.

B.5 Access control

• SSO via the customer's IdP for customer users; MFA delegated to the IdP.
• Role-based access for Jubi personnel; least-privilege; periodic access review.
• Customer-tenant access for Jubi staff requires a time-bound, customer-approved JIT grant; logged and surfaced in the customer audit trail (in build).
• Hardware-backed MFA on managed devices for production access.

B.6 Personnel

• Pre-employment background checks calibrated to local law.
• Confidentiality and IP-assignment agreements before access to non-public information.
• Onboarding security training; periodic refresh; specialised training for engineering and incident-response roles.
• Prompt revocation of access on offboarding.

B.7 Logging and monitoring

• Customer-facing audit log for AI requests and policy decisions.
• Platform logs (auth, deploy, infrastructure changes) shipped to a centralised log store with anomaly rules; retained for a period documented in the engagement.
• Per-tenant rate limits and behavioural baselines for unusual query volumes.

B.8 Endpoint and network

• Employee endpoints under MDM with disk encryption, screen-lock, and EDR.
• CDN/WAF in front of public ingress.
• Application services run in private subnets; no public database endpoints.

B.9 Vendor management

• Documented security review of vendors with access to customer data.
• DPA in place with each subprocessor; periodic review.

B.10 Incident response

• Documented severity matrix and escalation procedure.
• Customer notification without undue delay for confirmed personal data breaches affecting customer data.
• Blameless post-mortems for severity-1 incidents; sanitised findings shared with affected customers.

B.11 Data minimisation and segregation

• Inference contexts minimised to the data needed to answer the user's question.
• Atlas-defined PII classes filter prompt construction.
• Cross-tenant data access at the model layer is structurally prevented.

Annex C · Subprocessors

The current list of subprocessors is published at subprocessors.html and is incorporated into this DPA by reference. Material changes are notified to customer admins at least 30 days before they take effect, in accordance with clause 4.

Annex D · Standard Contractual Clauses

Where customer data is transferred from the EU/EEA to a country not subject to an adequacy decision, the parties incorporate by reference the Standard Contractual Clauses approved by the European Commission under Implementing Decision (EU) 2021/914, in the controller-to-processor module (Module 2) and, where applicable, processor-to-subprocessor module (Module 3). Where customer data is transferred from the UK, the parties incorporate the UK International Data Transfer Addendum issued by the Information Commissioner.

The role-specific completions, optional clauses, and docking-clause selections required by the SCCs and the UK Addendum are completed in the executed DPA. Where the SCCs require a docking clause or specify a supervisory authority, the executed DPA records the parties' selections.

Privacy: privacy@jubi.my · Security: security@jubi.my · Subprocessors: public list