Skip to content
ChannelCockpit
About usContact
Legal
Legal
Privacy Policy Terms of Service Data Processing Addendum Imprint Data Deletion
Tester login
Menu Limited-access private beta
About us Contact
Legal
Privacy Policy Terms of Service Data Processing Addendum Imprint Data Deletion

Data Processing Addendum

Article 28 GDPR terms for the narrowly defined circumstances in which ChannelCockpit processes personal data on a Controller's behalf.

Back to product
On this page Status and partiesEffect and priorityScope and instructionsConfidentiality and securitySubprocessorsInternational transfersAssistance and breachesReturn and deletionEvidence and auditsController duties and termsAnnex I · ProcessingAnnex II · TOMsAnnex III · Subprocessors

Status, version and parties

Version dated 16 August 2026. This published template defines safeguards that apply only after the activation and acceptance conditions in the next section are satisfied and evidenced for the relevant Customer.

Customer and Controller

The Customer and Controller is the person or organization identified in the versioned Acceptance Record. If an individual accepts for an organization, that record must identify the organization and evidence the individual's authority to bind it. This page contains no blank party field and does not identify a Customer by publication.

Processor

The Processor is Amed Bozo, a German sole proprietor (Einzelunternehmer), trading as ChannelCockpit.

Amed Bozo, trading as ChannelCockpit
Moritzstraße 43
65185 Wiesbaden
Germany
Email: support@channelcockpit.app

“Customer Personal Data” means personal data processed by the Processor on behalf of the Controller under this DPA. “Data Protection Law” means the GDPR and other Union or Member State data-protection law applicable to that processing. GDPR terms such as controller, processor, processing, personal data, data subject and personal data breach have their GDPR meanings.

Effect, acceptance and priority

Publication of this page alone does not bind either party. This DPA becomes part of the Service Agreement only after both parties execute or electronically accept the same version and a versioned Acceptance Record evidences that electronic acceptance, the accepted DPA and Service Agreement versions, the identity and authority of the accepting Customer, and the date and time of acceptance.

To request a processor-use assessment and manual DPA execution package, use the Contact page or email support@channelcockpit.app. ChannelCockpit will first confirm the intended role and scope, then provide the versioned agreement and annex package for review where the processing is eligible. Sending a request, receiving the package or discussing its terms does not activate processor-scope use.

The manual path remains fail-closed: both parties must accept the same version, and the Acceptance Record must identify the role assessment, documented instructions, rights-assistance process, versioned technical and organisational measures and complete subprocessor schedule. All of these conditions must be in force before processing begins.

The “Service Agreement” means the accepted Terms of Service and any separately evidenced access agreement identified in the same Acceptance Record. The Acceptance Record must also identify the operative versions of all three Annexes, the documented role assessment, the documented instructions and the rights-assistance process.

Processor activation boundary. Until a documented role assessment, Acceptance Record, documented instructions, rights-assistance process, versioned technical and organisational measures and complete subprocessor schedule are evidenced, ChannelCockpit must not be used for any processor-scope personal data. This is a prohibition, not a statement that the missing contract and operational controls exist.

Channel ownership or authority is a product-access condition: it permits a user to connect a channel, but it does not determine the parties' GDPR roles. The parties must assess each processing context before use, and roles depend on the processing facts and applicable law. Whenever ChannelCockpit processes personal data on behalf of a Controller, this DPA activation boundary applies, including for a channel managed for the user's own organization if the role facts establish a controller-processor relationship.

This DPA does not assign a categorical role to private or household use; roles in any such context depend on the processing facts and applicable law. For its own purposes, including account administration, security and legal compliance, ChannelCockpit acts as controller as explained in the Privacy Policy.

Mandatory Data Protection Law prevails. For Customer Personal Data, this DPA prevails over conflicting Service Agreement terms. A separately executed transfer instrument prevails for the transfer it governs. Other Service Agreement terms, including its liability allocation, continue to apply only to the extent consistent with those higher-priority rules.

Processing scope and documented instructions

Subject matter, duration, nature and purpose

The subject matter, duration, nature and purpose of processing, its data subjects and personal-data categories are limited to Annex I. Processing begins only at the effective time evidenced in the Acceptance Record, continues for the permitted Service Agreement term, and ends when return or deletion under this DPA is complete.

The Processor will process Customer Personal Data only on documented instructions from the Controller. Once the activation conditions are satisfied, instructions consist of the Controller's recorded choices within the Annex I service functions and any additional written instruction accepted through the recorded party contacts. A product command is not a valid processor instruction before activation or where it falls outside Annex I.

The Processor will immediately inform the Controller if, in its opinion, an instruction infringes the GDPR or other applicable Data Protection Law, and will suspend the affected processing while the parties resolve the issue. If the Controller insists on an unlawful instruction, the Processor may decline it and end the affected processing.

If processing is required by Union or Member State law to which the Processor is subject, the Processor will inform the Controller before processing unless that law prohibits notice on important grounds of public interest. The Processor will not determine new purposes or essential means for Customer Personal Data under this DPA.

Current capability boundary

The permitted service journey is limited to Today, Analytics, Connections, Publishing, Export, Disconnect and Delete as described in Annex I. It does not cover comments, direct messages, an inbox, team roles or billing.

The current service prohibits special categories of personal data under Article 9 GDPR and personal data relating to criminal convictions and offences under Article 10 GDPR. Both are prohibited in Customer Personal Data, including in drafts, captions, filenames and uploaded media. The Controller must not instruct that processing, and the Processor may reject or remove affected material where reasonably necessary.

Confidentiality and security

The Processor will limit access to Customer Personal Data to persons whose access is strictly necessary to provide, secure or verify the instructed processing. Every authorized person must be bound by confidentiality or an appropriate statutory confidentiality duty and must process the data only under the Controller's instructions, unless Union or Member State law requires otherwise.

Taking account of the state of the art, implementation costs, the nature, scope, context and purposes of processing, and risks to data subjects, the Processor will implement the complete versioned measures required by Article 32 GDPR to maintain security appropriate to the risk. Those measures must address confidentiality, integrity, availability and resilience; timely restoration of access following an incident; and regular testing, assessment and evaluation of effectiveness.

Annex II records the currently evidenced baseline and its unresolved activation gaps. It is not a warranty that every listed measure eliminates risk. Material changes affecting protection of Customer Personal Data must be risk assessed, documented and reflected in a later version accepted or notified under the applicable change process.

Subprocessors and changes

The Controller gives general written authorization for subprocessors only when it electronically accepts a complete, versioned Annex III through the Acceptance Record. The evidence-only inventory currently shown in Annex III is not that authorization and cannot activate processor-scope use.

After activation, the Processor must give at least 30 calendar days' advance written notice before adding or replacing a subprocessor, with the identity, location, processing purpose and applicable transfer information needed for an informed objection. The Controller has the opportunity to object on reasonable data-protection grounds before the change takes effect.

The parties will work in good faith to resolve a timely objection through an alternative that preserves equivalent protection. If they cannot resolve it, the Processor will not use the proposed subprocessor for the affected Customer Personal Data, or the Controller may end the affected processing before the change. A shorter notice is permitted only where necessary to comply with law or address an urgent material security risk; the Processor must then give notice before the change where possible and otherwise without undue delay, and preserve the Controller's suspension and exit options.

Every engaged subprocessor must receive by written contract substantially the same data-protection obligations that apply to the Processor, including appropriate safeguards, confidentiality, assistance, return or deletion and audit evidence. The Processor remains fully responsible to the Controller for each subprocessor's performance. On request, the Processor will provide relevant subprocessor terms, with redactions limited to information that must be protected.

International transfers

Under Chapter V GDPR, the Processor will transfer Customer Personal Data to a third country or international organization only on a documented instruction or where Union or Member State law requires it. The complete Annex III must identify actual processing locations, onward transfers and the legal mechanism for every transfer before activation.

Depending on the verified facts, that mechanism may be an adequacy decision under Article 45 GDPR or appropriate safeguards under Article 46, including the European Commission's 2021/914 Standard Contractual Clauses. Any required transfer clauses must be separately executed, completed for the actual parties and transfer, and supported by any required assessment and supplementary measures. Article 49 derogations are exceptional and may be used only where their conditions are actually met and documented.

This DPA does not itself adopt the 2021/914 transfer clauses or establish an adequacy decision. The Commission's 2021/915 Article 28 standard clauses likewise state that those processor clauses do not by themselves ensure Chapter V compliance.

Rights, compliance assistance and personal data breaches

Data-subject rights

Taking account of the nature of processing, the Processor will assist the Controller through appropriate technical and organisational measures, insofar as possible, with requests under Articles 12 to 23 GDPR. The Processor will promptly forward a request relating to Customer Personal Data through the agreed rights-assistance process and will not respond on the Controller's behalf unless authorized by the Controller or required by law.

Before activation, the parties must document request channels, identity-verification responsibilities, search and action steps, decision ownership, communication responsibilities and timeframes that allow the Controller to meet statutory deadlines. Product export, disconnect and delete controls can support particular operations but are not represented as a complete rights-response process.

Security, impact assessment and consultation

Taking account of the nature of processing and information available to it, the Processor will assist the Controller with compliance under Articles 32 to 36 GDPR. This includes relevant security information, personal data breach assessment and communications, a data protection impact assessment under Article 35, and prior consultation with a supervisory authority under Article 36 where required.

Processor breach notice

The Processor will notify the Controller without undue delay after becoming aware of a personal data breach affecting Customer Personal Data and will cooperate with the Controller's response. The notice will include, so far as then available:

  • the nature of the breach, including where possible the categories and approximate numbers of affected data subjects and records;
  • a contact point for further information;
  • the likely consequences; and
  • the measures taken or proposed to address the breach and mitigate adverse effects.

Where all information cannot be supplied at once, the Processor will provide the information then available and supplement it in phases without undue further delay. Notification is not an admission of fault or liability.

Return, deletion and end of processing

At the Controller's choice, the Processor will return or delete all Customer Personal Data after the end of the relevant processing services and delete existing copies, unless Union or Member State law requires retention. If retention is legally required, the Processor will inform the Controller where permitted, isolate the retained data from other processing, continue to protect it and delete it when the duty ends.

The Controller may also issue a documented instruction for earlier return, restriction or deletion within the agreed service scope. On request, the Processor will provide written confirmation of completed deletion or explain the lawful retention that prevents it.

Return and deletion cover data controlled by the Processor and its subprocessors. They do not delete data held independently by YouTube, TikTok, Instagram or Facebook for their own platform operations; the Controller must use the relevant platform controls for that data. Export, disconnect and account deletion have distinct current effects and retention limits described in Annex I and the Privacy Policy.

Compliance evidence and audits

The Processor will make available to the Controller all information necessary to demonstrate compliance with Article 28 GDPR and this DPA, and will allow for and contribute to audits, including inspections, by the Controller or an independent auditor it mandates.

Audits should first use current documentation where that can reasonably answer the question. On-site or technically intrusive work will occur at reasonable intervals, with reasonable advance notice, during ordinary operating hours and subject to confidentiality, safety, security and protection of other persons' data. Advance notice does not apply where a competent supervisory authority requires otherwise or credible evidence of material non-compliance makes urgent access reasonably necessary.

Audit scope must be relevant and proportionate to Customer Personal Data under this DPA. The Processor may use reasonable controls to avoid disclosing secrets, vulnerabilities or another person's data, but not to prevent meaningful verification. The parties will provide relevant audit material to a competent supervisory authority on request and address substantiated findings without undue delay.

Controller obligations and remaining terms

The Controller is responsible for establishing and documenting a lawful basis, providing transparent notices, honoring data-subject rights, applying data minimisation, ensuring the accuracy and legitimacy of Customer Personal Data, and issuing lawful documented instructions. It must have authority over every customer channel and connected-platform account used, configure access appropriately, and conduct any required risk assessment, data protection impact assessment or prior consultation.

The Controller must not submit prohibited data, conceal an unlawful purpose, ask the Processor to evade platform or legal requirements, or use the service outside Annex I. It must promptly provide information and decisions reasonably needed for rights, incident, audit, transfer and deletion assistance.

The liability provisions of the Service Agreement apply between the parties to the extent permitted by law, but do not restrict liability or data-subject rights under Article 82 GDPR or other mandatory law. Nothing in this DPA limits a supervisory authority's powers.

Notices under this DPA use the party contacts in the Acceptance Record; Processor notices may also be sent from or to support@channelcockpit.app. An amendment is effective for Customer Personal Data only through a versioned electronic record binding the relevant parties, except that a valid subprocessor change follows the notice-and-objection process above. A newly published page does not silently amend an accepted DPA.

The official GDPR text and the Commission decisions linked above are the primary legal references for this DPA.

Annex I · Processing details

Subject matter and duration

The subject matter is the Controller-instructed handling of Customer Personal Data for the current ChannelCockpit functions below. The duration begins at the effective time in the Acceptance Record and continues until the Service Agreement or affected processing ends and return or deletion is complete, subject only to documented legal retention.

Nature and purpose

  • Today: retrieve, organize and display bounded current channel, content, analytics-freshness and workflow status needed for the Controller's overview.
  • Analytics: retrieve authorized source metrics, store the current limited TikTok snapshot and delta history, preserve source, coverage and freshness context, and display source-aware results without creating a cross-platform total.
  • Connections: initiate and maintain Controller-authorized OAuth connections, store encrypted credentials and scopes server-side, display token-free status, refresh access where instructed, and revoke or remove the connection on Disconnect or Delete.
  • Publishing: store drafts, captions, settings, schedules and private media; validate file integrity, format and malware status; maintain review, preflight and queue state; and, only after the Controller's explicit confirmed instruction, conditionally transmit the selected payload to the chosen connected platform.
  • Export: assemble a bounded owner-scoped JSON export with sensitive credentials removed and make it available through a short-lived protected download.
  • Disconnect and Delete: revoke or remove credentials, clean provider-linked local artifacts, block new account writes, erase owner-scoped records and media, and reconcile interrupted or late lifecycle work.

Operations include collecting from the Controller and connected platform, recording, organizing, structuring, storing, retrieving, consulting, comparing, validating, displaying, transmitting on confirmed instruction, restricting, exporting and erasing. The Processor does not use Customer Personal Data for an unrelated purpose.

Categories of data subjects

  • natural persons identified in authorized channel, profile, Page or connection metadata;
  • creators, publishers and other people identified in the authorized content and source-aware analytics returned for that channel;
  • people named, depicted, heard, tagged or otherwise identifiable in Controller-supplied drafts, captions or media, including a minor only where ordinary personal data appears incidentally in permitted content; and
  • authorized Customer representatives insofar as their identity appears in connection, instruction, export, disconnect or deletion records that qualify as Customer Personal Data.

Categories of Customer Personal Data

  • channel, profile and Page identifiers; names, usernames, avatars, opaque platform identifiers, account kind and token-free connection status;
  • content or video identifiers, titles, captions, thumbnails, dates, source metadata, metrics, daily snapshots and deltas, coverage, freshness and provenance;
  • draft titles, captions, uploaded media, sanitized filenames, content type, size, hashes, technical validation and malware-scan results, settings, targets, schedules, review choices, preflight status and bounded operation or queue outcomes;
  • OAuth grants, scopes, expiry, encrypted access and refresh credentials and revocation state;
  • export, disconnect and deletion commands, status, timestamps and bounded lifecycle evidence; and
  • owner-bound pseudonymous identifiers, rate-limit state and redacted security or operational events only where they contain Customer Personal Data.

ChannelCockpit account administration, its direct security relationship and its own legal records remain Processor controller-scope activities except to the limited extent that a record also contains Customer Personal Data. Comments, direct messages, inbox content, collaborative role data and payment data are outside this Annex.

Special data and retention

Article 9 special-category data and Article 10 criminal-conviction or offence data are prohibited. No safeguard in this Annex authorizes their submission.

The current retention periods are explained in the Privacy Policy. In summary, TikTok analytics history can remain for up to 90 days; cursor and incomplete-upload state can expire after 24 hours; publishing operations and terminal queue records can remain for 30 days; and a media lifecycle action can bind media through seven days after that action or, for scheduled media, through the scheduled instant plus seven days. Later lifecycle actions may extend an existing media binding, and eligible cleanup is retried rather than promised at an exact physical instant.

  • Publishing preflight state expires after 24 hours and provenance records after 90 days.
  • An export object is nominally available for 10 minutes, its signed URL for two minutes and cleanup runs every five minutes; provider storage has a seven-day soft-deletion period.
  • Account deletion uses a 24-hour barrier and reconciliation window for interrupted or late writes.
  • Exact Cloudflare Access, reCAPTCHA, mailbox and operational-log periods are not currently verified. A complete, accepted retention schedule must resolve them before processor-scope activation.

Annex II · Technical and organisational measures

Activation status. This currently evidenced baseline is not a complete activation-ready TOM schedule. Risk-appropriate restoration and availability measures, provider-specific controls and unresolved configurations must be completed and versioned before processor-scope activation.

Identity, authentication and access

  • The current protected application uses a separate Cloudflare Access gateway followed by Firebase Authentication. The exact Access identity provider, claims, session configuration and log period still require verification.
  • Application data paths enforce authenticated owner scope. Firebase App Check protects current remote service requests; the web flow uses reCAPTCHA Enterprise, and service-side allowlists and enforcement are tested against selected environments.
  • Server runtime identities are environment-specific and limited to required Firestore, authentication, App Check, storage, secret and invocation permissions. Broad owner and editor roles are prohibited for those runtime identities.

Credentials, secrets and transmission

  • OAuth access and refresh credentials are encrypted with server-side key material, held in server-only records and excluded from client models and exports.
  • Client secrets, encryption keys, administrative keys and storage credentials remain server-side and are not written to source documentation or operational logs.
  • Current service boundaries use encryption in transit. The complete schedule must still identify the actual provider controls and account terms relied upon.

Private storage and media validation

  • Publishing media is owner-bound in private, environment-separated Cloudflare R2 storage. Bucket credentials and object paths are not public client data.
  • Upload completion binds byte length, hashes, multipart evidence and object metadata. A private validator checks type or container, codec, dimensions, duration and current ClamAV malware signatures before media can become validated.
  • Firebase Admin Storage is used separately for short-lived privacy JSON exports and is not a publishing-media fallback.

Input, integrity and abuse controls

  • Remote commands use bounded schemas and inputs, authentication, App Check, ownership checks and operation-specific rate limits.
  • Connection revision, opaque account scope, media evidence, deletion barriers and idempotency fences are rechecked around publishing and lifecycle state changes to limit stale or late writes.

Logging and data minimisation

  • Central logging owners redact credentials, authorization headers, sensitive query values, free payloads and direct identifiers. Functions log bounded structured fields and pseudonymize identity fields.
  • Client error reports omit raw error objects, email addresses and raw user identifiers; the application-level user field is derived into a pseudonymous hash.
  • Provider data retains source, coverage and freshness context, while exports omit credentials and bounded product views avoid unnecessary cross-platform combination.

Lifecycle, deletion and reconciliation

  • Account deletion first sets a server-only barrier, disables identity access and revokes refresh tokens before removing owner-scoped Firestore, private-media, export and rate-limit data.
  • Disconnect fences provider-linked work, removes the active credential and reconciles competing or late operations. Account deletion reconciles interrupted or late writes for 24 hours.
  • Media and export owners apply the bounded retention and cleanup controls stated in Annex I; failed cleanup keeps retry evidence rather than silently reporting completion.

Testing, change and unresolved resilience controls

  • Documented verification controls cover schemas, security rules, authentication and App Check enforcement, platform contracts, lifecycle behavior, deletion and architecture boundaries. Changes are subject to focused verification and controlled change management.
  • The current evidence does not establish a complete backup, recovery, timely restoration or service-availability control set for Customer Personal Data. Those controls must be selected against the actual risk, verified with the providers and captured in the accepted TOM version.
  • The TOM schedule must be reviewed when processing, risk, service providers or security controls materially change. No certification or uninterrupted-service representation is made by this Annex.

Annex III · Subprocessor schedule and recipient boundary

Not authorization-ready. Current operational evidence identifies the Contact and support-email route, but it does not verify every relevant account's exact contracting entity, processing locations, applicable data-processing terms, onward subprocessors or transfer mechanism. This evidence inventory is therefore not a complete subprocessor schedule. Processor-scope use remains prohibited until a complete version is supplied before and incorporated into the Acceptance Record.

Current infrastructure service categories and activation evidence
Service category Narrow current purpose Evidence required before authorization
Google and Firebase infrastructure Authenticated application identity; Firestore and Functions processing; App Check with reCAPTCHA Enterprise; short-lived Admin Storage exports; private Cloud Run media validation; bounded Logging, Monitoring and Error Reporting. Verify and version the exact contracting entity, account terms and DPA, service locations, onward subprocessors, retention and each Chapter V mechanism actually relied upon.
Cloudflare infrastructure Outer Access authorization gateway and private R2 storage for publishing media. Verify and version the exact contracting entity and terms, Access identity and session configuration, processing and support locations, onward subprocessors, retention and each transfer mechanism. The R2 EU jurisdiction setting alone is not sufficient evidence for all Cloudflare processing.
Contact and support email Resend forwards accepted same-origin Contact submissions; Cloudflare Email Routing forwards direct support email to the monitored Gmail mailbox. Verify and version the exact contracting entities, terms, roles, processing locations, retention, subprocessors and transfer mechanisms before Customer Personal Data can use that route.

Controller-selected platform recipients

YouTube, TikTok, Instagram and Facebook are Controller-selected platform recipients and authorized data sources for the instructed connection and publishing journey. They are not subprocessors for their own platform operations. The Controller must assess its legal basis, notices, platform terms and transfer duties for each instructed disclosure, while the Processor must transmit only the confirmed payload under a valid instruction and apply Chapter V where it makes a restricted transfer.

Platform names do not establish a particular legal entity, processing location or transfer instrument. Those facts must be verified for the actual connection and instruction; this Annex does not guess them.

ChannelCockpit
Product About usContact Privacy PolicyTerms of ServiceData Processing AddendumImprintData Deletion
Limited-access private beta Tester login © 2026 ChannelCockpit. All rights reserved.
Accessibility & display Adjust the page to suit you.
Appearance
Text size
Contrast
Motion

These preferences stay on this device.