Data Processing Agreement

The Customer is the controller of the Customer Personal Data (a "Data Fiduciary" under India's Digital Personal Data Protection Act, 2023). Magynta is the processor (a "Data Processor"), processing it only for the Customer. Where the Customer is itself a processor for another controller, Magynta is its sub-processor and the Customer passes on the instructions of that controller.

• "Customer Personal Data": the personal data described in Annex 1 that Magynta processes for the Customer.
• "Data Protection Law": every law that applies to the processing, including, as relevant, India's Digital Personal Data Protection Act, 2023 and its Rules ("DPDPA"), the EU General Data Protection Regulation ("GDPR"), the UK GDPR, and the GCC laws listed in section 15.
• "Data Subject" (or "Data Principal"): the person the data is about.
• "Personal Data Breach": a breach of security leading to accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.
• "Sub-processor": a third party Magynta engages that processes Customer Personal Data.

Subject matter: detecting sensitive data in what the Customer's End Users type, paste or attach on AI assistant sites, and reporting those detections to the Customer's administrators.

Nature: the Feldr browser extension checks content on the End User's device; that content is not sent to Magynta. Magynta collects, stores, organises, displays, exports and deletes the incident records, account data and logs listed in Annex 1, and sends the emails the Customer's use of the Service requires.

Purpose: to provide, secure and support the Service under the Agreement and the Customer's instructions; no other purpose.

Duration: for the term of the Agreement and until the data is deleted under section 13.

Data subjects: the Customer's End Users (employees, contractors and others it invites) and its administrators.

Categories of personal data: listed in Annex 1. In short: identity and account data (work email, name, department, role), incident records (rule label, masked preview, file name, AI site, browser, outcome, reason given, time), administrator security data (sign-in, multi-factor and audit-log records), and technical data about the extension.

Not processed: the text of prompts, the contents of files and images, and the full value of anything detected never leave the End User's device. The masked preview contains no character of a detected value.

Special categories: Magynta does not intend to receive special-category or sensitive personal data. A rule label (for example "Health record number") says what kind of data was found, not the data itself. A file name or a reason typed by an End User could, however, contain anything the End User chose to write; the Customer should tell its End Users not to put sensitive data in them.

Magynta processes Customer Personal Data only on the Customer's documented instructions. The Agreement, this DPA and the Customer's configuration of the Service (rules, frameworks, retention, alerts and integrations it switches on) are the Customer's complete instructions. Further instructions must be in writing and agreed if they change the scope or cost.

Magynta will tell the Customer promptly if, in its opinion, an instruction infringes Data Protection Law, and may suspend that processing until the instruction is confirmed or changed.

If a law requires Magynta to process Customer Personal Data otherwise, Magynta will tell the Customer before processing, unless that law forbids it.

The Customer is responsible for the lawfulness of its instructions, for having a lawful basis (or valid consent where the DPDPA requires it) for the processing, and for giving its End Users the notices its law requires.

Magynta ensures that everyone it authorises to process Customer Personal Data is bound by confidentiality, receives appropriate training, and has access only to what their role needs. Access to production systems is limited to named Magynta staff. [OWNER TO CONFIRM: the staff confidentiality agreements in place, and the list of roles with production access]

Magynta implements and maintains the technical and organisational measures in Annex 2, appropriate to the risk. Magynta may update them as long as the overall level of protection does not decrease.

The Customer gives general authorisation for Magynta to use the Sub-processors in Annex 3.

Magynta will tell the Customer of any intended addition or replacement of a Sub-processor at least [OWNER TO CONFIRM: notice period, for example 30 days] in advance, by email to the Customer's administrators [OWNER TO CONFIRM: and/or on a published sub-processor page]. The Customer may object on reasonable data-protection grounds within that period. The parties will discuss the objection in good faith; if it cannot be resolved, the Customer may end the affected part of the Service and receive a refund of prepaid fees for the remaining period.

Magynta imposes data-protection obligations on each Sub-processor no less protective than this DPA, and remains responsible to the Customer for its Sub-processors' performance.

Where data is stored: the Feldr API, dashboards and database run in Microsoft Azure (Azure Kubernetes Service), in the region stated in Annex 3. The database is MongoDB, self-hosted inside that cluster; no separate database provider holds the data. Emails are sent through Amazon SES in the ap-south-1 (Mumbai, India) region. Detection itself runs on the End User's device.

[OWNER TO CONFIRM: the production region. The deployment guide names Azure Central India; a GCC region (Azure UAE North or Qatar Central) is under consideration for GCC customers (go-live 91.7)]

Dedicated hosting: on the Enterprise plan the Service can be provided as a dedicated deployment in a region or country agreed in the Order Form, in which case database, backups and logs stay in that deployment. Email delivery may still use a different region unless the Order Form provides otherwise.

Where Customer Personal Data is transferred out of a country whose law restricts transfers, Magynta will transfer it only under a mechanism that law accepts:

• EU/EEA (GDPR): the Standard Contractual Clauses of Commission Implementing Decision (EU) 2021/914, Module 2 (controller to processor) or Module 3 (processor to processor), incorporated by reference. [OWNER TO CONFIRM: SCC options: docking clause, clause 9 option (general authorisation), clause 11 independent redress, clause 17 governing law (an EU member state) and clause 18 forum; and a transfer impact assessment for India]
• United Kingdom: the International Data Transfer Addendum to the EU SCCs issued by the Information Commissioner, or the International Data Transfer Agreement. [OWNER TO CONFIRM: IDTA or Addendum, and the Addendum's table entries]
• Saudi Arabia (PDPL): the Standard Contractual Clauses issued by SDAIA under the Regulation on Personal Data Transfer outside the Kingdom, and a transfer risk assessment where that Regulation requires one. [OWNER TO CONFIRM: which SDAIA clauses apply and who performs the risk assessment]
• United Arab Emirates (PDPL) and the DIFC and ADGM free zones: transfer to a country with adequate protection, or under contractual safeguards meeting the applicable law (for DIFC and ADGM, their standard contractual clauses). [OWNER TO CONFIRM: the transfer basis for UAE customers]
• Qatar, Bahrain, Oman and Kuwait: the contractual safeguards, approvals or permits the applicable law requires. [OWNER TO CONFIRM: transfer basis per country; Oman requires a permit for some sensitive data]
• India (DPDPA): transfers are allowed except to countries the Central Government restricts by notification; Magynta will not transfer Customer Personal Data to a restricted country.

Taking into account the nature of the processing, Magynta assists the Customer by appropriate technical and organisational measures to respond to requests from Data Subjects to exercise their rights (access, correction, erasure, restriction, portability, objection, grievance redressal and nomination, as their law provides).

Administrators can find and export a person's incident records and remove the person in the dashboard. Where a request cannot be completed in the dashboard (for example erasing the incident records of a removed person, which the dashboard does not do today), Magynta will do it on the Customer's written request within [OWNER TO CONFIRM: number of days].

If Magynta receives a request directly, it will pass it to the Customer without undue delay and will not respond itself except to confirm that it has passed it on, unless the Customer instructs otherwise.

Magynta provides reasonable information and assistance for the Customer's data protection impact assessments and any prior consultation with a regulator, including the descriptions in this DPA and its annexes. [OWNER TO CONFIRM: whether assistance beyond the provided documentation is chargeable]

Magynta will notify the Customer without undue delay, and in any case within [OWNER TO CONFIRM: number of hours, for example 48 hours; the Customer itself may have 72 hours under GDPR and the GCC laws, and must notify the Data Protection Board of India under the DPDPA Rules] after becoming aware of a Personal Data Breach affecting Customer Personal Data.

The notice goes to the Customer's administrators and its designated security contact, and contains, as far as known: the nature of the breach, the categories and approximate number of Data Subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Information not yet known will be given in phases as it becomes available.

Magynta will take reasonable steps to contain and investigate the breach, and cooperate with the Customer. The Customer decides whether to notify regulators and Data Subjects; Magynta will not do so on the Customer's behalf unless the law requires it or the Customer instructs it.

A notification is not an admission of fault or liability.

Incident history is kept for the period of the Customer's plan: Team: 90 days; Business: 1 year; Enterprise: the period in the contract. An administrator can choose to keep it longer, but never shorter than the plan period. Older incidents are deleted automatically. [OWNER TO CONFIRM: automatic deletion is built but switched off until the owner enables it at go-live; confirm before this DPA takes effect]

The administrator audit log is kept for the term of the Agreement. One-time sign-in codes, password-reset tokens and multi-factor challenges expire and are deleted automatically.

Database backups are kept for 14 days, so deleted data disappears from backups within 14 days of its deletion from the database. [OWNER TO CONFIRM: whether an encrypted copy is kept outside the cluster, where, and for how long]

[OWNER TO CONFIRM: how long server logs are kept]

During the Agreement, administrators can export incidents (CSV and PDF reports) and, on Business and Enterprise, the audit log.

When the Agreement ends, the Customer may ask for an export of its Customer Personal Data within [OWNER TO CONFIRM: export window, for example 30 days]. After that period, Magynta deletes the Customer Personal Data from its live systems within [OWNER TO CONFIRM: number of days], including the incident records of every End User, and it then ages out of backups within 14 days.

On request Magynta confirms the deletion in writing. Magynta may keep data only where the law requires it, and then keeps it confidential and processes it only for that purpose.

Copies on End Users' devices (settings and incident records waiting to be sent) are removed when the extension is removed; the Customer is responsible for removing the extension from its managed browsers.

Magynta makes available the information needed to demonstrate compliance with this DPA: this DPA and its annexes, its security documentation, answers to reasonable security questionnaires, and a summary of its most recent penetration test. [OWNER TO CONFIRM: which reports are shared (for example a SOC 2 report or ISO 27001 certificate, if and when obtained), and under what confidentiality terms]

If that information is not enough, or a regulator requires it, the Customer (or an independent auditor bound by confidentiality and not a competitor of Magynta) may audit Magynta's compliance, with at least [OWNER TO CONFIRM: notice period, for example 30 days] notice, during business hours, no more than once a year except after a Personal Data Breach or at a regulator's request, and at the Customer's cost. [OWNER TO CONFIRM: whether remote audits only, and whether Magynta charges for its time]

The Service is designed to help customers meet the following frameworks; this section adds what each requires of this DPA. It does not certify compliance with any law.

Each party's liability under this DPA is subject to the limitations in the Agreement. [OWNER TO CONFIRM: whether data-protection breaches have a separate, higher cap]

This DPA ends when Magynta no longer processes Customer Personal Data. It is governed by the law that governs the Agreement, except where the transfer clauses in section 8 require another law.

Data protection contact: Magynta Technologies Private Limited, B2 Golden Orchid, Plot No. 136, Sector 11, PCNTDA, Chikhali Pradhikaran, Pune - 411019, India; dpo@magynta.com. [OWNER TO CONFIRM: name of the data protection officer or grievance officer, if one is appointed]

• Identity and account

  What it contains

  Work email; name and department where the Customer provides them; role (End User, administrator); for single sign-on, the identity provider's name, email and group membership (never the password).

  Source

  The Customer's administrators, invitations, SCIM provisioning, single sign-on, the End User's sign-in by emailed code, and on Chrome and Edge the browser profile's email.

• Incident records

  What it contains

  For each detection: the rule's label (for example "Aadhaar Number"), detector type and rule id; the masked shape of the value (digits shown as 9, letters as a or A) and a masked preview with no character of the value; the file name and where in the file the finding was, if a file was involved; the AI site's host name; the browser; severity; the outcome (blocked, warned, sent anyway, redacted, monitored, allowed); the reason the End User picked or typed for sending anyway (up to 200 characters); the End User's email or an anonymous device key; date and time; model score and numeric features.

  Source

  The extension, when it detects sensitive data.

• End User requests

  What it contains

  A request to pause or remove Feldr and the reason typed; a notice that file-upload blocking was switched off; a notice that the extension was removed.

  Source

  The extension.

• Technical

  What it contains

  Extension version, how it was installed (for example by the organisation's policy), when it was last active.

  Source

  The extension.

• Administrator security

  What it contains

  Sign-in records, failed attempts, multi-factor enrolment (the secret stored encrypted), password hash, and an audit log of administrator actions with the administrator's email.

  Source

  The dashboard.

• Email content

  What it contains

  Recipient address and the content of sign-in codes, invitations, password resets, alerts and scheduled reports.

  Source

  Generated by the Service.

Frequency: continuous while the Service is in use.

Not processed: prompt text, file and image contents, full detected values, passwords of End Users, browsing history, activity on sites other than the supported AI sites.

• Data minimisation

  Measure

  Detection runs on the End User's device; the detection models are packaged in the extension and nothing is downloaded at run time. Prompt text, file contents and detected values are not sent. The extension may contact only the Feldr API (enforced by its content security policy).

• Encryption in transit

  Measure

  TLS on every connection to the API and dashboards (certificates from Let's Encrypt via cert-manager; HTTP redirected to HTTPS). [OWNER TO CONFIRM: TLS between the API and MongoDB inside the cluster, which is prepared but not enabled by default]

• Encryption at rest

  Measure

  Multi-factor secrets, webhook addresses and single sign-on client secrets are encrypted by the application with keys held as cluster secrets. Passwords are stored as bcrypt hashes (cost 12); password-reset tokens are stored only as hashes. [OWNER TO CONFIRM: encryption of the database and backup disks (Azure managed-disk encryption)]

• Access control

  Measure

  Every organisation's data is separated by its tenant identifier on every query. Administrators have role-based permissions. Multi-factor authentication is required for every administrator and super administrator. Single sign-on and SCIM are available. Sign-in and multi-factor attempts are throttled after repeated failures, per account and per network address.

• Extension sign-in

  Measure

  Each device holds its own token, issued after an emailed one-time code or single sign-on; incident reads and real-time updates require it.

• Logging and audit

  Measure

  An append-only audit log of administrator actions (exportable on Business and Enterprise); service logs without prompt content.

• Availability and backups

  Measure

  Nightly database backups kept 14 days, plus a backup before each deployment; documented restore and disaster-recovery runbook. If the API is unreachable, the extension keeps protecting with the last rules and queues incident records. [OWNER TO CONFIRM: off-cluster backup copy and restore-drill frequency]

• Vulnerability management

  Measure

  Dependency audits before release; security review of changes; a penetration test before go-live by the internal team. [OWNER TO CONFIRM: frequency of penetration tests and whether an external tester is used]

• Incident response

  Measure

  A documented service-incident and personal-data-breach procedure with severity levels, an on-call rota and client notification templates.

• People

  Measure

  [OWNER TO CONFIRM: staff confidentiality agreements, security training, background checks, and the joiner-mover-leaver process for production access]

• Microsoft Corporation (Microsoft Azure: Kubernetes Service, managed disks, container registry)

  Purpose

  Hosting of the Feldr API, dashboards and the self-hosted MongoDB database and backups

  Data

  All Customer Personal Data stored by the Service (Annex 1)

  Location

  [OWNER TO CONFIRM: production region; the deployment guide names Azure Central India, India]

• Amazon Web Services (Amazon Simple Email Service)

  Purpose

  Sending sign-in codes, invitations, password resets, alerts and reports

  Data

  Recipient email addresses and email content

  Location

  ap-south-1, Mumbai, India

[OWNER TO CONFIRM: that no other provider (for example an error-tracking, log-storage, support-desk or off-cluster backup service) processes Customer Personal Data; the repository shows none]

Not sub-processors: services the Customer chooses and connects act for the Customer, not for Magynta: its Microsoft or Google single sign-on, SCIM provider, Slack, Microsoft Teams and webhook or SIEM destinations. Let's Encrypt issues TLS certificates and receives only domain names. MongoDB is run by Magynta itself; no MongoDB company has access to the data.