DRAFT — NOT LEGAL ADVICE, NOT IN FORCE. This document was prepared by an AI assistant, not by a lawyer, from this repository's source code and documentation. It must be reviewed by counsel qualified in every jurisdiction in which the Service is offered before it is published, offered to anyone, signed, or relied on. Placeholders in
[BRACKETS]are decisions for the operator; nothing in them should be invented by anyone but the operator and their lawyer.A DPA is the document a Customer's procurement and legal functions will read line by line, and the one most likely to be negotiated. This draft is groundwork intended to save counsel drafting time, not to replace counsel. Every factual statement about the software traces to
docs/legal/data-map.md. Where the code and this document disagree, the code is correct and this document is wrong.
Document version: draft-1 · Prepared: 2026-08-07 · Status: unreviewed · Effective date: [NOT IN FORCE]
1.1 This Data Processing Agreement ("DPA") forms part of the between [LEGAL ENTITY NAME], incorporated in [JURISDICTION OF INCORPORATION], registered at [REGISTERED ADDRESS] ("Processor", "we", "us") and the Customer identified in the Terms ("Controller", "Customer", "you").
1.2 It applies to the hosted Service only. If you run the software yourself under the MIT Licence, we are not your processor, this DPA does not apply, and we never see your data. See §2.2.
1.3 The split of roles, stated once and applied consistently throughout.
This mirrors §6.2 and §1.2. This DPA governs only the first row.
1.4 Precedence. In respect of the Processing of Customer Personal Data, this DPA prevails over the Terms of Service, as §1 provides.
1.5 Terms defined in the GDPR — controller, processor, personal data, processing, data subject, personal data breach, supervisory authority — carry those meanings. Where the DPDP Act 2023 applies, Controller means Data Fiduciary, Processor means Data Processor, and data subject means Data Principal. Where the CCPA/CPRA applies, we are a service provider and you are a business.
2.1 Subject matter. Provision of the hosted Service: a sales CRM with an automated research and analysis agent.
2.2 Duration. For the term of the subscription, and thereafter only as §11 allows.
2.3 Nature and purpose of processing. Storage; structured retrieval; computation of coverage, connect-rate, stalled-deal and follow-up analyses; synchronisation with mailboxes and calendars the Customer's users connect; submission of record content to a large language model in order to produce research findings, briefs and answers; deletion on instruction.
2.4 Categories of data subject.
2.5 Categories of personal data. Name; business email address; telephone number; job title; employer; public social profile links; photographs of identified individuals; free-text notes written by the Customer's users; the full body and complete recipient list of email correspondence; calendar event details and complete attendee lists; call metadata including duration and whether the person answered; model-generated inferences and written characterisations of named individuals, with the evidence relied on; company records and website content extracted by a third party.
2.6 Special categories of data. None are solicited, no field exists for them, and the Terms prohibit the Customer from processing them through the Service ( §5.3). We cannot technically prevent such content being typed into a free-text field or written into a model-generated narrative, and we do not represent otherwise.
2.7 Frequency. Continuous.
3.1 Lawful basis is yours. You warrant that you have, and will maintain, a lawful basis for every category of Customer Personal Data you put into or connect to the Service, and that you have given every notice and obtained every consent the applicable law requires.
3.2 This is not boilerplate for this product, and we are not going to pretend it is. The Service is designed to hold data about third parties who never signed up. Three consequences you should take advice on before you deploy:
docs/legal/research.md §1.3.3 What the software does not record, and therefore what you must record elsewhere. There is no lawful-basis field, no consent-date field and no opt-out field on any contact record, and the CSV import captures no provenance for an uploaded list. If you need to evidence why a person is in your CRM, you must keep that evidence in another system. We state this here rather than leaving you to discover it during an audit.
3.4 Instructions. Your use of the Service, and the configuration choices your administrators make in it, constitute your documented instructions. Any other instruction must be agreed in writing and [STATE WHETHER IT IS CHARGEABLE].
3.5 Mailbox and calendar connection. Connecting a mailbox causes the Service to ingest the content of that user's correspondence and the attendee lists of their meetings. You instruct us to do this by connecting it. You are responsible for the lawfulness of that ingestion in respect of every correspondent and attendee. The automatic contact-creation setting is off by default; switching it on is your instruction and your risk.
3.6 Optional third-party capabilities. Each capability listed in §4 is off unless a key is configured. Enabling one is your instruction to send the described data to that provider. The LinkedIn lookup capability uses a third-party API and not an official LinkedIn API, and LinkedIn's terms prohibit storing their content obtained outside their own APIs, including indirectly. It is off by default. If you enable it you do so on your own assessment and indemnify us under §10.1(c).
3.7 Prohibited data. You will not process through the Service any special-category or sensitive personal data, data about children, government identifiers, payment-card data, or health information.
Drafted against the mandatory processor-contract terms of GDPR Art 28(3);
counsel should confirm each is discharged. See docs/legal/research.md §2.
4.1 Documented instructions only. We process Customer Personal Data only on your documented instructions, including as to transfers, unless required by law to do otherwise, in which case we will tell you first unless the law forbids it. We will tell you if we consider an instruction to infringe data-protection law.
4.2 We do not process it for our own purposes. We do not sell it, do not use it to build a profile of any individual for our own purposes, and do not use it to train our own models. On what a third-party model provider may do, see §7, which does not make a promise we cannot keep.
4.3 Confidentiality. Every person we authorise to process Customer Personal Data is bound by an obligation of confidentiality. [CONFIRM: employment contracts and contractor agreements actually contain one. Do not tick this clause until they do.]
4.4 Security. See §8, which describes the measures actually implemented and names the ones that are not.
4.5 Sub-processors. See §6.
4.6 Assistance with data-subject rights. See §9.
4.7 Assistance with your compliance obligations. Taking account of the nature of processing and the information available to us, we will assist you with data protection impact assessments, prior consultation, breach notification and security obligations. Our practical assistance is limited by §9.3 — there is no export tooling and no audit log — and we say so here rather than in a footnote.
4.8 Deletion or return on termination. See §11.
4.9 Information and audit. See §10.
5.1 The hosted Service is deployed one instance per Customer, each with its own Postgres database. There is no shared multi-tenant datastore.
5.2 What that lets us say honestly. Your records are not in the same database as another Customer's records. The separation is physical, not a filter in a query. We cannot cross-reference or aggregate your data with another Customer's because there is nothing to join across. This is a stronger isolation claim than most software of this kind can make, and it is true today.
5.3 What it does not fix. Within your own instance, records are visible to every member of your workspace by default, and several destructive operations — including deleting a company, a contact or a deal — are available to any signed-in member and are not restricted by role. Access control inside your workspace is your responsibility ( §4.4). We state this so that no reader infers a role-based restriction on deletion that does not exist.
5.4 If the hosted Service ever moves to a shared multi-tenant database, §5.1
to §5.3 cease to be accurate, this DPA and the
must be reissued, and notice given
under §6.3. [This must be treated as a gating condition on any such change.
docs/security/audit-2026-08.md finding C1 records that CRM records carry no
organisation identifier and reads are not scoped by one, which would become a
cross-tenant exposure the moment two organisations shared a database.]
6.1 General authorisation. You give us general written authorisation to engage sub-processors. The current list, with what each receives, is at , which forms part of this DPA.
6.2 Terms we impose. Each sub-processor is engaged under a written contract imposing data-protection obligations no less protective than those in this DPA, and we remain fully liable to you for its performance. [CONFIRM each such contract is actually in place before this clause is signed. For the large providers this means accepting their standard DPA and retaining the executed copy.]
6.3 Change notice. We will give you [NOTICE PERIOD — 30 days recommended] written notice before adding or replacing a sub-processor, by [NOTIFICATION MECHANISM]. You may object on reasonable data-protection grounds within [OBJECTION WINDOW — 15 days recommended]. If we cannot make the change avoidable for you, you may terminate the affected part of the Service without penalty and receive a pro-rata refund. Emergency replacement for security or continuity reasons may happen with shorter notice, and we will notify you [TIMEFRAME] afterwards. This mirrors §6.
6.4 The model provider is the hard case. Which model runs the agent is a runtime setting your own administrator selects, from a catalogue fetched live from the AI gateway. A single settings change alters which company receives contact names, call notes and model-written briefs about named individuals. Our §6.3 notice duty cannot sensibly extend to a choice you make. [DECISION REQUIRED, AND IT IS A REAL ONE — see §3.1: either (A) we restrict the selectable catalogue to a named list and treat every addition as a §6.3 change, which is the recommended option and the one this draft assumes, or (B) you select freely and thereby appoint that provider as a sub-processor yourself. The chosen option must be stated here in terms, because the allocation of responsibility differs completely between them.]
7.1 What leaves the deployment. The agent puts record content into prompts. Assume that names, business email addresses, job titles, employers, company website content, call and meeting note text, and the user's own question leave the deployment on every agent run.
7.2 Training and retention are governed by the provider's terms, not by ours or by this software. This DPA therefore does not state that Customer Personal Data is never used to train a model. It is not ours to give.
Two verified facts, stated because a procurement function will find them anyway:
docs/legal/research.md §4).[VERIFY THE CURRENT PUBLISHED POSITION OF EVERY PROVIDER IN THE CATALOGUE, CITE
IT, AND STATE IT HERE BEFORE THIS DPA IS OFFERED TO ANY CUSTOMER. This is the
first question a procurement function asks and it will not accept an evasion.
Enabling zero data retention is a small code change that would convert this
clause from a disclosure into a commitment, and it is the cheapest legal
improvement available anywhere in this directory. See docs/legal/research.md
§4.]
7.3 Agent session state is persisted outside the application database by the
agent framework. [UNRESOLVED — establish where that state physically lives and
under whose terms, and list the operator in
, before this DPA is offered.
docs/legal/data-map.md §3.2 flags this.]
7.4 Untrusted input. The agent reads content it did not author — company
websites, email bodies, public profiles — which may contain text crafted to
influence it. We take measures against this but cannot guarantee output is free
from the influence of injected instructions
(docs/security/audit-2026-08.md finding M1). Output is a prompt for a human,
not a finding of fact.
Annex II to this DPA is §8.2 and §8.3 together. Both. A Customer that is given
only the first half has been misled. The standing rule is to understate:
everything claimed maps to a verified finding in
docs/security/audit-2026-08.md.
8.1 We implement appropriate technical and organisational measures having regard to the state of the art, the cost of implementation, and the nature, scope, context and purposes of processing, as GDPR Art 32 requires.
8.2 Measures implemented and verified.
8.3 Measures not implemented. Disclosed because a security annex that omits them is a misrepresentation.
8.4 Personnel. [STATE THE ACTUAL POSITION: background checks, security training, access on a least-privilege basis, and who holds production database credentials. A one-or-two-person operation should say so rather than describe an enterprise security organisation that does not exist.]
8.5 Business continuity. [STATE THE BACKUP AND RESTORE POSITION, which is determined by the managed database provider, and STATE WHETHER A RESTORE HAS EVER BEEN TESTED. If it has not, say so.]
9.1 Taking account of the nature of the processing, we will assist you by appropriate technical and organisational measures, insofar as possible, to fulfil your obligation to respond to requests to exercise data-subject rights.
9.2 If a data subject contacts us directly about Customer Personal Data, we will not respond substantively. Where we can identify the Customer concerned we will pass the request on without undue delay and tell the data subject we have done so ( §3.3).
9.3 The limits of the assistance we can give, stated in advance rather than discovered during a one-month statutory deadline.
9.4 The suppression record — read this before you promise anything to a data subject. When a contact is deleted, the Service writes a suppression record containing that person's email address, and a reason string that today also includes their name. Without it, the connected mailbox sync recreates the person from the next email thread, defeating the deletion.
Deleting a person therefore does not remove all of their data. Their email address, and currently their name, remain in the database indefinitely, with no expiry and no deletion path in the user interface. The suppression is lifted only by re-adding the contact. There is no "forget completely" operation.
This is capable of being justified as a minimal record kept precisely in order to
give effect to an erasure — the argument recognised in GDPR Art 17(3) and in
suppression-list practice — but it must be disclosed to the data subject when
you confirm the erasure, and you cannot tell them that all of their data is
gone. [RECOMMENDATION TO THE OPERATOR: change the reason string so it does
not embed the person's name. The name is more data than the purpose requires and
its removal materially strengthens the justification. docs/legal/data-map.md
§4.3.]
9.5 Deletion cascades you should understand before instructing one. Deleting a company also destroys every deal and every activity at that account. Deleting a contact destroys their research facts, briefs, deal roles, activities and agent conversations. There is no soft delete and no archive — a delete is a delete and cannot be undone by us.
10.1 We will make available the information necessary to demonstrate compliance with this DPA and allow for and contribute to audits, including inspections, conducted by you or an auditor you mandate.
10.2 How that will work in practice. [SET THE PRACTICAL TERMS: frequency — commonly once in any twelve months except following a breach; reasonable notice — commonly 30 days; during business hours; subject to confidentiality; not by a competitor; and whether the auditor's costs and our reasonable time are chargeable. A deploy-per-customer operation with no certification should expect audit requests to be more frequent, not less, and should decide the position deliberately rather than negotiating it under pressure.]
10.3 Where available we may satisfy §10.1 by providing a current third-party audit report. [NONE EXISTS AS AT THIS DRAFT — see §8.3. Do not include this clause in a form that implies one does.]
10.4 The audit-log gap bears on this clause too. We can demonstrate what the system is configured to do; we cannot produce a record of who read or exported a particular record, because none is kept (§8.3).
11.1 On termination, at your choice, we will delete or return Customer Personal Data and delete existing copies, unless law requires us to keep it.
11.2 Return. [NO EXPORT MECHANISM EXISTS AS AT THIS DRAFT ( §6.4). Until one does, the only honest form of this clause is a manual database export delivered by us on request. State the format, the delivery method and the timeframe, and do not offer self-service export until it is built.]
11.3 Deletion. Because your data sits in its own database, deletion means
destroying that database and the associated stored files. There is no scripted
teardown procedure today, so this DPA states no number of days.
[DO NOT FILL IN A FIGURE UNTIL A TEARDOWN PROCEDURE EXISTS AND HAS BEEN TIMED.
docs/legal/data-map.md §4.6 and §6.5 carry the
same instruction, and all three documents must be filled in with the same
number.]
11.4 Backups. Deletion from backups lags deletion from the live database by the backup retention window of the managed database provider. [STATE THAT PROVIDER'S ACTUAL WINDOW HERE. It is not determined by this software.]
11.5 Suppression records survive deletion of a contact as described in §9.4, and §6.5 reserves this.
12.1 [UNRESOLVABLE UNTIL THE ENTITY, THE HOSTING REGION AND THE MODEL
CATALOGUE ARE CHOSEN. This section is a checklist for counsel, not a statement of
position. See docs/legal/research.md §§1–2.]
12.2 EEA transfers. Where we transfer Customer Personal Data out of the EEA, the parties agree the Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) are incorporated by reference, using the module that matches the relationship. [SELECT THE MODULE. For a Customer established in the EEA using our hosted Service, this is normally Module Two (controller to processor); where the Customer is itself a processor for its own client, Module Three (processor to processor). Complete Annexes I, II and III of the SCCs from §2, §8 and respectively — those sections are drafted to be lifted into them. Docking clause: decide whether to include it. A transfer impact assessment is required and is not written.]
12.3 UK transfers. The UK International Data Transfer Agreement, or the UK Addendum to the SCCs, applies. [SELECT ONE AND COMPLETE ITS TABLES.]
12.4 India. There is no EU adequacy decision for India — confirm this remains so at the date of publication. Under the DPDP Act, cross-border transfer follows a restricted-country model rather than an adequacy model, and the current list of restricted countries must be checked at publication.
12.5 The government-access and onward-transfer questions the SCCs require to be assessed depend on the hosting region and on each model provider's jurisdiction, which §6.4 makes a variable rather than a constant. This is another reason to prefer Option A (a restricted catalogue) in §6.4 — a transfer impact assessment cannot be written against a set of providers that an administrator can change at any time.
13.1 CCPA/CPRA. We are a service provider. We are prohibited from, and will not: sell or share personal information; retain, use or disclose it for any purpose other than performing the Service, or outside the direct business relationship, or for a commercial purpose other than performing the Service; or combine it with personal information received from another source, except as the regulations permit. We certify that we understand and will comply with these restrictions. We will notify you if we determine we can no longer meet them.
13.2 DPDP Act 2023 (India). Where the Act applies, you are the Data
Fiduciary and we are a Data Processor acting only under this DPA. We will
assist you with Data Principal requests under §9, notify you of a personal data
breach under §14 so that you can notify the Data Protection Board and affected
Data Principals, and delete data on your instruction under §11. [Note the
absence of a general legitimate-interests ground under the DPDP Act, which makes
§3.2 a live problem rather than a formality; and note that the DPDP obligation to
notify a breach carries no materiality threshold, which makes §14.1 stricter than
its GDPR equivalent. Confirm the current status of the DPDP Rules and of the Data
Protection Board against docs/legal/research.md §1 at the date of
publication.]
13.3 GDPR Art 28(3) checklist. Subject matter, duration, nature and purpose, type of personal data and categories of data subject are in §2. The Art 28(3)(a) to (h) obligations are in §4, and are elaborated in §§6, 8, 9, 10, 11 and 14. [COUNSEL TO TICK EACH SUB-PARAGRAPH OFF INDIVIDUALLY. A missing sub-paragraph is the most common defect in a processor contract.]
14.1 We will notify you without undue delay after becoming aware of a personal data breach affecting Customer Personal Data, with the information available to us, and will supply further information as it becomes available. [STATE A CONCRETE OUTER LIMIT — 48 hours is the usual expectation and 24 hours will be demanded by some Customers. Do not commit to a figure you have no monitoring or on-call arrangement to meet.]
14.2 You make the notification to the supervisory authority and to data subjects. You are the controller and it is your notification to make — GDPR Art 33 for the authority, Art 34 for data subjects, and the DPDP equivalents, which have no materiality threshold.
14.3 We will take reasonable steps to contain and remediate, and will cooperate with you.
14.4 What limits our ability to tell you what happened. There is no audit log (§8.3). Our account of a breach will be reconstructed from application and infrastructure logs, not from a record of record-level access. You should factor that into your own breach-assessment procedure now, not during an incident.
14.5 Notification is not an admission of fault.
15.1 Liability under this DPA is subject to §12. [A data-protection carve-out at a higher cap is standard in enterprise SaaS and will be demanded by any Customer with a procurement function. Decide it deliberately rather than discovering it in a negotiation — §12.4 carries the same note.]
15.2 Governing law and jurisdiction. [GOVERNING LAW] and the courts of [VENUE], save that the SCCs are governed as the SCCs provide. [An Indian entity selling into the EU should expect resistance to Indian law and venue for a DPA, and should take advice on whether a separate EU-facing contracting entity is warranted.]
15.3 Changes. We may update this DPA on [NOTICE PERIOD — 30 days recommended] notice where required by law or by a change to the Service. Material adverse changes take effect at your next renewal.
15.4 Order of precedence. This DPA, then the SCCs where they apply (which prevail over both in the event of conflict), then the .
15.5 Signature. [DECIDE HOW THIS IS EXECUTED: incorporated by reference and accepted on sign-up, or countersigned on request. Enterprise Customers will ask for a signed copy. Have a process before the first one asks.]
Ordered by how badly each would go if a Customer signed this DPA before it was resolved.