Skip to content

Data processing addendum.

How we process personal data for you, as your processor.

Effective: November 6, 2026

This data processing addendum ("DPA") is part of the terms of service between The Obelisk App Inc., a Delaware corporation ("Obelisk", "we"), and the customer that agreed to those terms ("Customer", "you"). It applies automatically whenever Obelisk processes Customer Personal Data, with no signature needed. If you need a countersigned copy, email legal@theobelisk.app.

1. Definitions

  • Data Protection Laws means every law on personal data that applies to the processing under this DPA, including the EU General Data Protection Regulation 2016/679 ("GDPR"), the GDPR as it forms part of UK law ("UK GDPR") and the UK Data Protection Act 2018, the Swiss Federal Act on Data Protection ("FADP"), and US state privacy laws such as the California Consumer Privacy Act as amended by the California Privacy Rights Act ("CCPA").
  • Customer Personal Data means personal data that Obelisk processes for Customer as a processor while providing the service. It includes data collected by the Obelisk tracking script on Customer's websites, leads and deals, uploaded documents, chat messages, the business brain, email recipients, and data Obelisk reads from services Customer connects.
  • Subprocessor means a company Obelisk engages to process Customer Personal Data.
  • Security Incident means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.
  • SCCs means the standard contractual clauses approved by the European Commission in Decision 2021/914. UK Addendum means the International Data Transfer Addendum to the SCCs issued by the UK Information Commissioner (version B1.0).
  • "Controller", "processor", "data subject", "personal data", "processing" and "supervisory authority" have the meanings given in the GDPR. "Business", "service provider", "contractor", "sell" and "share" have the meanings given in the CCPA.

2. Roles

  • Customer is the controller of Customer Personal Data and Obelisk is its processor. Under the CCPA, Customer is the business and Obelisk is its service provider.
  • Agencies. If Customer uses Obelisk for its own clients, Customer may act as a processor for those clients. Obelisk is then Customer's subprocessor. Customer confirms that its clients have authorised it to use Obelisk and to give Obelisk the instructions in this DPA, and Customer remains Obelisk's only point of contact.
  • Where Obelisk is a controller. Obelisk is an independent controller for account and sign-in data, billing records, security and abuse-prevention data, and service usage data, as our privacy policy describes. This DPA doesn't cover that data.
  • Annex 1 describes the processing.

3. Customer's responsibilities

Customer:

  • Has a lawful basis for the processing it asks Obelisk to do, and gives data subjects every notice the law requires, including a description of Obelisk tracking in its own privacy policy. Obelisk publishes wording Customer can use.
  • Shows a cookie banner and gets consent wherever the law requires it before Obelisk tracking sets cookies or collects contact details. Obelisk's built-in banner can do this.
  • Maps only email and name fields for lead capture and doesn't send special category data, children's data, payment card data or government ID numbers through the tracking script, identify(), custom events, uploads or connected services, unless the law allows it and Obelisk needs it for a task Customer asked for.
  • Chooses which agent actions to approve and which actions autopilot may take, and is responsible for the instructions those choices give.

4. Obelisk's obligations

Obelisk:

  1. Follows Customer's instructions. Obelisk processes Customer Personal Data only on Customer's documented instructions, unless the law requires otherwise, in which case Obelisk tells Customer first unless the law forbids it. The terms, this DPA, and Customer's use and configuration of Obelisk (including the actions Customer approves and its autopilot settings) are Customer's complete instructions. Obelisk tells Customer right away if it believes an instruction breaks Data Protection Laws.
  2. Keeps it confidential. Everyone at Obelisk who can access Customer Personal Data is bound by confidentiality, and only those who need access to provide, support or secure the service have it.
  3. Keeps it secure. Obelisk maintains the technical and organisational measures in Annex 2 and may improve them, but won't reduce the overall level of protection.
  4. Doesn't sell, share or reuse it. Obelisk doesn't sell or share Customer Personal Data, use it for advertising, use it to train AI models, or combine it with data from other customers or from its own sources, except as the CCPA allows a service provider to. Obelisk doesn't retain, use or disclose Customer Personal Data for any purpose other than providing the service under the terms, or outside its direct business relationship with Customer. Obelisk tells Customer if it can no longer meet its obligations under the CCPA, and Customer may then take reasonable steps to stop and fix unauthorised processing.
  5. Helps with data subject requests. Obelisk gives Customer tools to answer requests, including deleting a person and everything linked to them from Leads, deleting sites, documents and the account, and exporting audits. Obelisk exports a copy of Customer's data on request to privacy@theobelisk.app within 30 days. Where the tools aren't enough, Obelisk helps Customer answer requests to access, correct, delete, restrict, port or object, taking into account the nature of the processing. If a data subject contacts Obelisk directly about Customer Personal Data, Obelisk passes the request to Customer and doesn't answer it on its own, unless the law requires otherwise.
  6. Helps with compliance. Obelisk gives Customer reasonable help with data protection impact assessments, prior consultations with supervisory authorities and its security obligations, using the information available to Obelisk.
  7. Reports Security Incidents. Obelisk notifies Customer without undue delay, and within 48 hours, after becoming aware of a Security Incident affecting Customer Personal Data. The notice describes, as far as Obelisk knows at the time, what happened, the data and data subjects affected, likely consequences and the steps taken. Obelisk updates Customer as it learns more, takes reasonable steps to contain the incident and helps Customer meet its own notification duties. Notifying an incident is not an admission of fault.
  8. Deletes it at the end. Before deleting its account, Customer can ask for a copy of its data as item 5 describes. When Customer deletes its account, Obelisk deletes the Customer Personal Data in it after a 7-day grace period, and always within 30 days of the request. When Customer asks Obelisk to erase a single workspace, Obelisk does so within 30 days. Items Customer deletes in Obelisk, such as sites and documents, are permanently deleted 30 days after they go to the trash. Database backups roll over within 14 days, and a final backup taken when a database is shut down is kept for up to 90 days. Obelisk keeps data longer only where the law requires it, and then keeps it confidential and processes it only for that purpose.
  9. Shows its compliance. Obelisk makes available the information reasonably needed to demonstrate compliance with this DPA, including answers to security questionnaires and a summary of its security measures. If that isn't enough, or a supervisory authority requires it, Customer may audit Obelisk once a year, on at least 30 days' written notice, during business hours, at Customer's cost, without access to other customers' data, and under a confidentiality agreement. Customer may use an independent auditor who isn't a competitor of Obelisk.

5. Subprocessors

  • General authorisation. Customer authorises Obelisk to engage Subprocessors. The current list is on the subprocessors page.
  • Contracts. Obelisk engages each Subprocessor under a written contract with data protection obligations that are no less protective than this DPA, and remains liable to Customer for each Subprocessor's performance.
  • Notice of changes. Obelisk gives at least 30 days' notice before a new Subprocessor processes Customer Personal Data, by email to account owners and on the subprocessors page. In an emergency that threatens the security or availability of the service, Obelisk may replace a Subprocessor sooner and then tells Customer as soon as it can.
  • Objections. Customer may object on reasonable data protection grounds by emailing privacy@theobelisk.app within the notice period. The parties will discuss it in good faith. If Obelisk can't reasonably avoid using the new Subprocessor for Customer, Customer may end the affected service and receive a pro-rated refund of prepaid fees for the rest of the term.

6. International transfers

Obelisk stores Customer Personal Data in the United States (AWS us-east-1), and some Subprocessors process it in other countries. When a transfer from the European Economic Area, the UK or Switzerland to a country without an adequacy decision needs a safeguard:

  • EEA. The SCCs apply and are incorporated into this DPA: Module 2 (controller to processor) where Customer is a controller, and Module 3 (processor to processor) where Customer is a processor. For both: the optional clause 7 (docking) applies; in clause 9, option 2 (general authorisation) applies with the notice period in section 5; the optional wording in clause 11 doesn't apply; in clause 13, the supervisory authority is the one competent for Customer; in clause 17, the SCCs are governed by the laws of Ireland; in clause 18, disputes go to the courts of Ireland. Annexes I and II of the SCCs are completed by Annexes 1 and 2 of this DPA, and Annex III by the subprocessors page.
  • UK. The UK Addendum applies and is incorporated, completed with the information in the SCCs as set out above. In Table 4, both parties may end the UK Addendum as set out in its section 19.
  • Switzerland. The SCCs apply as above, with these changes: the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority for transfers governed by the FADP; references to the GDPR include the FADP; and "Member State" includes Switzerland so that data subjects there can bring claims where they live.
  • Obelisk ensures each Subprocessor that receives Customer Personal Data in a country without an adequacy decision is bound by the SCCs or another lawful transfer mechanism.
  • Government requests. If a public authority asks Obelisk for Customer Personal Data, Obelisk tells Customer unless the law forbids it, challenges requests it believes are unlawful, and discloses only the minimum the law requires.

7. Liability and precedence

  • Each party's liability under this DPA is subject to the limits in the terms, except where Data Protection Laws or the SCCs don't allow those limits.
  • If this DPA conflicts with the terms, this DPA wins on data protection matters. If it conflicts with the SCCs or the UK Addendum, those win.
  • This DPA ends when Obelisk stops processing Customer Personal Data.

Annex 1: Description of the processing

Data exporter: Customer, using the account details in Obelisk. Activities: using Obelisk to market its business or its clients' businesses. Role: controller or processor.

Data importer: The Obelisk App Inc., 131 Continental Dr, Suite 305, Newark, DE 19713, USA. Contact: privacy@theobelisk.app. Activities: providing the Obelisk marketing platform. Role: processor or subprocessor.

Categories of data subjects:

  • Visitors to Customer's websites that run Obelisk tracking.
  • Leads and customers of Customer who submit forms, are identified by Customer, or appear in its deals.
  • People who receive email from Customer's agents after confirming they want it.
  • Customer's team members, to the extent they appear in Customer's content.
  • People named in documents Customer uploads, chat messages, the business brain or data read from connected services.

Categories of personal data:

  • Tracking: a daily-changing visit code (no IP address stored), a random visitor ID after consent, pages viewed (address path and campaign tags), page titles, referrers, browser and operating system names, device type, browser language, scroll depth, outbound links, form submission events with field names, and the Google Analytics client ID if present and consented.
  • Leads and deals: email address, name, Customer's own customer ID, deal outcome and value, and the visits linked to them.
  • Email actions: recipient email addresses, consent records, message content and delivery records.
  • Content: any personal data in uploads, chat messages, brain facts, crawled pages and data read from or written to connected services (Google Search Console, Google Analytics, WordPress, GitHub, Slack, Linear, Jira).

Special categories: none intended. Customer must not send them (section 3).

Frequency: continuous, for as long as Customer uses Obelisk.

Nature of the processing: collection, storage, organisation, analysis, combination within Customer's own account, retrieval, use in AI tasks, transmission to services Customer connects, and erasure.

Purpose: providing Obelisk to Customer under the terms: tracking and attribution, lead records, reports, chat and agents, publishing and messages Customer approves or allows through autopilot, and support.

Retention: for as long as Customer keeps the data in Obelisk. Customer can delete a person, documents or its account at any time, and ask Obelisk to delete anything else; deleted data is erased as described in section 4, item 8. Obelisk deletes the daily random value used for cookieless counting each day.

Subprocessors: as listed on the subprocessors page, for the purposes stated there.

Annex 2: Technical and organisational measures

  • Encryption. All traffic to Obelisk uses TLS. The database, file storage and backups are encrypted at rest (AES-256). Connection tokens and passwords for connected services are additionally encrypted with versioned keys.
  • Tenant isolation. Every database query is scoped to the customer's organisation and workspace. Requests for another customer's data are answered as if it doesn't exist, and automated tests check this.
  • Access control. Roles (owner, admin, member) limit what each team member can do. Sign-in supports passkeys and emailed codes. Production access is limited to the people who need it.
  • Audit trail. Sign-ins, connections, keys and membership changes are written to an append-only log in which each entry is chained to the one before, so changes would show.
  • Agent safety. Agent actions on connected systems run only when a person approves them or when Customer's autopilot settings allow them, within listed actions, monthly caps and spending limits. Each action records what it changed so it can be undone where the connected service allows. Email waits 2 minutes before sending so it can be cancelled, goes only to confirmed recipients, and has per-workspace and per-recipient daily limits. Customer can pause all agents at once.
  • Network protection. The crawler and calls to customer websites leave through an egress proxy that blocks private network addresses. A web application firewall applies rate limits. Bot checks, rate limits and spending caps protect sign-up and free use.
  • Data minimisation. Logs and error reports carry IDs, counts and categories only, not page content, email addresses, tokens or full web addresses. The tracking script stores only the address path and campaign tags, never IP addresses, and never form values other than mapped email and name fields after consent.
  • Resilience. The main database is backed up automatically, with point-in-time recovery for up to 14 days, and backups are encrypted. Services run in managed containers that are replaced, not patched in place.
  • Development. Code changes are reviewed and pass automated tests, dependency checks and security checks before release. Production data isn't used for development or testing.
  • Incidents. Obelisk monitors errors and infrastructure health. Security Incidents are handled as section 4, item 7 describes.