Data processing agreement · in force

What we promise about the data in your accounts.

Paid work means you give us read access to your shop and your advertising accounts, and some of what is in them is personal data about your customers. This document is the agreement that has to exist before that happens: what we may do with it, what we must not, and what you can make us do. The free store check offered on the home page is not that work: it reads your public storefront, asks for no access to anything, and nothing below applies to it.

Regulation (EU) 2016/679, Article 28 · in force from 08.09.2026

The processor — the statutory details

Firma
WIL TRADE Spółka z ograniczoną odpowiedzialnością (WIL TRADE sp. z o.o.)
Seat and address
ul. Szosa Ełcka 13, 15-690 Białystok, Poland
Registration court
Sąd Rejonowy w Białymstoku, XII Wydział Gospodarczy Krajowego Rejestru Sądowego
KRS
0000970413
NIP
5423448874
Share capital
100 000,00 PLN

Contact: vitali@quantika.org. These are the details a limited company must publish on its website: Kodeks spółek handlowych art. 206 § 1, which covers websites in terms — "a także informacje na stronach internetowych spółki, powinny zawierać" (isap.sejm.gov.pl, KSH) — with Prawo przedsiębiorców art. 20 ust. 3 (isap.sejm.gov.pl) and uśude art. 5 ust. 1 and 2 (isap.sejm.gov.pl).

Quantika Commerce is the trading name on this site. The party to this agreement is WIL TRADE sp. z o.o.

When this takes effect

Approved by the owner of WIL TRADE sp. z o.o. on 8 September 2026, and in force from that date. What is published at this address is the version in force.

You do not sign this separately. It comes into force with the engagement itself: when we agree the work with you in writing, this agreement comes with it, and that written scope is the documented instruction paragraph (a) below is about. Article 28(9) asks for writing including electronic form, and that is what the exchange of emails is. If we publish a later version while you are working with us, we write and tell you; the version at this address is the one in force from then.

On anything to do with personal data, this agreement prevails over the service terms. Where a sentence here and a sentence in the terms of service cannot both be true of your data, this one governs. Everything else stays where it is written there — the price, the delivery, the ceiling on money, the governing law and the courts — and this agreement changes none of it.

Article 4(7), 4(8) and 28(10) — who is what

You are the controller. We are the processor. Neither of us gets to be vague about it.

You decide why your customer data exists and what is done with it: you run the shop, you chose the platforms, and you decide what the work is for. That makes you the controller — in the words of the Regulation, the one who "determines the purposes and means of the processing".

We look at that data because you asked us to, for the questions you set, and for nothing of our own. That makes us the processor — the one who "processes personal data on behalf of the controller". We do not use your customers' data to build products, to train models, to enrich a list of our own, or to sell anything to anyone.

The Regulation adds a warning we take seriously: a processor that starts deciding the purposes and means of processing is treated as a controller for that processing, with everything that follows. So if we ever want to do something with your data that you have not asked for, the answer is to ask you first, and this document is written to make that the only available route.

Sources: Regulation (EU) 2016/679, Article 4(7) and Article 4(8) (legislation.gov.uk/eur/2016/679/article/4) and Article 28(10) (legislation.gov.uk/eur/2016/679/article/28/adopted).

Article 28(3) — the particulars this contract must set out

Subject-matter, duration, nature, purpose, the data and whose it is.

Subject-matter and duration

The subject-matter is the analysis of your shop, marketplace and advertising data for the store economics work, and afterwards the building and running of whatever software you commission on the strength of it. For a project, the processing lasts as long as the scope agreed in writing says the work lasts, and the time it takes to deliver and discuss what comes out of it. For monthly work it lasts as long as the monthly engagement does — which you can end with a fortnight's notice. After that it lasts only as long as deletion or return under paragraph (g) takes.

Nature and purpose

Reading, extracting, aggregating and reconciling records so that channels, stores, campaigns and product lines can be compared on one profit-and-loss; and, in a build, moving those records between the systems you name. The purpose is yours: to see where the money in your business actually goes. We ask for read-only reporting scopes to begin with, and for write access only one scope at a time, saying what each one is for.

The types of personal data

What store-and-ads work touches, in practice: order and transaction records, which in a shop export usually carry a customer name, a delivery and billing address, an email address and often a telephone number; the identifiers the platform assigns to a customer or an order; payment, refund and dispute records; supplier and carrier invoice data where invoices are being reconciled against what was agreed; and the account identifiers of your own people through which access is granted to us. We ask for no special categories of data under Article 9 and no criminal offence data, and you should not send them to us.

The categories of data subjects

Your customers, past and present. Your staff and contractors, in so far as their accounts, names or actions appear in the systems we are given access to. Your suppliers and carriers, where their invoices form part of the reconciliation.

The exact list for a given engagement is whatever your export actually contains, and it is fixed in writing with the scope before work starts.

Your rights and obligations as the controller

Article 28(3) requires this contract to set out your side too, not only ours, so here it is rather than left to inference.

What is yours to do. You decide the purposes and the means, and you give us the instructions we act on — in writing, to the address in the engagement, because paragraph (a) below binds us to documented ones. It is on you, not on us, to have a lawful basis for the processing you ask for and to be entitled to give us the data; to have told your own data subjects what your privacy notice has to tell them; to give us access no wider than the work needs and to withdraw it when the work ends; to answer requests from your data subjects and to decide any notification to them or to your supervisory authority; and, under the Regulation's general rule for controllers, to put in place measures appropriate to the risk on your own side.

What is yours to demand of us. To instruct us, and to change or withdraw an instruction. To be told at once if we think an instruction breaks the law, under paragraph (a). To authorise or refuse a sub-processor and to be told before one changes, under paragraph (d). To be helped with your data subjects' requests, under paragraph (e), and with your obligations under Articles 32 to 36, under paragraph (f). To choose, at the end, whether your data comes back or is deleted, under paragraph (g). To be given what you need to demonstrate compliance, and to audit us, under paragraph (h). Every one of those is exercisable by writing to the address on this page; none of them costs you anything.

Who bears what if something goes wrong

We give no express warranty and no indemnity. Neither is stated in this agreement, and neither exists in any other document of ours. That is a decision we have taken and are telling you about, not a step we have put off: there is nothing here left for us to settle and nothing for you to ask us to fill in.

It does not mean you are owed nothing, and we would rather say so than let a bare "no warranty" do work it should not do. Every duty the Regulation puts on us as your processor stands, and so does every undertaking this agreement adds to them — the 24 hours on a breach, the deletion or return at the end, the audit, the help with your data subjects' requests. The promises in the service terms stand on their own footing. Under both sits the general law of Poland, which those terms choose and which decides what we answer for when we perform badly or not at all; nothing here narrows it, and what it does not permit to be narrowed we could not narrow in any case. What is limited is money, and only money: the liability section of the service terms caps it at €10,000 per engagement and states that the cap covers the work and the data alike, so a claim under this agreement falls inside that cap rather than beside it.

The position in one line, then: the law and the cap. No extra promise laid on top of what the law gives you, and nothing taken off it.

Source: Regulation (EU) 2016/679, Article 28(3), which requires a contract setting out the subject-matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subjects, and the obligations and rights of the controller; Article 28(9) requires that contract to be "in writing, including in electronic form" (legislation.gov.uk/eur/2016/679/article/28/adopted). For what makes you the controller and what that carries: Article 4(7) (legislation.gov.uk/eur/2016/679/article/4) and Article 24, the controller's own responsibility to implement appropriate technical and organisational measures (legislation.gov.uk/eur/2016/679/article/24/adopted).

Article 28(3)(a) — documented instructions

We process your data only on your written instructions, and we say so if one looks wrong.

We process personal data only on your documented instructions. The written scope we agree by email before an engagement starts is that instruction; anything beyond it needs another one, in writing, to the same address. That applies to any transfer to a country outside the European Economic Area as much as to anything else: we make none unless you have instructed it, or unless a law we are subject to requires it — and in that case we tell you before we process, unless that law forbids us to tell you.

If an instruction you give us looks to us as though it breaks the Regulation or another data protection law, we say so immediately and before carrying it out. We would rather have an awkward conversation than be the reason for a complaint against you.

Source: Regulation (EU) 2016/679, Article 28(3)(a) — the processor "processes the personal data only on documented instructions from the controller" — and the second subparagraph of Article 28(3) on informing the controller of an infringing instruction (legislation.gov.uk/eur/2016/679/article/28/adopted).

Article 28(3)(b) — confidentiality

Nobody touches your data without being bound to keep it quiet.

We undertake that nobody on our side is given access to your data unless they are first bound to confidentiality in writing, by their contract with us or by a separate undertaking, and that the duty outlives the engagement. We give access only to the people who need it to do the work you have commissioned, and no one else gets a look because they are curious.

Said plainly, because this document is meant to be relied on: that is a commitment we are making here, not a control we can show you a record of today. No confidentiality undertaking or contract clause of that kind exists in writing anywhere we can point you to, and here is why. One person does the work, as the measures section below sets out, and no third party has access to your data at all. So there is nobody to bind and nobody to sign — a paper in which the owner of the company undertakes confidentiality to himself would prove nothing to you, and we would rather tell you it does not exist than sign one and call it a control. That is the position today, and it is a decision we have taken and are telling you about, not a step we have put off. It changes the day it has to: before anyone but that one person is given access to your data, the undertaking exists in writing first, and from then on it is a document we can produce on request under paragraph (h).

We do not name your business as a client, quote your figures or publish anything recognisable from your accounts without your permission in writing. Any client case we publish on this site is published exactly that way — with permission and without the client's name — and it is the standard we hold ourselves to.

Source: Regulation (EU) 2016/679, Article 28(3)(b) — the processor "ensures that persons authorised to process the personal data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality" (legislation.gov.uk/eur/2016/679/article/28/adopted).

Article 28(3)(c) — security of processing

We take the measures Article 32 requires, and the first of them is asking for less access.

We undertake to take the technical and organisational measures required by Article 32 of the Regulation, appropriate to the risk. The measures we already work by, and which you can hold us to today, are these: we ask for read-only reporting scopes to begin with; we ask for write access one scope at a time and tell you what each is for; repositories, hosting, API keys and advertising accounts are created in your organisation with us as a collaborator rather than the owner, so every access we hold can be revoked by you, at any moment, without asking us; and we take copies of your data only where the work needs them.

Where the copies of your data actually sit while we work, who can reach them and whether they are encrypted is set out in the next section, in specifics. What is still not written down — backup, restoration and a regular testing regime — is named in the block at the end of this document rather than promised here.

Source: Regulation (EU) 2016/679, Article 28(3)(c) — the processor "takes all measures required pursuant to Article 32" (legislation.gov.uk/eur/2016/679/article/28/adopted).

Article 32 — the measures, in specifics

One laptop, one person, an encrypted disk, and no copy anywhere else.

This is the honest inventory of what protects your data on our side. It is short because the company is one person, and we would rather show you a short true list than a long one written to look reassuring.

  • One machine. Working copies of your data — exports, extracts, the spreadsheets the work is built in — live on a single company laptop. There is no server of ours, no shared drive and no copy on any other machine.
  • An encrypted disk. That laptop's disk is encrypted, so the data at rest on it is not readable by someone who ends up holding the hardware.
  • One person. One person — the founder, who does the work — has access to that machine and to the accounts you grant us. Nobody else is given access, because there is nobody else.
  • The least access that does the job. We ask for read-only reporting scopes to begin with, and for write access one scope at a time, saying what each is for; access is held in your organisation with us as a collaborator, so you can revoke any of it at any moment without asking us. Reducing what we can reach is the measure we rely on most.
  • As little data as the question needs. We take a copy only where the work needs one, and at the end of the engagement it is returned or deleted under paragraph (g) below.

What this list does not contain, it does not contain on purpose. We are not claiming a backup and restoration procedure, a testing regime, or a scheme for evaluating these measures regularly — Article 32(1)(c) and (d) speak of exactly those, and we have none written down. That gap is named in the block at the end of this document rather than papered over here.

Source: Regulation (EU) 2016/679, Article 32(1), which requires technical and organisational measures appropriate to the risk and gives as examples the pseudonymisation and encryption of personal data, the ability to ensure ongoing confidentiality, integrity, availability and resilience, the ability to restore availability and access after an incident, and "a process for regularly testing, assessing and evaluating the effectiveness" of the measures (legislation.gov.uk/eur/2016/679/article/32/adopted).

Article 28(3)(d) — other processors

We bring nobody else in without your written say-so, and we stay answerable for them.

We engage no other processor on your data without your prior specific written authorisation, or under a general written authorisation from you — and where the authorisation is general, we tell you in advance of any intended addition or replacement, so that you have the chance to object before it happens. That much is what the Regulation itself provides: it gives you the opportunity to object, and no more than that.

Here is what we add to it, as our own undertaking. While an objection of yours stands, we do not put that sub-processor near your data. If we cannot do the work without it, we say so and you may end the engagement on the terms in the service terms, rather than being presented with a change you refused.

Where you do authorise one, that sub-processor is put under the same data protection obligations as this document places on us, by a written contract. If it fails to meet them, we remain fully liable to you for its performance: "we outsourced it" is not an answer we get to give.

On the data coming in by the path we ask you for — access to your accounts — no sub-processor is engaged, none. That is as far as the sentence goes, and the next section sets out why: what goes back out to you goes by email and leaves through a mailbox provider, and an email you send us arrives through a forwarder and a mailbox provider both. Neither of those two is a path we can describe as clear, so we describe it as it is, direction by direction.

Source: Regulation (EU) 2016/679, Article 28(3)(d), read with Article 28(2) on authorisation and Article 28(4), under which the first processor "shall remain fully liable to the controller for the performance of that other processor's obligations" (legislation.gov.uk/eur/2016/679/article/28/adopted).

Article 28(2) and 28(4) — who else touches it

On the data coming in by the path we ask for, nobody but us. Everything that travels by email — what you send and what we send back — is a different path, and it is not ours to make private.

The honest answer depends on how the data travels, so this section splits by path and by direction rather than by what a message is about. There are three legs, and we walk all three below: what comes in by the access we ask for, what goes back out to you, and what comes in when you email us instead. Only the first is ours to keep clear, and we would rather tell you which than write a sentence that reads better than it is true.

Coming in, the path we ask for: access to your accounts

On the data coming in, this path has no sub-processor on it, none. What we ask for is read access to your store, marketplace and advertising accounts, at the least level that does the job, and we read it on the one encrypted laptop described in the previous section. Working copies of what we read stay on that laptop: there is no hosting provider, no storage service, no analysis tool and no AI service anywhere in it, and the bulk of your data — the store, marketplace and advertising records themselves — never travels by mail at all. Should the work ever need a sub-processor, we engage it only with your prior written authorisation, which is what paragraph (d) above already binds us to — and if you refuse, we say what we cannot then do rather than proceed.

What goes back out to you: what we deliver, and the return under paragraph (g)

This leg is email too, and on it your figures are in Google's hands. What we deliver is a written document with your own figures in it, and we send it to you by email; so is anything we return to you at the end of an engagement under paragraph (g) below. Both are written on the one encrypted laptop described in the measures section above — that is where the spreadsheets the work is built in live, and there is no copy on any other machine — and sent from the Google mailbox described in the next part of this section, so Google holds that document from the moment we send it until it reaches you, and after that it is in your mailbox and wherever your own mail goes.

Cloudflare is not on this leg, and we will not pad the list with it. Cloudflare Email Routing receives mail addressed to our domain and forwards it onward. It gives us no mailbox and nothing can be sent from it — sending is a separate Cloudflare product, which we do not use — so it stands on the way in and not on the way out. Cloudflare does remain the registrar and the DNS operator for quantika.org: that answers other servers' questions about where our domain's mail belongs, and it does not carry the message or anything attached to it. Naming a company that is not on the path would mislead you exactly as much as leaving out one that is.

One thing about this leg we tell you rather than pass over, because the domain looks busier than our arrangements are. quantika.org also carries sender records we inherited with the domain for three other mail providers — Amazon SES, Resend and Zoho. Sender records are exactly what lets a company send as a domain, so a controller who looked them up would reasonably wonder about this leg. We send from the Google mailbox and from nothing else: none of those three is used by us. That is our statement about our own arrangements, and it is what we are answerable for to you. It is not a statement that those records have been taken out of the domain's DNS — they have not been, and what is published in DNS is a different fact from what we use.

So granting us access keeps your data off the email path on the way in. It does not keep the work off it on the way out, and we are not going to tell you otherwise.

The other path in: an email you send us

This one we do not control, and we will not describe it as though we did. Email is the only contact channel this site offers, and the service terms on this site expressly contemplate you sending us things by email, in an attachment. Every email that reaches quantika.org — headers, body and attachments alike — passes through Cloudflare Email Routing and comes to rest in a Google mailbox. So if you attach a shop export, a customer list or an advertising report, Cloudflare and Google hold that data too, for as long as we hold the message. That is store and advertising data on a path with two companies standing on it, and calling it "correspondence" would not turn it into anything else.

  • Cloudflare, Inc. routes the mail addressed to quantika.org through Cloudflare Email Routing, and serves these pages: the site is deployed on Cloudflare Workers as static assets, so every page you read here comes from Cloudflare. On the mail leg it is a forwarder: it passes through whatever an email carries, without regard to what that is.
  • Google provides the mailbox that mail is forwarded into, and therefore holds the message — attachments included — where it comes to rest.

Both are recorded as EU-U.S. Data Privacy Framework Active on the Data Privacy Framework List, checked 7 September 2026, which is the adequacy basis for anything that does reach the United States. That list records companies, not individual transfers: it does not tell you which contracting entity a particular request actually runs through, and we do not claim to know.

Whether that makes those two your sub-processors under Article 28(2) and (4), rather than processors of our own mail, depends on what you chose to put in the message, and we do not assert the comfortable answer. The question is named as open in the block at the end of this document. What we do not do is claim the first path's answer for the second.

Which is why we ask for access rather than an export — and what that does not buy you

If you would rather your store and advertising data did not travel the email path, do not send us an export: grant us access instead. What that buys you is the bulk of it. The store, marketplace and advertising records are read where they sit, they never go by mail, no sub-processor of ours is on them, and you can shut the access off yourself at any moment without asking us. Email is then for arranging the work; the accounts are for the data the work is about.

What it does not buy you is a private way out. What we deliver is a document made of your figures and it goes to you by email, and so does anything returned to you at the end under paragraph (g): those figures are written on the one laptop the measures section describes and sent from a Google mailbox, so Google holds them from the moment we send them, and from there they go wherever your own mail goes. Access moves the bulk of your data off the email path; it does not move the deliverable off it.

If that matters to you, say so before the work starts and we will agree a route with you — but know what we have before you rely on it. Email is the only route we have built. There is no server of ours and no shared drive, as the measures section above says, and no other channel is offered anywhere on this site, so any other way of getting the document to you would have to be arranged for the occasion, around something you already run, rather than taken off a shelf here. We would rather settle that in advance than have you meet it when the document arrives. We offer no standing alternative to email and none is planned — that is the owner's decision, not a question left open, and anything else is arranged for the one engagement that asks for it. The email path itself is the same one the privacy notice on this site describes for everyone who writes to us, and it is described there in the same terms as here.

Sources: Regulation (EU) 2016/679, Article 28(2) on prior specific or general written authorisation and Article 28(4) on the first processor remaining fully liable (legislation.gov.uk/eur/2016/679/article/28/adopted). For the adequacy position of the two providers above: Commission Implementing Decision (EU) 2023/1795 of 10 July 2023, OJ L 231, 20.9.2023, p. 118 (eur-lex.europa.eu, CELEX 32023D1795) and the Data Privacy Framework List (dataprivacyframework.gov/list), checked 07.09.2026. Who stands on each leg of the mail is our own statement about our own arrangements, made on our own responsibility and not resting on anybody else's document: we have mail addressed to the domain received and forwarded by Cloudflare Email Routing, it comes to rest in a Google mailbox, and that mailbox is what our documents and the paragraph (g) return are sent from. Cloudflare gives us no mailbox and nothing can be sent from Email Routing, so it is not on the way out; Cloudflare's own documentation describes the product the same way, and it is a document you can open: "Route incoming emails to custom addresses, Workers, or external destinations" (developers.cloudflare.com/email-routing), with outbound sending listed there as a separate product, checked 07.09.2026. That we send from the Google mailbox and from no other provider, the inherited Amazon SES, Resend and Zoho sender records included, is a statement of the same kind and made on 08.09.2026: it is about what we use, and it is not a claim that those records are gone from the domain's DNS. What remains open is which contracting entity a given request reaches, and that is named in the block at the end of this document.

Article 28(3)(e) — helping you answer your customers

When one of your customers exercises a right, we do the finding and you do the answering.

If one of your customers asks for access to their data, for it to be corrected or erased, for processing to be restricted, for a copy in portable form, or objects to it, we help you answer — by appropriate technical and organisational measures and, in the Regulation's words, in so far as this is possible. In the systems we have been given access to, we find the records, extract them, correct them or delete them on your instruction.

That qualification is the Regulation's and we keep it rather than promise past it. Some of what you may need is genuinely outside our reach: records in systems we were never given access to, access you have since revoked, or a platform that does not expose the operation you are asking for. What we do undertake is this — we work to your deadline, and where we can see we will not make it, or cannot do the thing at all, we tell you at once and say why, so that the deadline is yours to manage with the facts in hand rather than a surprise at the end of it.

If such a request comes to us directly, we do not answer it ourselves — that is the controller's job, and answering it would be us deciding something that is yours to decide. We pass it to you within one working day, which is the answer time this company works to on all mail, and we tell the person that we have done so.

Source: Regulation (EU) 2016/679, Article 28(3)(e) — the processor "assists the controller by appropriate technical and organisational measures, insofar as this is possible, for the fulfilment of the controller's obligation to respond to requests for exercising the data subject's rights" (legislation.gov.uk/eur/2016/679/article/28/adopted).

Article 28(3)(f) — security, breaches, impact assessments

If something goes wrong on our side you hear it from us, early and in plain terms.

We assist you in meeting your obligations under Articles 32 to 36 of the Regulation, taking account of what the processing involves and what we know. In practice that is three things. First, security: the measures under paragraph (c) above. Second, breaches: if we become aware of a personal data breach affecting your data, we notify you without undue delay and tell you what happened, which data and roughly how many records are involved, what we have done and what we recommend — including the parts we do not yet know, rather than waiting until the picture is tidy. Third, assessments: where you carry out a data protection impact assessment or have to consult your supervisory authority, we give you the technical detail about our processing that you need for it.

"Without undue delay" stays as the standard, and the next section puts an outer bound of 24 hours on it, with the reason.

Source: Regulation (EU) 2016/679, Article 28(3)(f) — the processor "assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36" (legislation.gov.uk/eur/2016/679/article/28/adopted).

Article 33(2), read with Article 33(1) — how fast we tell you

Within 24 hours, because you have 72 of your own.

If we become aware of a personal data breach affecting data we process for you, we notify you without undue delay and in any event within 24 hours of becoming aware of it. The clock starts when we become aware, not when we have finished working out what happened.

The reason for the number is yours, not ours. As the controller you must notify your supervisory authority of a breach "without undue delay and, where feasible, not later than 72 hours after having become aware of it", and where you are later than that you have to give reasons for the delay. Your 72 hours cannot begin until we have told you. A deadline for us measured in days would eat the greater part of your window before you knew there was anything to decide — so we take a day at the outside and leave you the rest.

The 24 hours is an outer bound, not a waiting period. "Without undue delay" in paragraph (f) above still governs: if we know within the hour, you hear within the hour. We tell you what happened, which data and roughly how many records are involved, what we have done and what we recommend — including the parts we do not yet know, rather than holding the notice back until the picture is tidy, since a late complete notice is worse for you than an early incomplete one. The notice goes in writing to the contact named in the engagement, and we follow it up as we learn more.

What we do not do is decide anything for you. Whether the breach is notifiable to your supervisory authority, and whether your own data subjects have to be told under Article 34, are the controller's decisions — yours. Our duty is to put you in a position to take them in time.

Source: Regulation (EU) 2016/679, Article 33(2) — the processor "shall notify the controller without undue delay after becoming aware of a personal data breach" — read with Article 33(1), which sets the controller's own 72 hours and requires reasons for any delay beyond them (legislation.gov.uk/eur/2016/679/article/33/adopted). The 24 hours above is our contractual undertaking, tighter than the Regulation, which fixes no number for a processor.

Article 28(3)(g) — what happens at the end

When the work ends you choose: we give it back, or we delete it.

At the end of the engagement you tell us which you want, and we do it — return every piece of personal data we hold about your business, or delete it. We then delete the existing copies, including working copies and anything in our own notes, unless a law of the European Union or of a Member State requires us to keep it, in which case we tell you which data that is and why.

There is usually little to hand back, by design: the code, the repositories and every key are yours from the first commit, and the accounts are in your name, so ending an engagement is mostly a matter of you revoking our access and us destroying what is left on our side. We confirm in writing when it is done, and we do not treat retention of your data as leverage of any kind.

Source: Regulation (EU) 2016/679, Article 28(3)(g) — at the controller's choice the processor "deletes or returns all the personal data to the controller after the end of the provision of services relating to processing" and deletes existing copies unless Union or Member State law requires storage (legislation.gov.uk/eur/2016/679/article/28/adopted).

Article 28(3)(h) — proof and audits

You can ask us to show our working, and you can send someone to check it.

We make available to you all the information you need to demonstrate that the obligations in this document are being met — what data we hold, where it sits, who has had access to it and under which instruction. We allow audits and inspections carried out by you or by an auditor you mandate, and we contribute to them rather than merely permitting them: answering questions and showing configurations and access lists. That much is what Article 28(3)(h) requires — to make the information available, and to allow and contribute to the audit.

On what follows an audit we undertake this, and deliberately no more: where an audit finds that we are not meeting an obligation set out in this document, we put it right, and we agree the timing with you in writing. We are not promising to act on every finding an auditor might make — an audit can recommend things that go beyond this agreement, cost money, or belong to your side of the arrangement — and a blanket promise we could not keep would be worth nothing to you.

What an audit costs, how often you can have one, and how much warning we need. Once a year, on thirty days' written notice, and you bear the cost of it — your own people or your own auditor, and our time in answering them. More often than that, and sooner than thirty days, where there has been a personal data breach affecting your data or a supervisory authority requires the audit. Those are the arrangements; they are not a limit on the right the Regulation gives you, and where the two ever pull apart the Regulation wins.

We ask that anyone you send is bound by confidentiality in the same way our own people are. Where an instruction given in the course of an audit would itself infringe the Regulation, we say so, as under paragraph (a) above.

Source: Regulation (EU) 2016/679, Article 28(3)(h) — the processor "makes available to the controller all information necessary to demonstrate compliance with the obligations laid down in this Article and allow for and contribute to audits, including inspections, conducted by the controller or another auditor mandated by the controller" (legislation.gov.uk/eur/2016/679/article/28/adopted).

What we have not settled — and are telling you rather than hiding

This agreement is in force, and every line below is in it on purpose. Each is a question this document does not answer, or a fact that does not exist in writing anywhere we can point you to. As the controller you are entitled to know both before you rely on us. Nothing below is a decision we could take and have not: where the answer was ours to give we have given it above rather than list it here. The security measures, the sub-processors, the breach notification deadline and the ceiling on money were answered by the owner on 07.09.2026; the mail we send from, how this agreement is concluded, which document prevails on personal data, what an audit costs and how often you can have one, whether any route but email is offered, and whether we give a warranty or an indemnity, on 08.09.2026. All of them are in the sections above, and what is left of each, where anything is left, is stated narrowly here.

  • Backup, restoration and testing of the Article 32 measures. Where working copies sit, who can reach them and that the disk is encrypted are answered and stated in the measures section above. What is not: how those copies would be backed up and restored after an incident, and any regular process for testing and evaluating the measures — Article 32(1)(c) and (d). Nothing of that kind is written down, and the measures section says so rather than implying otherwise.
  • The written confidentiality undertaking paragraph (b) promises. No contract clause or separate undertaking of that kind exists in writing today, because one person does the work and there is nobody else to bind. Paragraph (b) states the commitment and states equally plainly why there is no record of it we can put in front of you.
  • Whether Cloudflare and Google are your sub-processors — for what you email us, and for what we email back. On the data coming in by the access we ask for they touch nothing, which is why the sub-processors section can answer "none" for that leg and only that leg. On an email you send us, Cloudflare Email Routing forwards whatever the message carries and a Google mailbox holds it, your data included if you attach it. On the way out — what we deliver, and the return under paragraph (g) — that document is written on our own laptop and sent from the same Google mailbox, so Google holds your figures from the moment we send it whether or not you ever email us anything; Cloudflare is not on that leg, as the sub-processors section explains. Whether any of that makes them sub-processors under Article 28(2) and (4) — and so whether the authorisation paragraph (d) describes is owed for them — has not been settled, and this agreement asserts neither answer.
  • Which form of sub-processor authorisation would be asked for — specific or general under Article 28(2) — if the work ever needs a sub-processor on client data. We engage none today on the data coming in by the access we ask for, as the sub-processors section states, and whether the two mail providers count as sub-processors is the open question above rather than a settled "no". So the question has not arisen: paragraph (d) keeps both routes open, and which of them would be asked for is answerable only against a particular sub-processor and a particular engagement, neither of which exists today.
  • Whether any transfer of client data outside the European Economic Area could arise. It can, and it does not take an email from you to bring one about. On the data coming in by the access we ask for, none arises: it sits on one laptop in Poland, no sub-processor touches it, and paragraph (a) forbids a transfer without your instruction. But what we deliver, and any return under paragraph (g), are sent from a Google mailbox, so on a pure access-path engagement — where you never email us anything at all — a transfer can arise the moment we send the document, without any act of yours. Whether one does on a given send we cannot tell you: the Data Privacy Framework List records companies and not individual transfers, and Google's services in the EEA are frequently contracted through Google Ireland Limited rather than Google LLC, in which case the data may not leave the EEA at all. We do not claim to know which entity a particular request reaches, and the sub-processors section above says so in the same terms. If you do email us an export, Cloudflare Email Routing carries it too on the way in. Cloudflare, Inc. and Google LLC are United States companies; the sub-processors section says so, with the Data Privacy Framework as the adequacy basis for anything that does reach the United States. What is not settled is two things. Which contracting entity each request actually runs through, and therefore whether a given send leaves the EEA at all. And whether either of those transfers — the one you cause by emailing us an export, and the one we cause by sending you the deliverable through a mailbox you did not choose — counts as made on your instruction within the meaning of paragraph (a). We assert neither answer to either, and we do not use the access path as a reason to claim that no transfer arises. What a future sub-processor's own infrastructure would imply is not recorded, because there is none to record.
  • Whether a representative in the United Kingdom is required under UK GDPR Article 27 for clients there. The ICO's test is whether the organisation offers goods or services to, or monitors the behaviour of, individuals in the United Kingdom; our clients are businesses, which points one way without settling it, and the answer depends on facts we do not have. We assert neither answer.
  • Whether the retention of any client personal data is required of us by Union or Member State law after an engagement ends, which paragraph (g) leaves open in the abstract.