Data Processing Agreement

This page describes how Keyfren actually works today, in plain language rather than legal language. It is not a substitute for legal advice.

This Data Processing Agreement ("DPA") is between Keyfren ("Processor", "we") and [Customer legal name] ("Customer", "Controller"), and applies for as long as Customer has a Keyfren account. It supplements, and is incorporated into, the Terms of Service Customer already agreed to by using Keyfren — it does not replace them.

Customer is the Controller of personal data processed through its Keyfren account: Customer decides who its users are, what contacts and communications they record, and why. Keyfren is the Processor, running the software Customer's users use and processing data strictly as instructed by Customer through its use of the product.

Where GDPR does not apply to Customer directly, the parties still intend for the substance of this DPA, in particular the security, sub-processor, and deletion commitments, to apply as a matter of contract.

Subject matter: hosting and operating the Keyfren service for Customer's account, including the underlying database, application server, and the integrations Customer's users choose to connect.

Duration: for as long as the Customer account is open, plus whatever period Keyfren retains data after closure under the deletion terms below.

Nature and purpose of processing: storing and displaying contact records, messages, emails, and calendar events that Customer's users add or connect; ranking and surfacing which contacts are worth reaching out to; and, where a user connects Gmail or Google Calendar, reading (never modifying) that data to build the same contact history automatically. Full detail is in the Privacy Policy, which this DPA does not restate but does not contradict.

Categories of data subjects: Customer's own users (its employees or team members with a Keyfren login), and the contacts those users record, people who have their own relationship with a Customer user but who never signed up for Keyfren themselves and never interact with it directly.

Categories of personal data: names, email addresses, phone numbers, notes, tags, message and email content, and calendar event details, exactly as described in the Privacy Policy's "What we store" and "What we take from Gmail and Google Calendar" sections.

Keyfren processes personal data only on Customer's documented instructions, which for a self-serve product means: as necessary to provide the features Customer's users actually use. Keyfren does not use Customer's data for its own purposes, does not sell it, and does not use it to train any model.

Everyone with any access to production data, in practice, the founder and any future engineer, is bound to keep it confidential.

Keyfren will assist Customer in responding to a data subject access, correction, or deletion request concerning a person in Customer's account. In practice this is often unnecessary: every Keyfren account already has a self-serve "Download my data" export and a "Delete account" action that a Customer user can use directly, covering the most common requests without needing to come through Keyfren at all.

Keyfren will notify Customer without undue delay after becoming aware of a personal data breach affecting Customer's account, and will provide what is known at the time rather than waiting for a complete picture before saying anything.

Password hashes use bcrypt; the password itself is never stored. OAuth access and refresh tokens (for a connected Google account) are encrypted at rest with AES-256-GCM, using a key held separately from the database.

Tenant isolation is enforced at the database level through row-level security, not only in application code, so one customer's account cannot read another's data through an application bug.

Account deletion is real and immediate, not a soft flag: deleting an account removes the row and cascades to every table that references it, contacts, messages, emails, calendar events, shares, and stored tokens, through database foreign-key constraints, not application logic that could be skipped.

What is not yet in place, stated plainly rather than left implied: no independent security audit or certification (SOC 2, ISO 27001) has been completed. For a company at this stage, that is normal, but it is Customer's decision whether that is acceptable for its use case, not Keyfren's to minimise.

Keyfren uses the following sub-processors to operate the service. Each is used strictly to provide part of the Keyfren infrastructure, not for any independent purpose of its own:

• Neon (database hosting, PostgreSQL) — stores all application data described above.

• Render (application server hosting) — runs the Keyfren API that Customer's users' devices talk to.

• Resend (transactional email) — sends account emails such as password resets and verification links. Does not receive contact or message data.

• PostHog (analytics and error monitoring) — receives page-view and device information only when a user has opted into analytics, and receives technical error details (never contact or message content) when the server encounters an unexpected error, regardless of that opt-in. See the Privacy Policy's "Who else can see it" section for the full split.

Keyfren will give Customer at least [30] days' notice before adding or replacing a sub-processor with access to Customer's data, during which Customer may object on reasonable data-protection grounds. This DPA does not yet specify what happens if the parties cannot resolve an objection, that mechanism needs to be agreed with an actual counterparty, not assumed here.

Neon's database and Render's application server are both hosted in the United States. Keyfren itself operates out of Panama City, Panama. If Customer or its users are in the EU, UK, or another jurisdiction with rules about moving personal data across borders, this means Customer's data leaves that region to be processed.

Keyfren has not yet put a formal transfer mechanism, such as the EU Standard Contractual Clauses, in place with its hosting providers. This is the single most important gap in this document for any Customer where that matters, and it is the first thing that needs resolving, with Neon and Render directly and with a lawyer's input, before this DPA could be relied on by a Customer with real EU transfer obligations.

On termination of Customer's account, or on request at any time before then, Customer can delete its own account and data immediately through Settings, no waiting on Keyfren to process anything.

Customer can export a complete copy of everything Keyfren holds for its account, profile, contacts, messages, emails, calendar events, and integration settings, at any time before deletion, through the same "Download my data" feature described in the Privacy Policy.

Customer may request reasonable information about Keyfren's security and data-handling practices to verify compliance with this DPA. Given Keyfren's size today, that is realistically a written questionnaire or a call rather than an on-site audit, formal on-site or third-party audit rights are the kind of term that gets negotiated once a real Customer is at the table, not decided unilaterally in a template.

This is a template drafted to describe what Keyfren actually does today, the same standard the Privacy Policy and Terms hold themselves to. It has not been reviewed by a lawyer, and it is not a substitute for legal advice for either party.

It is not yet an executed agreement. Fields in brackets need to be filled in and agreed with a specific counterparty, and the international-transfer gap above needs a real answer before this should be relied on for a customer with strict transfer requirements.

Questions about this document: support@keyfren.com.