Privacy & data handling

Kiln is an orchestration layer. We do not own or sell a contact database. When you enrich a row, Kiln calls data providers you have chosen — using your own API keys where you have supplied them — and stores the result in your workspace alongside a record of which provider supplied it, what it cost, and when.

That means for most customer data we act as a processor: you decide who to enrich and why, and we carry out that instruction. You are the controller of the B2B contact data in your tables.

Only from official, licensed provider APIs. Every provider in the catalog carries a published compliance scorecard in the product showing its data sourcing, lawful basis, certifications, data residency and opt-out route, so you can see the posture of each vendor rather than a single blanket badge.

We do not scrape LinkedIn or any other login-gated consumer platform. Public-data scraping of that kind sits in a genuine legal grey zone — hiQ v. LinkedIn ended in a breach-of-contract judgment against the scraper even after the CFAA claim failed — and it is not a risk we will put our customers behind. If a data source is only reachable by violating a platform's terms, we skip it and flag it instead of integrating it.

For B2B contact data in the EU/UK, the usual basis is legitimate interest. That basis is not automatic: it requires you to run and document a balancing test for your own outreach. Kiln helps by recording, per cell, which provider supplied the value and what that provider's documented consent basis is.

We practise data minimisation: enrichment columns return the specific field you asked for (a work email, a job title, a firmographic band) rather than a full personal profile. For EU-heavy lists, the built-in GDPR-first template uses only providers that derive addresses algorithmically instead of holding a contact database.

Individuals can request access, erasure, or opt-out from the workspace that holds their data. Inside Kiln, the workspace owner handles these from Operations → Privacy, or programmatically via POST /api/privacy/requests.

• Access returns every cell in the workspace that mentions the subject, with the table and row it sits in.
• Erasure redacts those cells, deletes the provenance rows that quote the value (leaving them would defeat the erasure), and clears any cached provider payload containing it.
• Opt-out adds the address or domain to the workspace suppression list.

Suppression is enforced before a provider is called, not at export time. A suppressed person is never looked up again, so the request stops the processing and the spend, not just the visible output.

Enriched values live in your workspace until you delete them or their row. Cached provider results expire automatically on a per-category schedule — 3 days for intent signals, 14 for technographics, 30 for contact data, 90 for firmographics — after which the data is re-fetched or dropped.

Decay policies let you go further: mark a column stale after N days and Kiln will flag or automatically re-source it, so you are not sending to an address that stopped working eight months ago.

• Provider API keys are encrypted at rest with AES-256-GCM and are never returned to the browser after saving — the UI only ever shows the last four characters.
• Kiln API keys are stored as SHA-256 hashes; the plaintext is shown once at creation and is unrecoverable afterwards.
• Every API key carries its own scopes and its own monthly credit ceiling, so a key given to an automation or an AI assistant cannot spend the whole balance.
• Every table that holds customer data carries an organization id, and every query is scoped by it.

AI columns send the row context you reference in the prompt to the configured model provider. Nothing else from your workspace is sent. Free sample runs are served from a local result cache, so testing a prompt does not repeatedly transmit the same data — or repeatedly bill you for it.

The providers you enable are sub-processors for the data you send them. Because Kiln is BYOK-first, in many cases your relationship with that vendor is direct and governed by your own contract with them. The in-product compliance scorecard lists each provider's residency and certifications so your register can be accurate.

Separately, these are the platform sub-processors every Kiln workspace relies on, regardless of which data providers you enable. A vendor review can copy this table straight into a register.

We will update this list before adding a new platform sub-processor. If your contract requires notice of a change, tell us and we will email you directly rather than expecting you to poll this page.

Privacy questions and data-subject requests: privacy@kiln.example. We aim to respond within 30 days, which is the GDPR ceiling rather than a target.