DRAFT — NOT EFFECTIVE. This is a proposed business-to-business addendum, not a statement that the planned advertising platform or its safeguards are operational. Complete every decision and the processing/security schedules before signature. The repository currently implements a marketing website and enquiry storage; production advertising data flows have not been verified.
This Data Processing Addendum ("DPA") supplements the executed platform agreement between Jolts Inc. ("Operator") and the customer identified in the order form ("Customer"). It applies from [DECISION: effective date and accepted contract version] to the processing described in Schedule A. The parties' privacy contacts are contact@jolts.xyz and [Customer privacy contact]. A commercial account contact is not automatically the Customer's authorized privacy contact.
1. Scope and allocation of roles
"Personal Data" means information protected as personal data or personal information by the law applicable to the relevant processing. "Customer Data" means Personal Data processed by Operator on Customer's documented instructions under Schedule A. "Data Protection Law" means applicable privacy, security, breach-notification and international-transfer law. "Breach" means a security breach resulting in accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to Customer Data.
For the operations expressly marked processor processing in Schedule A, Customer is controller and Operator is processor; where Customer acts for another controller, Customer is processor and Operator is subprocessor. Customer must identify that relationship and have authority to issue the instructions and appoint Operator. Role labels do not override the parties' actual decisions or conduct.
This DPA does not convert all ad-network processing into processing on Customer's behalf. Processing for Operator's own billing, legal obligations, account administration or independently determined advertising purposes requires its own role analysis, lawful basis and notice. Personal Data is not excluded from this DPA merely by calling it usage data, service data, metadata or an identifier. A change of purpose or role requires a documented assessment and the appropriate agreement before processing begins; joint control, if applicable, requires a separate arrangement allocating responsibilities and making its essence available where law requires.
2. Instructions and permitted processing
Customer's instructions consist of this DPA, the completed order form and schedules, and authorized written instructions compatible with them. Operator may process Customer Data only to deliver the agreed operations, apply the agreed safeguards and comply with lawful instructions. A product setting authorizes only the specific operation the setting describes; it is not authorization for unrelated profiling or advertising uses.
Operator must notify Customer promptly if, in its assessment, an instruction infringes applicable Data Protection Law, identify the concern, and pause the disputed operation until the parties establish a lawful path. If law compels other processing, Operator must identify that requirement to Customer before processing unless legally prohibited. Nothing requires a party to follow an unlawful instruction.
Operator must not sell Customer Data, disclose raw conversation text to advertisers, build cross-customer user profiles, or use Customer Data to train a general-purpose model under this DPA. Any proposed processing of that kind requires a separate approved design, role analysis, legal basis, notice/choice mechanism and agreement; a general license to provide or improve the Service does not supply those permissions. Service-specific diagnostics must remain within the recorded purposes, access limits and retention periods.
3. Customer responsibilities and minimum data
Customer is responsible for having authority to supply Customer Data and for the notices, lawful basis and choices required for its collection and the instructions it gives. Customer must not treat this DPA as consent from an app user. Operator remains responsible for its own legal obligations and the lawfulness of its own processing choices.
The integration must use the least identifying information reasonably needed for the agreed placement. Full conversation histories, account identifiers, precise location and persistent advertising identifiers are not enabled by default under this draft. Storage of conversation text requires a completed field list, purpose, retention period, access policy and user-facing notice in Schedule A.
Credentials, payment-card details, government identifiers, special-category information, criminal-offence information and data about children are prohibited unless the parties first approve a specific lawful processing schedule and appropriate safeguards. Free text can contain such information incidentally; the parties must agree detection, suppression, rejection and deletion procedures, rather than assuming a contractual prohibition prevents collection. An incident involving prohibited data must be escalated and assessed, not silently retained for later use.
4. Personnel, security and service boundaries
Operator must restrict Customer Data access to personnel whose responsibilities require it, bind those personnel to confidentiality or an appropriate statutory duty, and provide training relevant to their access. Access must end when no longer needed.
The executed security schedule must describe the technical and organizational measures actually maintained for the authorized processing. The parties must assess those measures against the nature, context and risks of the data, including stored conversations, inference and re-identification. Operator must not materially reduce the agreed protection during the processing term. Material changes affecting Customer's risk assessment must be explained before implementation where reasonably practicable.
The accompanying security schedule is a proposed implementation checklist. It is not an assertion of certification, encryption coverage, incident readiness, tested backups or a particular hosting region until completed and accepted.
5. Subprocessors
[DECISION: select specific authorization, or general written authorization subject to the following process.] Under general authorization, Customer authorizes only the subprocessors listed in the completed register and engaged under this section. The register must disclose legal identity, task, data categories, processing locations and applicable transfer safeguards. Affiliates and external model providers are included when they process Customer Data; a provider is not exempt because it supplies a standard API.
Operator must notify Customer of a proposed addition or replacement [DECISION: notice period] before the new processing starts. Customer may object on reasonable data-protection grounds within [DECISION: objection period]. The parties must investigate a substitute, restriction or other reasonable solution. If no solution is available, the affected processing must not begin for Customer and either party may end the affected service without an early-termination penalty; the order form must address prepaid unused charges.
Operator must impose enforceable obligations providing the protection required for the delegated processing and remains responsible to Customer for the subprocessor's performance of those obligations. Urgency does not waive legally required authorization. The parties may agree an expedited written authorization where necessary to preserve service or security.
6. Individual rights and regulatory cooperation
Operator must promptly route requests concerning Customer Data to Customer and not independently decide Customer's response, except where law requires it. Operator must provide reasonable technical and organizational assistance to locate, export, correct, restrict and delete data and implement applicable objections or consent withdrawals. Identity checks must be proportionate and must not require unnecessary sensitive data.
The parties must agree how a pseudonymous request or event identifier connects to Customer's user records. Neither party may promise account-level deletion unless that mapping or a documented alternative is available. Operator must not re-identify people solely to create a rights workflow when a less intrusive lawful method is available.
Operator must supply information and reasonable assistance needed for Customer's impact assessments, prior consultations, regulatory enquiries, processing records and security obligations, taking account of the processing and information available. Routine assistance included in the commercial fee and exceptional assistance charges must be specified in the order form. A fee dispute must not delay legally required assistance or notification. Each party remains free to cooperate with a competent authority.
7. Personal data breaches
Operator must notify Customer without undue delay after becoming aware of a Breach affecting Customer Data. [DECISION: agree an operational initial-notice target that is shorter than applicable Customer deadlines; do not substitute a fixed target for the without-undue-delay obligation.] Notice must go to the designated privacy/security contact through the agreed channel, with an escalation route if delivery fails.
Available information must include the affected operations and data, approximate scope where known, likely consequences, containment and recovery actions, and a contact for follow-up. Operator may provide information in stages and must not wait for a complete investigation before the initial notice. It must preserve relevant evidence, investigate, mitigate reasonably foreseeable harm and cooperate with Customer's response.
Customer controls notices made on its behalf to individuals or authorities, except where Operator has its own legal duty. Neither party may prevent the other from meeting that duty. Notice of a suspected or confirmed Breach is not an admission of liability. Unsuccessful attacks without a compromise of Customer Data are not automatically Breaches, but security monitoring must distinguish and investigate them appropriately.
8. Evidence, audits and remediation
Operator must make available information needed to demonstrate its compliance with this DPA and permit and contribute to Customer or its independent auditor's proportionate audits and inspections. The parties should use existing relevant reports and remote evidence first where those adequately answer the question. Commercial confidentiality, other customers' data and security-sensitive information must be protected through appropriate arrangements, not used to prevent meaningful verification.
[DECISION: ordinary audit notice, frequency and cost allocation.] Those ordinary arrangements do not restrict a competent authority or prevent an additional audit reasonably needed after a material incident, credible noncompliance concern or material processing change. The parties must document findings, responsible owners and remediation dates proportionate to risk. Operator must promptly address a material failure to meet its obligations; unresolved unsafe processing must be suspended.
9. Transfers and government demands
Processing and remote access may occur only in the locations approved in Schedule A and the subprocessor register. The parties must assess each cross-border disclosure and onward transfer, including support access. A server location alone does not establish where all processing occurs.
Where a restricted transfer needs contractual safeguards, the parties must execute the applicable approved instrument and complete its required selections and annexes before the transfer. The EU Commission's applicable SCCs, the UK IDTA or UK Addendum, and any jurisdiction-specific adaptations must be selected based on the actual parties, roles and applicable law. This draft is not itself a completed transfer instrument.
Operator must review the legal validity of government demands, disclose only what it is lawfully required to disclose, and notify Customer where permitted. Challenges, transparency, supplementary safeguards, suspension and other obligations under an executed transfer instrument remain controlling. A contractual instruction cannot override applicable law or make an otherwise unlawful transfer lawful.
10. End of processing and retention
At the end of the relevant processing, Customer may choose return or deletion of Customer Data, and Operator must delete remaining copies unless applicable law requires retention. Complete [DECISION: export format, retrieval window, active-system deletion period and backup expiry] before signature. Retained backups must be protected, placed beyond ordinary use and deleted on the documented cycle; a restoration must reapply deletion instructions.
Any legally required retention must be identified by data category, reason and period, with processing limited to that requirement. Records independently required for Operator's billing or legal obligations must be separated from processor data and addressed in the applicable controller notice. Operator must provide written confirmation of completed deletion on request, identifying any lawful remaining retention. Undefined retention, silent indefinite storage and reuse of retained conversation content are not authorized.
11. Contract administration
This DPA prevails over conflicting commercial provisions concerning Customer Data processing; an applicable mandatory transfer instrument prevails over this DPA. Neither a limitation of liability nor an audit provision may reduce mandatory statutory or third-party rights. [DECISION: align interparty liability, indemnities and insurance with the negotiated platform agreement; do not assume the commercial cap covers all privacy matters.] Changes affecting data subjects or mandatory obligations must be documented. Processing must not continue on unresolved schedules merely because a commercial order was signed.
Schedule A — Processing instructions and role register
Complete one row for each actual data flow. These are candidate classifications requiring validation, not declarations of present functionality.
| Operation | Proposed role and decision required | Mandatory scope fields |
|---|---|---|
| Receive a publisher's contextual ad request | Processor only if Operator acts on documented publisher purposes/instructions; otherwise assess independent or joint control | Exact transmitted fields, inference, matching purpose, recipients, suppression, retention |
| Store conversation text | Separate approved processing operation; role follows purpose and use | Selected messages versus full history, necessity, lawful basis, sensitive-data handling, access, deletion and backup periods |
| Deliver and count a placement | Assess each publisher/advertiser disclosure separately | Event IDs, time, format, device/network fields, deduplication, raw versus aggregate report recipients |
| Cross-client optimization, tracking or audience building | Not authorized by this processor DPA; separate role and legal design required | Profile linkage, storage/access technology, notice, choice and applicable objection/opt-out signals |
| Advertiser campaign administration | Distinguish account data, creative content and identifiable audience data | Data subjects, Customer instructions, reporting permissions, retention |
| Operator billing, tax and fraud decisions for its own purposes | Assess independent-controller operations separately | Legal grounds, recipient disclosures, retention and rights contact |
For each approved processor operation record: Customer/controller identity and authority; data-subject categories; Personal Data fields; purpose; nature of operations; frequency; duration; retention/deletion; approved locations and remote access; authorized recipients; subprocessors; rights-request mapping; security controls; prohibited fields; and contact/escalation owners. No sensitive-data category is approved by an empty field.
Schedule B — Transfer completion record
Record whether a restricted transfer occurs and the legal mechanism supporting it. For EU SCCs, confirm the currently applicable approved text and module: controller-to-controller, controller-to-processor, processor-to-processor or processor-to-controller as appropriate. Complete party identities/signatures and roles, transfer description, competent authority, governing-law/court selections, optional provisions, subprocessor arrangements, Annex II measures, and Annex III where applicable. Do not rewrite mandatory clauses.
For UK transfers, complete the approved IDTA or Addendum, its parties, selected clauses/modules and appendix information, and required risk assessment. For any transfer, record destination-law assessment, provider due diligence, supplementary measures, review date and suspension trigger. Adequacy may be used only where the actual recipient and transfer fall within its scope. [DECISION: approved transfer counsel review and sign-off.]