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, so 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, the DPA, is between two parties. One is the customer who owns a workspace on the Service, called the Customer or you. The other is Assessly Pte. Ltd. (UEN 202613864N), trading as Forculus, which provides the Service, called Forculus or we:
It applies whenever we process personal data on your behalf in providing the Service under the Terms of Service. It is meant to meet what Singapore's Personal Data Protection Act 2012 requires of an organisation and the data intermediary that processes personal data for it, including protection (section 24), retention (section 25) and notice of a data breach (section 26C). It is also meant to meet 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
- PDPA means Singapore's Personal Data Protection Act 2012 and the regulations made under it.
- Data protection law means every law that applies to the processing of personal data under this DPA, including the PDPA, the GDPR, the UK GDPR and Data Protection Act 2018, and the Swiss FADP.
- Organisation, data intermediary and individual have the meanings given in the PDPA. For processing the PDPA governs, controller means organisation, processor means data intermediary, and data subject means individual.
- PDPC means Singapore's Personal Data Protection Commission.
- Personal data, processing, controller, processor, data subject, personal data breach and supervisory authority otherwise have the meanings given in the GDPR. A personal data breach includes a data breach as the PDPA defines it, and a supervisory authority includes the PDPC.
- 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, which the PDPA calls the organisation, or a processor acting for your own controller. We are your processor, which the PDPA calls your data intermediary. That covers the people you share apps with, the data your apps store, the audit log of who used them, what your identity provider sends us, and the members of your workspace in their capacity as your users.
We also need some data to run our relationship with you: your account, sign-in security, billing and support. For that data we are an independent controller, and the organisation responsible for it under the PDPA, as the Privacy Policy describes. This DPA does not apply to it.
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, such as deploying an app, sharing it, setting a public path, or 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 in another way, we tell you before we do. The exceptions are where that law forbids telling you on important grounds of public interest, and where telling you could put someone at risk or get in the way of a report the law requires, such as a report of child sexual abuse material to the authorities.
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, where we look into a report of abuse or copyright infringement about one of your apps, or where a legal obligation requires it.
6. Security
We implement and maintain the technical and organisational measures in Annex 2. They are designed to protect customer data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access. They are the reasonable security arrangements section 24 of the PDPA requires of us. We may improve them over time, but 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, and an export of the workspace and of each app's database on every plan. Deleting takes an app or a workspace offline at once, and section 11 says when its data is removed from Cloudflare. A record an app deletes is gone from its live database straight away, and the app can no longer read it. It stays in that database's point-in-time history for up to 30 days, and is then gone for good (Annex 2).
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. 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, saying 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 lets you answer most requests yourself, including requests for access and correction under the PDPA. 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, but 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. We don't charge for it unless the effort is disproportionate, and then 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.
For customer data the PDPA covers, we notify you without undue delay from the time we have credible grounds to believe the breach has occurred, as section 26C of the PDPA requires of a data intermediary. We don't wait until we have confirmed it.
You then have your own duties under the PDPA. You assess whether the breach is notifiable. If it is, you notify the PDPC within 3 calendar days of that assessment, and notify the affected individuals where it is likely to cause them significant harm. We cooperate with you and give you the information you reasonably need to meet those duties, and the same duties under other data protection law. 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 exports as one JSON document, with its configuration, members, grants, the names of its tokens, secrets and environment variables, and the retained audit log. Each app's database exports as SQL. A static site is the files you uploaded.
When you delete an app or a workspace, it is taken offline at once. We may keep it, with its data, for up to 30 days so that it can be restored on your instruction, and then delete it for good. You can have it deleted for good sooner at any time. A workspace we close is not kept, and nor is a deleted workspace whose last owner deletes their account. Deletion for good is immediate and permanent. The apps' 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, including the one that records the deletion, 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, and they are never restored. The control-plane database's restore history 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, for as long as it requires, and protect it as confidential. Examples are billing records, and a workspace's data after a report to the authorities or a request from them to preserve it. While the law requires us to keep a workspace's data, it and its apps can't be deleted. This is how we meet the retention limitation the PDPA sets for us as your data intermediary.
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 by an independent auditor you appoint who is bound by confidentiality and is not a competitor of ours. An audit may take place no more than once a year, unless a supervisory authority requires one or it follows a breach. It needs at least 30 days' written notice, takes place during business hours, must not disrupt the Service or expose other customers' data, and is 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 personal data the PDPA covers is transferred out of Singapore, we and each subprocessor protect it as section 26 of the PDPA and Part 3 of the Personal Data Protection Regulations 2021 require. Each recipient is bound by legally enforceable contractual obligations to give the data a standard of protection comparable to the PDPA.
Where the transfer involves personal data protected by the GDPR, the UK GDPR or the Swiss FADP, going 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 you as data exporter and Assessly Pte. Ltd. as data importer, and 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 13 and Annex I.C: the supervisory authority of the EU member state where you are established, or, if you are not established in the EU, where your Article 27 representative is, or else the Irish Data Protection Commission
- Clause 17 governed by the law of Ireland, and for Clause 18, the courts of Ireland
- Annex I completed by Annex 1 and Annex 3 of this DPA, and Annex II by Annex 2
- Between us and each subprocessor, we have the SCCs or another lawful transfer mechanism in place. We 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. Liability under this DPA and under the Terms counts toward a single cap. A limitation doesn't apply where, and as far as, data protection law does not allow it. Nothing in this section limits the rights of data subjects under the SCCs.
15. Term and precedence
This DPA lasts as long as we process customer data for you. Sections 5, 11 and 14 still apply after it ends. 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 the Terms describe. A change that reduces your protection needs your agreement.
This DPA is governed by the laws of Singapore, except the SCCs, which are governed as Clause 17 says.
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, and a further 30 days for the control plane's records of it. |
| Nature and purpose | Storing and running the Customer's code and data. Authenticating the people the Customer shares apps with, through the Customer's own identity provider where it has one, and passing their identity to the app. Adding and removing workspace members as the Customer's identity provider tells us over SCIM. 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. Sending the lines the Customer's apps write to their logs to a destination the Customer sets up (a log drain), on the Customer's instruction. To measure CPU time for billing, the platform briefly receives each invocation's execution record from Cloudflare. The record contains the request's headers, including the identity token the platform issued for the request, its URL and the app's logs. The platform keeps only the CPU time and which app it was. |
| Categories of data subjects | The Customer's staff and contractors who are workspace members. The people the Customer shares apps with, typically colleagues, contractors and 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. What the Customer's identity provider sends over SCIM: the provider's id for a person, their name, given name and family name, whether they are active, and their groups. Sign-in and request metadata: IP address, user agent, country, timestamps, paths and 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. The exceptions are 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. Request headers, URLs and application log lines contained in execution records, received transiently and not stored. The lines the Customer's apps write to their logs, which Cloudflare keeps for 7 days, and which the platform holds for a log drain until they are sent, for at most 7 days. Whatever the Customer's apps store, which the Customer decides. 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. Nor is it designed for protected health information as HIPAA defines it, or for payment card details such as card numbers, expiry dates or security codes, and the Customer must not use it for either. We sign no business associate agreement. |
| Frequency | Continuous, for as long as the workspace exists. |
| Retention | As set out in section 11 and in the Privacy Policy. The audit log is kept for 3 months on Free and Team, or 12 months on Business and Enterprise, and deleted within two days after that. After any change of plan, events older than the new plan's retention are deleted 30 days after the plan changed. App logs are kept by Cloudflare for 7 days, and can be read back for 1 day on Free and 7 days on Team, Business and Enterprise. Log lines held for a log drain are deleted once sent, or after 7 days if they could not be. |
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, by 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 and Neon. Most audit-log entries older than 30 days are moved to an archive, and are also encrypted with a key specific to the workspace before they are stored there.
- Customer secrets, meaning third-party credentials and webhook signing secrets, are additionally encrypted with a platform key before storage, and are never shown back to a person. 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. Environment variables are not secrets: their values are stored as the Customer sets them, and anyone who can edit the application can read them.
- 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 owners and admins 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 before it is deployed, including the adversarial authentication cases and the cross-tenant isolation tests. It then goes through a staging deployment and its checks before production, with no exception.
- 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. The restore window is up to 7 days, 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. 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. A workspace owner can put the database back as it was at a moment in that history, on your instruction. Nothing else restores from it.
- We have a Data Protection Officer, who can be reached at dpo@forculuslabs.tech.
- 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, the control plane, audit queue, audit-log archive | Requests on the global edge. The control plane in the Asia-Pacific region. The audit-log archive in R2, which Cloudflare is asked to keep in the Asia-Pacific region. Each app's database and files in the Cloudflare region nearest where the person who created the app was, as a hint Cloudflare follows where it can. They stay where they were made |
| Neon, LLC | The control-plane database (Postgres) | AWS ap-southeast-1 (Singapore) |
| Plus Five Five, Inc. (Resend) | Transactional email: sign-in codes, invitations, notices to workspace owners, and alerts to our own staff | Sent from ap-northeast-1 (Tokyo), Japan. Also processed in the United States |
| Proton AG | Our own mailboxes: the email you send us and our answers | Switzerland, Germany or Norway |
Stripe is not on this list. It processes only billing data, which we hold as controller, and no customer data. The Subprocessors page names it.