Data processing agreement

This Data Processing Agreement ("DPA") forms part of the agreement between [to be provided: company legal name] ("Provider") and the organisation that subscribes to AdCharter ("Customer") under the AdCharter Terms of Service. It applies whenever Provider processes Customer Personal Data as a processor (or subprocessor) on Customer's behalf while providing AdCharter.

Customer accepts this DPA when it accepts the Terms of Service, and no separate signature is needed. If your organisation needs a countersigned copy for its records, write to [to be provided: email address for legal notices]. Changes to this DPA are made in the same way as changes to the Terms of Service.

Key terms

These key terms complete the DPA in the same way as the Cover Page of the Common Paper DPA. Capitalised words have the meanings given here, in Section 11 (Definitions) or in the Agreement. If a term is not defined, its default meaning is "none" or "not applicable".

Provider: [to be provided: company legal name], a Wyoming [to be provided: type of company], [to be provided: company address], which operates AdCharter.
Customer: the organisation that has accepted the Agreement, as identified in its AdCharter account and billing details.
Agreement: the AdCharter Terms of Service between Provider and Customer. This DPA supplements the Agreement.
Service: AdCharter, the online service for planning, briefing, producing, approving and launching Meta ads and reporting on their performance, as described in the Agreement.
Approved Subprocessors: the Subprocessors listed on the sub-processors page, as updated under Section 2.6.
Provider Security Contact: [to be provided: privacy email address].
Security Policy: the technical and organisational measures described in Annex II.
Service Provider Relationship (CCPA): applies. Provider is a "service provider" under the CCPA (Section 2.7).
Security Incident notice: without undue delay and no later than 72 hours after Provider becomes aware of the Security Incident (Section 4).
Subprocessor changes: at least 30 days' notice before a new Subprocessor is used, with a right to object (Section 2.6).
Governing law and courts: as set out in the Agreement, except where Section 3 provides otherwise for the EEA SCCs and the UK Addendum.
Transfers from the EEA: the EEA SCCs, Module Two (controller to processor) and Module Three (processor to processor) (Section 3.2).
Governing Member State: Ireland. The EEA SCCs are governed by Irish law (Clause 17) and disputes are resolved by the courts of Ireland (Clause 18(b)).
Transfers from the UK: the UK Addendum, governed by the laws of England and Wales, with disputes resolved by the courts of England and Wales (Section 3.3).
Transfers from Switzerland: the EEA SCCs as adapted in Section 3.4.
Term: from the date Customer accepts the Agreement until Provider has deleted all Customer Personal Data (Section 10).

1. Roles of the parties

1.1 Provider as Processor

In situations where Customer is a Controller of the Customer Personal Data, Provider will be deemed a Processor that is Processing Personal Data on behalf of Customer.

1.2 Provider as Subprocessor

In situations where Customer is a Processor of the Customer Personal Data (for example, an agency that uses the Service for its clients' brands), Provider will be deemed a Subprocessor of the Customer Personal Data.

1.3 Provider as Controller

This DPA does not apply to Personal Data that Provider Processes as a Controller for its own purposes, such as account and billing administration, the public website and the security of the Service. Provider's Privacy Policy describes that Processing.

2. Processing

2.1 Processing details

Annex I describes the subject matter, nature, purpose and duration of this Processing, as well as the Categories of Personal Data collected and the Categories of Data Subjects.

2.2 Processing instructions

Customer instructs Provider to Process Customer Personal Data: (a) to provide and maintain the Service; (b) as may be further specified through Customer's use of the Service, including by connecting integrations such as Meta or Slack; (c) as documented in the Agreement; and (d) as documented in any other written instructions given by Customer and acknowledged by Provider about Processing Customer Personal Data under this DPA.

Provider will abide by these instructions unless prohibited from doing so by Applicable Laws. If Applicable Laws require Provider to Process Customer Personal Data in another way, Provider will inform Customer of that legal requirement before Processing, unless the law prohibits this. Provider will immediately inform Customer if it is unable to follow the Processing instructions, or if, in its opinion, an instruction infringes Applicable Data Protection Laws. Customer has given and will only give instructions that comply with Applicable Laws.

2.3 Processing by Provider

Provider will only Process Customer Personal Data in accordance with this DPA, including Annex I. If Provider updates the Service to update existing or include new products, features or functionality, Provider may change the Categories of Data Subjects, Categories of Personal Data, Special Category Data, Special Category Data restrictions or safeguards, Frequency of Transfer, Nature and Purpose of Processing, and Duration of Processing as needed to reflect the updates by notifying Customer of the updates and changes.

2.4 Customer processing

Where Customer is a Processor and Provider is a Subprocessor, Customer will comply with all Applicable Laws that apply to Customer's Processing of Customer Personal Data. Customer's agreement with its Controller will similarly require Customer to comply with all Applicable Laws that apply to Customer as a Processor. In addition, Customer will comply with the Subprocessor requirements in Customer's agreement with its Controller.

Customer has complied with and will continue to comply with all Applicable Data Protection Laws concerning its provision of Customer Personal Data to Provider and/or the Service, including making all disclosures, obtaining all consents, providing adequate choice and implementing relevant safeguards required under Applicable Data Protection Laws. This includes informing the people Customer invites or assigns to tasks (such as client approvers, freelancers and content creators) and the people shown in content that Customer uploads.

2.6 Subprocessors

(a) Provider will not provide, transfer or hand over any Customer Personal Data to a Subprocessor unless Customer has approved the Subprocessor. By accepting this DPA, Customer approves the Approved Subprocessors. The current list of Approved Subprocessors includes the identities of the Subprocessors, their country of location and their anticipated Processing tasks. Provider will inform Customer in writing, by email to Customer's organisation admins and by updating the list of Approved Subprocessors, at least 30 days before any intended change to the Approved Subprocessors, whether by addition or replacement of a Subprocessor. This gives Customer enough time to object to the change before Provider begins using the new Subprocessor. Provider will give Customer the information necessary to allow Customer to exercise its right to object. Customer has 30 days after notice of a change to object in writing to [to be provided: privacy email address], otherwise Customer will be deemed to accept the change. If Customer objects within 30 days of notice, Customer and Provider will cooperate in good faith to resolve Customer's objection or concern. If they cannot resolve it before the new Subprocessor starts Processing Customer Personal Data, Customer may terminate the Agreement by written notice without penalty, and Provider will refund any prepaid fees for the period after termination.

(b) When engaging a Subprocessor, Provider will have a written agreement with the Subprocessor that ensures the Subprocessor only accesses and uses Customer Personal Data (i) to the extent required to perform the obligations subcontracted to it, and (ii) consistently with the terms of the Agreement.

(c) If the GDPR applies to the Processing of Customer Personal Data, (i) the data protection obligations described in this DPA (as referred to in Article 28(3) of the GDPR) are also imposed on the Subprocessor, and (ii) Provider's agreement with the Subprocessor will incorporate these obligations, including details about how Provider and its Subprocessor will coordinate to respond to inquiries or requests about the Processing of Customer Personal Data. In addition, Provider will share, at Customer's request, a copy of its agreements (including any amendments) with its Subprocessors, or a link to them where they are the Subprocessor's published standard terms. To the extent necessary to protect business secrets or other confidential information, including personal data, Provider may redact the text of its agreement with a Subprocessor before sharing a copy.

(d) Provider remains fully liable for all obligations subcontracted to its Subprocessors, including the acts and omissions of its Subprocessors in Processing Customer Personal Data. Provider will notify Customer of any failure by its Subprocessors to fulfil a material obligation about Customer Personal Data under the agreement between Provider and the Subprocessor.

(e) Some Approved Subprocessors (Meta, Slack and Google) are used only when Customer or its users choose to connect them. When they do, Provider sends Customer Personal Data to that service on Customer's instruction. To the extent that the service Processes that data under Customer's own agreement with it (for example, Meta's terms for advertisers or Slack's customer terms), that agreement governs that Processing and Section 2.6(d) does not apply to it. Customer can stop these transfers at any time by disconnecting the integration.

2.7 Service provider under the CCPA

To the extent the California Consumer Privacy Act, Cal. Civ. Code § 1798.100 et seq. ("CCPA") applies, the parties acknowledge and agree that Provider is a service provider and is receiving Personal Data from Customer to provide the Service as agreed in the Agreement and described in Annex I (Nature and Purpose of Processing), which constitutes a limited and specified business purpose. Provider will not sell or share any Personal Data provided by Customer under the Agreement. In addition, Provider will not retain, use or disclose any Personal Data provided by Customer under the Agreement except as necessary for providing the Service for Customer, as stated in the Agreement, or as permitted by Applicable Data Protection Laws, and will not combine it with Personal Data that Provider receives from or on behalf of others, except as the CCPA permits. Provider certifies that it understands the restrictions of this Section 2.7 and will comply with all Applicable Data Protection Laws. Provider will notify Customer if it can no longer meet its obligations under the CCPA.

2.8 Security and confidentiality

Provider will implement and maintain the technical and organisational measures in the Security Policy (Annex II) to protect Customer Personal Data. Provider may update these measures over time, provided the updates do not materially reduce the overall protection of Customer Personal Data. Provider will ensure that the people it authorises to Process Customer Personal Data are bound by appropriate confidentiality obligations and access Customer Personal Data only as needed to provide, support or secure the Service.

3. Restricted transfers

3.1 Authorisation

Customer agrees that Provider may transfer Customer Personal Data outside the EEA, the United Kingdom, Switzerland or other relevant geographic territory as necessary to provide the Service. Provider is established in the United States, and some Approved Subprocessors are located there. If Provider transfers Customer Personal Data to a territory for which the European Commission or other relevant authority has not issued an adequacy decision, Provider will implement appropriate safeguards for the transfer of Customer Personal Data to that territory consistent with Applicable Data Protection Laws, such as the EU-US Data Privacy Framework (and its UK Extension) where the recipient is certified, or standard contractual clauses.

3.2 Transfers from the EEA

Customer and Provider agree that if the GDPR protects the transfer of Customer Personal Data, the transfer is from Customer from within the EEA to Provider outside of the EEA, and the transfer is not governed by an adequacy decision made by the European Commission, then by entering into this DPA, Customer and Provider are deemed to have signed the EEA SCCs and their Annexes, which are incorporated by reference. Any such transfer is made pursuant to the EEA SCCs, which are completed as follows:

Module Two (Controller to Processor) of the EEA SCCs applies when Customer is a Controller and Provider is Processing Customer Personal Data for Customer as a Processor.
Module Three (Processor to Processor) of the EEA SCCs applies when Customer is a Processor and Provider is Processing Customer Personal Data on behalf of Customer as a Subprocessor.
For each module, the following applies (when applicable):
- the optional docking clause in Clause 7 does not apply;
- in Clause 9, Option 2 (general written authorisation) applies, and the minimum time period for prior notice of Subprocessor changes is 30 days, as set out in Section 2.6;
- in Clause 11, the optional language does not apply;
- all square brackets in Clause 13 are removed;
- in Clause 17 (Option 1), the EEA SCCs are governed by the laws of the Governing Member State, Ireland;
- in Clause 18(b), disputes are resolved by the courts of the Governing Member State, Ireland;
- the audits described in Clause 8.9 are carried out in accordance with Section 5, to the extent this is consistent with the EEA SCCs; and
- Annex I and Annex II of this DPA and the list of Approved Subprocessors contain the information required in Annex I, Annex II and Annex III of the EEA SCCs.

3.3 Transfers from the UK

Customer and Provider agree that if the UK GDPR protects the transfer of Customer Personal Data, the transfer is from Customer from within the United Kingdom to Provider outside of the United Kingdom, and the transfer is not covered by UK adequacy regulations, then by entering into this DPA, Customer and Provider are deemed to have signed the UK Addendum and its Annexes, which are incorporated by reference. Any such transfer is made pursuant to the UK Addendum, which is completed as follows:

Table 1: the parties' details and key contacts are those in Annex I(A).
Table 2: Section 3.2 of this DPA contains the information required in Table 2 of the UK Addendum.
Table 3: Annex I, Annex II and the list of Approved Subprocessors contain the information required by Annex 1A, Annex 1B, Annex II and Annex III of the UK Addendum.
Table 4 is modified as follows: neither party may end the UK Addendum as set out in Section 19 of the UK Addendum. To the extent the Information Commissioner issues a revised Approved Addendum under Section 18 of the UK Addendum, the parties will work in good faith to revise this DPA accordingly.
The UK Addendum, and the EEA SCCs as amended by it, are governed by the laws of England and Wales, and disputes are resolved by the courts of England and Wales.

3.4 Transfers from Switzerland

For Personal Data transfers where Swiss law (and not the law in any EEA member state or the United Kingdom) applies to the international nature of the transfer, references to the GDPR in Clause 4 of the EEA SCCs are, to the extent legally required, amended to refer to the Swiss FADP or its successor instead, and the concept of supervisory authority will include the Swiss Federal Data Protection and Information Commissioner. The term "Member State" in the EEA SCCs will not be interpreted in a way that prevents data subjects in Switzerland from bringing claims in their place of habitual residence in Switzerland.

3.5 Alternative transfer mechanisms

If the European Commission, the UK government or another competent authority adopts updated or replacement standard contractual clauses, or another lawful transfer mechanism, that applies to transfers under this DPA, Provider may rely on it instead by notice to Customer, and the parties will take any steps reasonably needed to put it in place.

4. Security incidents

Upon becoming aware of any Security Incident, Provider will: (a) notify Customer without undue delay, and in any event no later than 72 hours after becoming aware of the Security Incident; (b) provide timely information about the Security Incident as it becomes known or as is reasonably requested by Customer, including, where available, the nature of the Security Incident, the categories and approximate number of data subjects and records concerned, its likely consequences, and the measures taken or proposed to address it; and (c) promptly take reasonable steps to contain and investigate the Security Incident.

Provider will send notifications by email to Customer's organisation admins. Provider's notification of or response to a Security Incident as required by this DPA will not be construed as an acknowledgement by Provider of any fault or liability for the Security Incident.

5. Audits and reports

5.1 Audit rights

Provider will give Customer all information reasonably necessary to demonstrate its compliance with this DPA, and Provider will allow for and contribute to audits, including inspections, by Customer or an independent auditor mandated by Customer, to assess Provider's compliance with this DPA. However, Provider may restrict access to data or information if Customer's access to the information would negatively impact Provider's intellectual property rights, confidentiality obligations (including to other customers) or other obligations under Applicable Laws.

Customer will first seek to verify Provider's compliance through the information described in Sections 5.2 and 5.3. Customer may carry out an audit or inspection if that information is not sufficient to demonstrate compliance, after a Security Incident affecting Customer Personal Data, or when a supervisory authority requires it. For any audit or inspection:

Customer will give at least 30 days' written notice to the Provider Security Contact, and the parties will agree the scope, timing and duration in advance;
it will take place during normal business hours and be conducted so as to minimise disruption to Provider's business;
it will take place no more than once in any 12-month period, unless it follows a Security Incident or a supervisory authority requires it;
any auditor will be bound by confidentiality obligations and will not be a competitor of Provider;
it will not give access to other customers' data; and
Customer will bear its own costs and the auditor's costs.

Provider will maintain records of its compliance with this DPA for 3 years after the DPA ends.

5.2 Security information

Upon written request, Provider will give Customer, on a confidential basis, up-to-date information about the measures in the Security Policy, together with any independent audit reports or certifications that Provider or its Subprocessors make available, so that Customer can verify Provider's compliance with the Security Policy.

5.3 Security due diligence

In addition, Provider will respond to reasonable requests for information made by Customer to confirm Provider's compliance with this DPA, including responses to information security, due diligence and audit questionnaires, or by giving additional information about its information security programme. All such requests must be in writing and made to the Provider Security Contact, and may only be made once a year, unless they follow a Security Incident or a supervisory authority requires them.

6. Cooperation

6.1 Response to inquiries

If Provider receives any inquiry or request from anyone else about the Processing of Customer Personal Data, Provider will notify Customer about the request, and Provider will not respond to the request without Customer's prior consent, other than to refer the requester to Customer. Examples of these kinds of inquiries and requests include a judicial, administrative or regulatory agency order about Customer Personal Data where notifying Customer is not prohibited by Applicable Law, or a request from a data subject. If allowed by Applicable Law, Provider will follow Customer's reasonable instructions about these requests, including providing status updates and other information reasonably requested by Customer.

The Service lets Customer access, correct, export and delete Customer Personal Data itself, which helps Customer respond to data subject requests. If a data subject makes a valid request under Applicable Data Protection Laws to delete or opt out of Customer's giving of Customer Personal Data to Provider, Provider will assist Customer in fulfilling the request according to the Applicable Data Protection Law. Provider will cooperate with and provide reasonable assistance to Customer, at Customer's expense, in any legal response or other procedural action taken by Customer in response to a third-party request about Provider's Processing of Customer Personal Data under this DPA.

6.2 DPIAs and DTIAs

If required by Applicable Data Protection Laws, Provider will reasonably assist Customer in conducting any mandated data protection impact assessments or data transfer impact assessments and consultations with relevant data protection authorities, taking into consideration the nature of the Processing and Customer Personal Data.

7. Deletion and return of data

7.1 Deletion by Customer

Provider will enable Customer to delete Customer Personal Data in a manner consistent with the functionality of the Service, for example by deleting content, removing users or deleting its organisation. Provider will comply with this instruction as soon as reasonably practicable, except where further storage of Customer Personal Data is required by Applicable Law. When an organisation admin deletes Customer's organisation, all Customer Personal Data, including uploaded files, is permanently deleted 30 days after the deletion request.

7.2 Return and deletion when the subscription ends

Customer can export Customer Personal Data (as JSON and CSV files, with download links for uploaded files) at any time during its subscription. When the subscription ends, Customer's account stays available in read-only mode for 30 days so that Customer can view and export its data. After that period, Provider will delete Customer Personal Data unless further storage is required or authorised by Applicable Law. Copies held in backups are overwritten in the normal backup cycle, no later than 30 days after deletion.

If return or destruction is impracticable or prohibited by Applicable Laws, Provider will make reasonable efforts to prevent additional Processing of Customer Personal Data and will continue to protect the Customer Personal Data remaining in its possession, custody or control. For example, Applicable Laws may require Provider to continue hosting or Processing Customer Personal Data.

7.3 Certification of deletion

If Customer and Provider have entered into the EEA SCCs or the UK Addendum as part of this DPA, Provider will only give Customer the certification of deletion of Personal Data described in Clause 8.1(d) and Clause 8.5 of the EEA SCCs if Customer asks for one.

8. Limitation of liability

8.1 Liability caps and damages waiver

To the maximum extent permitted under Applicable Data Protection Laws, each party's total cumulative liability to the other party arising out of or related to this DPA will be subject to the waivers, exclusions and limitations of liability stated in the Agreement.

Any claims made against Provider or its Affiliates arising out of or related to this DPA may only be brought by the Customer entity that is a party to the Agreement.

8.3 Exceptions

This DPA does not limit any liability to an individual about the individual's data protection rights under Applicable Data Protection Laws. In addition, this DPA does not limit any liability between the parties for violations of the EEA SCCs or the UK Addendum.

9. Conflicts between documents

This DPA forms part of and supplements the Agreement. If there is any inconsistency between this DPA, the Agreement or any of their parts, the part listed earlier will control over the part listed later for that inconsistency: (1) the EEA SCCs or the UK Addendum, (2) this DPA, and then (3) the Agreement.

10. Term

This DPA starts when Customer accepts the Agreement and continues until the Agreement expires or is terminated. However, Provider and Customer will each remain subject to the obligations in this DPA and Applicable Data Protection Laws until Customer stops transferring Customer Personal Data to Provider and Provider stops Processing Customer Personal Data, including during the export and deletion periods in Section 7.

11. Definitions

"Applicable Laws" means the laws, rules, regulations, court orders and other binding requirements of a relevant government authority that apply to or govern a party.
"Applicable Data Protection Laws" means the Applicable Laws that govern how the Service may process or use an individual's personal information, personal data, personally identifiable information or other similar term, including, where they apply, the GDPR, the UK GDPR, the Swiss FADP and the CCPA.
"Controller" will have the meaning(s) given in the Applicable Data Protection Laws for the company that determines the purpose and extent of Processing Personal Data.
"Customer Personal Data" means Personal Data that Customer uploads or provides to Provider as part of the Service, or that Provider receives on Customer's behalf through integrations Customer connects (such as Meta or Slack), and that is governed by this DPA. It is the Personal Data contained in the Customer Content defined in the Agreement.
"DPA" means this Data Processing Agreement, including the Key terms, its Annexes, and the policies and documents referenced in it.
"EEA SCCs" means the standard contractual clauses annexed to the European Commission's Implementing Decision (EU) 2021/914 of 4 June 2021 on standard contractual clauses for the transfer of personal data to third countries pursuant to Regulation (EU) 2016/679 of the European Parliament and of the Council.
"European Economic Area" or "EEA" means the member states of the European Union, Norway, Iceland and Liechtenstein.
"GDPR" means European Union Regulation 2016/679 as implemented by local law in the relevant EEA member nation.
"Key terms" means the section of this DPA headed "Key terms".
"Personal Data" will have the meaning(s) given in the Applicable Data Protection Laws for personal information, personal data or other similar term.
"Processing" or "Process" will have the meaning(s) given in the Applicable Data Protection Laws for any use of, or performance of a computer operation on, Personal Data, including by automatic methods.
"Processor" will have the meaning(s) given in the Applicable Data Protection Laws for the company that Processes Personal Data on behalf of the Controller.
"Restricted Transfer" means (a) where the GDPR applies, a transfer of personal data from the EEA to a country outside of the EEA which is not subject to an adequacy determination by the European Commission; and (b) where the UK GDPR applies, a transfer of personal data from the United Kingdom to any other country which is not covered by adequacy regulations under United Kingdom data protection law.
"Security Incident" means a Personal Data Breach as defined in Article 4 of the GDPR (or the equivalent term in other Applicable Data Protection Laws) affecting Customer Personal Data.
"Service" means the product and/or services described in the Agreement.
"Special Category Data" will have the meaning given in Article 9 of the GDPR.
"Subprocessor" will have the meaning(s) given in the Applicable Data Protection Laws for a company that, with the approval and acceptance of Controller, assists the Processor in Processing Personal Data on behalf of the Controller.
"Swiss FADP" means the Swiss Federal Act on Data Protection of 25 September 2020.
"UK GDPR" means European Union Regulation 2016/679 as implemented by section 3 of the United Kingdom's European Union (Withdrawal) Act 2018 in the United Kingdom, as amended.
"UK Addendum" means the international data transfer addendum to the EEA SCCs issued by the Information Commissioner for parties making Restricted Transfers under section 119A(1) of the Data Protection Act 2018.

Annex I — Details of processing

A. List of parties

Data exporter

Name: Customer, as identified in its AdCharter organisation and billing details.
Address: the address in Customer's billing details.
Contact person: Customer's organisation admins, at the email addresses registered in AdCharter.
Activities relevant to the transfer: use of the Service as described in Section B.
Role: Controller, or Processor where Customer Processes the data on behalf of its own clients (for example, an agency working for brands).
Signature and date: Customer is deemed to have signed this Annex by accepting the Agreement, on the date of acceptance.

Data importer

Name: [to be provided: company legal name], operator of AdCharter.
Address: [to be provided: company address].
Contact: [to be provided: privacy email address].
EU representative: [to be provided: EU representative].
UK representative: [to be provided: UK representative].
Activities relevant to the transfer: providing the Service as described in Section B.
Role: Processor, or Subprocessor where Customer is a Processor.
Signature and date: Provider is deemed to have signed this Annex on the date Customer accepts the Agreement.

B. Description of processing

Service: AdCharter.

Categories of data subjects (people whose Personal Data Customer and its users put into the Service):

Customer's users: team members, organisation and brand admins, members and guests;
invited guests, client approvers and reviewers, including people who act through personal task links without an account;
freelancers, such as video editors and designers;
content creators, including those who have a creator profile but no account;
people shown in uploaded images and videos;
Customer's own customers or other individuals, only if Customer includes them in content, comments or files.

Categories of personal data:

names, email addresses and roles in Customer's organisation and brands;
activity in the Service: tasks, approvals, feedback, state changes and history, including actions taken through task links;
comments and @mentions, and any personal data Customer includes in briefs, storyboards, ad copy or product information;
uploaded images and videos (such as creatives and creator footage) and their file details, which may show people;
content creator profiles: name, description and tags;
Slack user IDs matched by email address, and Slack channel IDs, when Slack is connected;
Meta business asset IDs (such as ad accounts, Pages, Instagram accounts and pixels), access tokens, ad content and aggregated performance metrics, when Meta is connected;
IP addresses and technical details (such as browser type) recorded in server logs.

Special category data: none intended. The Service is not designed to Process Special Category Data, and Customer should not submit it. If Customer's content incidentally contains it (for example, in creator footage), the measures in Annex II apply.

Frequency of transfer: continuous, for as long as Customer uses the Service.

Nature of processing: Provider will Process Customer Personal Data as instructed in Section 2.2. The nature of Processing includes:

receiving data, including collection, access, retrieval, recording and data entry;
holding data, including storage, organisation and structuring;
using data to run Customer's workflows, send notifications, launch ads in Customer's Meta ad accounts and show their performance, without automated decision-making or profiling of individuals;
updating data, including correction, adaptation and alteration;
protecting data, including restricting access and encryption;
sharing data with Approved Subprocessors and with integrations Customer connects, on Customer's instruction;
returning data to Customer through export;
erasing data, including destruction and deletion.

Purpose of processing: to provide the Service to Customer under the Agreement: planning, briefing, producing, approving and launching Meta ads, reporting on their performance, sending notifications by email and Slack, providing support and keeping the Service secure.

Duration and retention: as long as required (i) to carry out the Processing instructed in Section 2.2(a)–(d), namely for Customer's subscription and the 30-day read-only period after it ends, followed by deletion as described in Section 7 (with backup copies overwritten within 30 days); or (ii) by Applicable Laws.

Transfers to Subprocessors: the same subject matter and nature as above, limited to what each Subprocessor needs for the tasks described on the sub-processors page, for the duration of the Agreement or until Customer disconnects the relevant integration.

C. Competent supervisory authority

The supervisory authority of the data exporter, as determined in accordance with Clause 13 of the EEA SCCs. For transfers under the UK Addendum, the UK Information Commissioner. For transfers from Switzerland, the Swiss Federal Data Protection and Information Commissioner.

Annex II — Security measures

Provider maintains the following technical and organisational measures (the Security Policy).

Access control and tenant isolation

Customer data is separated by organisation and brand. Every database query on customer data is automatically limited to the organisations and brands the signed-in user may access.
Access is role-based per brand (organisation admin, brand admin, member and guest). Guests see only the items assigned to them, and content creators see only their own briefs and files.
Every subscription to live updates is checked for access before updates are delivered.
Administrative tools that work across customers are kept to a minimum, reserved for the platform operator and reviewed.

Sign-in with email and password requires a confirmed email address. Passwords are stored only as salted hashes.
"Sign in with Google" is optional and is linked to an existing account only when Google reports a verified email address.
Two-step sign-in with an authenticator app is available to every user, and admins are encouraged to turn it on.
Personal task links for people without an account are valid for 7 days, work only while the task is open, and actions taken through them are recorded under the invited person.
Forms are protected against cross-site request forgery.

Encryption

In transit: the Service is available over HTTPS only, and connections to Subprocessors and integrations use HTTPS.
At rest: access tokens and secrets (such as Meta and Slack tokens and payment provider keys) are encrypted in the database with ASP.NET Core Data Protection, whose keys are stored separately from the database.
Database backups are encrypted.

Files

Files are uploaded directly to file storage through short-lived signed links. The storage credentials stay on the server and never reach the browser.
Files are organised by organisation and brand, and AdCharter checks a user's access before issuing a time-limited download link.
Only accepted file types (images and videos within size limits) are stored.

Availability and backups

The database is replicated continuously (Litestream) to separate object storage (DigitalOcean Spaces), so that it can be restored after a server failure. The server restores the latest copy automatically if its database is missing.
Backup copies are kept for a limited period of no more than 30 days.
Background work, such as ad launches and notifications, is stored in the database and retried after errors, so that it survives restarts.

Infrastructure and configuration

Staging and production are separate environments, each with its own server, database, keys and integration settings.
A host firewall allows only the traffic the Service needs, and the application runs under a dedicated service account without administrator rights.
During initial setup, the server accepts connections only from the administrator's IP address.
Secrets are kept in protected configuration files on the server or encrypted in the database, never in source code.
Each release is checksummed; configuration, keys and the database are backed up before a release is deployed, and changes are tested on staging before production.
Calls to the Meta Marketing API are signed with an app secret proof, and payment webhooks are verified with a signing secret.
Physical security of servers and storage is provided by the data centres of the hosting provider listed among the Approved Subprocessors.

Logging and monitoring

Server logs record requests and errors (IP address, request path, browser details) for security and troubleshooting, and are kept for up to 30 days.
The Service keeps a history of actions on briefs and tasks, recorded under the person who took them.
A system health screen and automatic email alerts to the platform operator cover failed jobs, integrations that need reconnecting, backup status and disk usage, and an external uptime check monitors the Service.

Least privilege and personnel

Access to production systems and Customer Personal Data is limited to authorised personnel who need it to operate, support or secure the Service and who are bound by confidentiality obligations.
Integrations request only the permissions they need. For example, Google sign-in uses only the basic profile scopes (openid, email and profile), and the Slack app uses a small set of bot scopes.

Data minimisation, retention and erasure

AdCharter never receives payment card details; payments are handled on Stripe's hosted pages.
Performance data from Meta is limited to aggregated campaign metrics.
Customers can export their data and delete users or their organisation. Deleted organisations are permanently removed after 30 days, and backup copies are overwritten within 30 days.
Removing AdCharter in Facebook settings or disconnecting Meta deletes the connection's access token and Meta data. Slack data is deleted within 14 business days after the Slack app is removed.

Incident response

Security Incidents are contained, investigated and notified as described in Section 4.

Annex III — Sub-processors

The list of Approved Subprocessors on the sub-processors page is incorporated into this DPA by reference and forms Annex III. It sets out each Subprocessor's name, the Processing it carries out, the data concerned, its location and the transfer safeguard used, and it is updated as described in Section 2.6.

Licence and attribution

This DPA is based on the Common Paper Data Processing Agreement Standard Terms Version 1.1, available at https://commonpaper.com/standards/data-processing-agreement/1.1/, and used under the Creative Commons Attribution 4.0 International licence (https://creativecommons.org/licenses/by/4.0/). Programz has modified and adapted the text.