Data Processing Agreement

Draft — not yet in force

This is a draft prepared by Build Remote and it has not been reviewed by a lawyer. It is written to carry the terms that Article 28(3) of the UK and EU GDPR and the CCPA’s service-provider definition require, but wanting to carry them and carrying them are different things, and only a qualified data protection lawyer can tell you which this is. It should be reviewed end to end, and the open questions in Annex D settled, before it is offered to a client as binding.

If you are a client reading this before that review: it tells you accurately what we do with your customers’ data today. It is the commitment we intend to be held to.

1 · Who is who

You are the controller of your customers’ personal data — in California terms, the business. You decide why it is collected and what happens to it. We are your processor, or service provider: we hold it and show it back to you, and we act on your instructions.

This agreement forms part of the Terms and applies for as long as you have an account. Where it and the Terms disagree about personal data, this page wins.

Your own account details — your name, your business, your email, your billing — are a different matter. We are the controller for those, and the privacy page covers them.

You agree to this when you add a card, which is what the card page says. We record which version of each document you agreed to and when, you can see that record in Billing, and neither you nor we can edit it afterwards.

2 · We act on your instructions, and only those

We process your customers’ personal data only on your documented instructions. Your instructions are the Terms, this agreement, and whatever you do in your console — turning on a chat widget, connecting a CRM, exporting your enquiries, asking us to delete one.

If we think an instruction breaks data protection law, we will tell you and not act on it until you confirm. We would rather have that conversation than carry it out.

3 · What we will never do with it

These are the commitments the CCPA requires a service provider to make, and we make them:

• We never sell it and we never share it for cross-context behavioural advertising. Not for money, not for anything else of value.
• We never use it for our own purposes — not to market to your customers, not to build a product, not to train a model.
• We never combine it with personal information we receive from anywhere else, or from another client.
• We never keep, use or hand on any of it outside our direct relationship with you, except where the law requires it of us.

We understand these restrictions and we will comply with them. If we ever cannot, we will tell you promptly, and you may stop and put right any unauthorised use.

4 · Who can see it

Each business reads only its own enquiries, and that is enforced by the database rather than by our good intentions — see Annex C. Our own staff can reach client data only where supporting you needs it. Everyone who can is bound to keep it confidential, and that duty outlasts their working for us.

5 · Keeping it safe

We apply the measures set out in Annex C, which describes what is actually built rather than what would sound reassuring. We review them as the product changes, and we will not weaken them during your subscription.

6 · The companies we rely on

Running this service means using other companies — for hosting, for the database, for sending email. Annex B lists every one that can touch your customers’ data, and what each is for. You agree to the ones listed there.

If we add or replace one, we will tell you by email at least 30 days beforehand, and you may object. If you object and we cannot offer a reasonable alternative, you may cancel without penalty and we will refund any unused part of the month. Each of them is bound by terms no weaker than these, and if one of them mishandles your data, that is our responsibility to you, not theirs.

7 · When one of your customers exercises a right

Someone who contacted you can ask you to show them what you hold, correct it, or delete it. Answering is your obligation, not ours — but you cannot answer without us, so we will help.

Tell us and we will delete a single enquiry, or produce everything we hold about one person, and confirm when it is done. If one of your customers contacts us directly we will not answer for you; we will point them to you and let you know.

Write to privacy@build-remote.com. We aim to come back within three working days, which leaves you room inside the 30 days the UK and EU allow and the 45 days California allows.

8 · If something goes wrong

If personal data we hold for you is lost, exposed or reached by someone who should not have reached it, we will tell you without undue delay and in any case within 48 hours of becoming aware. Reporting it to a regulator is your call to make, and the clock on that is 72 hours, so ours has to be shorter — telling you at hour 71 would honour a promise and leave you an hour to do something that takes a day.

Nobody is yet named to answer this out of hours. The procedure is written (docs/incident-response.md) and the roles are defined, but the rota is empty — so this commitment is one we intend and have not yet staffed. It is listed in Annex D rather than left for you to discover.

We will tell you what happened, which data and roughly how many people are affected, what it is likely to mean, and what we have done — and we will keep telling you as we learn more, rather than waiting until we have a complete story.

9 · Helping you meet your own obligations

If you have to carry out a data protection impact assessment, consult a regulator, or demonstrate that your processing is secure, we will give you the information you need. You should not have to reverse-engineer your own supplier to answer a regulator.

10 · Getting it back, and getting rid of it

You can export your enquiries and your site’s content at any time while you have an account, and we will help if the export does not cover what you need.

When you leave, tell us whether you want your data returned or deleted. If you say nothing, we delete it 30 days after the account closes — long enough to change your mind, short enough that we are not sitting on other people’s data for no reason. Backups age out within a further 30 days. We keep only what the law makes us keep, such as billing records.

11 · Checking that we do this

You may ask us to show that we are meeting this agreement, and we will answer with what we have: this document, Annex C, and specific answers to specific questions. Once in any twelve months you may ask for an audit, on 30 days’ notice, during working hours, and without disturbing other clients’ data.

We are a small company and we are not going to pretend otherwise: there is no SOC 2 report and no third-party penetration test yet. Saying so is more useful to you than a certificate we do not hold.

12 · Where the data lives

Our hosting, database and email providers are US companies. Where each one physically processes your customers’ data:

• Supabase — The database, sign-in, and stored photos: region not yet confirmed
• Vercel — Hosting, and server logs that briefly contain visitor IP addresses: United States — iad1 (Washington, D.C.) (confirmed 2026-09-22)
• Resend — The emails the portal sends: United States (confirmed 2026-09-22)
• Upstash — Rate limiting; holds a visitor's IP address for minutes: region not yet confirmed

We serve businesses in the United States only. Moving personal data out of the UK or the EEA needs a specific legal mechanism, and rather than claim one we have not put in place, we do not take clients there. Restricting who we serve is the mechanism.

If your business is in the UK or the EEA, or a meaningful number of your customers are, tell us before you sign up — this agreement is not written for that and we would rather say so now than discover it later. The reasoning, and what it would take to change, is in docs/international-transfers.md.

13 · Changes

If we change this agreement in a way that affects you, you hear about it by email at least 30 days before it applies — the same notice we give for a price change. If a change makes things worse for you, you may cancel without penalty.

The processing

Subject matter. Running your website and console.
Duration. As long as you have an account, plus the deletion window in clause 10.
Nature and purpose. Receiving enquiries from your website, storing them so they cannot be lost, showing them to you, and passing them to a CRM if you have connected one.

Whose data, and what

Your customers and enquirers: name, email address, phone number, the service they asked about, the message they wrote, which page they were on, and when. Plus the SMS consent wording they were shown and the moment they accepted it, which exists so that you can evidence consent if you are ever asked to.

Your job applicants, where you use the careers page: whatever they put in the application.

Visitors to your website: IP addresses, briefly, to stop automated abuse flooding your forms.

We do not ask for and have no use for government identifiers, financial account numbers, health data, biometrics or precise location. If a customer volunteers something like that in a message it sits in the message; please do not build a process that collects it.

Sub-processors

• Supabase — the database your enquiries live in, the sign-in system, and the private store for photos you send the team. United States.
• Vercel — hosting for your website and the portal. Its server logs briefly contain visitor IP addresses. United States.
• Resend — the emails the portal sends you, and the review requests it sends your customers when you turn them on (their name and email address). United States.
• Upstash — the rate limiter that stops bots flooding your forms; holds a visitor’s IP address for minutes. United States.

Not sub-processors, and why that matters

Whop handles payments. Card details go straight to Whop and never pass through this site or our database. Whop decides how it handles that data for its own payment, fraud and compliance duties, so it is not processing on our instructions.

Your CRM or chat provider — GoHighLevel, or whatever you connect — is normally your own account and your own processor, not ours. When you connect it you are instructing us to send your enquiries there, and what happens to them afterwards is between you and that provider. Worth knowing: it means you may need your own agreement with them.

GitHub holds your site’s content and configuration — the words and pictures on your pages, which are yours but are not personal data about your customers.

Separation between businesses

Every table carrying client data has row-level security enabled and forced, so the rule applies even to the table’s owner. A signed-in session can read only the rows belonging to businesses it is attached to. This is a database rule, not a filter in application code that a missing where clause could defeat.

Enquiries cannot be forged or quietly erased

The enquiry table grants a browser session no insert and no delete policy at all. An owner can mark how they have dealt with an enquiry; nobody using the portal — including us — can edit what the person actually wrote. A record of a conversation that can be rewritten is not a record.

Credentials and cards

Passwords are hashed by our authentication provider and are never visible to us. Card details never reach our servers. The keys that let our own backend bypass row-level security live in the environment, never in the code, and are never written to a log.

Photos

Photos you send the team are kept in a private store, not a public one — there is no address anyone could guess to reach them. They are used on your site and nowhere else, and we keep a record of where each came from and that you confirmed it was yours to use.

An audit log that cannot be tidied

Reserved actions are written to an append-only log with a database trigger guarding what may be inserted and by whom. You can read it; nobody can edit it.

On your website itself

Forms are rate-limited by IP and carry a honeypot. Fonts are served from your own domain rather than fetched from Google, so no third party learns about a visit that way. A chat widget loads only after the visitor is told who provides it and accepts — nothing third-party runs before that.

Open questions

Listed rather than glossed, because these are the parts a regulator or a client’s lawyer will ask about first, and a confident answer we have not earned would be worse than none.

• Serving the UK or EEA would need work nobody has done. The US-only restriction in clause 12 is now enforced — sign-up refuses a business outside the United States, and the database will not store one — so the restriction is the mechanism and it holds. Widening it is the open part: it would need Standard Contractual Clauses or a verified Data Privacy Framework certification for every provider in Annex B, and a transfer impact assessment each. None of that exists, and none of it is worth doing until a client is actually asking.
• Two providers’ regions are still unconfirmed. Clause 12 names them. Vercel was verified against the live deployment and Resend against its own agreement, but Supabase and Upstash need somebody with a login — nothing outside can see either. For Upstash the first question is whether it is used at all; if it is not, it should come off these lists rather than be given a region.
• The 48-hour breach commitment is not yet staffed. The written procedure now exists (docs/incident-response.md) and the three roles are defined, but nobody is named to them and there is no out-of-hours route. Naming them is a decision about who actually picks up at 2am, and until somebody makes it this page will keep saying so.
• The privacy inbox has to exist. privacy@build-remote.com is printed in clauses 7 and 8. An address in a contract that bounces is worse than no address, because whoever writes to it believes they have told us.