How we process personal data for you.

This agreement is between you, the organisation that holds a DataGrine account (the customer), and DataGrine, Chennai, India (DataGrine, “we”). It forms part of our terms of service and applies whenever you use the DataGrine application to move helpdesk records that contain personal data. You accept it by using the application; there is nothing separate to sign, and a countersigned copy is available on request.

For the records you migrate, you are the controller and we are your processor. You decide what moves, from where, to where and how it is mapped; we carry that out and nothing else. For the data we hold about you as a customer - your team’s names and emails, your organisation, your plan and billing - we are the controller, and our privacy policy covers that, not this agreement.

Where we run a migration for you as a managed service, the same platform, the same controls and this same agreement apply. The only difference is who is at the keyboard.

The processing is a migration: copying companies, contacts, tickets or conversations (with their messages and attachments) and knowledge-base articles from one helpdesk platform to another, and holding a working copy of those records while the migration is checked.

It lasts for the lifecycle of each migration in the application. A migration is active for 7 days after its first completed full run. We email you 2 days before it is archived - hidden, restorable, data kept - and 30 days after archive it is purged. You can delete a migration at any point before that, and your organisation’s owner can delete the whole organisation once no run is in progress; this agreement ends for that data when it is gone.

We read records from your source platform over its official API using credentials you provide, transform them to the shape your target platform accepts using the field mappings you set, and write them to your target platform. We keep the pulled records, the transformed payloads and the target’s responses so that the result can be reconciled against the source, a failed record can be retried, and a run can be rolled back. That is the whole purpose. We do not use the records for anything else, do not sell or share them, and do not train any model on them.

The data subjects are whoever appears in your helpdesk: the people who raised or were copied on tickets, your agents and teammates, and anyone named in a ticket, a note, an attachment or an article. The categories of personal data are those records carry, and the detail is in Annex 1.

We do not ask for special-category data and the application has no field for it. If your end users have put health, financial or similar information into a ticket, it moves with the ticket, held to the same controls as everything else. It is your decision as controller whether such records are in scope, and the application’s scope filters let you narrow which records move.

The configuration you set in the application is your documented instruction. The platforms you connect, the objects you select, the filters you apply, the field and value mappings, the run you start (demo, full or delta), and any rollback you order are the instructions we act on, and the application records them against the migration. On a managed engagement we confirm each instruction in writing before acting on it.

We process personal data only on those instructions. If the law we are subject to requires us to do otherwise, we tell you before we do, unless that law forbids telling you. If an instruction would, in our view, break data protection law, we tell you that too and wait.

Everyone who works for us and could see customer data is bound to confidentiality in writing, and is told what this agreement requires of them.

In practice, our staff have no standing access to your migrations. To look at one, an engineer needs a support-access grant that you give in the application, per migration, for a fixed number of hours, and can revoke at any time. Every use of that access, and every refused attempt, is written to the audit log. Access ends by itself when the migration is archived.

We apply the technical and organisational measures in Annex 2, chosen for the risk of moving customer service records between platforms. Annex 2 also says plainly what we do not yet do. We may improve the measures over time; we will not lower the protection they give during the term of a migration without telling you first.

You authorise us to use the sub-processors listed in Annex 3, for the purposes given there. Each is bound by a written contract that imposes data protection obligations no weaker than this agreement, and we remain responsible to you for what they do.

Before a new sub-processor handles customer data, or an existing one takes on a new purpose, we email your organisation’s owner at least 14 days in advance. If you object on reasonable data protection grounds within that time, we will try to resolve it with you; if we cannot, you may delete the affected migrations and end this agreement for them, and we refund any fee paid for work that was not delivered as a result.

Your own source and target platforms are not our sub-processors. They act on your account, under your contract with them, and we send them only what you have instructed us to move.

If a data subject contacts us about data we process for you, we pass the request to you without responding to it ourselves, and we help you answer it: the application lets you find and inspect the records concerned and roll back what was written to the target, and where that is not enough we act on your written request. We help you with a data protection impact assessment or a consultation with a supervisory authority in the same way, to the extent it concerns our processing.

If we become aware of a personal data breach affecting your data, we notify the owner of your organisation without undue delay and in any case within 72 hours, with what we know at that point - what happened, which migrations and record types are affected, what we have done and what we recommend - and we keep you updated as we learn more. We do not tell anyone else about a breach of your data before you do, unless the law requires it.

You do not need to ask for your data back at the end: the migrated records are already in your target platform, and the source is untouched. What we hold is a working copy, and it is deleted on the lifecycle above or sooner when you delete the migration or the organisation.

A purge deletes every pulled, transformed and target record copy, the before-and-after record images in the rollback ledger, the request and response logs of every API call made for the migration, and the stored platform credentials. Disconnecting a platform blanks its credentials immediately, whatever the lifecycle says. API request logs are also deleted 30 days after they are written, migration or no migration.

What survives a purge, and why: the migration’s name, dates and counts; your field mappings; the map of source record ids to target record ids; and the audit rows. None of these contain record content. They are kept so that a later delta run can tell what has already moved, so a rollback can be accounted for, and so we can show what was done and by whom. They go when you delete the migration or the organisation.

On a managed engagement we delete the migration at handover, unless you ask us to keep it for the reconciliation window, in which case it follows the lifecycle above. Deleting our copy never touches what has been written into your target platform; removing that is a rollback, which you order.

We give you the information you need to show that this agreement is being met. In the first place that is written: answers to your security questionnaire, this agreement and its annexes, and a description of the controls behind any item in Annex 2 that you ask about, within a reasonable time and at no charge.

Where written answers are not enough, you or an independent auditor you appoint may audit our processing once in any twelve months, on at least thirty days’ notice, at your cost, during working hours, in a way that does not expose another customer’s data. We may also ask you to cover the cost of an audit that goes beyond a day of our time. Audit findings are confidential to the two of us.

We are based in Chennai, India, and that is where our engineers work from. Your data is hosted with the infrastructure provider in Annex 3, in the European Union or the United States; we confirm which on request. So if you are in the EEA or the UK, some processing takes place outside it - in India when one of our engineers uses a support-access grant you have given, and in the United States if that is where your organisation is hosted.

We do not rely on an adequacy decision for India. Where the GDPR or the UK GDPR applies to you, the European Commission’s standard contractual clauses (controller-to-processor module) are incorporated into this agreement, with the UK International Data Transfer Addendum where UK law applies, and Annex 1, Annex 2 and Annex 3 of this agreement serve as their annexes. Each sub-processor in Annex 3 processes under its own data processing terms, which include standard contractual clauses where a transfer needs them.

Liability under this agreement is subject to the limits and exclusions in the Terms, and the two are read together as one cap, not two. Nothing here limits a liability that data protection law says cannot be limited.

If this agreement and the Terms disagree about personal data, this agreement wins. If this agreement and the standard contractual clauses disagree, the clauses win. A countersigned copy of this page is this agreement, not a different one; a different data processing agreement that we have signed with you wins over this page, for the migrations it covers. This agreement is governed by the law of India, and the courts of Chennai, Tamil Nadu, India hear any dispute under it, the same as the Terms.

You accept this agreement by using the DataGrine application to process personal data: our terms of service incorporate it, and it applies from the first migration you create, with no separate signature needed. If your privacy team wants a countersigned copy, email support@datagrine.com and we will return a signed PDF of this version, or review yours. We change the date at the top when this text changes, and we email your organisation’s owner about any change that reduces what we commit to.

Data subjects. Your end users: the people who raised tickets or conversations and the people copied on them. Your agents and teammates, as authors, assignees and mentions. Anyone named in the body of a ticket, a note, an attachment, a company record or a knowledge-base article.

Personal data.

• Identifiers - platform record ids, external ids, tags, and the map from a source id to the target id we created for it.
• Contact details - name, email address, phone and mobile number, company, job title and similar profile fields, and any custom fields your platform holds against a contact or company.
• Ticket and conversation content - subject, description, every message and note in the thread, who wrote it and when, status, priority, assignment, custom fields and tags.
• Attachments - any file attached to a ticket, message or article, including images embedded in a message body. They pass through our workers in memory and are never stored by us.
• Knowledge-base content - categories, folders and articles, including author and anything a body names.

Copies we hold during the lifecycle. The record as pulled from the source, the payload we sent to the target, the target’s response, any error the target returned, the request and response body of each API call (truncated, with file bytes and credentials removed), and the rollback ledger’s image of each target record before and after we wrote it.

Source and destination. Your own accounts on the helpdesk platforms you connect - currently Freshdesk and Intercom, with Zendesk in preview - accessed with credentials you provide, over each platform’s official API. They are your processors under your contract with them, not ours.

Frequency and duration. On demand, when you start a run; retained on the lifecycle the agreement describes.

What the application does today, as it is built:

• Platform credentials are encrypted at rest with a key derived for each organisation from a master key, so one organisation’s stored keys cannot decrypt another’s. They are never placed in queues or task arguments, are blanked the moment you disconnect a platform, and are deleted at purge.
• Encryption in transit. The application refuses to start in production with a non-HTTPS front end or origin, sends strict transport security headers, and calls every helpdesk platform and provider over HTTPS.
• Authentication. Passwords are hashed with bcrypt and must be at least twelve characters; email verification is mandatory before a password account can sign in; Google sign-in uses OpenID Connect with PKCE and a nonce, and identity is taken from a signature-verified ID token. Sessions use a short-lived access token held in browser memory and a rotating, server-side revocable refresh session in a Secure, HttpOnly cookie. Sign-in and sign-up endpoints are rate-limited and refuse rather than open when the limiter is unavailable.
• Access control. Roles are owner, admin and teammate, plus read-only client seats granted per migration; every migration route must declare the capability it needs or the build fails, and an unknown role gets none. Every query is scoped to the organisation on the migration row. A client seat never receives credentials or raw record content, and a migration it has no grant for does not exist to it.
• No standing staff access. Our engineers reach a migration only under a support-access grant you give per migration, time-boxed and revocable, and every use or refusal is audit-logged.
• Attachments never touch our disks. Files stream through worker memory from your source to your target, at most 15 MB each and four at a time, and are discarded. No object storage is used.
• Logging is content-aware. API request logs never record headers, credentials or file bytes, are truncated per body, and are deleted after 30 days.
• Every target write is ledgered and can be rolled back per run; a rollback is its own audited execution, commits step by step, and only ever reverses what the migration wrote: a record it created is removed, and a record it updated is put back to what it held before.
• Your API quota is protected. Rate limits are enforced account-wide across all our worker processes, learning your plan’s real limit from the platform’s own headers, so a migration does not exhaust the quota your support team is using.
• Hardening. Interactive API documentation is off in production, containers run as a non-root user, secrets are injected from the environment at deploy time, and dependency audits run on every release.
• No AI processing. No customer data is sent to any AI or language-model provider.

What we do not yet do, so you can assess it rather than find out later:

• Migrated record copies, API logs and rollback-ledger images are not encrypted at the application layer; encryption at rest for them is the infrastructure provider’s volume encryption.
• There is no multi-factor authentication yet. Google sign-in carries whatever second factor your Google account enforces.
• There is no rotation of the credential encryption key yet.
• Every team role can view the stored platform credentials of a migration; we do not yet restrict that to owners and admins.
• There is no self-service account deletion or password reset; both are done by support on request, within 30 days.
• The audit trail covers access grants, support access and administrative events, not every user action; run starts, rollbacks and sign-ins are recorded operationally rather than in the audit log.
• We hold no SOC 2 or ISO 27001 certification and have not yet commissioned an independent penetration test. The practices above are aligned with the GDPR’s requirements; they are not certified against them.

Who handles customer data for the DataGrine application, and for what:

• Cloud infrastructure provider - compute, database and cache, including the TLS ingress, holding everything at rest, in the European Union or the United States. We name the provider and the region on request, and to your organisation’s owner before it first holds customer data.
• Resend - transactional email: verification, invitations and retention warnings. Receives the recipient’s email address and name, your organisation and migration names, and the link in the email. Never record content.
• Google - sign-in with Google, if your team uses it: email, name and profile picture. Also the web fonts the application loads from Google’s CDN, which receives the visitor’s IP address.
• Intercom - our own in-app support chat, when enabled: the signed-in user’s id, email, name and account date, and whatever they type in the chat. This is DataGrine’s workspace and is separate from any Intercom account you migrate to or from.

Who handles data for this website, where we are the controller - named here because the privacy policy gives categories and points to this list:

• Vercel - hosting for this site.
• Neon - the database that stores enquiries and demo sign-ups.
• Resend - delivers enquiry emails to us.
• Slack - tells us an enquiry arrived.
• Cal.com - the booking calendar, if you use it.
• Intercom - the support chat on this site, when enabled.

Each provider’s own hosting region is stated in its data processing terms, which we can share on request. We email your organisation’s owner 14 days before this list changes, as the sub-processors clause says.