Data Processing Addendum

Available by separately signed agreement for qualified United States business accounts. This page is a transparent framework, not a self-serve contract and not an automatic addition to the Terms of Service.

Availability and formation

Common Compute has a reviewed United States Data Processing Addendum framework for qualified business customers. It becomes a contract only when Common Compute and the customer sign an order or addendum that identifies the covered Service, data, purpose, duration, routing boundary, and authorized contacts. It is not incorporated into the Terms of Service automatically and cannot be accepted through the generic legal-acceptance endpoint.

Email contact@commoncompute.ai with the subject "DPA request". Do not send personal data or a production payload with the request.

1. Roles and scope

For covered Customer Content that Common Compute processes only to provide the customer's documented workload instructions, the order may identify the customer as controller or business and Common Compute as processor or service provider. Common Compute remains an independent controller for its own account, security, fraud-prevention, payment, tax, legal, and service-governance records to the extent applicable law assigns that role.

The role for each data flow is fact-specific. A title in an order does not change how a party actually determines purposes or means. Stripe processes payment data under its own terms. Cloudflare supplies hosting, storage, and email infrastructure. An independent provider operator may process the plaintext assigned to its Device and must be expressly authorized for the covered routing boundary.

2. Documented instructions

Covered instructions are to receive, stage, route, execute, return, secure, meter, reconcile, support, and delete Customer Content for the exact offered workload and model pair in the signed order. Common Compute will notify the customer if an instruction appears to violate applicable law, unless law prohibits notice.

No instruction authorizes model training, advertising, sale, unrelated profiling, provider reuse, or a workload outside the current offered catalog.

3. Provider routing and confidentiality

Marketplace execution may disclose plaintext Customer Content to the assigned provider-operated Device. A signed DPA does not make that Device technically unable to inspect plaintext. A covered order must either: (a) authorize this marketplace path and its disclosed controls; or (b) name a different eligible routing boundary that the Service actually supports.

Common Compute will route covered DPA work only under the eligibility stated in the signed order. Where marketplace providers are authorized, the assigned provider must have accepted the current Provider Agreement before receiving the covered work. Until fleet-wide agreement enforcement is activated, this may reduce eligible capacity or make capacity unavailable.

4. Security measures

The applicable technical and organizational measures are the current controls identified in the signed order and trust model, including TLS in transit, encrypted managed object storage, hashed credentials, short-lived artifact access, signed task and model metadata where implemented, scoped task scratch, access control, audit records, incident procedures, and deletion jobs.

These measures do not promise a hardware enclave, end-to-end encryption from customer to model, provider-blind execution, a certification, a particular residency boundary, or a control not identified in the signed order.

5. Confidentiality and personnel

Common Compute will limit covered access to people and eligible providers who need it to operate, secure, support, or comply with law and who are subject to appropriate confidentiality duties. The customer is responsible for its own users, instructions, credentials, notices, consents, and lawful basis.

6. Subprocessors

The signed order will identify the authorized infrastructure and provider categories and the method for material-change notice. Common Compute will use a written obligation requiring a subprocessor to protect covered personal data to the extent required for the assigned processing. A customer's reasonable objection and available remedy will be stated in the signed order.

7. Assistance and requests

Taking into account the nature of the Service and information available, Common Compute will provide reasonable assistance for verified data-subject requests, security inquiries, impact assessments, regulator inquiries, and breach duties that concern covered processing. The customer remains responsible for deciding whether and how to respond as controller.

8. Incidents

Common Compute will notify the covered customer without undue delay after confirming a breach of covered personal data and will provide available information reasonably needed for the customer's obligations. Notice is not an admission of fault. Provider notice duties and internal escalation do not replace any different deadline stated in a countersigned order or required by law.

9. Return, deletion, and retention

Customer task inputs for terminal jobs become eligible for early purge after a one-hour grace period, and the outer task-artifact sweep is 30 days, unless the signed order states a supported shorter boundary. Final-job payloads may be deleted earlier through the supported API or dashboard. Metadata needed for billing, fraud, security, tax, dispute, legal-hold, and audit purposes may remain after payload deletion.

Provider task scratch is outside Common Compute's direct storage control. The Provider Software performs terminal cleanup, and the Provider Agreement prohibits retention, but Common Compute cannot promise remote erasure of an unreachable or provider-preserved copy.

10. Transfers, audits, and liability

The standard framework is for United States customers and does not include Standard Contractual Clauses, the UK Addendum, or a business associate agreement unless separately executed. Cloudflare's global edge may process data outside a customer's state. Any required transfer mechanism must be in the signed order before covered data is submitted.

Audit evidence, frequency, confidentiality, cost, and remediation are defined in the signed order. The Terms of Service and signed order govern liability; this status page itself creates no additional warranty, indemnity, or liability.