Data processing agreement

Template revision 2026-08-17 · Between [CUSTOMER LEGAL ENTITY] (controller) and [VENDOR LEGAL ENTITY] (processor)

1. Roles and precedence

The controller determines the purposes and means of processing dental claim data. The processor processes it only to provide the service and only on the controller's documented instructions. This agreement forms part of [MASTER AGREEMENT, DATE] and prevails over it on data protection matters.

Where the data is protected health information under HIPAA, a Business Associate Agreement is required in addition to this agreement and governs to the extent of any conflict: [BAA REFERENCE AND DATE]. As of this revision, no BAA exists — and the AI layer is therefore configured off, because sending PHI to a model provider without one is exactly what the mode gate prevents.

2. Subject matter, duration, nature and purpose

Subject matter: Processing of dental claims and their supporting records to adjudicate, review and reconcile them.
Duration: The term of the master agreement, plus [POST-TERMINATION PERIOD] for return or deletion.
Nature: Storage, rule evaluation, pricing, routing to human review, payment reconciliation, statistical analysis for payment integrity, and audit logging.
Purpose: Claim adjudication and payment integrity on the controller's behalf.

3. Categories of data and of data subjects (Annex I)

Data subjects: Patients and their dependents, plan subscribers, treating and billing providers, and the controller's own operators.
Personal data: Name, date of birth, member identifier, relationship to subscriber, postal address, provider identifiers, and operator usernames and roles.
Special category data: Health data: procedure codes, tooth and surface detail, diagnosis codes, clinical narratives, radiographs and other clinical attachments, and orthodontic treatment facts.
Financial data: Submitted charges, allowed and recommended amounts, liabilities, remittance and payment references.
Frequency: Continuous, for as long as claims are submitted.

4. Processor obligations

Process only on the controller's documented instructions, and tell the controller if an instruction appears unlawful.
Impose confidentiality on every person with access, and grant access only where needed to provide the service.
Implement the measures in Annex II and not materially reduce them during the term.
Assist the controller with data-subject requests, impact assessments and regulator enquiries — see section 7 for what that assistance can and cannot be automated today.
Return or delete personal data on termination, per section 9.
Make available the information needed to demonstrate compliance, and submit to audit per section 8.

5. Sub-processors

The controller authorises the sub-processors listed at [SUB-PROCESSOR LIST LOCATION]. The processor will give [NOTICE PERIOD] notice of any addition or replacement, during which the controller may object on reasonable data protection grounds.

Factual, from the code: the only sub-processor the software itself introduces is the model provider, and only when the AI layer is switched on. In its shipped configuration (PHI mode off) no data leaves the process to any third party. In deidentified, free text is withheld whole before anything is sent. In phi-allowed, unredacted content is sent to Anthropic (model claude-opus-5) and a BAA is a precondition.

Hosting, backup and support providers are the controller's or the operator's choices and are not introduced by the software: [LIST].

6. Personal data breach

The processor will notify the controller without undue delay and in any event within [NN] hours of becoming aware of a personal data breach, with the information available at the time, and will supplement it as more becomes known. Notification contact: [CONTROLLER SECURITY CONTACT].

7. Data-subject requests

Factual, and a limitation to negotiate around: there is no self-service mechanism for access, rectification, erasure, restriction, portability or objection. The platform can withdraw a claim from the corpus when a VOID is processed, scoped to one tenant and matched on patient identity rather than on the subscriber alone — but a rights request today is answered by an operator working through the API and the audit trail by hand. Any response deadline in [SECTION] has to be achievable by that manual route.

8. Audit and demonstrating compliance

The controller may audit the processing [FREQUENCY] on [NOTICE], and the processor will cooperate.

Factual, and unusually strong here: an auditor can self-serve most of this. There is an evidence-package endpoint that returns, for one sampled claim, the decision, the execution trace, the rule versions that ran, the approvals behind them, the overrides, and the access log — nine sections, each carrying its own completeness status rather than a silent gap. Eight compliance queries answer without engineering assistance. Two sections cannot be complete today and say so on every package: rules do not yet carry the authoritative policy source they came from.

Third-party assurance the controller may expect, none of which exists yet: SOC 2 Type II report, closed-out penetration test, and a disaster-recovery drill against a documented RPO and RTO.

9. Return and deletion

On termination the processor will, at the controller's election, return the personal data in [FORMAT] and delete remaining copies within [PERIOD], except where law requires retention.

Factual, and a gap: no retention or deletion schedule is implemented. The PostgreSQL store trims nothing on a timer; the development store keeps only the most recent 2,000 events per tenant. Deletion at the end of a term is an operational task somebody performs, not a setting.

10. International transfers

Where personal data is transferred out of [JURISDICTION], the parties will rely on [SCCs MODULE / DPF / ADEQUACY] and complete a transfer impact assessment. Enabling the AI layer is itself such a transfer.

11. Liability, term, governing law

[LIABILITY CAP AND CARVE-OUTS] · [TERM AND TERMINATION] · [GOVERNING LAW AND VENUE]

Annex II — technical and organisational measures

Accurate as of this revision, and written to be checkable against the source rather than to read well. Measures the software does not provide are listed as absent rather than omitted.

Implemented in the software

Tenant isolation. Every read and write carries a tenant scope derived server-side from the session; nothing a request asserts can select it. A cross-tenant identifier answers 404, not 403, so a refusal discloses nothing. The relationship graph is one graph per tenant, so a cross-tenant traversal cannot be expressed.
Patient-level separation. Clinical history is keyed on patient identity, not on the subscriber, so one dependent's records cannot satisfy, price or deny another's claim.
Role-based access. Distinct author, reviewer, approver and admin roles; content authoring is refused to the clinical reviewer role by name.
Four-eyes change control. A rule cannot be approved by the person who submitted it, nor by anyone who edited its content or its test evidence after submission, nor by the operator who asked a model to draft it. A version whose history cannot be classified is refused rather than waved through.
Append-only access trail. Reads and exports record actor, route, outcome and subjects. Refused reads are recorded too. An export without a stated disclosure purpose is refused.
Auditor evidence package. Per-claim, nine sections, each with its own completeness status.
Model-provider boundary. Three PHI modes, shipped off; whole-text redaction in the middle mode; the unredacted mode documented as requiring a BAA. Every model call is logged with what was sent.
Session integrity. Tokens are signed; there is no built-in secret, and a weak or known secret is refused at startup.
Determinism. The same claim against the same rule content yields the same decision, so a disputed outcome can be reproduced exactly.

Not provided by the software — deployment responsibilities

Transport encryption (the development configuration serves plain HTTP on localhost), encryption at rest, and key management.
Backup, restore, and any tested recovery objective.
Network isolation, intrusion detection, monitoring and alerting.
Retention and scheduled deletion — no schedule exists.
Automated data-subject request handling — manual today.
Asymmetric signing of distributed content: the bundle signature is an HMAC, so a compromised data plane could mint content for its peers.
Durable multi-writer plane state, and multi-region operation.