DPA & Subprocessors

1. What this page is#

When you publish a website with KaiBuild, your visitors' data passes through our systems — most obviously when one of them fills in a contact form. You decide what that form asks and what you do with the answers. We hold it for you.

This page sets out that arrangement: what we process, why, for how long, who else touches it, what we have actually built to protect it, and what you can require of us. It applies to every customer, on every plan, without signing anything. A separately signed data processing agreement is available on request — write to [email protected] — and where one is signed, it governs over this page.

Related: Privacy Policy (your own data, where we decide) and Cookie Policy.

2. Roles#

• Your account and billing data — we decide why and how it is processed. GDPR calls that a controller; Indian law calls it a Data Fiduciary. Same role, different word.
• Data about your site's visitors, which you instruct us to process by publishing a site — you decide why and how, and we act on your instructions. GDPR calls us a processor; Indian law calls us a Data Processor.

The distinction matters in one practical way: when a visitor to your site asks about their data, that request is yours to answer, and we help you answer it. When you ask about your own account data, it is ours.

What you are responsible for. You decide what your forms collect, and you must have a lawful reason to collect it. You publish your own privacy notice to your visitors. You decide whether to collect anything sensitive — health, financial, biometric, or data about children — and if you do, that decision and its consequences are yours. Nothing here transfers your obligations to us.

3. Details of the processing#

Separately from form submissions, we count requests and bytes served per site so that plan limits can be enforced. Those are aggregate counters, not visitor records — no page, referrer, or identifier is kept against them.

Captcha on your forms is your relationship. If you turn on Turnstile or hCaptcha for your site's forms, you enter your own provider keys and your visitors' data goes to your account with that provider. Until you configure one, no captcha provider is called for your forms at all. We do not put our keys in front of your visitors.

4. Our commitments as processor#

• Instructions. We process visitor data only to provide the Service and on your documented instructions — which, in practice, are the choices you make in the product plus anything you put in writing to us. If an instruction looks unlawful to us, we will tell you rather than quietly comply.
• Confidentiality. Access is limited to the people who need it to run the Service, and they are bound to keep it confidential.
• Security. The measures in section 5, kept appropriate to the risk as the Service changes.
• Assistance with requests. Section 7.
• Incidents. We undertake to tell you without undue delay once we know a personal data breach has affected data we hold for you, with what we know: what happened, what data, and what we are doing. We give you the information you need for your own notification duties. We do not publish a fixed hour count, because a deadline we have not checked against the law that binds us would be a number rather than a promise.
• Subprocessors. Section 6 — the list, and how changes are notified.
• Deletion and return. Section 8.
• Audit. Section 9.

5. Security measures#

What follows is what the Service does today. We hold no security certification — no SOC 2, no ISO 27001 — and we do not imply one. If a certification matters to your procurement, say so before you buy rather than after.

• No passwords exist to be stolen. Sign-in is delegated entirely to Google; we never receive one.
• Session tokens are not reachable by page scripts, are sent only on same-site navigation, and are marked secure in production.
• Traffic is served over HTTPS between browsers and our origin.
• Visitor IP addresses are hashed with a secret salt before a form submission is written to storage. The stored value cannot be turned back into an address.
• Your captcha secret keys never leave the server. The public and secret halves of a site's captcha configuration are separated in code, and an automated test holds that separation in place so a future change cannot leak one.
• Site identifiers taken from a URL are sanitised before being used to locate stored data, so a crafted request cannot read or write another customer's files.
• Public form submissions are capped per IP per day, which is what makes the volume of an attack finite. A captcha raises the cost of a submission; only a cap bounds it.
• Administrative access is restricted to a privileged role, and support access to an account uses a signed token that expires after two hours and records who acted.
• Published sites cannot read the application session. Pages served for customer sites never run the code that reads a signed-in session, by design.

No method of transmission or storage is completely secure. These measures reduce risk; they do not remove it.

6. Subprocessors#

Effective as of the date at the top of this page. Each entry says what the provider is used for, because a name without a purpose tells you nothing about your exposure.

Our queues, databases, search index and agent tracing run on infrastructure we operate ourselves. They are not separate vendors and your data does not leave our systems to reach them.

Changing the list#

Before a new subprocessor starts handling data we hold for you, we will update this page and give notice in-product or by email. If you object on reasonable data-protection grounds, tell us within 15 days of the notice. We will try to offer an alternative; if we cannot, you may terminate the affected service and we will not treat that as a breach by you. Replacing a provider with an equivalent one, or adding one that touches nothing but our own infrastructure, does not restart that clock.

Every subprocessor is engaged under terms that impose obligations equivalent to ours, and we remain answerable to you for what they do with data we gave them.

7. Helping you answer your visitors#

A visitor to your site who wants their data — a copy, a correction, a deletion — is asking you, not us. What we do is make it possible for you to answer:

• Every submission for a site is visible in your inbox in the product, and exportable as CSV, so "what do you hold about me" is something you can answer without asking us.
• Where you need something the product does not yet do — deleting a single submission, or all of them for one email address — write to [email protected] and we will do it. We acknowledge within 24 hours and aim to complete within 15 days.
• If a visitor contacts us directly about your site, we will not answer on your behalf. We will pass it to you and tell them we have.
• We will give you the information you reasonably need for a data protection impact assessment or a regulator's enquiry about processing we carry out for you.
• If a public authority demands data we hold for you, we will tell you before disclosing it unless we are legally forbidden from doing so — and where we are forbidden, we will tell you as soon as we may.

8. Deletion and return#

• You can export at any time. Form submissions download as CSV from your inbox. That is the return mechanism, and it does not depend on your account being in good standing.
• Deleting a site removes its record, its published versions, its backups, the artifact we serve, and the transcript of your conversations with the agent about it.
• Deleting a site does not by itself clear stored form submissions. They are your business records and we do not silently destroy them. Ask us and we will delete them — for one site, one form, or everything.
• Cancelling a plan deletes nothing. Sites are paused and restorable — see Cancellation & Refunds. If you would rather we destroyed the data than held it paused, say so and we will.
• On termination, we delete or return the personal data we hold for you at your choice, except where we are required to keep something — billing records for tax, or material we must retain for a live legal claim or abuse investigation. Where we keep something for that reason, we will tell you what and why.

9. Audit#

You may ask us to demonstrate that we are doing what this page says. In practice that means: write to [email protected] with your questions, and we will answer them in writing, including how a particular measure in section 5 is implemented. We would rather answer a hard question than decline it.

An on-site inspection is available where your own regulator requires one, on reasonable notice, at a time that does not disrupt other customers, limited to what concerns your data, and subject to confidentiality. We may charge for our time on a repeat inspection in the same year where the first found nothing.

We have no third-party audit report to hand you, because we have not been audited. Saying so is more useful to your procurement than a page of adjectives.

10. International transfers#

We operate from India. The providers in section 6 operate in the United States, the EEA, the UK and elsewhere, so data we hold for you will cross borders.

Where the law applying to you requires a safeguard for that transfer — Standard Contractual Clauses, the UK Addendum, an adequacy finding, or an equivalent — we rely on the appropriate mechanism for each provider. Where your own rules restrict which countries a category of data may reach, tell us before you rely on the Service and we will tell you honestly whether we can meet it.

11. Contact#

Krushang Vachhiyat — [email protected], 3/2392, Salabatpura, Surat 395003, Gujarat, India.