Data processing agreement
Part of the agreement between Born and the customer. It sets out how Born handles personal data that the customer puts into Born.
Parties
Customer (controller): Company name, Company number, Address.
Born (processor): [Company legal name], [Company number], [Registered address], [Country].
1. What this covers
- Subject: Born stores and processes personal data on the customer's behalf to provide the Born service under the main agreement and the terms of service.
- Duration: as long as the main agreement, plus the time needed to return or delete the data (clause 8).
- Nature and purpose: storing, organizing, searching and displaying customer content; drafting and checking with AI models; sending notification emails; sharing with the agencies the customer chooses.
- Data subjects: the customer's staff and the agency staff they invite; people named in the customer's content (for example contacts, customers in research).
- Categories of data: names, work email addresses, roles; content the customer uploads or writes, which may contain personal data. Born is not designed for special categories of data, and the customer agrees not to upload them.
2. Born's obligations
- Process personal data only on the customer's documented instructions - the main agreement, this DPA and the customer's use of Born's features are those instructions - and tell the customer if an instruction seems to break data protection law.
- Make sure everyone with access is bound by confidentiality.
- Keep the security measures in Annex 2 in place, and improve them over time, never weaken them.
- Help the customer respond to requests from data subjects, and with security, breach notification, impact assessments and consultations, as far as Born's role allows.
3. Sub-processors
The customer authorizes the sub-processors in Annex 1. Born tells the customer at least 30 days before adding or replacing one; the customer may object on reasonable data protection grounds, and if it can't be resolved, end the affected service. Born puts the same data protection obligations on each sub-processor and remains responsible for them.
4. Transfers outside the EEA
Where a sub-processor processes personal data outside the EEA, Born makes sure the transfer is covered by an adequacy decision (such as the EU-US Data Privacy Framework for certified companies) or the EU standard contractual clauses, with supplementary measures where needed.
5. Personal data breaches
Born tells the customer without undue delay, and within 48 hours of becoming aware, of a personal data breach affecting the customer's data - with what's known, what's being done, and a contact - and keeps the customer updated.
6. Audits
Born gives the customer the information needed to show compliance with this DPA, and allows reasonable audits on 30 days' notice, at most once a year unless a breach or regulator requires more, carried out so as not to expose other customers' data.
7. AI models
Content sent to AI providers is used only to produce the answer for that request. The providers in Annex 1 do not use it to train their models.
8. End of the service
A customer admin can download all the customer's data from Settings at any time. When the main agreement ends, Born deletes the customer's personal data within 30 days, unless the law requires it to be kept.
9. Liability and precedence
Liability under this DPA follows the main agreement. If this DPA and the main agreement conflict on personal data, this DPA wins. Governed by [Governing law, e.g. the laws of Lithuania].
Annex 1 - Sub-processors
Supabase ([Supabase region, e.g. EU (Frankfurt)]) - Database, file storage and sign-in. Receives: Everything stored in Born: account details, brand knowledge, uploaded files, briefs, projects and their history.
Vercel (EU (Dublin) for the application; global network for delivery) - Runs the Born application and its scheduled jobs. Receives: Everything passing between your browser and Born while you use it; cookie-free, anonymous page-view counts.
Anthropic (United States) - The AI model (Claude) behind briefs, answers, lessons and asset checks. Receives: The text and images Born sends with each request: the brief being written, relevant brand knowledge and file passages, uploaded creative under review.
DeepInfra (United States) - Search fingerprints (embeddings) and relevance checks for finding past work. Receives: Short passages of text from briefs, lessons and imported files.
Firecrawl (United States) - Reading a website when you ask Born to scan one. Receives: Only the web address you give it; it returns that public page's text.
Resend (United States) - Sending Born's emails (invitations, notifications, password resets). Receives: Recipient name and email address, and the text of the email.
Sentry (EU) - Error monitoring, so problems are fixed before you report them. Receives: Technical error reports tagged with an organization and user id only - no request contents, cookies, addresses or file contents.
Annex 2 - Security measures
- Encryption: all traffic over TLS; data and files encrypted at rest by the hosting providers.
- Separation: every organization's data is separated by row-level security in the database itself, not only by application code. Automated isolation tests sign in as different organizations and check that nothing crosses over; they run on every change to access rules.
- Least access: agencies see only what a brand shares; sensitive brand-only fields are readable by the server alone; admin-only actions are checked on the server.
- Files: uploads are checked against their real file type before they're accepted; files are stored privately and shared only through short-lived links.
- Abuse limits: per-person and per-visitor rate limits on expensive and public actions, and a monthly AI usage cap per organization.
- Monitoring: error monitoring with private data removed before it leaves Born (no request contents, cookies or addresses).
- Records: an append-only audit log of admin actions, and an activity log on every project that can't be edited or deleted.
- Environments: a separate test environment with test data only; changes are tried there before production.
- Accounts: passwords are hashed by the sign-in provider; invitation links are single-use, expire after 14 days and are stored only as a hash.
Signatures
Customer
Name:
Title:
Date:
[Company legal name]
Name:
Title:
Date: