Data processing agreement

When this applies

This agreement forms part of the terms of service and applies whenever we process personal data on a merchant's behalf. It applies from the day an account is created. There is no separate signature ceremony, no negotiation queue, and no version of Channekt that runs without it.

It is written to satisfy Article 28 of the UK GDPR and of Regulation (EU) 2016/679, and it is written to be read. Where a paragraph could be either precise or short, it is precise.

Who is who

The merchant is the controller of their customers' personal data. They decide what is collected, why, and for how long, because the order came from their shop.

AXICOM is the processor. We hold that data to do the things the merchant asks: import their orders, keep their stock correct, publish their catalogue, and produce the documents a parcel needs.

For a merchant's own staff - the people who log in, their names, their email addresses, what they did in the product - we are the controller, because those records exist for us to run and secure the service. The privacy page covers that side.

A connected shop or marketplace is not our sub-processor. Shopify, eBay, WooCommerce, Magento and the rest are the merchant's own accounts under the merchant's own agreements, and data moves between them and Channekt because the merchant asked for it to.

What we process, and why

Subject matter	Providing Channekt: multi-channel catalogue, stock, order and fulfilment management
Duration	For as long as the account is active, plus the deletion window in Deletion and return
Nature of the processing	Collection from connected channels, storage, organisation, retrieval, consultation by the merchant's own staff, use to produce shipping and customs documents, transmission back to connected channels and to carriers, erasure
Purpose	Only to provide the service and to keep it secure and working
Categories of data subject	The merchant's customers, and the merchant's own staff
Categories of personal data	Name, email address, telephone number, billing and shipping address, the channel's own identifier for that person, and what they bought and for how much. For staff: name, email address, role, and their activity in the product
Special category data	None is asked for and none is needed. Nothing in the product invites it. If a merchant's own free-text field carries it, it is theirs and it is processed the same way as anything else in that field
Card and payment data	None. Card data never touches our systems: payment is the shop's or the marketplace's, and our own billing is Stripe's hosted checkout

Our instructions

We process personal data only on the merchant's documented instructions, including on transfers, unless we are required to do otherwise by law - in which case we tell the merchant before processing, unless the law forbids that on important grounds of public interest.

Using the product is an instruction. Connecting a channel, importing orders, printing a label, sending an export, switching on a feature: each is an instruction to process the data that action needs. This agreement, the terms and the settings a merchant chooses are the documented instructions, and no separate ticket is needed for the product to do what its buttons say.

We do not use a merchant's data for our own purposes. We do not sell it, we do not use it to advertise, and we do not train models on it or allow a sub-processor to.

If we think an instruction infringes data protection law, we will say so and may pause that instruction until it is resolved.

Confidentiality

Everyone we allow near personal data is bound to keep it confidential, by contract or by statute, and that duty outlives their involvement. Access is limited to the people who need it to do the work, and personal data is only accessed in support of a merchant when it is necessary to answer their request or to keep the service secure and working.

Security

We take the measures required by Article 32. They are described in full, control by control, on the security page, and summarised in Annex II. That page also lists what is not built yet, and that list is part of what is being represented here rather than a separate marketing document.

Sub-processors

The merchant gives general authorisation for us to engage the sub-processors listed on the sub-processors page, which is the authorised list for the purposes of this agreement.

We will give at least 30 days' notice before a new sub-processor starts handling a merchant's data or an existing one is replaced. A merchant may object within those 30 days on reasonable data protection grounds; we will try to offer a way to carry on without the change, and if there is none, the merchant may end the agreement for the affected part of the service without penalty and be refunded for what was paid and not used.

Every sub-processor is engaged under a written contract imposing obligations no weaker than these. We remain fully liable to the merchant for their performance.

Transfers out of the UK and EU

The application, the database and the backups are in London. Files are in the European Union. One optional feature calls a model in Belgium. Where any transfer outside the UK or EEA happens - Stripe and the optional assistant are the two - it is covered by the UK International Data Transfer Addendum and the EU standard contractual clauses, and by a transfer risk assessment we will share on request.

Exact regions, and what each recipient actually sees, are on the sub-processors page rather than paraphrased here, so there is one place that has to be right.

Helping you meet your own obligations

Requests from data subjects. Most of what a controller needs is in the product: a merchant can find a customer, see what is held, export it, and erase it themselves. If a request reaches us instead, we do not answer it - we pass it to the merchant without undue delay, because it is theirs to answer. Where the product cannot do it, we help, and for a request that the product already handles we do not charge.

Erasure. When a channel tells us a person has asked to be forgotten, the request is written down before it is attempted, so a process that dies half way leaves a record saying the erasure is owed and a sweep picks it up. Identifying fields are tombstoned; the financial and inventory records survive without them, which satisfies erasure and bookkeeping at the same time. Nothing in that path writes the person into a log.

Assessments. We give reasonable help with data protection impact assessments and prior consultations, taking into account what we know and what a processor can see.

Security and breach. We help with the obligations in Articles 32 to 36, which in practice means the access record, the audit trail and the answers in the next section.

Personal data breaches

We tell the affected merchant without undue delay and in any case within 24 hours of becoming aware of a personal data breach affecting their data. The clock starts when any one of us becomes aware, not when the investigation is finished.

The notice describes, as far as we know it at the time:

• what happened and when, and when we became aware
• the categories and approximate number of people and records concerned, from the access record rather than estimated
• the likely consequences
• what we have done to contain it and what we are doing next
• who to contact for more, and when the next update will come

If we do not have all of it in 24 hours, the merchant still hears from us in 24 hours, and the rest follows as we learn it.

We do not notify a merchant's customers or their regulator on their behalf, because those are the controller's decisions. We give them what their own notification needs, in time for the 72-hour deadline. The full procedure, including severity levels and the review that follows, is on the security page.

Deletion and return

At the end of the service, the merchant chooses whether their data is returned or deleted. A merchant can export their own catalogue, orders and customers from the product at any time, including after cancellation and before the deletion window closes.

Unless the merchant asks otherwise, data is deleted 30 days after the account ends. Backups are not surgically edited: a deleted account's data remains inside encrypted database backups until those backups age out on their normal schedule, which is within 35 days, and nothing is restored from them selectively.

We keep only what the law requires us to keep, and for no longer, and it stays subject to this agreement while we hold it.

Audits and information

We make available the information needed to show that these obligations are met. In the first instance that is this page, the security page, the sub-processors page and written answers to questions, including a completed security questionnaire.

A merchant, or an auditor they appoint who is not a competitor of ours, may audit us once in any twelve months, on 30 days' written notice, during working hours, without unreasonable disruption, and under confidentiality. More often if a regulator requires it or after a breach affecting their data. Each side bears its own costs for the first such audit in a year; we may charge reasonably for time spent on further ones.

We will not give an auditor access to another merchant's data, to our own staff's personal data, or to information that would compromise the security of the service for everybody else.

Liability and precedence

The limits of liability in the terms of service apply to this agreement too, except where data protection law says they cannot.

If this agreement and the terms disagree about the processing of personal data, this agreement wins. If either disagrees with mandatory data protection law, the law wins. If a paragraph here is unenforceable, the rest stands.

We tell merchants before this agreement changes in a way that reduces their protection, and the version and date are at the top of this page. Older versions are in the repository's history, which is public in effect because the page is versioned with the code rather than edited in a content system.

Annex I: the processing

The parties

Controller	The merchant: the organisation named on the Channekt account, at the address and contact given in its billing details
Processor	AXICOM SRL, Romania. Contact for data protection: support@channekt.com

Description of the processing

As set out in What we process, and why: the subject matter, duration, nature, purpose, categories of data subject and categories of personal data are all there rather than repeated here in smaller type.

Frequency

Continuous, for as long as the account is active. Orders arrive from connected channels as they are placed, and stock and catalogue changes are sent back as they happen.

Retention

For the life of the account, then deleted as described in Deletion and return. The record of who looked at personal data is kept twelve months.

Competent supervisory authority

For merchants established in the United Kingdom, the Information Commissioner's Office. For merchants established in the European Union, the authority of the member state in which the merchant is established. For AXICOM as processor, the Romanian National Supervisory Authority for Personal Data Processing.

Annex II: security measures

The measures below are the summary. Each one is described properly, with where it is enforced, on the security page.

Measure	What it is
Separation of tenants	Forced row-level security in the database, the organisation set per transaction, no query path that omits it, and a generated isolation test on every endpoint
Access control	Role-based permissions from one shared catalogue, enforced at the route and again in the service, with a test covering every role and permission
Encryption in transit	HTTPS everywhere, including between our own services
Encryption at rest	Whole-database encryption from the host, plus per-field sealing of every credential with keys derived per purpose from a master key held outside the database
Authentication	argon2id password hashing with parameter upgrade on sign-in, breach checking through the k-anonymity range API, ten-minute access tokens, rotating refresh tokens with family revocation on replay
Logging and accountability	Every read of customer personal data recorded as pointers with no second copy and no search terms, kept twelve months; a separate audit trail of changes with before and after values; secret redaction on all logs
Resilience and recovery	Daily managed backups with point-in-time recovery in the same region, a written restore procedure, and migrations gating every deploy
Secure development	Type checks, lint, unit tests and the isolation suite enforced before a push; build, migrate and deploy from one pipeline; secret scanning and dependency vulnerability checks
Minimisation	Only what an order carries and a parcel needs; no card data; no personal data sent to the assistant; erasure by tombstoning that preserves the financial record
Incident response	A written procedure with severity levels, a one-hour containment start, and merchant notification within 24 hours of becoming aware

Annex III: sub-processors

The authorised list, with what each one does, where it is, and whether it sees personal data, is at channekt.com/sub-processors. It is a live page rather than a snapshot, and the date at the top of it is the date something on it last changed.

Getting a signed copy

Write to support@channekt.com with the organisation's legal name and registered address and we will return a countersigned copy, or complete yours if your process needs your own paper. We do not require a signature for these obligations to apply.

AXICOM SRL · support@channekt.com