Data processing agreement

01Roles

“Customer” is the business using PatchLabs. “PatchLabs” is the provider described in the terms. For personal data contained in the repositories, reports and workspace content the Customer submits (“Customer Personal Data”), the Customer is the controller and PatchLabs is the processor. For account data (such as members’ email addresses and sign-in records), PatchLabs is a controller and the privacy policy applies.

02What we process

03Our obligations

PatchLabs will:

• process Customer Personal Data only on the Customer’s documented instructions (the terms, this agreement and the Customer’s use of the service), unless the law requires otherwise, in which case we’ll tell the Customer first unless that is prohibited;
• make sure everyone authorised to process it is bound by confidentiality;
• apply the security measures in Annex A;
• help the Customer, taking into account the nature of the processing, to respond to data subject requests, and with security, breach notification, impact assessments and consultations with the ICO;
• make available the information needed to show compliance with Article 28 UK GDPR, and answer reasonable security questionnaires.

04Subprocessors

The Customer gives general authorisation for PatchLabs to use the subprocessors listed in Annex B. We’ll email account owners at least 14 days before adding or replacing one. The Customer may object on reasonable data protection grounds; if we can’t address the objection, the Customer may stop using the affected part of the service and close their account. We impose data protection obligations on each subprocessor equivalent to these and remain responsible for them.

05Personal data breaches

We’ll notify the Customer without undue delay, and in any case within 48 hours, after becoming aware of a personal data breach affecting Customer Personal Data. The notice will describe what happened, the data and people likely affected, the likely consequences and what we are doing about it, with updates as we learn more.

06International transfers

Where Customer Personal Data is transferred outside the UK, we rely on UK adequacy regulations (including the UK Extension to the EU-US Data Privacy Framework where the recipient participates) or the UK International Data Transfer Addendum to the EU standard contractual clauses.

07Audits

We hold no third-party certifications today. On request, and no more than once a year unless there has been a breach, we’ll answer a written questionnaire and walk the Customer through our pipeline and controls. On-site audits need reasonable notice and must not compromise other customers’ data.

08Customer obligations

The Customer confirms it has a lawful basis to submit the repositories and any personal data in them, that it is authorised to have them checked, and that its instructions comply with data protection law. We recommend not committing real personal data to repositories at all.

09Deletion

The lab database for each check is deleted when the check ends, and the working copy of the repository within 30 days. When the Customer deletes an app, a workspace or its account, we delete the related reports, fixes and receipts from our database, except where the law requires us to keep them. On request, we’ll confirm deletion in writing.

AAnnex A: security measures

• No production access. Checks work only from the repository; we never connect to customers’ databases. Live posture, when the Customer enables it, loads only the public home page of a verified domain, as any visitor would, with no credentials.
• Disposable lab. A new Postgres database per check, seeded with synthetic data and dropped when the check ends.
• Constrained AI agent. No web access; writes limited to the fix folder and the working copy; may run only the lab verifier; repo-supplied agent configuration removed before it runs; spend cap per check.
• Independent verification. Every fix is re-tested by a separate verifier on a freshly rebuilt lab before it is offered as proven.
• Authentication. Passwordless email links (single use, 20 minutes); sessions and API keys stored only as hashes; sessions revocable.
• Network. HTTPS for the website and API; webhooks limited to HTTPS public hosts.
• Integrity. Ed25519-signed receipts for every finished check, verifiable with our published public key.
• Data minimisation. Only a salted hash of IP addresses is stored; exposed keys are recorded masked; model costs and internal paths are not exposed to users.
• Access. Production systems are accessible only to the founder.

BAnnex B: subprocessors