Privacy Policy

DRAFT, NOT IN FORCE. This document is an unapproved draft. It has not been reviewed by a lawyer and it is not a statement of anyone's rights or obligations.

It contains unresolved [[TO CONFIRM: ...]] markers, each of which is a real-world fact nobody has confirmed yet. Two clauses must not be published as drafted: section 8.4 states what Anthropic does with prompt data and has not been checked against the agreement in force, and section 2 must not claim either way whether an EU or UK Article 27 representative has been appointed.

Do not present this to a customer, quote from it, or rely on it. The effective date below is the date this draft was loaded, not a date on which anything takes effect.

Effective date: [[TO CONFIRM: effective date]] Last updated: [[TO CONFIRM: date this version was published]] Version: [[TO CONFIRM: version label, for example 1.0]]

This policy explains what personal information Clickbase handles, why, who it is shared with, where it goes, and what you can do about it. It is written to be read, not to be survived. If anything in it is unclear, ask us using the details in section 17.

1. About this policy#

This policy covers:

• the Clickbase application at app.clickbase.tech;
• the Clickbase website at clickbase.tech;
• the supporting systems that run behind them, including our integration gateway and our data ingestion pipeline.

It applies to three different groups of people, and the distinction matters because our legal role is not the same for each:

1. The people who use Clickbase. Staff of an agency that holds a Clickbase account. Every Clickbase account is held by an agency.
2. The people at an agency's clients. Named contacts recorded against a client business. A client is a record inside an agency's account, not an account holder in its own right.
3. Consumers whose data flows through offline conversion tracking. People who bought something or submitted a lead form, whose contact details an agency sends through Clickbase to an advertising platform so that platform can measure and optimise advertising.

Section 3 explains our role for each group. Section 7 deals with group 3 specifically, because it is the most sensitive path in the system.

2. Who we are#

Clickbase is operated by [[TO CONFIRM: full registered legal entity name, for example From First Click (Pty) Ltd]], registration number [[TO CONFIRM: company registration number]], a company incorporated in the Republic of South Africa, with its registered address at [[TO CONFIRM: registered address]].

Our information officer for the purposes of the Protection of Personal Information Act 4 of 2013 (POPIA) is [[TO CONFIRM: name and contact details of the registered information officer]].

[[TO CONFIRM: whether an EU or UK representative has been appointed under Article 27 of the GDPR or the UK GDPR. This is required if the platform is offered to agencies established in the EU or UK. Do not publish a claim either way until this is decided.]]

3. Our two roles#

We have two distinct roles, and which one applies depends on whose information it is.

3.1 We are an operator (processor) for your business data#

For everything an agency puts into Clickbase, or that flows into Clickbase from that agency's connected advertising accounts, the agency is the responsible party under POPIA and the controller under the GDPR. We are its operator and processor.

That means we process that information only to provide the service, on the agency's instructions, and we do not decide what it is used for. The agency decides what to collect, whose data to upload, and what to send to an advertising platform. This includes:

• client records and named client contacts;
• campaign, budget and pacing configuration;
• tasks, comments, approvals and uploaded files;
• customer lists uploaded for audience building;
• offline conversion data pushed to advertising platforms.

3.2 If you have appointed us to run your advertising#

Some agencies also engage us separately for paid media management. Where that happens, our people operate that agency's advertising through Clickbase, but our role over that agency's data does not change: the agency is still the responsible party and controller, and we are still its operator and processor. We do not become the controller of another agency's client data by being asked to run its campaigns, and one agency's account is never merged with another's.

3.3 We are a responsible party (controller) for our own user accounts#

For the account and profile information of the individual people who sign in to Clickbase, and for the analytics and error data generated by their use of the application, we act as the responsible party and controller in our own right. We decide what to collect and why, so that we can run and secure the service.

4. The personal information we process#

4.1 Agency user accounts#

Held so people can sign in and so we know who did what.

Information

• Identity. Detail: First name, last name, full name, profile image.
• Contact. Detail: Email address.
• Account. Detail: User identifier from our authentication provider, organisation membership, role within the organisation, whether the account is internal to us.
• Optional linked identifiers. Detail: Slack user identifier, where an organisation has linked one.
• Timestamps. Detail: When the record was created and last updated.

Authentication itself, including passwords and any multi-factor secrets, is handled by our authentication provider (see section 9). We never see or store your password.

4.2 Activity and audit records#

Held so that changes to advertising accounts are attributable and reviewable.

• Which user requested a change, and which user approved or rejected it.
• What the change was, what it targeted, and when it happened.
• Task comments, task assignments and collaborator lists.
• Files uploaded to a task or a brief, including images, PDFs, spreadsheets and documents.
• Notifications generated for a user.

4.3 Client records#

Held on behalf of the agency. Names of client businesses, their advertising account identifiers, their status, currency and metadata, and named client contacts where an agency records them.

4.4 Consumer identifiers in offline conversion tracking#

Where an agency uses offline conversion tracking, contact details of that agency's clients' customers pass through the system on their way to an advertising platform. This is set out in full in section 7.

4.5 Technical and usage information#

Collected automatically when someone uses the application.

• IP address, browser type and version, device and operating system.
• Pages and features used, and the sequence of actions taken.
• Error reports, including stack traces, and the state of the application at the time of an error.
• Performance traces and profiles.
• Session recordings of application use (see section 14).

4.6 What we do not collect#

We do not process special personal information under POPIA, or special category data under the GDPR, as part of running the platform. We do not process children's information (see section 15). We do not take payment card details in the application; if we bill you, billing is handled outside the application.

5. Where the information comes from#

• From you directly, when you create an account, invite users, record clients, upload files, or type into the application.
• From your authentication provider, which sends us your name, email address and profile image when your account is created or updated.
• From advertising platforms, when we read delivery and spend data back from the advertising accounts you connected. This data is aggregated at campaign, ad set and ad level and does not identify individuals.
• From your own systems, where you configure offline conversion tracking to read conversion records you have placed in a data warehouse.
• Automatically, from your use of the application, as described in section 4.5.

6. Why we process it, and on what basis#

Purpose

• Provide the platform, authenticate users, apply access controls. Information used: Account, activity. Our basis under POPIA: Necessary to perform the contract with you (s11(1)(b)). Our basis under the GDPR: Contract (Art 6(1)(b)).
• Attribute and audit changes to advertising accounts. Information used: Activity, audit. Our basis under POPIA: Legitimate interest in an accountable, reviewable system (s11(1)(f)). Our basis under the GDPR: Legitimate interests (Art 6(1)(f)).
• Manage clients, campaigns, budgets and approvals on the agency's instruction. Information used: Client records, campaign data. Our basis under POPIA: Processing as an operator on the responsible party's instruction (s20, s21). Our basis under the GDPR: Processing as a processor on the controller's instruction (Art 28).
• Push offline conversions and audience memberships to advertising platforms. Information used: Consumer identifiers. Our basis under POPIA: Processing as an operator on the responsible party's instruction. Our basis under the GDPR: Processing as a processor on the controller's instruction.
• Diagnose faults, monitor performance, keep the service secure. Information used: Technical, usage. Our basis under POPIA: Legitimate interest in a working and secure service (s11(1)(f)). Our basis under the GDPR: Legitimate interests (Art 6(1)(f)).
• Understand how the product is used and improve it. Information used: Usage, session recordings. Our basis under POPIA: Legitimate interest in improving the service (s11(1)(f)). Our basis under the GDPR: Legitimate interests (Art 6(1)(f)) or consent where required.
• Send service and account emails. Information used: Account. Our basis under POPIA: Necessary to perform the contract (s11(1)(b)). Our basis under the GDPR: Contract (Art 6(1)(b)).
• Meet legal and regulatory obligations. Information used: As applicable. Our basis under POPIA: Compliance with an obligation of law (s11(1)(c)). Our basis under the GDPR: Legal obligation (Art 6(1)(c)).

Where we rely on a legitimate interest, we have considered whether that interest is outweighed by the rights of the people concerned. You can ask us for our assessment, and you can object (see section 13).

Where the agency is the responsible party, the lawful basis for processing that agency's client and consumer data is the agency's to establish, not ours. If you are an agency using Clickbase, you must have a lawful basis for every list you upload and every conversion you send, and you must have given the people concerned the notice the law requires.

7. Offline conversion tracking, and exactly what is hashed#

This section is deliberately specific, because it is the part of the system that handles the personal information of people who never interact with Clickbase at all.

7.1 What offline conversion tracking does#

An agency's client records conversions in its own systems, for example a purchase or a lead. The agency places those records in a data warehouse. On a schedule, Clickbase's integration gateway reads those records and sends them to an advertising platform so the platform can attribute and optimise advertising.

The platform needs to recognise the person. That is why identifiers travel at all.

7.2 Identifiers are hashed before they reach an advertising platform#

Our integration gateway applies SHA-256 hashing to identity fields before any request leaves our systems for an advertising platform. Hashing is one-way: the platform receives a fingerprint, not the underlying value. The gateway is the only component that holds advertising platform credentials, and it is the only component that performs this hashing.

Values that are already a 64-character hexadecimal SHA-256 digest are passed through unchanged, so an agency that hashes its own data before sending it to us is not double-hashed.

7.3 Exactly which fields are hashed, and which are not#

Meta Conversions API. Each field is normalised and then SHA-256 hashed.

Hashed before sending.

• Email address
• Phone number
• First name, last name
• City, state or province
• Postal code, country, gender
• Date of birth
• External identifier

Sent as provided, not hashed.

• IP address of the browser
• Browser user agent string
• Meta browser identifier (fbp)
• Meta click identifier (fbc, or one derived from a supplied fbclid)
• Event identifier supplied by the agency for de-duplication
• Event metadata such as conversion value, currency and product identifiers

Google Ads, through the Data Manager API. Email address and phone number are normalised and SHA-256 hashed. The Google click identifier (gclid), the transaction identifier, conversion value, currency, event source and event timestamp are sent as provided and are not hashed.

Google Ads Customer Match audiences. Email address, phone number, first name and last name are normalised and SHA-256 hashed. Country code and postal code travel in plain text, because Google's own API requires them alongside the hashed name fields.

Meta Custom Audiences. Only email address and phone number are supported, and both are normalised and SHA-256 hashed.

7.4 What this means honestly#

Three things follow, and we would rather state them than leave them to be discovered.

1. Hashing is not anonymisation. A SHA-256 hash of an email address is still personal information under both POPIA and the GDPR, because the platform holds the same hashes for its own users and matches on them. That is the entire purpose. Hashing limits exposure in transit and at rest on the platform side; it does not remove the person from the transaction.
2. Some fields genuinely leave in the clear. IP address, browser user agent, platform click and browser identifiers, click identifiers, transaction identifiers, and country and postal code in the Google Customer Match case, are sent as provided. Advertising platforms require them unhashed. Any custom event metadata an agency chooses to attach, such as order values or product identifiers, is also sent as provided.
3. The source data is not hashed. Hashing happens at the moment of sending. Before that, the conversion records sit in the data warehouse the agency configured, in whatever form the agency put them there, and they pass through our scheduling component on the way. Where an agency supplies raw email addresses and phone numbers, those raw values exist in our infrastructure until the moment the gateway hashes them.

If you are an agency using this feature, points 2 and 3 are yours to disclose to your own clients and, through them, to the people whose data it is.

7.5 Customer list uploads#

An agency can upload a customer list to build an advertising audience. The contact rows are read by our systems, passed to the integration gateway, and hashed there before upload, exactly as described above. The raw rows are not returned to the automated agent by that upload path.

However, a file you attach to a task can be read by the agent through its file inspection tools, and its contents can therefore reach our AI provider as part of a prompt. See section 8. Do not attach a customer list to a task or chat unless you intend the agent to be able to read it.

8. The automated agent, and what reaches our AI provider#

Clickbase includes an automated agent built on Anthropic's Claude models, accessed through Anthropic's API. It can plan and carry out campaign work on your instruction.

8.1 What is sent to the AI provider#

To do its work, the agent sends the following to Anthropic:

• your instructions and the conversation, including task comments;
• context about the client, campaigns, budgets and performance data relevant to the task;
• the results of the reads it performs against your advertising accounts;
• the contents of images and PDF files attached to the task, inlined into the prompt;
• the contents of text and spreadsheet files attached to the task, where the agent reads them using its file inspection tools.

Before any of the agent's internal reasoning is streamed to your screen or stored, it passes through a scrubber that removes credential-shaped values such as API keys and bearer tokens. That scrubber targets secrets. It is not a personal information filter, and it should not be relied on as one.

8.2 Human approval before anything goes live#

The agent builds everything in a paused state. A person in your organisation must approve any change that starts advertising spend, or that increases spend already running, before it is applied. This is described in full in our Terms of Service.

8.3 Automated decision making#

The agent does not make decisions that produce legal effects concerning an individual, or that similarly significantly affect an individual. It operates on advertising accounts and campaign configuration, not on people. Where it proposes a change that moves money, a person decides.

Automatic budget pacing can adjust a campaign budget without a person approving each change. It is switched on per client, it operates within configured safety caps, it refuses anything above those caps, and it does not activate anything. It does not make decisions about individuals.

8.4 What Anthropic does with it#

[[TO CONFIRM: the exact commercial terms in place with Anthropic, in particular whether the account is on terms under which inputs and outputs are not used to train models, and the applicable retention period. State the position precisely and do not publish a claim that has not been checked against the agreement in force.]]

9. Who we share personal information with#

We do not sell personal information. We share it only with the service providers below, and only for the purposes described. Each acts under contract.

9.1 Infrastructure and core platform#

Provider

• **Vercel**. What it does: Hosts and serves the Clickbase application and website. What it receives: Every request to the application, including IP address and request metadata. Application data in transit..
• **Supabase**. What it does: The primary database and file storage for the application. What it receives: All account records, client records, campaign and budget data, tasks, comments, approvals, audit records and uploaded files. Encrypted platform credentials..
• **Google Cloud (BigQuery)**. What it does: Stores ingested advertising delivery and spend data, and the conversion tables an agency configures for offline conversion tracking. What it receives: Aggregated campaign, ad set and ad level metrics. Where an agency uses offline conversion tracking, the conversion records that agency places there, which may include unhashed email addresses and phone numbers..
• **Cloudflare**. What it does: DNS and network routing for our domains, and the tunnel that fronts our integration gateway. What it receives: Request and connection metadata, including IP address..
• **Our own server infrastructure**. What it does: Runs our integration gateway, our data ingestion pipeline, the agent service and our workflow scheduler. What it receives: All data passing through those components, including offline conversion records in the form the agency supplied them..

[[TO CONFIRM: the physical location and legal jurisdiction of the self-hosted server infrastructure, and whether it is to remain self-hosted. This must be stated accurately in section 10.]]

9.2 Authentication#

Provider

• **Clerk**. What it does: Runs sign-in, sessions, organisations and invitations. What it receives: Name, email address, profile image, organisation membership and role, authentication credentials, sign-in metadata including IP address..

9.3 Monitoring and analytics#

Provider

• **Sentry. What it does: Error reporting, performance tracing and session replay. What it receives: Errors and stack traces, performance traces, application state at the time of an error, user identifier, email address and IP address, browser console output, session recordings with text masked by default, and feedback you submit through the in-app widget including your name and email. It also receives the inputs and outputs of agent interactions, which include client campaign data, budgets and ad copy.**.
• **PostHog**. What it does: Product analytics. What it receives: Events describing feature use, linked to a user identifier, email address, name and organisation identifier..

Analytics requests are routed through a proxy on our own domain before reaching PostHog. This reduces the chance of them being blocked; it does not change what PostHog receives.

9.4 Advertising platforms#

Where you have connected an account, we send data to that platform on your instruction.

Platform

• **Meta**. What it receives: Campaign, ad set, ad and creative configuration. Budget and status changes. Audience memberships as hashed identifiers. Offline conversion events, hashed and unhashed fields as set out in section 7.3..
• **Google Ads**. What it receives: Campaign, ad group, ad and asset configuration. Budget and status changes. Customer Match audience members as hashed identifiers plus plain text country and postal code. Offline conversion events through the Data Manager API, as set out in section 7.3..
• **LinkedIn Ads**. What it receives: Campaign configuration, budget and status changes..
• **Microsoft Ads**. What it receives: Campaign configuration, budget and status changes..

We read reporting data back from all four.

9.5 Other services#

Provider

• **Anthropic**. What it does: Provides the AI models behind the automated agent. What it receives: The prompts and context described in section 8.1..
• **1Password**. What it does: Stores our own system credentials. What it receives: Our operational secrets. It does not receive customer data..
• **Slack**. What it does: Receives our internal operational alerts about system health, ingestion failures and budget discrepancies. What it receives: Alert messages, which can name a client and a campaign..
• **Resend**. What it does: Sends transactional email from our systems. What it receives: Recipient email address and message content..
• **Google Workspace**. What it does: Where you ask the agent to work with files in your Google Drive, we read them through a service account. What it receives: The file identifiers you name. Files are streamed directly into our storage..
• **Google Maps Geocoding API**. What it does: Converts a street address you supply into coordinates, so a campaign can target a radius around it. What it receives: The address text you supply..
• **Brave Search API**. What it does: Web search, where the agent needs to look something up. What it receives: The search query..
• **Sanity**. What it does: Content management for the public website at clickbase.tech, including this policy. What it receives: Website content only. It receives no customer data and no application data..

9.6 Other disclosures#

We may also disclose personal information:

• where the law, a court, or a regulator requires it;
• to establish, exercise or defend a legal claim;
• to a professional adviser under a duty of confidentiality;
• to a buyer or successor in a merger, acquisition or sale of assets, on notice to you.

9.7 Changes to this list#

We will keep this list current. Where we add a sub-processor that will handle an agency's customer data, we will notify the agency's account administrators in advance so they have the opportunity to object.

10. Where the information goes#

Some of our service providers process data outside South Africa, including in the United States and the European Union. Specifically:

• Sentry and PostHog are configured on their United States regions.
• Anthropic, Clerk, Vercel, Supabase, Cloudflare, Google Cloud, Slack, Resend, 1Password, Brave and Sanity are all capable of processing data outside South Africa. [[TO CONFIRM: the specific hosting region selected for each of Supabase, Vercel, Google Cloud (BigQuery dataset location), Clerk and Anthropic, so that this section can state each one precisely rather than generally.]]
• Advertising platforms process data in their own global infrastructure.

Under POPIA, we transfer personal information outside South Africa on the basis of section 72, relying on the recipient being subject to a law or binding agreement that provides an adequate level of protection, and on the contractual terms we have in place with each provider.

Under the GDPR, where personal data of people in the EU or the UK is transferred outside the EEA or the UK, we rely on the European Commission's Standard Contractual Clauses, the UK International Data Transfer Addendum where applicable, or an adequacy decision where one covers the destination.

You can ask us for details of the safeguards that apply to a specific transfer.

11. How long we keep personal information#

We are going to be plain about this, because a policy that claims a deletion process that does not exist is worse than one that admits a gap.

11.1 What is deleted on a schedule#

Data

• Gateway action log, recording calls made to advertising platforms. Retention: 90 days, deleted by a scheduled job.
• Host and system metrics. Retention: 30 days, deleted by a scheduled job.
• The agent's intermediate reasoning events. Retention: 48 hours, deleted by a scheduled sweep.
• Orphaned agent memory summaries. Retention: Deleted after a configured period once the source session is gone.

11.2 What you can delete yourself#

You can delete campaigns, budget lines, tasks, sub-tasks and task attachments from within the application. Deleting an attachment removes both the record and the stored file.

11.3 What is retained until we act on a request#

There is currently no automated deletion of user account records or of client records.

• When a user is removed from your organisation, their membership is updated, but the record holding their name, email address and profile image is retained.
• When an organisation is closed, it is marked as archived. Its records are retained.
• Client records, campaign history, approvals, audit records and uploaded files are retained for as long as the account is open.

We do this on purpose for the audit trail, which has to remain intact for changes that moved money. It is not a reason to keep personal information indefinitely.

If you ask us to delete personal information, we will do it manually. Contact us using section 17. We will confirm what was deleted and what we had to retain, and why. We are building automated deletion, and this section will be updated when it exists rather than in anticipation of it.

11.4 What we cannot delete#

• Data already sent to an advertising platform. Conversions, audience memberships and campaign configuration pushed to Meta, Google, LinkedIn or Microsoft are held by that platform under its own retention rules. Deleting your Clickbase data does not remove them. You must deal with the platform directly.
• Backups. Data may persist in routine backups for a limited period after deletion from the live system. It is not returned to service and is overwritten on the normal backup cycle. [[TO CONFIRM: the backup retention period, so it can be stated here as a number.]]
• Records we are required by law to keep, for the period the law requires.

11.5 Records held by our providers#

Our monitoring and analytics providers apply their own retention periods to the data they hold. [[TO CONFIRM: the configured retention period for Sentry and for PostHog, so they can be stated here.]]

12. How we protect personal information#

• In transit and at rest. All traffic to and from the application uses TLS. Data at rest in our database and file storage is encrypted by the platform.
• Access control in the database. Tenant data is separated at the database level using row level security, so a query made under one organisation's session cannot read another organisation's records.
• Credential handling. Advertising platform credentials granted by an organisation are stored encrypted, held separately from the metadata about the connection, and are never displayed back to anyone. Our own system credentials are held in a dedicated secrets manager and injected at runtime, never committed to code.
• One way out. Only our integration gateway holds advertising platform credentials, and it is the only component permitted to call an advertising platform. Nothing else in the system holds a platform token.
• Scoped machine access. Machine to machine access to the gateway uses scoped API keys. A key can only invoke the specific actions it is scoped for. Keys are stored as hashes; the key itself is never stored.
• Outbound request protections. Any request the system makes to a URL that a user or the agent could influence is checked against a guard that rejects private and internal network addresses, re-checks every redirect, and enforces size and time limits.
• Redaction in logs. Request and response payloads recorded in the gateway's audit log are passed through a redaction layer that removes secret-shaped values before they are stored.
• Agent containment. Commands the agent runs are executed in a container with no network access and none of the credentials that can move money. The agent's own tools are fixed code with a bounded surface, not a general shell.
• Audit trail. Every change made to an advertising account through the platform is recorded with the user who requested it, the user who approved it, and what was applied.

No system is perfectly secure. If a compromise of personal information occurs, we will notify the Information Regulator and the people affected as POPIA requires, and, where the GDPR applies, the relevant supervisory authority within 72 hours as Article 33 requires.

13. Your rights#

13.1 If you are in South Africa (POPIA)#

You have the right to:

• be told whether we hold personal information about you, and to access it;
• have inaccurate, misleading or out of date information corrected;
• have information deleted or destroyed where we are no longer authorised to keep it;
• object, on reasonable grounds, to processing based on legitimate interests;
• object to processing for direct marketing, and to withdraw consent to it at any time;
• not be subject to a decision based solely on automated processing that has legal consequences for you;
• complain to the Information Regulator (section 17).

Requests for access are made on Form 2 under the Promotion of Access to Information Act. We will respond within the period POPIA and PAIA allow.

13.2 If you are in the EU or the UK (GDPR)#

You have the right to access, rectification, erasure, restriction of processing, data portability, and to object to processing based on legitimate interests. Where we rely on consent, you may withdraw it at any time, which does not affect the lawfulness of what was done before. You have the right to complain to your local supervisory authority.

13.3 How to exercise a right#

Contact us using section 17. We will respond within 30 days for a POPIA request and within one month for a GDPR request, and we will tell you if we need longer and why. We may ask you to verify your identity before we act.

13.4 If your data is in Clickbase because of an agency#

If you are a client of an agency that uses Clickbase, or a customer of one of that agency's clients, then that agency, not us, decides what happens to your information. We hold it as their operator. Send your request to them. If you send it to us, we will pass it to them and tell you we have done so, and we will support them in answering it. We will not act on it directly, because it is not ours to act on.

14. Cookies, analytics and session recording#

14.1 Cookies#

The application uses cookies that are strictly necessary to sign you in and keep your session secure. Those are set by our authentication provider and cannot be switched off without breaking sign-in.

We also use cookies and similar technologies for product analytics and error monitoring.

[[TO CONFIRM: whether a cookie consent banner is implemented on `app.clickbase.tech` and `clickbase.tech`. If the platform is offered to users in the EU or the UK, consent is required for analytics and session recording cookies before they are set. No such banner was found in the application code at the time of writing.]]

14.2 Session recording#

Our error monitoring provider records a sample of application sessions, and records the session whenever an error occurs. These recordings are used to reproduce faults.

Recordings are captured with the provider's default masking, which masks text content and blocks media. What is visible is the structure and flow of the interface and the actions taken, not the text on screen.

14.3 Product analytics#

Product analytics events are linked to your user identifier, your email address, your name and your organisation. [[TO CONFIRM: whether session recording is also enabled in the PostHog project settings, which is configured outside the application code.]]

14.4 Do Not Track#

We do not currently respond to Do Not Track browser signals.

15. Children#

Clickbase is a business tool. It is not directed at children and we do not knowingly collect the personal information of anyone under 18. If you believe a child's information has reached us, contact us and we will delete it.

16. Changes to this policy#

We may update this policy. When we do:

• we update the "Last updated" date and the version at the top, and publish the new version;
• for a change that materially affects how we handle your personal information, we give you at least [[TO CONFIRM: notice period, for example 30 days]] notice before it takes effect, by email to your account administrators and by a notice in the application;
• for a change that does not materially affect you, such as a clarification, a corrected contact detail, or a sub-processor's name change, the updated version applies from the date we publish it.

Every version of this policy is retained. Earlier versions are available on request, and are listed at [[TO CONFIRM: URL of the version history page, if one is published]].

17. How to contact us, and how to complain#

Contact us first. We would rather fix something than have you escalate it.

[[TO CONFIRM: full registered legal entity name]] [[TO CONFIRM: registered address]] Privacy and data protection: [[TO CONFIRM: privacy email address]] Information Officer: [[TO CONFIRM: name of the registered information officer]] General support: [[TO CONFIRM: support email address]]

If you are not satisfied, you may complain to a regulator.

South Africa, the Information Regulator: JD House, 27 Stiemens Street, Braamfontein, Johannesburg, 2001 PO Box 31533, Braamfontein, Johannesburg, 2017 Complaints: [email protected] General enquiries: [email protected] Website: https://inforegulator.org.za

EU or UK: your local supervisory authority. In the UK, that is the Information Commissioner's Office at https://ico.org.uk.