Data processing agreement

This data processing agreement ("DPA") forms part of the terms of service between you ("Customer") and Pristine Technology, doing business as Apex Actions, a Texas company ("Apex Actions"). It applies where, in using the service, Customer has us process personal data that is subject to the EU General Data Protection Regulation, the UK GDPR and Data Protection Act 2018, the Swiss Federal Act on Data Protection, or a law that requires terms of this kind ("Data Protection Law"). Terms defined in those laws have the same meaning here.

Nothing here requires signature: it applies by virtue of the terms. If your procurement needs a signed copy, write to legal@apexactions.com and we will countersign this text.

1. Roles

For the personal data in Customer's content — code, commits, workflow files, logs, artifacts, caches and the identities of the people who appear in them — Customer is the controller (or a processor acting for its own controller) and Apex Actions is the processor. Apex Actions processes that data only to provide the service, on Customer's documented instructions, which are: the terms, this DPA, and what Customer's workflows and settings tell the service to do.

For data about Customer's own users — their accounts, their sign-ins, their acceptance of the terms, their billing — Apex Actions is an independent controller, and the privacy policy applies.

2. Details of the processing

3. Apex Actions' obligations

Apex Actions will:

1. Follow instructions. Process the data only on Customer's documented instructions, including for transfers, unless the law requires otherwise — in which case we tell Customer before processing, unless the law forbids it. We will tell Customer if an instruction appears to us to infringe Data Protection Law.
2. Keep it confidential. Ensure that everyone we authorise to process the data is bound by confidentiality, and that access is limited to those who need it to provide, secure or support the service.
3. Secure it. Implement the technical and organisational measures in Annex 1, appropriate to the risk, and not reduce them during the term.
4. Use subprocessors responsibly. Section 5.
5. Help with rights requests. Taking account of the nature of the processing, help Customer by appropriate technical and organisational measures to respond to data subjects' requests. Most such requests are satisfied by Customer's own controls: deleting content from the repository, uninstalling the App, or deleting a run's logs and artifacts from the app.
6. Help with security, breach and assessment. Help Customer meet its obligations on security, breach notification, data protection impact assessment and prior consultation, taking account of what we know and what the processing is.
7. Report breaches. Notify Customer without undue delay, and in any case within 72 hours, after becoming aware of a personal data breach affecting Customer's data, with what we know then and the rest as we learn it, to the e-mail address on the account.
8. Delete or return. Section 8.
9. Demonstrate compliance. Section 7.

4. Customer's obligations

Customer is responsible for the lawfulness of the data it has us process, for its instructions, for the permissions it gives the App, for what its workflows do with data, and for informing data subjects as the law requires. Customer will not instruct us to process data in a way that would breach Data Protection Law.

5. Subprocessors

Customer gives general written authorisation for Apex Actions to use the subprocessors listed at subprocessors. We will give at least thirty days' notice before adding or replacing one, by updating that page and writing to the e-mail address on the account. Customer may object on reasonable data-protection grounds within that period; if we cannot resolve the objection, Customer may end the affected service without penalty for the remainder of the period.

We impose data protection obligations on each subprocessor that are no less protective than those here, and we remain responsible to Customer for what they do.

6. International transfers

The service runs in the United States (Annex 2). Where Customer's data is subject to the GDPR, the UK GDPR or Swiss law, its transfer to us and to our subprocessors is made under the European Commission's Standard Contractual Clauses (Decision 2021/914, module two, controller to processor, or module three where Customer is itself a processor), with the UK International Data Transfer Addendum where UK law applies and the Swiss amendments where Swiss law applies. Those clauses are incorporated here by reference and take precedence over this DPA for the transfer they govern; Annex 2 supplies the information they require. Where a transfer mechanism we rely on becomes invalid, we will cooperate to put another in place.

7. Audit

On request, no more than once a year unless a breach or a supervisory authority requires otherwise, Apex Actions will make available the information reasonably necessary to demonstrate compliance with this DPA: this document, the security page, our subprocessors' certifications, and written answers to a reasonable questionnaire. Where that is not sufficient, Customer or an independent auditor bound by confidentiality may audit, on thirty days' notice, during business hours, in a way that does not compromise other customers' data, at Customer's cost.

8. Deletion and return

Customer can export logs and artifacts from the app at any time. On uninstallation of the App from a repository, or termination of the agreement, Apex Actions deletes that repository's data within thirty days and its logs, artifacts and caches at the end of the plan's retention period, whichever is later — unless the law requires us to keep it, in which case we keep it only for that purpose, and only for that long. Backups are rotated on a fixed schedule — a weekly full backup with daily increments, four full backups kept — so deleted data leaves the backup set within thirty-five days and is never restored except to recover the service as a whole.

9. Liability

The liability of each party under this DPA is subject to the limitations and exclusions in the terms of service, and the same cap applies in aggregate across the terms and this DPA.

10. Precedence and changes

Where this DPA conflicts with the terms, this DPA prevails for the processing it governs; where it conflicts with the standard contractual clauses, the clauses prevail. We may update this DPA to reflect a change in law or in the service; we will give thirty days' notice of a change that reduces the protection it gives, in the way section 5 describes.

Annex 1 — Technical and organisational measures

• Isolation. Every job runs in a fresh container on a machine that is discarded when the job ends, with no route from the job to the platform's cloud identity. Nothing from one job is visible to the next; nothing from one customer is visible to another. Caches and artifacts are scoped to the repository that wrote them.
• Access. No long-lived credentials for people, CI or workloads; access to production is by named identity and short-lived credentials. Privileged actions in the service are recorded in an append-only audit log with actor, time and network address.
• Secrets. Write-only values, sealed at rest, provided to the job that needs them and never logged, displayed or snapshotted.
• Encryption. In transit, TLS everywhere; at rest, provider-managed encryption on every volume, bucket and database.
• Availability. Managed database with continuous backup; infrastructure defined as code and reproducible; alarms with a named responder.
• Development. Every change passes lint, typecheck, tests and a documented review before it ships; dependency and image provenance are recorded.
• Incident response. A written procedure with notification within the period in section 3.7.
• Personnel. Everyone with access is bound by confidentiality and trained in these measures.

The security page describes the measures in more detail and is updated as they change.

Annex 2 — Transfer details