Data Processing Agreement

Parties and How This Agreement Applies

This Data Processing Agreement (“DPA”) is between Advanced Technology Labs LLC, 30 N Gould St Ste R, Sheridan, WY 82801, United States, operator of PaidSync.ai (“PaidSync”), and the customer who accepts the PaidSync Terms of Service (“Customer”). It is incorporated into and forms part of the Terms of Service, and applies where PaidSync processes personal data subject to the EU General Data Protection Regulation (“GDPR”) or the UK GDPR on the Customer’s behalf. Where the Terms of Service are accepted on behalf of a company or other organisation, the Customer is that organisation; where they are accepted by a sole trader for their business, the Customer is that sole trader. A user the Customer invites to its workspace does not become a separate party to this DPA.

The Customer accepts this DPA electronically by accepting the Terms of Service, and no separate signature is needed, as set out in section 14. In the event of conflict, this DPA prevails over the Terms of Service, and the Standard Contractual Clauses in section 12 prevail over this DPA.

1. Roles

PaidSync holds two different roles depending on the data, and this DPA governs only the first.

Processor. For the advertising account data the Customer connects and the instructions the Customer issues through the Service, PaidSync acts as the Customer’s processor. Where the Customer is itself a processor for its own clients, PaidSync acts as a sub-processor and this DPA operates as the Article 28(4) flow-down. The Customer confirms it holds the authorisation of its own controllers to engage PaidSync.

Controller. For the Customer’s account, profile, billing, security, support-contact and product-usage data, PaidSync is an independent controller and the Privacy Policy governs.

Not sub-processors. The advertising platforms the Customer connects (Google, Meta, LinkedIn, TikTok, Microsoft, Snapchat, Reddit, Pinterest, X and OpenAI Ads) act under the Customer’s own direct agreements with them. PaidSync passes the Customer’s reads and writes to them on instruction. The Customer’s own AI assistant (for example Claude or ChatGPT used over MCP) is engaged by the Customer under its own agreement with that vendor and is not PaidSync’s sub-processor. The same applies to a model provider whose API key the Customer supplies to the Service, which acts under the Customer’s own agreement with it. PaidSync’s MCP server sends nothing to any model provider, except that its image generation tool sends the image description it is given to Google Gemini. Microsoft Clarity, which records how people use the paidsync.ai website and workspace for PaidSync’s own purposes described in the Privacy Policy, receives those recordings as an independent controller and is not a sub-processor; its recordings mask all text shown on screen, so no data from connected advertising accounts reaches it.

2. Scope of the GDPR and of the Transfer Clauses

PaidSync is established in the United States. For the processing covered by this DPA, PaidSync acts on the Customer’s documented instructions. Where the controller, meaning the Customer or, where the Customer acts as a processor, the client for which it acts, is established in the Union, the European Data Protection Board treats PaidSync’s processing on its behalf as not subject to the GDPR in its own right; PaidSync is bound by the obligations of Article 28 through this contract, and the Standard Contractual Clauses in section 12 apply to it in full. Where that controller is established outside the Union and its processing is subject to the GDPR under Article 3(2), the European Data Protection Board considers PaidSync’s processing on its behalf to be subject to the GDPR under Article 3(2) as well; the Clauses still bind PaidSync as terms of this DPA, but the European Commission’s position is that they do not serve as the transfer safeguard for that processing. PaidSync’s independent processing of the controller data described in section 1, where it acts as a controller offering a service to persons in the Union, is outside this DPA and outside the Standard Contractual Clauses in section 12, and is addressed in the Privacy Policy.

3. Processing on Documented Instructions

PaidSync processes personal data only on the Customer’s documented instructions, being this DPA, the Terms of Service, and the actions the Customer or its authorised users take in the Service, unless required otherwise by applicable law, in which case PaidSync informs the Customer first unless the law prohibits it. PaidSync immediately informs the Customer if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection provisions.

PaidSync does not sell personal data, does not use it to serve advertising, and does not use Customer personal data to train generalised or non-personalised AI or machine learning models. The model providers PaidSync engages receive Customer personal data under contractual terms that prohibit training on it. No data derived from the Customer’s connected advertising accounts is used for product development, analytics or benchmarking without a separate written instruction; finding and fixing faults in the Service, as described in Annex 1, and testing new versions of the Service against the production database are part of providing it.

The Customer warrants that the processing it instructs has a lawful basis, that any notices to data subjects and any consents that applicable law requires for that processing have been given and obtained, and that it is entitled to connect to the Service each advertising account it connects. To the extent the Customer acts as processor for its own clients, the lawful basis, notices and consents are the relevant controller’s responsibility, and in place of those warranties the Customer warrants that its instructions, including its engagement of PaidSync, have been authorised by that controller. Assistance or processing beyond the functionality of the Service, and beyond what Article 28 GDPR, this DPA and the Standard Contractual Clauses require of PaidSync, needs the parties’ prior written agreement and may carry a reasonable fee. PaidSync informs the Customer immediately if it is unable to follow an instruction.

4. Confidentiality

Persons authorised to process personal data are bound by written confidentiality obligations, and access is limited to those who need it to deliver the Service.

5. Security

PaidSync implements the technical and organisational measures in Annex 2, which reflect what is enforced in the Service today, including the gaps stated plainly there.

6. Sub-processors

The Customer gives general written authorisation for the sub-processors listed at paidsync.ai/security#sub-processors, which is the single current list and is derived from the services the code connects to and the email service PaidSync uses for support. PaidSync gives at least 30 days notice by email to the workspace owner before adding or replacing a sub-processor. The Customer may object on reasonable data protection grounds within that period. If the objection cannot be resolved, the Customer may terminate the affected service without penalty for the unused prepaid term. PaidSync imposes data protection obligations on each sub-processor no less protective than this DPA and remains liable for their performance. On request PaidSync provides a copy of the relevant sub-processor terms.

7. Data Subject Rights

PaidSync assists the Customer by appropriate technical and organisational measures, insofar as possible, in responding to data subject requests, and forwards any request it receives directly to the Customer without responding itself. Erasure of stored daily summaries for a connected account is actioned within 30 days of a request to support@paidsync.ai. On a request to the same address, PaidSync also erases within 30 days any other Customer personal data described in Annex 1, for the whole account or, for the records kept for a brand, a named brand, including after the Customer’s account is deleted, as set out in section 10. Erased data can remain in backups and archived copies as set out in Annex 2.

8. Personal Data Breach

PaidSync notifies the Customer without undue delay, and in any event within 48 hours of becoming aware of a personal data breach affecting Customer personal data, with the information available at the time, supplemented as the investigation progresses.

9. Impact Assessments

PaidSync provides reasonable assistance with data protection impact assessments and prior consultation with a supervisory authority, taking into account the nature of processing and the information available to it. On request PaidSync supplies the technical inputs to the Customer’s transfer impact assessment.

10. Deletion and Return

The Customer may delete its account from Settings at any time. On a deletion request the user is signed out, and after a 30 day recovery window the Service’s automated deletion hard deletes the profile, the brand records the Customer created with each brand’s profile, brief and saved instructions, up to 200 approval cards per brand, any workspace the Customer owns, automations, PaidSync API keys, connected platform tokens and the authentication record. Account deletion does not by itself erase the other records described in Annex 1, including the conversation history, the change log, the daily advertising summaries, cached reports, run records and saved workflows, any model provider API key a user supplied, and the other records kept for each brand. Public report links that the Customer’s users created, or that show the Customer’s brands, are erased with the account. Deleting a brand in the workspace archives it and removing a chat only hides it; neither erases data. Until the deletion becomes permanent, automations the Customer has enabled keep running and connected advertising accounts can keep syncing; to stop that processing at once, the Customer pauses its automations and disconnects its advertising platforms before requesting deletion.

On a request to support@paidsync.ai, PaidSync erases those records within 30 days, for the whole account or, for the records kept for a brand, a named brand, including after the account is deleted, and confirms in writing when it has done so, naming any backups or archived copies in which the data remains until they expire or are deleted. When an account deletion becomes permanent, PaidSync treats it as the choice of deletion under Clause 8.5 of the Standard Contractual Clauses for that account’s records and, within the following 30 days and without a further request, erases the records described in Annex 1 that remain for that account, including the error text described below, and confirms in writing to the email address on the account when it has done so. The automated emails sent when a deletion is requested and when it becomes permanent are not the confirmation of deletion under Clause 8.5. Where the Customer has invited other users to its workspace, only the deletion of the account that owns that workspace is treated as the Customer’s choice under Clause 8.5; when an invited user deletes their own account, PaidSync erases the records that remain for that user only on the Customer’s request. A Customer that wants its data returned instead asks support@paidsync.ai for a copy before deleting its account; self-serve export is not built, and PaidSync produces the copy on request. If PaidSync suspends or terminates the Customer’s account, the Customer can still ask support@paidsync.ai for a copy or for erasure under this section.

After account deletion, PaidSync keeps its own records of individual tool calls, which are billing and product-usage records for which it is controller under section 1, for 7 years with the user identifier, email address and name removed; until PaidSync erases it as described above, the record of a call that failed can keep up to 300 characters of the error message returned for it, which can contain Customer personal data. A deletion audit log, which keeps the user identifier and email address, is kept for 7 years. Invoices and the customer record held by Stripe keep the details, such as name, email address and any billing address, that tax records need. Erased data can remain in backups and archived copies as set out in Annex 2.

11. Audit

PaidSync makes available the information necessary to demonstrate compliance with Article 28 and answers security questionnaires in writing within two business days. Access and change logs for the Customer’s workspace are produced on request. No independent third-party audit report (SOC 2, ISO 27001) exists today and PaidSync does not claim one. The Customer may conduct an audit or inspection no more than once per year on 30 days written notice, and additionally following a personal data breach, at its own cost, subject to confidentiality and to not compromising other customers’ security.

The Customer keeps confidential PaidSync’s written questionnaire answers and any information it obtains through an audit or inspection under this section, and may share them only with its professional advisers and auditors bound by confidentiality, any controller for which the Customer acts as processor, a competent supervisory authority, in legal or regulatory proceedings relating to the processing, or as applicable law requires. This does not apply to information that is public other than through a breach of this section. Audits under Clause 8.9 of the Standard Contractual Clauses are carried out in accordance with this section, to the extent the Standard Contractual Clauses permit.

12. International Transfers

PaidSync’s database, its scheduled backups and uploaded files are in the United States, in Google Cloud region us-central1 in Iowa, where PaidSync’s backend also runs, and the web application’s server functions run on Vercel in Washington, D.C., United States. Copies of the database made for a May 2026 hosting migration are in Google Cloud’s United States multi-region. Requests reach them through Vercel’s and Google’s global networks, and Vercel decrypts each request in the Vercel region nearest the user before passing it on. Application and audit logs are kept in Google Cloud Logging, which may store them in any Google data centre, and Vercel also keeps logs of the web application’s server functions. Some sub-processors, including the model providers, may process personal data outside the United States; the list referred to in Annex 3 gives each one’s location. Personal data transferred to PaidSync leaves the EEA. Advanced Technology Labs LLC is not certified under the EU-US Data Privacy Framework and will notify the Customer if that changes.

The parties incorporate the Standard Contractual Clauses approved by Commission Implementing Decision (EU) 2021/914, completed as follows. Module Two (controller to processor) applies where the Customer is a controller. Module Three (processor to processor) applies where the Customer is a processor for its own clients. Module One (controller to controller) does not apply, as set out in section 2. Clause 7, the docking clause, does not apply. Under Clause 9, Option 2, general written authorisation, applies with the 30 day notice period in section 6. Under Clause 11, the optional independent dispute resolution paragraph does not apply. Under Clause 13, the competent supervisory authority is that of the Member State in which the Customer is established; where the Customer is not established in a Member State but falls within Article 3(2) GDPR, it is that of the Member State in which the Customer’s representative under Article 27(1) is established or, where the Customer need not appoint one, that of a Member State in which the data subjects concerned are located. Under Clause 17, the Clauses are governed by the law of Ireland. Under Clause 18, disputes are resolved before the courts of Ireland. Annexes I, II and III to the Clauses are populated by Annexes 1, 2 and 3 to this DPA.

For transfers subject to the UK GDPR, the UK International Data Transfer Addendum to the Clauses issued by the Information Commissioner applies. PaidSync will conduct and document a transfer impact assessment where required, and will notify the Customer if it becomes unable to comply with the Clauses.

13. Governing Law and General

This DPA is governed by the law of Ireland and the parties submit to the courts of Ireland for any dispute arising under it, and the Governing Law section of the Terms of Service does not apply to this DPA or to the Standard Contractual Clauses. To the extent permitted by the Standard Contractual Clauses and applicable data protection law, PaidSync’s liability to the Customer arising out of or related to this DPA is subject to the limitations and exclusions of liability in the Limitation of Liability section of the Terms of Service as it read on the date of this version of this DPA, other than its disclaimer of warranties. Those limitations and exclusions do not apply to liability for fraud, wilful misconduct or gross negligence, or for death or personal injury. Nothing in this DPA or in the Terms of Service limits liability to data subjects, including under Article 82 GDPR and the Standard Contractual Clauses, or any other liability that cannot be limited under applicable data protection law. Save as amended by this DPA, the Terms of Service remain in force.

14. Execution and Changes

Acceptance of the Terms of Service is acceptance of this DPA. A Customer that accepted an earlier version accepts this version by continuing to use the Service for 30 days after PaidSync has emailed a link to it to the email address on the Customer’s account; during those 30 days the earlier version applies and the Customer may object by email and terminate the affected service. Acceptance has the same effect as each party signing the Standard Contractual Clauses incorporated in section 12, including Annex I, and, where it applies, the UK International Data Transfer Addendum, and the parties are deemed to have signed them as of the date the Customer accepts this version of this DPA. Where the Customer accepted an earlier version, that version applied until this version took effect. No separate signature is needed for this DPA or those Clauses to apply. The person who accepts the Terms of Service for the Customer confirms that they are authorised to bind the Customer.

PaidSync may update this DPA only where applicable data protection law requires it or to add protection for the Customer or for data subjects, by email to the workspace owner at least 30 days before the update takes effect, and no update lowers the protection that the Standard Contractual Clauses give. The Customer may object to an update by email before it takes effect and may then terminate the affected service; continuing to use the Service after the update takes effect is the Customer’s approval of it. Any other addition, deletion or change to this DPA, whether made on a copy of it or in another document, has no effect unless PaidSync agrees to it in a written amendment signed by PaidSync, and until then this DPA applies without it. Completing or updating the Customer’s own details as data exporter, and giving instructions under section 3, are not changes to this DPA.

Annex 1. Details of Processing

Data exporter (list of parties). The Customer, as identified in its PaidSync account and contactable at the email address on that account, together with any data protection officer or representative it names to PaidSync; the Customer may send its legal name and address for this entry to support@paidsync.ai. Activities relevant to the data transferred: use of the PaidSync.ai platform to read and manage its advertising accounts. Role: controller, or processor where it acts for its own clients. Signature and date: the Customer is deemed to have signed by accepting this DPA as set out in section 14, as of the date set out there.

Data importer (list of parties). Advanced Technology Labs LLC, operator of PaidSync.ai, 30 N Gould St Ste R, Sheridan, WY 82801, United States; contact person Ahmed Ashraf, founder, at support@paidsync.ai. Activities relevant to the data transferred: provision of the PaidSync.ai platform as described in this Annex. Role: processor, or sub-processor where the Customer acts for its own clients. Signature and date: PaidSync is deemed to have signed as of the same date.

Subject matter. Provision of the PaidSync.ai platform, which lets the Customer and AI assistants acting on the Customer’s instruction read and manage the Customer’s connected advertising accounts.

Duration. The period the Customer uses the Service, then, after an account deletion, the 30 day recovery window and up to 30 days for PaidSync to complete erasure, as set out in section 10, and, for data in backups and archived copies, until they expire or are deleted as set out in Annex 2.

Nature and purpose. Connecting advertising accounts by OAuth or, for OpenAI Ads and Meta agency access, with a key or token the Customer enters, reading advertising performance data, reading lead-form submissions and uploading customer lists when the Customer asks, executing changes the Customer or its authorised users approve or instruct, storing daily aggregate summaries and cached report sections so reports open quickly, summarising report data with a model provider, keeping conversation history so chats can be reopened, keeping the brand records, plans, findings, notes, files and run records the Customer and its agents create, running code and saved workflows sent by the Customer’s assistant and recording each run, answering the Customer’s instructions with a model provider, logging changes, recording failed tool calls with the error returned in order to find and fix faults in the Service, sharing a report by link when the Customer creates one, and emailing the Customer’s users about pending approvals, account performance and connections that stop working.

Categories of data subjects. The Customer’s own personnel who hold PaidSync workspace accounts. Data subjects whose data sits inside the Customer’s connected advertising accounts, to the limited extent described below, including individuals who submit the Customer’s lead forms. Individuals whose details the Customer supplies for a customer list upload. Any individual the Customer’s users reference in free-text instructions, notes or uploaded files.

Categories of personal data, stored by PaidSync. Name and email address recorded against a connected advertising account, and the email address recorded against a change made to one or a run of code. OAuth tokens for connected advertising accounts, and the API keys and system user tokens used to connect OpenAI Ads and Meta agency access, encrypted at rest with AES-256-GCM. Any model provider API key a user supplies, encrypted at rest with AES-256-GCM under a separate key-encryption key. A daily summary per connected advertising account: date, account identifier, currency, and that day’s spend, impressions, clicks, conversions and conversion value, kept with the account’s name, its connection and sync status including the last error message the platform returned, and, for its recent ads, their name, status, metrics and a link to their thumbnail image. Cached report and dashboard sections for each brand, with a short written summary of each report, and copies of reports the Customer shares by link, which anyone holding the link can open until it expires or is revoked. For each brand, its profile and brief, the instructions and memory notes (up to 500 characters each) saved by the Customer or its agents, text extracted from files uploaded as brand knowledge (up to 150,000 characters per file), custom skills, media plans, audit findings, brand analyses and plans made with the Operator, records of agent and automation runs including each phase’s result of up to 8,000 characters, outcome measurements for changes applied in the workspace, and in-app notifications. Approval cards, which hold the account, tool, arguments and expected effect of each proposed change. The brand’s audit log of changes applied in the workspace, from an approval card or automatically, with the user, each change’s full arguments and its result. The change log of changes applied through PaidSync from any client, which keeps a summary of up to 600 characters of the arguments; for a customer list upload that summary can include the email addresses, phone numbers, names, dates of birth, postcodes and other identifiers supplied. When the Customer uses the chat or the Operator inside paidsync.ai, the conversation history: conversation titles, the user’s instructions, the replies and up to 4,000 characters of each result used to answer. When code is run through PaidSync’s code-running tool, or a saved workflow is run, from the Customer’s own AI assistant, a run record: the code sent (up to 8,192 characters), the tools it called with any error they returned, and the first 1,024 characters of its result, with the user’s identifier and email address; and the workflows the Customer saves. When a tool call fails, up to 300 characters of the error message returned for it, kept in PaidSync’s own record of that call, which is otherwise billing and product-usage data for which PaidSync is controller under section 1. Automations the Customer sets up, with their instructions, schedules and settings. Ad creatives the Customer uploads. Application logs, which can include users’ email addresses, IP addresses and advertising account identifiers.

Read or passed through in session. Whatever report the Customer requests, which can include search-term reports containing what people typed into the search engine. Lead-form submissions (name, email address, phone number and the answers given), read from Meta when the Customer asks for them. Email addresses, phone numbers, names and other identifiers the Customer supplies for a customer list upload, which PaidSync hashes before sending them to Google or Meta. Offline conversion data the Customer supplies for upload, such as click identifiers, which is passed to the advertising platform. Audience lists are read as name and size only, and their members are never read from the platform. Parts of what is read or passed through are kept where the stored categories above say so: in the conversation history, the run records and the change log. Keyword lists, ad text, audience lists and customer match data are not copied into the daily summaries.

Sent to a model provider. When the Customer uses the chat, the Operator or brand profile generation inside paidsync.ai, and each time an automation the Customer set up runs, the instruction and the data needed to answer it, including the brand’s saved instructions and parts of its knowledge files when they are relevant. When a report is refreshed, including automatic background refreshes that can run as often as hourly for brands viewed in the previous 24 hours or where an approval card was applied in the previous 30 days, the report’s figures and the names of the accounts in it are sent to OpenAI to write a short summary. When the Customer uses PaidSync over MCP from its own AI assistant, nothing, except the image description sent to Google Gemini when the image generation tool is used.

Special category data. None instructed. The Customer will not instruct, and PaidSync will not knowingly process, Article 9 or Article 10 data.

Frequency. Continuous while the Customer uses the Service.

Retention. Tokens and keys for connected advertising accounts, and the name and email recorded with them, for the life of the account, then a 30 day recovery window, then hard deleted; tokens for a disconnected platform are deleted on disconnect. The brand records with each brand’s profile, brief and saved instructions, up to 200 approval cards per brand, and automations, for the life of the account, then hard deleted with it. Uploaded ad creatives are deleted 30 days after upload. Application logs are kept for 30 days. Every other category above is kept until PaidSync erases it, which it does within 30 days of a request to support@paidsync.ai and, without a request, within 30 days after an account deletion becomes permanent, as set out in section 10; account deletion does not remove these records by itself. For records of tool calls, erasure removes the error text; the rest of each record is PaidSync’s own billing and product-usage record under section 1, kept for 7 years without the user identifier, email address or name, as the Privacy Policy describes. When an account is first connected, the last 90 days of its history are fetched, and older history, up to 365 days back, can be fetched later. Erased data can remain in backups and archived copies as set out in Annex 2.

Competent supervisory authority. That of the Member State in which the Customer is established, or as otherwise set out for Clause 13 in section 12.

Annex 2. Technical and Organisational Measures

Derived from what is enforced in code and in the production configuration. The product controls are also documented at paidsync.ai/security. Gaps are stated rather than omitted; where the detail of a gap would itself help an attacker, it is given to customers on request under section 11.

Encryption. OAuth tokens for connected advertising accounts, and the API keys and system user tokens used to connect OpenAI Ads and Meta agency access, encrypted at rest with AES-256-GCM. Customer-supplied model provider keys encrypted at rest with AES-256-GCM under a separate key-encryption key. All service endpoints served over TLS. Web and API endpoints are served over HTTPS only, with HTTP Strict Transport Security. Firestore data encrypted at rest by Google Cloud.

Access control and authentication. The Customer connects each advertising platform through that platform’s own OAuth screen, except OpenAI Ads, connected with an API key, and Meta agency access, connected with a system user token, either of which the Customer enters in PaidSync. PaidSync never requests or holds an advertising platform password. MCP clients authenticate by OAuth 2.0 with PKCE and dynamic client registration. An API key cannot apply changes to Google Ads, where it allows only reads and dry runs; on the other platforms an API key can apply changes, subject to the same checks as an OAuth session. Role-based access control with viewer, editor, admin and owner. Only an admin or owner may place an agent in a band that executes without a person, or turn on auto-approve for a brand. Disconnecting a platform deletes its tokens.

Access to production. One person, PaidSync’s founder, holds administrative access to the Google Cloud project, the hosting account and the source code. Browser clients can reach the database directly only for their own user record, their own API key and a shared grader report opened by its link; the Firestore security rules deny all other direct access, and the release checks compare the published rules with the reviewed rules whenever a Google Cloud credential is available to them.

Tenancy isolation. Each session is bound to one active account per platform. Inside a code run or saved workflow, a mutation naming a different account than the run is anchored to is refused before the platform API is called; a tool called directly, including from the workspace, acts on the account it names or, when it names none, on the active account. Tenancy invariants are asserted by automated checks on deploy.

Integrity of processing. In the paidsync.ai workspace, meaning the chat, the Operator, the specialist agents and automations, by default every change is written as an approval card showing account, tool, arguments and expected effect, and requires a person to approve before the write runs. An admin or owner may instead place an agent in a band that executes without a person (act with guardrails or full auto), or turn on auto-approve for a brand so that its chat applies changes without a card; in those cases the spend ceilings and the protected-campaign list still apply, and the tools that can never run automatically still become cards. When the Customer’s own AI assistant, or another client the Customer connects by OAuth or with an API key, calls PaidSync directly over MCP, PaidSync writes no approval card and applies no spend ceiling, kill switch or protected-campaign list: a change runs when the client calls the tool with the dry run turned off and, for a destructive tool, the confirmation flag set, and whether a person confirms it first depends on the Customer’s own client. On every path, every Google Ads create tool and most other create tools default to a dry run, although some Google Analytics, Google Tag Manager and creative-upload tools have no dry run and apply on the first call; a pre-write validator checks arguments against the platform rule set and blocks or warns, destructive tools require an explicit confirmation flag, and inside a code run or saved workflow the account check described under tenancy isolation applies. In the workspace, spend ceilings are derived from the Customer’s configured monthly cap, a named list of tools can never run automatically in any band, and two independent kill switches stop automatic changes, the platform gate failing closed. After a write, some tools read the changed object back and compare it with what was sent; in the workspace, a write counts as applied only when the platform’s response confirms the change, such as an old and new value, a count or the new object’s identifier, and a mismatch or a missing confirmation is reported as a failed write. A card moves from pending to executing in one atomic step.

Logging and accountability. Live mutations are written, on a best-effort basis, to a change log with user, account, tool, argument summary and actor, whichever client made it; a change on a platform other than Google Ads, Meta, LinkedIn, Microsoft or TikTok is recorded against the account active in the session, and a change is not recorded when no account is set for its platform. Changes applied in the workspace, from an approval card or automatically, are also written with the user, their full arguments and results to the brand’s audit log. Changes applied from an approval card store an inverse for one-tap undo where the platform offers a safe one; for a change applied automatically in the workspace, the inverse is kept with the outcome check so that a rollback card can be raised if the change regresses; changes made from the Customer’s own AI assistant have no stored undo. A daily check measures each change applied in the workspace 7 days later, comparing spend, conversions, CPA and ROAS, and the change log reports a before-and-after outcome for each change it records. Administrative changes to the Google Cloud project are recorded in audit logs kept for 400 days, and writes to the database and to the sign-in service in audit logs kept for 30 days. Application logs are kept for 30 days.

Availability and resilience. The database runs in Google Cloud region us-central1, where Google replicates it across several zones, with delete protection switched on. The backend runs on Google Cloud Run in the same region with at least two instances running at all times, and the web application’s server functions run on Vercel in its Washington, D.C. region.

Backup and restore. Point-in-time recovery keeps seven days of earlier versions of the database, and a backup is taken weekly and kept for 98 days in the same region. Copies of the database made in May 2026 for a hosting migration, held in Google Cloud’s United States multi-region, and the database as it stood before that migration, held in an earlier Google Cloud project in us-central1, are also kept until PaidSync deletes them, no later than October 31, 2026. Data erased from the live database remains in these copies until they are deleted. Files deleted from Cloud Storage remain recoverable for 7 days.

Testing of measures. Every production release of the web application and of the backend runs more than 130 automated checks before it can be deployed, including checks that one customer’s session cannot reach another customer’s accounts and that admin and billing endpoints refuse forged identities, and a failed check stops the release. After each backend release, a synthetic cross-customer test runs against the new version. A scheduled job re-inserts known past defects to confirm the checks still catch them.

Vulnerability management. A job scheduled daily on PaidSync’s own workstation scans the dependencies of the product code for known vulnerabilities; a run that cannot complete is reported as a finding, and critical findings are escalated. A release is blocked if a credential-shaped file would be published.

Incident response. Security reports go to support@paidsync.ai. PaidSync’s founder handles each security report and incident, and confirmed security defects receive regression checks in the release checks. Personal data breaches are notified as set out in section 8.

Physical security. PaidSync runs no data centres of its own; Google Cloud, Vercel and Vercel’s infrastructure providers operate the facilities. Google commits in its Cloud Data Processing Addendum to maintain ISO 27001 certification and annual SOC 2 and SOC 3 reports for its audited services, and Vercel’s data processing addendum provides for an annual independent audit such as SOC 2 Type 2.

Deletion. Self-serve account deletion from Settings, with the user signed out at once, a 30 day recovery window, then hard deletion of the records listed in section 10. The other records described in Annex 1 are not removed by account deletion, deleting a brand only archives it, and removing a chat in the workspace only hides it; PaidSync erases those records by hand within 30 days after the deletion becomes permanent, and within 30 days of a request to support@paidsync.ai, as set out in section 10.

Assistance with data subject requests. A request PaidSync receives directly from a data subject is forwarded to the Customer. A copy of the Customer’s data is produced by email on request. Erasure is carried out within 30 days of a request, for the whole account or, for the records kept for a brand, a named brand, and for the daily summaries of a named connected advertising account, as set out in sections 7 and 10.

Stated gaps, as of the version date above. No SOC 2, ISO 27001 or other independent third-party audit report, and no independent penetration test. No automated audit log export; logs are produced on request. No self-serve data export; produced on request. Single sign-on on request, not by default. No multi-step approval chain; one approval from an editor or above executes a card. Multi-factor sign-in is not available for PaidSync user accounts. Reads of the database are not recorded in an audit log. There is no second hosting region, no uptime commitment and no continuous uptime monitoring with alerting. Restoring from the scheduled backups or from point-in-time recovery has not been tested. The copies of the database from the May 2026 hosting migration, and the database as it stood before that migration, are kept until PaidSync deletes them no later than October 31, 2026, so until then data held before that migration cannot be erased from every copy. Erasure after account deletion is carried out by hand rather than by the Service. Dependency scanning runs from PaidSync’s own workstation rather than a hosted pipeline, and some findings rated high or medium in third-party libraries remain open. There is no written incident response plan, no dedicated security team and no on-call rota. Further detail on these and other gaps is available to customers on request, under the confidentiality terms of section 11.

Annex 3. Authorised Sub-processors

The current list of sub-processors, with each one’s legal entity, location and what it receives, is maintained at paidsync.ai/security#sub-processors and is incorporated here by reference. A service on that list is a sub-processor under this DPA only where it processes, on PaidSync’s behalf, personal data that PaidSync processes as the Customer’s processor, and the list groups the services on that basis. The advertising platforms on that list are not sub-processors, as section 1 sets out. The Customer’s general authorisation under section 6 covers the services in the list’s Sub-processors group; any other service that comes to process such data on PaidSync’s behalf is treated as an addition under section 6. Where processing takes place is set out in section 12. Notice of additions or replacements, and the Customer’s right to object, are set out in section 6.

Contact

Questions about this DPA or requests for sub-processor terms go to support@paidsync.ai.