Data Processing Agreement

apublished

Version 1.0 Last updated: 8 August 2026 Effective: 8 August 2026

How this document works

This Data Processing Agreement ("DPA") forms part of the Terms of Service between you ("Customer") and Hippolyte Surer, sole proprietor, Avenue du Delay 11, 1110 Morges, Switzerland ("apublished", "we", "us").

It applies automatically, without signature, whenever we process personal data on the Customer's behalf and the Customer is subject to the EU General Data Protection Regulation, the UK GDPR or the Swiss Federal Act on Data Protection. Accepting the Terms of Service accepts this DPA.

If your procurement process requires a signed copy, or your own DPA template, write to legal@apublished.com. We will sign this document as it stands, and we will look at a reasonable alternative, but we cannot accept terms that conflict with what the social platforms require of us.

Order of precedence. On the subject of personal data processed on the Customer's behalf, this DPA prevails over the Terms of Service and the Privacy Policy. The Standard Contractual Clauses incorporated by Section 11 prevail over this DPA where they conflict.

1. Definitions

"Data Protection Law" means, as applicable: Regulation (EU) 2016/679 (the "GDPR"); the GDPR as incorporated into UK law by the European Union (Withdrawal) Act 2018 together with the UK Data Protection Act 2018 (the "UK GDPR"); and the Swiss Federal Act on Data Protection of 25 September 2020 with its Ordinance (the "FADP").

"Customer Personal Data" means personal data contained in Customer Content or otherwise processed by us on the Customer's behalf through the Service.

"Controller", "Processor", "Data Subject", "Personal Data", "Processing" and "Personal Data Breach" have the meanings given in the GDPR. Under the FADP, "Controller" corresponds to the responsible party and "Processor" to the order processor.

"SCCs" means the Standard Contractual Clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.

"UK Addendum" means the International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018, version B1.0.

"Subprocessor" means a processor engaged by us to process Customer Personal Data.

Other capitalised terms have the meaning given in the Terms of Service.

2. Roles of the parties

The Customer is the Controller of Customer Personal Data. apublished is the Processor.

Where the Customer is itself a processor acting for another controller, apublished is a subprocessor, and references to the Customer's instructions include instructions passed down from that controller. The Customer confirms that it has the authority to appoint us on those terms.

apublished is an independent Controller for the account, billing, support, security and website data described in Section 3 of the Privacy Policy. This DPA does not apply to that data.

3. Subject matter and details of processing

The subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out in Annex I.

The processing lasts for the term of the Terms of Service, plus the retention periods described in Section 10.

4. Instructions

We process Customer Personal Data only on the Customer's documented instructions, including as to transfers to a third country, unless required to do otherwise by Union, Member State or Swiss law to which we are subject. In that case, we inform the Customer of that legal requirement before processing, unless the law prohibits it on important grounds of public interest.

The Customer's documented instructions are:

(a) the Terms of Service and this DPA; (b) the Customer's use of the Service through its interfaces, including every API call, MCP call and scheduled target, which constitutes an instruction to process the data it contains for the purpose that call describes; (c) any further written instruction the parties agree.

We will tell the Customer if, in our opinion, an instruction infringes Data Protection Law. We may suspend performance of an instruction that we reasonably believe is unlawful, or that would put our access to a platform at risk, until it is resolved.

We do not use Customer Personal Data for our own purposes. We do not use it to train machine learning models, to build profiles, for advertising, or to create any product other than the Service provided to the Customer.

5. Customer obligations and warranties

The Customer warrants that:

• it has a valid legal basis for the processing it instructs, and has given the notices and obtained the consents that Data Protection Law requires from data subjects, including from any person whose personal data appears in Customer Content;
• it has the authority of each social media account holder whose channel it connects, including any consent the platform requires before content is published on that holder's behalf;
• its instructions comply with Data Protection Law and with the terms of the platforms to which it publishes;
• it will not send us special categories of personal data under Article 9 GDPR, data relating to criminal convictions and offences under Article 10 GDPR, or sensitive personal data under the FADP, unless it has told us in advance and the parties have agreed the additional measures in writing. The Service is not designed for such data.

The Customer is responsible for the accuracy, quality and legality of Customer Personal Data and of the means by which it acquired it.

6. Confidentiality

We ensure that every person authorised to process Customer Personal Data, whether employee or contractor, is bound by an appropriate obligation of confidentiality that survives the end of their engagement, and is trained in their obligations. Access is limited to those who need it to perform the Service.

7. Security

We implement and maintain the technical and organisational measures set out in Annex II, taking into account the state of the art, the costs of implementation, and the nature, scope, context and purposes of processing, as well as the risk to data subjects.

We may update those measures, provided that the level of protection is not reduced. The current version of Annex II is always the one published at apublished.com/dpa.

8. Subprocessors

General authorisation. The Customer gives a general authorisation for us to engage Subprocessors, subject to this Section.

Current list. The Subprocessors engaged as at the date of this DPA are listed at apublished.com/subprocessors, with their role, the processing they perform and their location. That page is incorporated into this DPA.

Changes. We will give the Customer at least 30 days' notice before adding or replacing a Subprocessor. Notice is given by email to the account address and by updating the subprocessor page. The Customer may subscribe to change notifications from that page.

Objection. The Customer may object to a new Subprocessor on reasonable data protection grounds by writing to legal@apublished.com within the notice period, stating the grounds. We will work in good faith to address the objection, which may include offering a reasonable alternative or a configuration that avoids the Subprocessor. If we cannot, the Customer may terminate the affected part of the Service by written notice, and we will refund any prepaid fees for the period after termination. Termination on this ground is the Customer's exclusive remedy.

Flow-down and responsibility. Each Subprocessor is engaged under a written contract imposing data protection obligations that are no less protective than those in this DPA, appropriate to the processing it performs. We remain fully liable to the Customer for the performance of each Subprocessor's obligations.

Emergency changes. Where a Subprocessor must be replaced urgently for security, availability or legal reasons, we may do so immediately and will notify the Customer as soon as possible with an explanation.

9. Data subject rights, assistance and breach notification

Requests received by us. If a data subject contacts us directly with a request concerning Customer Personal Data, we will not respond to the substance ourselves. We will tell them to contact the Customer, and forward the request to the Customer without undue delay, unless the Customer has instructed otherwise or the law requires otherwise.

Assistance. Taking into account the nature of the processing, we will assist the Customer by appropriate technical and organisational measures, insofar as this is possible, in fulfilling its obligation to respond to requests to exercise data subject rights under Chapter III of the GDPR and the equivalent provisions of the UK GDPR and the FADP. The Service's own API allows the Customer to retrieve, correct and delete Customer Personal Data directly, and that is the primary means of assistance.

Further assistance. We will assist the Customer, taking into account the nature of processing and the information available to us, in complying with its obligations under Articles 32 to 36 GDPR: security of processing, breach notification to the authority and to data subjects, data protection impact assessments, and prior consultation.

Personal Data Breach. We will notify the Customer without undue delay, and in any event within 48 hours, after becoming aware of a Personal Data Breach affecting Customer Personal Data. The notification will describe, to the extent known at the time and supplemented as more becomes known:

• the nature of the breach, including the categories and approximate number of data subjects and records concerned;
• the likely consequences;
• the measures taken or proposed to address it and to mitigate its effects;
• a contact point for further information.

We will not notify a supervisory authority or a data subject about a breach affecting Customer Personal Data on the Customer's behalf unless the Customer asks us to in writing or the law requires us to.

Cost. Assistance is provided at no charge where it is proportionate to the Service. Where a request requires significant engineering effort beyond the Service's own capabilities, we may charge our reasonable costs, agreed with the Customer in advance.

10. Deletion and return

On termination of the Terms of Service, and at the Customer's choice, we will delete or return Customer Personal Data.

In practice:

• the Customer may export Customer Personal Data through the API at any time while the account is active;
• where the Customer closes the account themselves, deletion from active systems is immediate and irreversible, with no restore window — the Customer is told so before confirming, and export is available at any time beforehand;
• where we terminate the account, we retain Customer Personal Data for 30 days, during which the Customer may ask us to restore access to export it, and delete it from active systems after that period;
• copies may persist in backups until they age out of the backup cycle; we do not currently publish a backup retention period or a tested restore commitment;
• OAuth tokens and platform data are deleted on the shorter deadlines described in Section 9 of the Privacy Policy, some of which are imposed on us by the platforms;
• we may retain Customer Personal Data where Union, Member State or Swiss law requires us to, in which case we retain only what is required, keep it confidential, and process it only for the purpose that requires its retention.

We will certify deletion in writing on request.

11. International transfers

The Customer authorises us to transfer Customer Personal Data outside Switzerland, the EEA and the United Kingdom as necessary to provide the Service, including to the Subprocessors listed at apublished.com/subprocessors and to the social platforms the Customer instructs us to publish to.

Where a transfer requires a safeguard under Chapter V GDPR, the equivalent UK provisions or Article 16 FADP, the following apply, in this order:

(a) Adequacy. Where the European Commission, the UK Secretary of State or the Swiss Federal Council has recognised the destination as providing adequate protection, we rely on that recognition. This covers transfers between Switzerland and the EEA, and transfers to a recipient certified under the EU-US and Swiss-US Data Privacy Framework for the data covered by that certification.

(b) EU Standard Contractual Clauses. Otherwise, the SCCs are incorporated into this DPA by reference and are deemed executed by the parties, as follows:

• Module Two (controller to processor) where the Customer is a controller, and Module Three (processor to subprocessor) where the Customer is itself a processor;
• Clause 7, the docking clause, applies;
• Clause 9, subprocessors: Option 2, general written authorisation, with the notice period in Section 8 of this DPA;
• Clause 11(a): the optional independent dispute resolution body is not used;
• Clause 17: the clauses are governed by the law of Ireland;
• Clause 18(b): disputes are resolved before the courts of Ireland;
• Annex I of the SCCs is Annex I to this DPA; Annex II of the SCCs is Annex II to this DPA; Annex III, where used, is the subprocessor list.

(c) Swiss amendments. Where the FADP governs the transfer, the SCCs apply with the amendments recognised by the Federal Data Protection and Information Commissioner: references to the GDPR are read as references to the FADP; the competent supervisory authority is the FDPIC; "Member State" is read so as not to exclude data subjects in Switzerland from enforcing their rights in their place of habitual residence; and the clauses protect the data of legal entities until the FADP no longer does.

(d) UK. Where the UK GDPR governs the transfer, the UK Addendum is incorporated and completed as follows: Table 1 is populated with the parties' details in Annex I; Table 2 selects the Module and options above; Table 3 refers to Annexes I and II of this DPA; in Table 4, neither party may end the Addendum when the Approved Addendum changes.

(e) Transfer assessment. We have assessed the laws of the destinations to which we transfer, and we apply supplementary measures where our assessment indicates they are needed, including encryption in transit and at rest with keys we control. We will provide our assessment to the Customer on reasonable request, subject to confidentiality.

Government access requests. If we receive a legally binding request from a public authority for Customer Personal Data, we will notify the Customer, unless prohibited by law, in which case we will use reasonable efforts to obtain a waiver of the prohibition and will document our efforts. We will challenge requests that we consider unlawful, and we will disclose only the minimum the request compels.

12. Audit

We will make available to the Customer the information necessary to demonstrate compliance with Article 28 GDPR and the equivalent provisions of the UK GDPR and the FADP, and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates.

To keep this workable for a small provider:

• in the first instance, we satisfy this obligation by providing our security documentation, the description of measures in Annex II, our subprocessor list, our incident history, and written answers to a reasonable security questionnaire, once per year;
• if that is not sufficient to demonstrate compliance, or after a Personal Data Breach affecting the Customer, the Customer may conduct an audit on 30 days' written notice, during business hours, no more than once in any 12 month period, subject to confidentiality, without access to other customers' data or to any premises or system whose disclosure would breach our obligations to a third party;
• the auditor must not be a competitor of ours;
• the Customer bears the cost of the audit, and our reasonable costs of supporting it, unless the audit reveals a material breach of this DPA by us, in which case we bear our own costs.

13. Liability

Each party's liability under this DPA is subject to the limitations and exclusions of liability in the Terms of Service, except that nothing in this DPA or the Terms limits either party's liability to a data subject under Data Protection Law, or under Clause 12 of the SCCs, or any liability that cannot be limited under Swiss law, including liability for unlawful intent or gross negligence under Article 100 of the Swiss Code of Obligations.

14. General

This DPA takes effect on the effective date of the Terms of Service and ends when all Customer Personal Data has been deleted or returned under Section 10.

We may update this DPA where necessary to reflect a change in Data Protection Law, a decision of a competent authority, a change in the SCCs, or a change to our Subprocessors or measures that does not reduce protection. Material changes are notified as described in Section 22 of the Terms of Service.

Except as stated in Section 11, this DPA is governed by Swiss law, and the courts of Morges, Canton of Vaud, Switzerland have exclusive jurisdiction.

If any provision is held invalid, the rest remains in force.

Annex I

A. List of parties

Data exporter (Controller)

Data importer (Processor)

B. Description of transfer

Categories of data subjects

• The Customer's own users: employees, contractors and other individuals to whom the Customer grants access to its apublished account.
• Holders of the social media accounts the Customer connects, and administrators of those accounts.
• Individuals whose personal data appears in content the Customer schedules or publishes, including individuals depicted, named or identifiable in text, images, video or audio.
• Individuals whose data is returned by a platform in response to a publication, such as the identity of the publishing account.

Categories of personal data

• Identification and contact data: name, email address, user role, display name, handle.
• Authentication data: password hash or identity provider identifier, API key hashes, OAuth access and refresh tokens and their scopes.
• Social account data: platform account, page and channel identifiers, display names, avatar URLs, account type and health status.
• Content data: post text, captions, titles, descriptions, tags, links, and the images, video and audio submitted for publication, including any personal data contained in them.
• Scheduling and delivery data: scheduled times, state transitions, attempts, provider job identifiers, published post identifiers and URLs, error codes.
• Technical data: IP address, user agent, request metadata, timestamps, audit records.

Sensitive data

None is intended, requested or expected. The Service is not designed to process special categories of personal data under Article 9 GDPR, data on criminal convictions under Article 10 GDPR, or sensitive personal data under the FADP. The Customer must not submit such data without a prior written agreement on additional safeguards.

If such data is nonetheless present in Customer Content, the restrictions applied are those in Annex II, in particular encryption at rest, tenant isolation enforced at the database level, strict access limitation and audit logging.

Frequency of transfer

Continuous, for the duration of the Terms of Service.

Nature of the processing

Collection, recording, organisation, structuring, storage, adaptation and alteration for platform-specific formatting, retrieval, consultation, use, transmission to the platforms the Customer selects, restriction, erasure and destruction.

Purpose of the processing

To provide the Service: to accept content, validate it against platform constraints, hold it until a scheduled time, publish it to the channels the Customer has connected, record the outcome, deliver webhooks, and support the Customer.

Retention period

As set out in Section 10 of this DPA and Section 9 of the Privacy Policy.

Transfers to subprocessors

Subject matter, nature, and duration as stated for each Subprocessor at apublished.com/subprocessors.

C. Competent supervisory authority

Where the SCCs apply under the GDPR, the competent supervisory authority is the authority of the EU Member State in which the Customer's Article 27 representative is established, or, where the Customer is established in the EEA, the authority of that Member State.

Where the FADP applies, the competent authority is the Federal Data Protection and Information Commissioner (FDPIC), Feldeggweg 1, 3003 Bern, Switzerland.

Where the UK GDPR applies, the competent authority is the Information Commissioner's Office, United Kingdom.

Annex II

Technical and organisational measures

The measures below are those in place as at the date of this DPA. They may be improved but not reduced.

1. Pseudonymisation and encryption

• All external connections use TLS. Internal service-to-service connections use encrypted transport.
• Data at rest is encrypted at the storage layer by our hosting and object storage providers.
• OAuth access and refresh tokens, and other credentials, are additionally encrypted at the application layer using envelope encryption: a per-record data key wrapped by a master key held in a key management service. The master key never exists in plaintext inside the application process. Key version is recorded per record to allow rotation.
• The PKCE verifier used during a platform connect flow is encrypted for the duration of the flow and discarded afterwards.
• API keys are stored only as keyed hashes, with the HMAC pepper held in the key management service and never in the database, so that a database dump alone is not sufficient to verify guessed keys offline.
• Webhook payloads are signed with a per-endpoint HMAC secret.

2. Confidentiality

• Tenant isolation is enforced by the database, not by application code. Every HTTP request runs under a database role with row-level security enforced and no bypass privilege, and fails closed. A separate role with bypass exists only for the cross-tenant scheduling loop, is confined to a single audited module, and every handler re-enters a tenant scope immediately after claiming work.
• Tenant isolation is verified by an automated test that interleaves requests from two tenants through a deliberately constrained connection pool and asserts zero cross-visibility. It runs on every change.
• Access to production systems is limited to personnel who require it, is protected by multi-factor authentication, and is reviewed periodically.
• Least privilege is applied to database roles, object storage credentials and platform API scopes.
• All personnel with access are bound by written confidentiality obligations.

3. Integrity

• API keys are scoped and revocable, and revocation propagates across the fleet in under one second.
• Security-relevant mutations, including connecting and disconnecting channels, key creation and revocation, and plan changes, are recorded in an audit log.
• Uploaded media is validated by inspecting its actual content rather than its filename or declared type, and is processed in a role isolated from the publishing path.
• Server-side fetching of customer-supplied URLs, including webhook delivery, is guarded against requests to private, loopback and link-local addresses, so that a customer-supplied URL cannot be used to reach internal infrastructure.
• Input is validated against a single schema definition shared by the API, the documentation and the client contracts.

4. Availability and resilience

• Work is claimed under a lease with automatic recovery of abandoned work, so that a worker failure does not lose or duplicate a publication.
• Publication is idempotent: the provider job identifier is persisted before the publishing call, and ambiguous retries are checked for duplicates before being repeated.
• Retries use exponential backoff with full jitter, and a circuit breaker isolates a failing platform from the rest of the queue.
• Backups as provided by our managed database provider. We do not yet commit to a retention period or state that a restore has been tested; when we can, it will be recorded here and on the security page.
• Monitoring and alerting on error rates, queue depth, dispatch punctuality and platform health.

5. Testing and evaluation

• An automated test suite of over 450 tests runs on every change, including dedicated tests for tenant isolation under concurrency, for claim and lease correctness under concurrent workers, and for end-to-end behaviour against a real access-controlled database connection rather than a mock.
• Dependencies are monitored for known vulnerabilities and updated.
• Security-relevant changes are reviewed before deployment.

6. Subprocessor governance

• Subprocessors are assessed before engagement, engaged under written terms no less protective than this DPA, published at apublished.com/subprocessors, and reviewed periodically.

7. Incident response

• A documented process for detecting, triaging, containing and reporting security incidents, including notification of affected customers within the period in Section 9.

8. Data minimisation and deletion

• We request the narrowest platform scopes that the Customer's chosen features require.
• Retention periods are enforced automatically, including the shorter deletion deadlines imposed on us by individual platforms.
• Deletion of a channel triggers revocation of the token with the platform, not merely deletion on our side.

Annex III

Subprocessors

The current list, with the role, processing activity and location of each Subprocessor, is maintained at apublished.com/subprocessors and forms part of this DPA. A snapshot as at the date of this document is reproduced in that page's own version history.