Legal
Data Processing Addendum
How we process personal data on your behalf. This addendum is part of the Terms of Service and applies to every workspace automatically; nothing needs signing. If your procurement process needs a countersigned copy, ask and we will send one.
1. Parties and scope
This Data Processing Addendum (DPA) is between the customer who owns a workspace on the Service (Customer, you) and Jia Yang Inc., trading as Jiayang Cloud (Jiayang, we):
It applies whenever we process personal data on your behalf in providing the Service under the Terms of Service. It is intended to meet the requirements of Article 28 of the GDPR and the UK GDPR, and the equivalent provisions of other laws that require a written contract between a controller and its processor.
2. Definitions
Data protection law means every law that applies to the processing of personal data under this DPA, including the GDPR, the UK GDPR and Data Protection Act 2018, the Swiss FADP, and Singapore's Personal Data Protection Act 2012. Personal data, processing, controller, processor, data subject, personal data breach and supervisory authority have the meanings given in the GDPR. Customer data means the personal data you or your users put into the Service or that the Service produces for you, as described in Annex 1. Subprocessor means a third party we engage to process customer data. SCCs means the Standard Contractual Clauses in Commission Implementing Decision (EU) 2021/914.
3. Roles
For customer data, you are the controller (or a processor acting for your own controller) and we are your processor. That covers the people you share apps with, the data your apps store, the audit log of who used them, and the members of your workspace in their capacity as your users.
For the data we need to run our relationship with you (your account, sign-in security, billing, support), we are an independent controller, as described in the Privacy Policy. This DPA does not apply to that.
You are responsible for the lawfulness of the data you process on the Service: for having a basis to collect it, for telling data subjects what you do with it, and for the instructions you give us.
4. Instructions
We process customer data only on your documented instructions. Your instructions are: this DPA, the Terms of Service, and what you do in the Service (deploying an app, sharing it, setting a public path, exporting or deleting data). Using the Service's features is an instruction to do what those features do.
We will tell you if we believe an instruction breaks data protection law, and we may pause the affected processing until it is resolved. We will not process customer data for any purpose of our own, and we will not sell it.
If a law we are subject to requires us to process customer data otherwise, we tell you before we do, unless that law forbids it on important grounds of public interest.
5. Confidentiality
Everyone we authorise to process customer data is bound by a written duty of confidentiality, is given access only as far as operating the Service needs, and has that access logged. We don't read the content of your apps or the data they store, except where you ask us to for support or where a legal obligation requires it.
6. Security
We implement and maintain the technical and organisational measures in Annex 2, which are designed to protect customer data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access. We may improve them over time; we will not reduce the overall level of protection during the term.
The Service is built so that you can meet your own obligations: a signed identity on every request, a complete audit log, revocation within a minute, an export of the workspace and of each app's database on every plan, and a delete that is immediate and complete.
7. Subprocessors
You give us general authorisation to engage the subprocessors in Annex 3 and on the Subprocessors page. Each of them is bound by a written contract with data protection obligations at least as protective as this DPA, and we remain fully responsible to you for their performance.
Notice. We tell workspace owners by email at least 30 days before adding or replacing a subprocessor, with what it will do and where.
Objection. If you object on reasonable data protection grounds within those 30 days, we will talk to you about a way around it. If there is none, you may end the affected workspace's plan and delete the workspace before the change takes effect, and we refund any prepaid fees for the period after that.
8. Data subject requests
If a data subject contacts us about data in your workspace, we point them to you and tell you, unless the law requires us to answer directly. We don't respond on your behalf.
The Service gives you the means to answer most requests yourself: the audit log shows what was processed about whom; the export gives it to you in a portable form; removing a share or deleting a record is immediate, though a record deleted from an app's database stays in that database's point-in-time history for up to 30 days (Annex 2). Where a request needs something the Service can't do, we assist within a reasonable time, at no charge unless the effort is disproportionate, in which case we agree a cost with you first.
9. Personal data breaches
If we become aware of a personal data breach affecting customer data, we notify the affected workspace owners without undue delay, and in any case within 72 hours of confirming it, by email to the owner's address. The notice says what happened, which data and roughly how many people are affected, what we have done and are doing, and who to contact. We update it as we learn more.
We cooperate with you and give you the information you reasonably need to meet your own notification obligations. We don't notify supervisory authorities or data subjects on your behalf unless you ask us to in writing or the law requires it.
10. Assistance
Taking into account the nature of the processing and the information available to us, we assist you with data protection impact assessments and prior consultations with a supervisory authority, where they concern the Service. The Security page, Annex 2 and the Subprocessors page are written to be the starting material for one.
11. Deletion and return
You can export customer data at any time while the workspace exists, on every plan: the workspace as one JSON document (configuration, members, grants, the names of tokens, secrets and environment variables, and the retained audit log) and each app's database as SQL. A static site is the files you uploaded. When you delete an app or a workspace, or when the agreement ends, deletion is immediate and permanent: the apps are taken offline at once and their scripts, databases, containers and files are removed from Cloudflare right away. A deleted app's configuration, versions, sharing grants, tokens, secrets and environment variables go with it. Its entries in the workspace's audit log, the one recording the deletion among them, stay for the audit log's retention (Annex 1) like any other entry, and go with the workspace. Only the control plane's own records of a deleted workspace linger, for 30 days, for accounting; they are never restored. The control-plane database's restore history (Neon's point-in-time restore, up to 7 days on the plan we run: Launch, neon.com/pricing, checked 22 September 2026) ages out within a further 7 days and is not used to restore deleted data. While an app exists, what it deletes or overwrites in its database stays in Cloudflare D1's point-in-time history for up to 30 days (Annex 2). We confirm deletion in writing if you ask.
We keep only what the law requires us to keep (billing records, for example), for as long as it requires, and protect it as confidential.
12. Audit
We make available the information you need to show that we meet the obligations in this DPA. In order:
- The documentation we publish: this DPA, the Security page, the Subprocessors page, and our providers' own certifications and reports.
- Written answers to a reasonable security questionnaire, once a year, or after a breach or a material change.
- An audit, by you or an independent auditor you appoint who is bound by confidentiality and is not a competitor of ours, no more than once a year unless required by a supervisory authority or following a breach, on at least 30 days' written notice, during business hours, in a way that does not disrupt the Service or expose other customers' data, and at your cost. You give us a copy of the findings.
13. International transfers
Customer data may be processed in the countries listed in Annex 3. Where that involves a transfer of personal data protected by the GDPR, the UK GDPR or the Swiss FADP to a country without an adequacy decision:
- Between you and us, the SCCs, Module Two (controller to processor), or Module Three where you are a processor, are incorporated into this DPA by reference, with: Clause 7 (docking) included; Option 2 of Clause 9(a) with the 30-day notice period in section 7 above; the optional language in Clause 11 not included; Clause 17 governed by the law of Ireland and Clause 18 the courts of Ireland; Annex I completed by Annex 1 and Annex 3 of this DPA; Annex II by Annex 2. For UK data, the UK International Data Transfer Addendum (version B1.0) applies to the SCCs, with the tables completed by the same annexes. For Swiss data, the SCCs are read with the FDPIC's adaptations.
- Between us and each subprocessor, we have the SCCs or another lawful transfer mechanism in place, and will give you a copy on request with commercial terms redacted.
If a transfer mechanism we rely on stops being valid, we will work with you in good faith to put an alternative in place.
14. Liability
Each party's liability under this DPA is subject to the limitations and exclusions in the Terms of Service, taken together with liability under the Terms as a single cap, except where data protection law does not allow a limitation.
15. Term and precedence
This DPA lasts as long as we process customer data for you, and sections 5, 11 and 14 survive it. If it conflicts with the Terms of Service, this DPA wins for personal data. If it conflicts with the SCCs, the SCCs win. We may update this DPA to reflect changes in law or in the Service, with the notice described in the Terms; a change that reduces your protection needs your agreement.
Annex 1: Details of the processing
| Subject matter | Hosting, serving, access control and audit logging of the applications the Customer deploys on the Service. |
|---|---|
| Duration | The life of the Customer's workspace; the control plane's records of it for a further 30 days. |
| Nature and purpose | Storing and running the Customer's code and data; authenticating the people the Customer shares apps with and passing their identity to the app; recording every request and every change in an audit log; sending invitation emails on the Customer's instruction; holding third-party credentials the Customer gives us and attaching them to the app's outgoing requests; checking the signature of each delivery to a verified public path with the signing secret the Customer gives us, before the delivery reaches the app. |
| Categories of data subjects | The Customer's staff and contractors who are workspace members; the people the Customer shares apps with (typically colleagues, contractors, clients); the end users of the Customer's apps, whose data the apps store; anyone whose data appears in the Customer's content. |
| Categories of personal data | Email addresses and roles; sign-in and request metadata (IP address, user agent, country, timestamps, paths, response codes); the audit log; the contents of deliveries to a verified public path, which the control plane reads to check their signature and does not keep, apart from the identifier the provider gives a delivery, which is recorded in the audit log, and, where the provider signs the time it sent a delivery, a hash of the delivery's signature, kept so that a replayed copy can be refused and deleted within an hour; and whatever the Customer's apps store, which is determined by the Customer. The Service is not designed for special categories of data or for data about children, and the Customer must not use it for those without a written agreement with us covering the additional measures required. |
| Frequency | Continuous, for as long as the workspace exists. |
| Retention | As set out in section 11 and in the Privacy Policy; the audit log for 3 months (Free, Team) or 12 months (Business), and after a downgrade, events older than the new plan's retention are deleted 30 days after the plan changed. |
Annex 2: Technical and organisational measures
Access to apps
- Every application is reachable only through the platform's edge. Applications have no public address, route or ingress of their own.
- The edge authenticates every request (browser session or bearer token), evaluates the workspace's access rules, and passes the application a signed identity token valid for 60 seconds. Applications verify the signature, issuer, audience and expiry; a header on its own is never trusted. Every inbound header that could carry an identity is stripped before the platform sets its own.
- Missing configuration, an unreachable key set, or a failed access-rule lookup results in a denial, never a default allow. Access is denied unless a rule allows it.
- Revoking a person's access or a token takes effect within 60 seconds, including for open connections.
Isolation between customers
- Each workspace's rows in the control-plane database are protected by row-level security policies in the database itself, so a query can never return another workspace's data whatever the application code does.
- Each application runs in its own isolate or container, with its own storage, its own secrets and its own logs. Cross-tenant isolation is tested on every change to the platform.
- An application's outgoing traffic goes through an egress proxy that refuses connections to the platform's own hosts.
Encryption
- All traffic is TLS. Data at rest is encrypted by the storage providers (Cloudflare, Neon).
- Customer secrets (environment values, third-party credentials and webhook signing secrets) are additionally encrypted with a platform key before storage and are never shown back to a person. Environment values and third-party credentials are decrypted only at the moment they are attached to a request. A webhook signing secret is decrypted inside the control plane to check the signature of every delivery sent to its public path, including a forged one. It is never given to the application, and never logged or stored decrypted.
- Session and bearer tokens are stored as hashes.
Audit and monitoring
- Every request to an application and every administrative action is written to an append-only audit log the workspace's members can see, with the actor, the time and the source.
- Platform components verify their configuration on every request and fail closed when it is incomplete.
People and process
- Staff access to production is limited to what operating the Service requires, goes through the providers' own access controls, and is logged. Operator actions on a workspace are recorded in a platform audit log.
- Every change to the platform passes automated test suites (including the adversarial authentication cases and the cross-tenant isolation tests) before it is deployed, and then a staging deployment and its checks before production. The one exception is a revert while staging itself is broken, which can be deployed to production without the staging check, by hand and one deployment at a time; the deployment's record shows the check was skipped.
- Secrets for the platform itself are held in the providers' secret stores, never in source code or continuous-integration logs.
- The control-plane database is backed up continuously by Neon's point-in-time restore; on the plan we run the restore window is up to 7 days (Launch plan, neon.com/pricing, checked 22 September 2026), so a deletion is gone from the restore history within that time.
- Each Workers app's database is Cloudflare D1, which keeps a point-in-time history of the last 30 days (Time Travel, on the Workers Paid plan we run: developers.cloudflare.com/d1/reference/time-travel, checked 23 September 2026). Cloudflare maintains it, it is always on and it cannot be switched off, so a row an app deletes or overwrites stays in that history for up to 30 days. The platform offers no way to restore from it.
- A responsible disclosure process is published on the Security page.
Annex 3: Subprocessors
The current list, kept up to date, is the Subprocessors page. At the date of this DPA it is:
| Subprocessor | What it does | Location |
|---|---|---|
| Cloudflare, Inc. | Hosting, edge network, application runtime and storage, audit queue | Requests on the global edge; account data in the United States |
| Neon, Inc. | The control-plane database (Postgres) | AWS us-east-2 (Ohio), United States |
| Resend, Inc. | Transactional email: sign-in codes, invitations, notices to workspace owners, and alerts to our own staff | eu-west-1 (Ireland) |
| Stripe, Inc. | Payments, invoicing and tax; receives the workspace owner's email address and the workspace name as the customer's email and name, and the hourly request counts | United States |
| Proton AG | Our support, privacy and security mailboxes: the email you send us and our answers | Switzerland, Germany or Norway |