Data Processing Agreement

1. At a glance

This page is a summary of our data processing framework and of the vendors we rely on. It is not legal advice, and it does not replace or vary the DPA you accept — the accepted or countersigned DPA always governs.

2. Roles and scope

Data protection law distinguishes the controller, who decides why and how personal data is processed, from the processor, who processes it on the controller's behalf. Different countries use different names for the same two roles — in Australia the controller is an APP entity and the processor is a service provider; in the United States a processor is often called a service provider too — but the split is the same. For the data you put into your NextGen account:

• You are the controller. You decide what personal data to collect, why you collect it, and how it is used. You are responsible for having a lawful basis (or the equivalent requirement under your local law) and for giving the required privacy notices to the people in your database.
• NextGen is the processor. We process that data only on your documented instructions — which include the DPA itself, your configuration of the platform, and your use of its features — and only to provide the service.
• We never become the controller of your customer data. We do not sell it, we do not use it for our own marketing, and we do not use it to train machine-learning models.
• Some data we control ourselves. Account registration, billing, support and security data — the information we need to run your account — is processed by NextGen as a controller under our Privacy Policy, not under the DPA.

3. What the DPA covers — and what it does not

Our DPA governs personal data that NextGen processes on your behalf inside the platform. It cannot govern what happens once data leaves it, or where you connect a third party yourself.

Covered by our DPA

• CRM records: contacts, companies, custom fields, notes and tasks
• Pipelines, opportunities and deal records
• Calendars, availability and bookings
• Forms and form submissions
• Websites, funnels and pages you build on the platform
• Ticketing and support records
• Invoices and payment records as records (the payment processor is a separate controller)
• Memberships, courses, communities and the client portal
• Workflows and automations executed inside the platform
• Reporting and analytics over your own data

Not covered by our DPA

• Payment processors and payment service providers, which act as independent controllers for their own regulatory purposes
• Third-party integrations that you choose to enable — social, messaging, advertising or other external services
• Any outbound webhook, API call or data export that sends personal data to a system outside the platform
• Any service you connect that we have not listed as a sub-processor

4. International transfers

NextGen operates self-contained regional deployments. Your account data and its backups are held in the region you choose — United States (Virginia), EEA (Frankfurt), United Kingdom (London), Canada (Montreal), Singapore or Australia (Sydney). The United States, European Economic Area and Australian regions are live today; the United Kingdom, Canada and Singapore regions are rolling out, and a region becomes selectable for new accounts once its infrastructure is live. Wherever your data is held, any transfer of personal data to another country is governed by the safeguards below.

• Standard Contractual Clauses. Transfers are made under the EU Standard Contractual Clauses, which are incorporated into the DPA and completed by its Schedules: Module Two where you are the controller and we are your processor, and Module Three where you are yourself a processor and we act as your sub-processor.
• Where we are established, and why it matters to you. Outside the United States, the entity that contracts with you is NextGen OS LLP, established in the United Kingdom; only customers whose Services are provided in the United States contract with NextGen OS, Inc., so a customer outside the United States has no contract with the US entity. Because a non-US customer's processor is UK-established, transfers from the EEA to us currently rely on the European Commission's adequacy decision for the United Kingdom. If that decision ever lapses or is suspended, the Standard Contractual Clauses apply to those transfers automatically, and we will tell you. Where a feature you switch on involves a sub-processor established in the United States, that is disclosed in Section 5.
• UK coverage. The UK International Data Transfer Addendum applies for UK data.
• Australian coverage. Disclosures of Australian personal information overseas are made under APP 8, after the reasonable steps set out in Schedule 7 of the DPA, including a written assessment and contractual protections with the recipient.
• Other countries. If your local law imposes its own transfer rules — for example Canada's PIPEDA accountability principle or Singapore's PDPA transfer limitation obligation — we will work with you on any additional terms you need. The DPA's general processor obligations apply in the meantime.
• Adequacy and the Data Privacy Framework. Where a recipient is certified under the EU-US Data Privacy Framework or the destination benefits from an adequacy decision, that mechanism is relied on instead of, or alongside, the clauses.
• Transfer impact assessments. On request we provide an assessment of the destination country's laws and the supplementary measures we apply, including our technical and organisational measures.
• Government access requests. We notify you of a legally binding request for your data unless prohibited by law, we challenge requests where there are reasonable grounds, and we disclose only the minimum necessary.
• Other sub-processors. Some of the services you can switch on — text and image AI, SMS and voice, and the media CDN — are provided by sub-processors outside your region, and those are listed in Section 5. They are covered by the safeguards above.

5. Sub-processors

Transparency about our vendors is part of the obligation we accept as your processor. The table below lists the sub-processors we engage, their purpose, where they process data, and the safeguard that applies to any transfer. We will give you at least thirty days' notice before adding or replacing a sub-processor, and you may object.

This is a summary of the list in Schedule 3 of the DPA. The authoritative list — with the notice process, the change log and the contact for objections — is on our sub-processor page. We give at least 30 days' notice before a new sub-processor begins processing your data.

Not sub-processors. You connect your own payment provider account (Stripe, PayPal, GoCardless, NMI, Authorize.net) under your own agreement with them, and we connect to it only on your instruction; where we process payment data as a controller, that is covered by our Privacy Policy. Social, messaging and advertising providers that you enable yourself (for example Meta, Slack, Telegram, YouTube, Gmail and Google services), messaging connections you add with your own credentials (for example Twilio or TextGrid), and email delivery services you connect with your own credentials such as SendGrid and Mailgun, are engaged by you and are outside our DPA. So is anything you connect by webhook, API call or export. This exclusion is substantive, not formal: we are not the processor or sub-processor for an integration you connect yourself, we give no warranty about it, and its security, retention, location and onward transfers are matters between you and that provider. Our own messaging and voice run through Telnyx, which is listed above.

Self-operated components. Our database engine, queue and state store, secrets and key management, the global router and its regional replicas, the self-hosted mail transfer agent, and the Android SMS and WhatsApp messaging bridge — which we operate on our own server and which transmits and briefly holds message content to deliver it through those channels — run on infrastructure we operate in your region. They are components we run ourselves, not separate vendors we disclose your data to.

AI models and their origin. The text model we run may be an open-weights model published by a third party. What matters for a transfer is who processes the data, not who published the model: text AI inference is performed by DeepInfra in the United States under a written Article 28 contract with contractual zero data retention, so your data is not sent to the model's publisher or to any other jurisdiction.

6. Security measures

The DPA commits us to specific technical and organisational measures, set out in full in Schedule 2 of the agreement. In summary:

• Tenant isolation: every account has its own physically separate database, so there is no shared table between customers.
• Encryption at rest: field-level AES-256-GCM application encryption for designated fields, with a unique key per account.
• Key management: the master key is held in a hardware-backed secrets manager, is non-exportable, and keys are destroyed on account deletion (cryptographic erasure).
• Encryption in transit: TLS 1.2 or higher, and an encrypted private network between our servers.
• Access control: role-based permissions, multi-factor authentication, hashed API keys and per-object authorisation checks.
• Audit logging: access to and disclosure of personal data, and all writes, are recorded with the acting user, account, path, result, IP address and user agent.
• Regional isolation: your data is stored and processed on infrastructure in the region you choose, and account databases are not replicated between regions.
• No model training: your data is never used to train or improve AI models.

The full measure list, including the items still being formalised, is in Schedule 2 of the standard DPA. We publish the open items rather than implying a finished programme.

7. Your responsibilities

• Lawful basis and notices. Make sure you have a lawful basis for the personal data you collect, and give the required privacy notices to the individuals in your database.
• Instructions. Your configuration and use of the platform are your processing instructions to us. Keep them within the law.
• Access management. Use individual user accounts, enforce MFA, and remove access from people who leave.
• Data minimisation. Store only the personal data you actually need, and keep it accurate.
• Third parties. If you connect an external service or send data outside the platform, you are responsible for that transfer and for any contract it requires.
• Sensitive data. If you process special-category or sensitive personal data, you must be able to rely on an applicable condition under your local law (Article 9(2) GDPR, APP 3 for sensitive information in Australia, or the equivalent), and you must tell us so we can confirm the right configuration.

8. How to accept our DPA

Our standard DPA is published in full and accepted, not signed. Under clause 15.4 it takes effect when you accept it, in either of these ways, and acceptance has the same effect as signing:

• (a) By incorporation. If your Underlying Agreement or an order form incorporates the standard DPA by reference, accepting those terms accepts the DPA as it stands at that date. This is how most customers are covered, and needs nothing further from you.
• (b) By accepting the DPA itself. Confirm your acceptance in writing to legal@mail.thenextgencrm.com, naming your Processor (the entity shown in the acceptance table of your completed copy), the person accepting and the date.

You do not need a signature from us for the DPA to be binding, and we keep a record of each acceptance — the date, the accepting person, the version accepted and a hash of the text accepted (clause 15.5) — which we will send you on request as evidence of the version in force.

Want a signed copy? A signature is optional and we are happy to provide one. Email legal@mail.thenextgencrm.com with your signatory's name and title and we will return a completed, signed counterpart — typically within five business days. This is the right route if your procurement or audit process requires an executed contract on file, or if you need negotiated terms rather than the standard form.

Not every customer needs a separate DPA. If you do not process personal data on behalf of others — for example if you only use the platform for your own internal records — the processing terms in our Terms of Service and Privacy Policy may be enough.

9. Contact

Questions about data processing, the DPA, sub-processors or international transfers: