Data Processing Agreement

This agreement covers the personal data Apex holds for you: the details of the people who contact your client's business. It does not cover the data Apex holds about you as our customer. Clause 1.3 says where that lives.

At a glance

1. Who this is between, and what it covers

1.1 The parties.This agreement is between Apex Discover LLC, a Wyoming limited liability company (“Apex”, “we”), and the organisation that holds the Apex account (“you”). It takes effect alongside the main agreement between us: the signed order form, statement of work or master services agreement, or where none is signed, our published Terms of Service(together, the “Main Agreement”).

1.2 Where you are an agency.Most of our customers are agencies who buy a seat per client business. In that case “your client” means the local business whose website the data comes from, and you confirm two things: that you are authorised to give the instructions in this agreement on that client's behalf, and that this agreement is entered into for that client's benefit as well as your own. The product asks you to confirm that authority by name, per client, every time you switch capture on. Clause 4 explains the record that creates.

1.3 What is out of scope. Apex is a controller, not a processor, for the data it holds about you: your name, your work email, your login, your billing details, and the email addresses of anyone you nominate to receive lead notifications. That is governed by our privacy policy, not by this agreement. The distinction matters because it decides who answers a request about that data, and the answer there is us, not you.

1.4 What is in scope. Everything else in this document concerns lead data: personal data about your client's own customers, described in clause 3.

2. Roles

For lead data:

• You are the controller. You decide what is collected, from which websites, for what purpose, and how long it is kept. Where you act as a processor for your own client, that client is the controller and you are their processor; this agreement then sits underneath yours with them.
• Apex is the processor. We hold and move the data to deliver the service you bought. We do not decide what is collected or why, and we do not use it for any purpose of our own.

Each of us is responsible for our own compliance with data protection law. We do not advise you on yours, and this agreement is not that advice.

3. What is processed

3.1 Subject matter and duration. The processing runs for as long as your Main Agreement runs, and ends when clause 11 is complete. Our retention statement, in the words that appear in our privacy policy and in our records of processing, is:

Retained for the life of the client relationship; deleted or returned on termination.

We do not delete your client's customer records on a timer, because they are your client's records and that is your client's decision, not ours.

3.2 Nature and purpose.To receive a lead submitted on your client's website, deliver it to the people you nominate, store it so you can work it, and record which AI assistant or search engine the visit is associated with. On the lead-capture pipeline, also which page the visitor landed on; forms on websites we host record no page. Nothing else.

3.3 Categories of data subject.End consumers: your client's own customers and prospective customers, being people who submit a form on a website you operate or that we host for you.

3.4 Categories of personal data.

Where we host your client's website, that site's own form also records the service requested and the service area, both free text.

How the referral source is worked out.The website keeps a small first-touch record in the visitor's own browser for up to 90 days: the tracking tags on the link they clicked and the name of the site they came from. It holds no name and no identifier for a person, it is first touch rather than last, so it is never overwritten once set, and it is not used to follow anyone across other websites. On websites we host it is a cookie scoped to that client's own pages; on the capture snippet it is browser storage and no cookie is set at all. The notice wording we supply discloses it in those terms.

3.5 The four fields, and what that guarantee is worth. The lead-capture pipeline accepts exactly four fields: name, email, phone and message. Anything else in the payload is discarded, and an unrecognised field at the top level rejects the whole submission. Our website snippet additionally refuses form fields whose names look like passwords, card numbers, government identifiers or tokens, and refuses any form containing a password input.

Say plainly what that does and does not do: it constrains the shape of a submission, not its contents. The snippet's field checks run in the visitor's browser. A message box can hold anything a person chooses to type. Clause 4 of the lead data addendum to our Terms of Service turns that into an obligation on you, and clause 12.3 below tells you what to say to a client in a regulated vertical.

3.6 The one place we record an IP address.When a lead arrives through the capture pipeline, we write one audit entry recording that the capture happened, and that entry carries the submitting device's IP address in full: not hashed, not truncated, not masked. Its purpose is abuse investigation and proof of origin. A second, short-lived copy exists as a rate-limiting key held by our Redis provider, which expires on its own sliding window and is not reachable by an erasure request. Both are stated here rather than left to be discovered.

Forms on websites we host record no IP address in our database, and write no audit entry. The address is still read to apply a rate limit, and applying that limit means a copy of it is held briefly by our Redis provider as the key it counts against. That copy expires on its own window and an erasure does not reach it, exactly as on the capture doors. “Not recorded” would be the easier sentence and it would be wrong.

3.7 No special-category data by design. We do not solicit, and the product has no field for, data revealing health, race, religion, politics, trade union membership, sex life, sexual orientation, genetic or biometric identifiers. We also do not knowingly hold data about anyone under 16.

4. Your instructions, and the record we keep of them

4.1 What your documented instructions are. Apex processes lead data only on your documented instructions. Those instructions are, in full:

1. this agreement;

2. the configuration you set in the product, in particular the list of website addresses that may submit leads for a given client, capped at ten per client;

3. the recorded authorisation captured at the moment lead capture is switched on for a client; and

4. any further written instruction we accept from you.

4.2 The recorded authorisation, and why it matters. Lead capture cannot be switched on without a named person ticking a confirmation, and the product stores four things against that client at that moment:

The confirmation states two things, in this order: that the person ticking it is authorised to turn capture on and configure it for that business, and that the page carrying the form publishes a notice telling visitors what is collected, why, that Apex Discover LLC receives that information as a service provider for the business and does not sell it, and how to ask for a copy or a deletion. The exact wording is the sentence shown on the screen where you tick it, and it names Apex rather than a generic category on purpose: an attestation that some unnamed provider was disclosed is one a person can honestly give while the disclosure this product depends on is absent.

Two design points are worth knowing, because they are what make this record evidence rather than decoration:

• The promise is written before the switch. The acknowledgement is recorded first and capture is armed second, so no configuration can exist without an authorisation behind it.
• It is re-confirmed on every save, and the timestamps move with it. The stored row therefore describes who authorised the current configuration, which is the question that matters if the website list changed. Every earlier authorisation survives in our append-only audit log.

This is the record this agreement leans on. If a regulator or your own client asks when you instructed us and who did it, that is the answer, and we can produce it. Clause 12 covers how.

4.3 Instructions we will not follow. If we believe an instruction breaches data protection law, we will tell you and may pause that processing until it is resolved. We will not quietly comply.

4.4 Nothing of our own.We do not use lead data for our own purposes, including improving or training any AI model, benchmarking, or the benefit of any other customer. We do not sell it and we do not share it for anyone else's advertising.

5. Confidentiality

Everyone at Apex with access to lead data is bound by a duty of confidentiality that survives the end of their engagement. Access is granted on a least-privilege basis and only to people who need it to operate or support the service.

Opening one named person's record writes an audit entry naming that record, and so does every export, deletion and change to who receives lead notifications. Being precise about the limit, because it is what an auditor asks: the list view writes nothing. Opening one lead is recorded; scrolling a page of them is not. That is a deliberate choice, taken so the trail is not swamped by one row per page view, and it is recorded here rather than left for someone to infer that the trail answers a question it does not.

6. Security

6.1 The measures. Our technical and organisational measures are recorded in full, with the file and line each one is implemented at, in docs/ops/processing-records.md section 8. That record is maintained as part of the codebase and is re-verified against the running system, so it does not drift from reality the way a security page does. In summary it covers: row-level security on every table with no exceptions, tenant isolation asserted automatically on every change, database policy drift detection, encryption in transit and at rest, the four-field allow list, a per-client website allow list, rate limiting on both submission doors, removal of personal data from error reports before they leave our systems, an append-only audit log that no customer role can read, and webhook credentials stored only as hashes.

6.2 The residual risks. docs/security/lead-capture-threat-model.md lists the surface of this feature and, for each risk, the control, what is left over, and what would detect an exploit. We hand it over in full rather than summarise it, because a summary of a threat model is a marketing document.

6.3 Three things we do not claim. Stated here so nobody has to discover them in diligence:

• No certification. Apex holds no SOC 2 report, no ISO 27001 certificate and no equivalent. We will not imply one.
• No penetration test of this surface yet. A full authenticated scan of the lead-capture surface is a condition of switching capture on and has not yet run. Until it has, we do not describe the feature as penetration tested.
• No automated database backups. Point-in-time recovery is off and there are no managed backups on the current database plan. An interim manual procedure and the recommendation to upgrade are recorded in docs/runbooks/monitoring.md section 5. This is an availability and integrity risk under Article 32(1)(c), it is our largest open security item, and clause 13.3 is written to match it rather than to paper over it.

6.4 The one AI exception, and it is not lead data. Lead data never reaches an AI model. That is enforced structurally: an automated test fails the build if any code in the lead pipeline gains a path to an AI provider. Separately, where a client has our text-message assistant switched on, a consumer's own message text is sent to our AI provider so a reply can be drafted. That is a different feature with a different disclosure, it is switched on per client, and it is described where you switch it on. The text-message track is not currently sold.

7. Sub-processors

7.1 General written authorisation. You give us general written authorisation to engage sub-processors, subject to this clause.

7.2 The published list. Every sub-processor that can touch lead data is listed on our sub-processor page, with what each one does and what category of data each can receive. The list is specific rather than generic: it records, for example, that our email provider receives a consumer's name and the message they wrote because that is what a new-lead notification contains, while their phone number and email address are structurally absent from it; and that our error-monitoring provider may incidentally receive a name inside a technical error report, because the scrubber that strips email addresses, phone numbers and access tokens does not strip names.

7.3 The AI assistants we measure are not sub-processors of lead data. We put questions about your client's business, drawn from that client's own tracked question list, to AI assistants and record how they answer. Those questions contain no information about any individual. This is the first question most agencies ask, so it is answered here rather than left to a support ticket.

7.4 Notice of change. We give you at least 30 days' written notice before adding a sub-processor or letting an existing one start receiving a new category of data. Notice is by email to your account contacts and by an update to the published list.

7.5 Your right to object.You may object on reasonable data protection grounds within those 30 days. We will work with you to find an alternative. If we cannot, you may terminate the affected part of the service without penalty and without waiting for a renewal date, and clause 11 then applies to that client's data.

7.6 Our responsibility. Each sub-processor is bound by written terms no less protective than these. We remain liable to you for their performance as if it were our own.

8. Helping you answer the individual

8.1 What the law asks. As controller you owe the individual their rights of access, correction, deletion, portability, restriction and objection. As processor we owe you help.

8.2 What we actually do.If one of your client's customers asks about their data, come to us and we will produce a complete copy of everything we hold about that person, or remove them completely, or both.

8.3 The honest position, which is a response time and not a screen. There is no self-service screen in the product todayfor an individual export or an individual deletion. The tooling that does the work is built, tested and proven against production, including against the foreign keys that would otherwise make a deletion fail silently or half succeed. What is missing is the door: serving one person's request today means we run that tooling for you, on request.

So we commit to a response time rather than to a feature:

Those are deliberately shorter than your own clock, which is one month under the GDPR and 45 days under the CPRA, so the time is spent on your decision rather than on our queue. If a request is unusually complex we will tell you inside the acknowledgement window rather than at the deadline.

8.4 We do not act on our own initiative. If an individual contacts us directly we will pass the request to you and support you in answering it. We are not permitted to hand over or delete your records on our own judgement, and you would not want a supplier who was.

8.5 What a deletion actually reaches.A deletion removes the person's contact record and everything linked to it across every table that holds their details or their words, including messages inside a conversation, which are reached through the conversation rather than directly. It writes an audit entry recording that it happened, with row counts and no names, and then reads that entry back to confirm it landed.

One thing it does not reach, named rather than left to be found: the short-lived IP address held as a rate-limiting key by our Redis provider. An erasure does not touch it and it expires on its own window, in minutes.

The IP address recorded on a capture entry is cleared by an erasure. Our audit log is append-only by design, so clearing it needs a permission narrow enough not to weaken that: the database grants us the ability to update that one column and no other. Verified against the production database on 2026-08-23.

No consumer address is held under either heading at present. The platform-wide switch for lead capture is on, but no client has enabled it, so nothing has been captured and the audit table holds no rows. Verified against the production database on 2026-08-31. Clause 3.6.

8.6 Procedure. The step-by-step is docs/ops/data-subject-request-runbook.md, written to describe the procedure as it actually is rather than as it should be.

9. Helping you with assessments

We will give you the information you reasonably need for a data protection impact assessment or a prior consultation with a supervisory authority, so far as it concerns processing we carry out for you and so far as you cannot get it from the documents in clause 12. Sections 2, 3 and 8 of our records of processing are written to be handed over for exactly this.

10. Breach notification

10.1 The commitment. If we become aware of a personal data breach affecting lead data we process for you, we notify you without undue delay and in any case within 48 hours of becoming aware. That is deliberately set inside your own 72-hour obligation to your supervisory authority, so you are not spending your clock waiting for ours.

10.2 What the notice contains, so far as we know it at the time, with the rest to follow as we learn it: what happened and when, which categories of data and roughly how many individuals are affected, the likely consequences, what we are doing about it, and a named contact.

10.3 What we do not do.We do not notify your client's customers or a supervisory authority on your behalf. That is the controller's call and the controller's wording, and a processor who makes it for you has taken a decision that was never theirs.

10.4 Our procedure is docs/ops/breach-runbook.md, including who is woken, what is preserved, and how the 48 hours is measured.

11. When the relationship ends: delete or return

This is the clause your client's counsel will read first, so it describes what the software actually does.

11.1 Your choice. At the end of the service, GDPR Article 28(3)(g) gives you the choice of having lead data returned or deleted. Both are built, both were proven against production, and both are yours to run.

11.2 Return.Once a client is removed from your account, an agency administrator can download a complete JSON export of that client's whole customer book from Settings, then Archived. It contains every contact record with their events, reviews, sequence steps, conversations, messages, appointments, deals and lead intent. It is generated on request and handed straight to your browser; we never keep a server-side copy, because a second copy of a customer database sitting in a bucket is a second thing to breach and a second thing to find on the next erasure request.

Two limits, stated rather than implied:

• It is reachable only for a client whose status is removed (archived), and only by an agency administrator. A live client's customer database is not available for deletion from a settings page.
• It is a return-on-termination mechanism, not an individual portability tool. It returns the entire book, not one person. If one person wants their own copy, that is clause 8.

11.3 Deletion. The purge deletes every contact for that client and everything linked to them, in an order chosen so that a failure part way through leaves a person who can still be found and finished rather than one whose records are stranded where no future request could reach them. It writes a single audit entry recording what was destroyed, by table, with no names in it.

11.4 What deletion keeps, and why you will notice. The purge keeps all measurement history: the visibility checks, the action items, the record of what was measured and when. That is deliberate. Measurement history is business data about the client, not personal data about a consumer, and it is your own record of the work that was done. The distinction this turns on is the one the law turns on: your client's record is data Apex holds as controller, and your client's customers' data is what Apex processes for you. Only the second is erased here.

11.5 Neither happens automatically, and that is on purpose. Removing a client archives it. It does not erase anything. Three reasons the purge stays an explicit act: an automatic purge would silently take away the choice the article grants you; the person clicking Remove is usually trying to stop the billing and cannot answer “export or delete?” on their client's behalf in that moment; and a Remove button that quietly destroyed a customer database is a defect waiting for its first misclick.

11.6 Download first, then delete. The two are separate acts in the product, in that order, because an export handed over as the last step of a deletion destroys the original before anyone has confirmed the copy arrived.

11.7 Timing. You have 30 days from the end of the Main Agreement to take your export. After that, and unless you tell us otherwise or the law requires us to keep something, we may run the deletion ourselves. We will tell you before we do.

11.8 What we keep either way.The audit trail itself is not erased. What it holds about an erased person is an identifier pointing at a record that no longer exists, which identifies nobody, and it is the only proof the erasure was carried out. Where an audit entry carries a consumer's IP address, we clear that one column and keep the entry, subject to the permission point in clause 8.5. We also keep anything the law requires us to keep, including billing records, which are our own controller data.

12. Audit and information rights

12.1 What we provide, on request and without charge. Scoped to what a company our size can honestly stand behind:

12.2 What we do not offer.No on-site audit, no customer-run penetration test of our infrastructure, and no SOC 2 or ISO report, because none exists. If your client's procurement process requires one, tell us before you sign rather than after, and we will tell you plainly whether we can meet it. We would rather lose the deal than pass an attestation we do not hold.

12.3 One thing to tell a client in a regulated vertical. A free-text message box can contain anything a person chooses to type, including health information sent to a medical practice or case details sent to a law firm. The four-field allow list constrains the fields, not what a person writes in them. Clients in regulated verticals should be told this in plain words before capture is switched on, and the lead data addendum makes it your obligation not to solicit it deliberately.

13. Where the data goes, and where it does not

13.1 The United States, and only there.All lead data is stored in the United States, in Amazon Web Services' Oregon region (us-west-2), through our database provider. There is no EU or UK data residency option, and adding one is not on our roadmap. We address the exposure contractually rather than by infrastructure, and we say so rather than letting a procurement questionnaire discover it.

13.2 Transfers.The realistic case is a European or UK visitor filling in a form on a US client's website. Where a transfer of that kind requires them, the Standard Contractual Clauses approved by the European Commission are incorporated into this agreement by reference, in the module matching the roles in clause 2, and the parties intend Module Three where you act as a processor for your own client, which is the agency case. Where the UK GDPR applies, the UK International Data Transfer Addendum applies to those clauses. Annex 1 and Annex 2 of this agreement populate the annexes those clauses require. Where the clauses and this agreement conflict, the clauses prevail.

13.3 Business continuity, stated to match clause 6.3. We do not offer a recovery time or recovery point commitment for lead data, because we do not hold automated backups today. If your client's requirements depend on one, raise it before you sign.

14. Liability

Each party's liability under this agreement is subject to the limitations and exclusions in the Main Agreement, which are not increased or reduced by this document. Nothing here limits either party's liability to a data subject or to a supervisory authority under applicable data protection law, or any liability that cannot lawfully be limited.

15. Term, changes and precedence

15.1 Term. This agreement starts when you first use a feature that collects lead data and runs until the Main Agreement ends and clause 11 is complete.

15.2 Changes.We may update this agreement to reflect a change in the law, a change in the service, or a correction. Material changes are notified to active customers with at least 30 days' notice, and the sub-processor notice in clause 7.4 runs on its own timetable. We keep the effective date at the top current.

15.3 Precedence. On the processing of lead data, this agreement prevails over the Main Agreement. The Standard Contractual Clauses prevail over both. On everything else, the Main Agreement governs, including its terms on payment, term, termination and governing law.

15.4 Signature. The published version applies to every customer using lead capture, with no signature required. If your organisation or your client needs a countersigned copy naming both parties, email legal@apexdiscover.ai and we will execute one.

16. Contact

Annex 1: Description of the transfer

Populates the annexes required by the Standard Contractual Clauses.

Annex 2: Technical and organisational measures

The measures are enumerated, with the file and line each is implemented at, in docs/ops/processing-records.md section 8, which is incorporated here by reference and maintained as part of the product rather than as a marketing page. Section 8 also names the open weaknesses, and clause 6.3 above repeats them, so that a reader of this annex alone is not left with a better impression than a reader of the record.

This document is accurate about the software: every factual claim in it traces to code, to a document in this repository, or to a query run against production on 2026-08-22. Related: docs/ops/processing-records.md(the verified fact base) · our privacy policy · our sub-processor page · docs/legal/terms-addendum.md · docs/legal/notice-at-collection.md · docs/security/lead-capture-threat-model.md · docs/ops/data-subject-request-runbook.md · docs/ops/breach-runbook.md. Drafted August 23, 2026.