United Kingdom GDPR and the Data Protection Act 2018
Privacy notice
Chapter one of the ZAAPTO handbook, and the longest of the three. An integration studio is judged by what it does at a boundary, so this notice is arranged as a set of boundaries rather than as a set of topics, and each one states the personal data that crosses it.
Effective 15 August 2026 Handbook chapter 1 ZAAPTO LTD, company number 16938315
1. How this chapter is arranged
Most privacy notices are organised by topic, which suits the drafter and leaves the reader hunting. This one is organised by boundary, because that is how the work itself is organised and because a boundary is the only place where personal data actually moves anywhere.
Sections 5 to 11 take one boundary each and answer the same five questions about it: what crosses, where it came from, why it is being handled, what makes that lawful, and how long the record survives afterwards. Sections 12 to 24 then take the matters that run across every boundary at once — the bases, the retention schedule, your rights, what happens when something goes wrong.
Two shorthand terms are used throughout. Estate means the collection of systems an organisation has bought and runs. Crossing means an item of personal data moving from one party's estate into another's. The point of the arrangement is that you should be able to find your own situation by asking which boundary you are standing at.
If you only need one thing. Data about you that sits inside a client's system is the client's to answer for, not ours; section 7 explains why and section 18 tells you what to do about it. Everything else on this page is ZAAPTO's own answer to give.
2. Who publishes it, and how to reach them
This notice is published by ZAAPTO LTD, a private company limited by shares, formed in England and Wales and carrying company number 16938315. Its registered office is the address held against that number on the public register at Companies House, and that is where anything needing to arrive on paper should be sent.
Every data protection matter, a request to exercise a right included, goes to [email protected]. The address is monitored by the people who run the company, and a request sent to it is not filtered through anyone else first.
2.1 Data protection officer
No Data Protection Officer has been appointed. Article 37 makes one compulsory for a public authority, and for an organisation whose core activity is either large-scale monitoring of people or large-scale handling of the sensitive categories described in section 14. A studio of this size doing integration work meets none of those descriptions. Accountability therefore rests with the company's own officers, and the address above reaches them.
2.2 Representative
ZAAPTO LTD is established in the United Kingdom and is answerable to the United Kingdom's regulator, so the Article 27 requirement to appoint a representative here does not arise.
3. Two hats: controller and processor
Data protection law draws its sharpest line between the organisation that decides why personal data is handled and how, which it calls the controller, and the organisation that handles it on someone else's instructions, which it calls the processor. Every duty in this chapter, and every route you have for enforcing a right, follows from which of the two ZAAPTO is at the boundary you care about.
ZAAPTO wears both hats, for different data, and this chapter never mixes them.
3.1 Where the company is the controller
At the boundaries in sections 5, 6, 8 and 11. This is data ZAAPTO collects for reasons of its own: the request records behind this website, the correspondence arriving at the enquiry address, the contact details and accounting records that keeping a company in order requires, and anything reaching an application the company publishes under its own name. At these boundaries ZAAPTO chooses the purpose, picks the lawful basis, sets the retention period, and answers to you directly.
3.2 Where the company is the processor
At the boundary in section 7. During an engagement ZAAPTO builds inside a client's estate, and the personal data there belongs to the client's world: their employees, their customers, their suppliers, the people who appear in their records. The client settled long ago why that data exists. ZAAPTO touches it only on the client's documented instructions and for no purpose of its own.
The practical consequence is worth stating plainly. If your data is in a client's system, that client is the one who has to answer you. Should you write to us instead, we will say so quickly, pass your request to the controller wherever we can identify who that is, and tell you that we have done it — but we cannot decide the request ourselves, and pretending otherwise would waste your time.
3.3 The written terms behind the processor hat
Before any processing starts, a written agreement carrying everything Article 28(3) requires is in place: what the processing is and how long it lasts, which categories of people and data are involved, a duty of confidence on anyone who touches it, the security obligations in Article 32, the rule that no sub-processor is engaged without the client's approval, help with rights requests and with the client's own duties, return or destruction of the material at the end, and the client's right to inspect and audit. A client who wants to see those terms before signing anything only has to ask.
4. The boundaries, mapped
One table, so that a reader can find the right section without reading the six that do not apply to them.
| Section | Boundary | Typical person | ZAAPTO's hat | Who answers a request |
|---|---|---|---|---|
| 5 | A browser reaching this website | Anyone reading a page | Controller | ZAAPTO LTD |
| 6 | Your mailbox and ours | Someone who has written in | Controller | ZAAPTO LTD |
| 7 | Your systems and ours | A person recorded in a client's estate | Processor | The client, as controller |
| 8 | The company's own books | A contact at a client or supplier | Controller | ZAAPTO LTD |
| 9 | The suppliers behind us | Anyone in sections 5, 6 or 8 | Controller | ZAAPTO LTD |
| 10 | Leaving the United Kingdom | Anyone in sections 5, 6 or 8 | Controller | ZAAPTO LTD |
| 11 | A phone running an app we publish | Someone who installed it | Controller | ZAAPTO LTD |
Scroll the table sideways where your screen is too narrow to hold it.
5. Boundary one: a browser reaching zaapto.uk
ZAAPTO's hat: controller
The thinnest boundary in the handbook. You request a document, a server returns it, and the exchange leaves a trace at the server end. Nothing on these pages asks you to identify yourself, and there is no form here to submit.
| What crosses | Where it comes from | Why | Lawful basis | How long it lasts |
|---|---|---|---|---|
| Connection records | Generated automatically by the hosting platform as it answers your request: network address, the moment of the request, the path asked for, the response code, the browser string | Serving the page, keeping the site standing under automated traffic, and diagnosing a fault when one is reported | Legitimate interests, itemised at 13.1 | Held by the hosting provider on its own rolling cycle, a matter of days; ZAAPTO keeps no separate copy |
| Font requests | Sent by your own browser straight to Google's font hosts when a page needs its lettering | Rendering the pages in the two typefaces the design uses | Legitimate interests, itemised at 13.2 | Whatever Google's own retention practice provides; the request never reaches ZAAPTO |
Scroll the table sideways where your screen is too narrow to hold it.
Nothing here is used to build a picture of you. There is no analytics package on this site, no advertising identifier, no measurement beacon, and no attempt to recognise a device between visits. The stored side of this boundary — what is left behind on your own equipment — is inventoried in chapter three, which also explains how to stop the font request from leaving your browser at all.
Google receives the font requests as a recipient in its own right. That is a crossing out of the country as well as out of our hands, so it is picked up again at section 10.
6. Boundary two: your mailbox and ours
ZAAPTO's hat: controller
Email is the only channel this company publishes, so almost everyone ZAAPTO knows about arrived across this boundary. What crosses is whatever you chose to put in a message, and the decision about how much that should be is entirely yours.
| What crosses | Where it comes from | Why | Lawful basis | How long it lasts |
|---|---|---|---|---|
| Who you are | You: a name, an address to reply to, an employer, a job title, a telephone number if you offer one | Recognising who is writing and replying to the right person | Legitimate interests, or steps taken before a contract where an engagement follows | See the schedule at section 16 |
| What you wrote | You: the description of a process, a problem, a timetable, a budget, and anything attached | Understanding the question well enough to answer it, and quoting for work if it comes to that | Legitimate interests, or steps taken before a contract | See the schedule at section 16 |
| The envelope | Added by mail systems in transit: routing headers, timestamps, spam and authentication verdicts | Delivering the message and keeping fraudulent mail out of the mailbox | Legitimate interests, itemised at 13.3 | Carried with the message it belongs to |
Scroll the table sideways where your screen is too narrow to hold it.
A first enquiry needs remarkably little: what the process does, who touches it, and how often it runs. It does not need a customer list, a staff export, a database dump or a set of credentials, and none of those should be sent at this stage. If a conversation reaches the point where real data genuinely has to be examined, that happens under the written terms described at section 7 and not by attachment to an email.
Your message is read by the person who does the work, and it is not passed to anyone outside the company except in the circumstances listed at section 9.
7. Boundary three: your systems and ours
ZAAPTO's hat: processor
This is the boundary the business exists to work on, and the one where the roles reverse. An engagement means building inside a client's estate: reading from one system, writing to another, and moving records between the two so the same fact stops being typed twice. The personal data in those records is the client's, gathered by the client, for purposes the client set before ZAAPTO appeared.
Who the data is about depends entirely on the client's business. It may be their staff, their customers, the people they buy from, or anyone else their systems record. ZAAPTO does not choose those categories and does not add to them.
7.1 What actually crosses
- Access, rather than copies. The normal arrangement is scoped access into a client-owned system, not a transfer of records to us. Data stays where the client keeps it.
- Samples, where a specification needs them. Understanding a record format sometimes requires seeing real examples. Where anonymised or invented data will do the job, that is what is asked for; where it will not, a minimal sample is agreed in writing, kept for the shortest workable period, and destroyed when the question it answered is closed.
- Whatever a running automation carries. Once built, a handoff moves records between the client's own systems. It does not route them through anything ZAAPTO owns, because there is no ZAAPTO platform in the middle for it to route through.
- Credentials. Issued by the client, scoped to the named system, held in the client's own secret store, and cut off by the client whenever the client decides.
7.2 What governs it
Everything at this boundary runs on the written processor terms described at 3.3, which sit alongside the engagement contract. Instructions come from the client and are recorded. ZAAPTO adds no purpose of its own, keeps nothing back at the end, and does not use anything seen here to improve a product, train a model or inform another client's work.
7.3 If you are the person in the record
Then your rights are exercisable against the client, who is the controller, and the client's own privacy notice is the document that tells you how. Writing to us is not wasted — we will route the request and confirm that we have — but the decision is not ours to make, and any attempt by us to make it would be the wrong answer arriving from the wrong organisation.
8. Boundary four: the company's own books
ZAAPTO's hat: controller
Running a company generates records about people even when nobody sets out to collect any. This boundary is the one between an ordinary working relationship and the paperwork it leaves behind.
- Client and supplier contacts. Names, work addresses, roles and telephone numbers of the people ZAAPTO deals with at an organisation. Handled to perform the contract, or on legitimate interests where the person is a contact at a company rather than the counterparty in their own right.
- Contracts and what was agreed. Signed engagements, specifications, scope changes, approvals and the correspondence that settled them. Handled to perform the contract and to establish or defend a legal claim later.
- Money. Quotations, invoices, payment records and the entries an accountant needs. Handled because tax and company legislation requires it, which is a legal obligation rather than a choice.
- Access administration. A record of which accounts were requested for which engagement, when they were granted and when they were withdrawn. Handled on legitimate interests, itemised at 13.4.
Nothing at this boundary is bought in. ZAAPTO does not purchase contact lists, does not enrich records from data brokers, and does not scrape professional networks to build a prospect file. Everybody in these records got there by dealing with the company.
9. Boundary five: the suppliers behind us
ZAAPTO's hat: controller
A studio this size runs on other people's infrastructure, and every supplier is a boundary of its own. The categories are these, and the list is deliberately short because each addition is a place data can go.
- The hosting and delivery provider that serves these pages and produces the connection records at section 5, acting on ZAAPTO's instructions under written terms.
- The email provider that carries correspondence to and from the published address, acting on ZAAPTO's instructions under written terms.
- Google, which receives a font request directly from your browser as described at section 5. Google is a recipient in its own right at that moment rather than a processor acting for us.
- Professional advisers — an accountant, and a solicitor or insurer if a dispute ever needs one — bound by their own duties of confidence and by their own professional obligations.
- A public authority, where disclosure is required by law, ordered by a court, or necessary to establish or defend a legal claim. A demand of that kind is checked against what it actually compels before anything is handed over.
Nobody outside that list receives personal data from ZAAPTO. Nothing is sold, rented, bartered or handed to an advertising network, because the company has no business model in which any of that would earn anything. Where a supplier is engaged as a processor, written terms carrying the Article 28(3) obligations are in place before data reaches them, and a new supplier is assessed before it is added rather than afterwards.
Where the boundary at section 7 is concerned, sub-processors work the other way round: ZAAPTO does not appoint one for client data without the client's approval, which is one of the terms recorded at 3.3.
10. Boundary six: leaving the United Kingdom
ZAAPTO's hat: controller
Some of the crossings above also cross a border, and an international transfer needs a lawful footing of its own on top of the basis that permits the handling in the first place.
Two of them do so in the ordinary course. Font requests reach Google, whose serving infrastructure is worldwide, so the address your browser connects from may be handled outside the country. Hosting and email providers of the kind a small company uses commonly run support or resilience operations abroad even where the data itself sits in a British or European facility.
Where a transfer of that sort happens, one of the following carries it, and which one depends on the supplier and on where the receiving end sits:
- adequacy regulations made for the destination country, meaning the government has decided that country's protection stands comparison with ours;
- the International Data Transfer Agreement, or the UK Addendum bolted onto the European standard contractual clauses, with a transfer risk assessment behind it;
- an exception in Article 49 where one genuinely applies, which for this company would be a rare and specific event rather than routine practice.
A reader who wants to know which mechanism covers a particular supplier can ask at the address in section 2 and will be told, with a copy of the safeguard where its terms are not commercially confidential. At the boundary in section 7 the question belongs to the client, whose instructions decide where their own data may go, and whose contract with us records the answer.
11. Boundary seven: a phone, an app and a store
ZAAPTO's hat: controller
Work built for a client belongs to the client and is published, if at all, in the client's name under the client's own privacy notice. Separately from that, ZAAPTO may publish an application under its own name through the Apple App Store, Google Play or a comparable channel. This section states the terms that apply to any such application, so that a reader meets them before an install rather than afterwards.
11.1 What an application of ours may hold
- An account identifier and the address used to sign in, where the application has accounts at all.
- Content you enter, which stays yours and is handled to make the application do the thing you opened it for.
- Diagnostic records of a crash or an error, used to fix the defect that produced them.
- The device and version details a support conversation needs in order to be useful.
11.2 Tracking, and the two stores' declarations
An application published by ZAAPTO does not track you across other companies' apps and websites. In consequence there is no reason for it to raise the App Tracking Transparency prompt on iOS, since ATT exists to ask permission for exactly the cross-property tracking that is not being done. Should that ever change, the prompt would appear first and this section would be rewritten before the version carrying it was submitted.
On Android, the Data Safety declaration filed with Google Play states what an application collects, what it shares and what it does with each item. That declaration and this section are kept in step deliberately: where the two are read side by side they should say the same thing, and if they ever diverge the divergence is a defect worth reporting to the address in section 2.
11.3 Advertising and analytics inside an application
Advertising software development kits and third-party advertising identifiers are not built into applications the company publishes. Where measurement is needed to keep an application working, it is aggregated, tied to no advertising identifier, and disclosed in both store listings.
12. Lawful bases, gathered in one place
Each boundary above names its lawful basis as it goes. This section gathers them so that the whole picture can be seen at once, since a basis determines which rights you have and is therefore worth finding quickly.
| Basis | Article | Where it is used |
|---|---|---|
| Legitimate interests | 6(1)(f) | Connection and font records at section 5; handling correspondence at section 6; keeping business contacts and access records at section 8. Each interest is named at section 13 |
| Steps before a contract, and performing one | 6(1)(b) | Quoting for work after an enquiry, then everything done to deliver a signed engagement |
| Legal obligation | 6(1)(c) | Accounting and tax records, and a disclosure the law compels |
| Consent | 6(1)(a) | Only where something genuinely optional is offered and asked for separately. No part of this website relies on it, and it is never used as a fallback for something already covered above |
Scroll the table sideways where your screen is too narrow to hold it.
At the boundary in section 7 the lawful basis is not ZAAPTO's to select. The client chooses it as controller, records it in their own notice, and instructs us accordingly.
13. Legitimate interests, named
Naming an interest is the point of relying on it. A notice that says "legitimate interests" without saying whose, or for what, has told the reader nothing they can weigh or object to. These are the four, each with the balance that was struck against it.
13.1 Keeping the website up and diagnosable
The interest is publishing a reachable site and being able to work out why it broke. Connection records are the minimum that makes either possible, they are generated by the act of serving a page rather than collected on purpose, they build no profile, and they age out on the provider's own cycle. A reader loses nothing they would reasonably expect to keep.
13.2 Setting the pages in the intended typefaces
The interest is a site that reads the way it was designed to read. The cost is that your browser tells a font host the ordinary things any request tells any server. It is disclosed at section 5, it is repeated in chapter three, and any reader who would rather not make the request can stop it in a few seconds by the method given there. That escape route is what makes the balance defensible.
13.3 Answering the people who write in
The interest is running a business that replies to correspondence, and the sender's interest points the same way, since they wrote in order to be answered. Only what the sender chose to send is handled, only for as long as section 16 allows, and an objection is straightforward to make and quick to act on.
13.4 Knowing which keys were cut, and when they were returned
The interest is being able to demonstrate that access into a client's estate was scoped, granted and withdrawn as agreed. This protects the client at least as much as it protects us. The record covers accounts and dates rather than anything about the person who administered them, which keeps it proportionate to the job it does.
Any of these can be objected to under section 18. An objection is weighed properly rather than answered with a form of words, and where the interest cannot carry the weight, the handling stops.
14. Special category and criminal offence records
Article 9 fences off a set of particularly sensitive categories: health, genetic and biometric identifiers, ethnicity, political opinion, religious or philosophical conviction, trade union membership, and information about sex life or sexual orientation. Article 10 does something similar for criminal convictions and offences.
At the boundaries where ZAAPTO is the controller — sections 5, 6, 8 and 11 — none of these categories is sought, and none is needed for any of the purposes described. If sensitive detail arrives unasked in a message, it is not made use of, and it goes when the correspondence around it goes.
At the boundary in section 7 the position is different, because a client's own systems may well hold such records: a business with an occupational health file, a charity with case notes, an employer with equality monitoring. Where an engagement touches data of that kind, the client identifies it as controller, names the Article 9 condition it relies on, and instructs us in writing. ZAAPTO handles it only within those instructions, and a request to instrument or automate a process resting on sensitive data is scoped with that fact in front of both parties rather than discovered halfway through.
15. Children
ZAAPTO sells to organisations. This website, the enquiry address and the company's services are all directed at people acting in a business capacity, and none of them is designed for, marketed to, or of any plausible interest to a child.
No part of this site invites an age, and none of the boundaries where ZAAPTO is the controller is expected to produce data about children. Should it become apparent that information about a child has arrived at one of them without any lawful reason to be there, it is deleted rather than retained, and a parent or guardian who believes that has happened can raise it at the address in section 2 and will get a direct answer.
Where a client's own systems hold data about children — a school, a paediatric practice, a youth organisation — the client is the controller, and the extra care that comes with children's data is written into the instructions and the scope before any work begins. An application published under section 11 that was ever aimed at a younger audience would carry its own notice, the age rating each store requires, and a description of the additional protections applied.
16. Retention
A retention period is a promise about deletion, so each one below has a reason attached. Records are kept for the stated period and then removed, and where something is genuinely needed for longer, the reason is the thing that gets recorded, not an indefinite extension of the period.
| Record | Boundary | Kept for | Why that period |
|---|---|---|---|
| Connection records | 5 | The hosting provider's own cycle, measured in days | Long enough to investigate an incident, too short to become a history of anybody |
| An enquiry that goes nowhere | 6 | Twelve months after the last message | Enough for the same person to come back and be recognised, without keeping a file on a conversation that ended |
| An enquiry that becomes work | 6 | Folded into the engagement record below | The conversation is part of what was agreed and is read alongside it |
| Engagement records and contracts | 8 | Six years from the close of the engagement, longer while a dispute is running | Matches the limitation period for a contract claim in England and Wales |
| Accounting and tax records | 8 | Six years after the financial year they fall in | Fixed by tax and company legislation rather than by choice |
| Access administration records | 8 | Six years from the close of the engagement | Kept with the contract they evidence, since that is what they are read against |
| Samples taken during scoping | 7 | Destroyed as soon as the question they were taken for is settled | The client's instructions govern, and the shortest workable period is the instruction sought |
| Client data in a client system | 7 | The client's schedule, not ours | The controller sets retention; the processor follows it |
| Application account records | 11 | Removed on request, and otherwise when an account is closed | Section 23 sets out the route and the timing |
Scroll the table sideways where your screen is too narrow to hold it.
17. Holding the boundaries closed
Article 32 asks for measures suited to the risk. The risk profile of this company is unusual in one respect worth being honest about: the most valuable thing it touches is access into other organisations' systems, so the measures are weighted towards access rather than towards storage.
- Access into a client's estate is requested one system at a time, named, and narrowed to what the described work needs. A service account with reduced permissions is used ahead of a person's login wherever a system offers one.
- Credentials are issued by the client, live in the client's own secret store, and are cut off by the client without needing anything from us. Nothing is copied into a personal note, a spreadsheet or a message.
- Multi-factor authentication is used on the accounts that matter, and devices carry full-disk encryption.
- Client data is not pulled onto local machines as a matter of habit. Where a sample is genuinely necessary it is minimised, agreed in writing, and destroyed on schedule.
- This website has no database behind it and no administrative interface exposed to the internet, which removes a whole class of problem rather than mitigating it. Pages are served over HTTPS with a content security policy that names every host a page may contact.
- Correspondence and business records sit in reputable managed services with their own security programmes, chosen partly for that reason.
What these measures are for is stopping records being destroyed, lost, altered, exposed, or reached by somebody with no business in them — whether that happens through an accident or because someone intended it. No arrangement is perfect, which is why section 20 exists and says what happens when one of these fails.
18. Your rights, and how to use them
Where ZAAPTO is the controller, these are yours to exercise against this company. Where the boundary at section 7 applies, they are exercisable against the client instead, for the reason given at 7.3.
- To be told what is going on. Articles 13 and 14. This chapter is how that duty is discharged, which is why it is arranged to be searched rather than merely published.
- To get a copy. Article 15. You can have confirmation of whether anything about you is held, a copy of it, and the surrounding detail: purposes, categories, recipients, retention, and where it came from.
- To have it corrected. Article 16. Something inaccurate gets fixed, and something incomplete gets completed.
- To have it deleted. Article 17. Available when the data is no longer needed, when consent was the basis and has been withdrawn, when an objection succeeds, or when handling was unlawful. It gives way where a legal obligation or a live legal claim requires the record to survive, and you will be told which applies.
- To have it frozen. Article 18. Handling can be restricted while an accuracy dispute or an objection is being resolved.
- To take it with you. Article 20. Where the basis was consent or a contract and the handling is automated, you can have your data as a file ordinary software will open, or sent straight to another organisation where that is technically workable.
- To object. Article 21. Where legitimate interests are the basis, you can object and the handling stops unless there are grounds strong enough to outweigh your objection. Against direct marketing there is nothing to weigh: the objection is absolute and takes effect at once.
- To withdraw consent. Article 7(3). As easy to withdraw as it was to give, with no effect on what was lawfully done beforehand.
- Not to be subject to a solely automated decision with legal or similarly significant effects. Article 22, and see section 21.
18.1 Making a request
Write to [email protected]. Say what you want; naming an article is helpful but not required, and a request written in plain words is perfectly valid. There is no charge, no form to fill in and no need for anyone to be represented.
The statutory clock is one month from receipt, extendable by two further months for a request that is genuinely complex, in which case you are told inside the first month that the extension is being taken and why. In practice a request at this company involves searching a mailbox and a small set of business records, so the honest expectation is considerably sooner than the deadline.
Identity is verified only where there is a real doubt about who is asking, and proportionately: enough to be sure a record is not handed to the wrong person, never a demand for documents that would tell us more about you than we already hold.
19. Complaining, and the ICO
If something here has gone wrong, the quickest route is to say so at [email protected]. A complaint is answered by the people who run the company, and the answer explains what was found rather than merely confirming that the complaint arrived.
You are not obliged to come here first, and nothing in this chapter conditions your right to complain on having done so. The United Kingdom's supervisory authority for data protection is the Information Commissioner's Office, and you may go to it at any time:
- Information Commissioner's Office at Wycliffe House on Water Lane, Wilmslow, Cheshire SK9 5AF
- Telephone 0303 123 1113
- The ICO publishes its complaint process, and its live contact details, on its own website
The right to a judicial remedy sits alongside the right to complain, and using one does not spend the other. Regulation 6 questions about storage on your device, covered in chapter three, go to the same regulator.
20. When a boundary fails
A personal data breach is any security failure that destroys, loses, alters, exposes or opens up personal data, deliberately or otherwise. Losing a laptop counts. So does sending an attachment to the wrong recipient. The word covers far more than an intrusion, and treating it narrowly is how organisations end up reporting late.
20.1 Where ZAAPTO is the controller
The incident is contained first, then assessed and recorded — every one, whether or not it turns out to be reportable, because the record is what makes the next assessment better. Where the failure looks likely to put people's rights at risk, the ICO is told inside 72 hours of the company becoming aware of it; if that deadline is missed, the report states plainly why it slipped rather than leaving the gap unexplained. Where the risk to the people affected is high, they are told directly, in language that says what happened, what it means for them, and what to do about it.
20.2 Where ZAAPTO is the processor
The client is told without undue delay, as Article 33(2) requires, with whatever detail they need in order to make their own assessment and meet their own deadline. The decision about notifying the regulator or the individuals belongs to the client as controller. Our job is to make sure they can take it in time and with accurate information in front of them.
21. Automated decisions and profiling
No decision with a legal or similarly significant effect on anyone is taken by automated means at any boundary where ZAAPTO is the controller. Nobody is scored, ranked or profiled here. Whether to reply to an enquiry, whether to quote for work, and whether to take an engagement are all judgements made by a person who can be asked to explain them.
Automation is of course the substance of what the company builds, and that deserves a straight answer rather than a silence. Work delivered to a client can route records, calculate, trigger and update inside the client's estate. Where a piece of work would produce a decision about a person that carries legal or similarly significant weight, that is flagged during scoping, and the design of the safeguards — human review, a route to challenge the outcome, an explanation the affected person can actually read — is the client's responsibility as controller and part of what gets specified in writing before anything is built.
22. Marketing
ZAAPTO runs no mailing list, publishes no newsletter and sends no campaigns. There is nothing here to subscribe to and nothing to unsubscribe from, which is the simplest way for a company of this size to keep out of trouble under both the electronic communications regulations and the general law.
Contact details that arrive through an enquiry are used to answer that enquiry and to carry on the conversation it started. They are not added to a list, not used to send unrelated material later, and not passed to anybody else for their own marketing. A message that asks about one process will only ever be answered about that process.
Should the company ever decide to send something periodic, it would be asked for separately and in terms, it would carry a working way out of it in every message, and this section would say so before the first one went out.
23. Deleting an account and its data
Both stores require a published, reachable route to delete your account and the data attached to it, and the route belongs in the same document as everything else rather than behind a support queue.
23.1 An application published by ZAAPTO
Where an application published under section 11 has accounts, you can delete your account from inside the application itself, and the same request can always be made in writing to [email protected] from the address the account uses. Either route ends the same way: the account is closed and the content held under it is removed from live systems, with routine backups aging out on their own cycle afterwards.
What survives a deletion of data is limited to what has to. An accounting record of a payment stays because tax legislation says it must. A minimal note that a particular account was deleted and when may be kept so that the deletion itself can be evidenced. Neither is used to rebuild anything about you, and you are told which of them applies to your request.
23.2 Everything else this chapter covers
There is no account to close at the other boundaries, so deletion is simply the erasure right at section 18 exercised at the address in section 2. Correspondence and business contact records are removed on request, subject only to the retention that a legal obligation or a live legal claim compels, and you are told which of the two is holding the record if either is.
23.3 Data inside a client's system
Deletion there is the client's decision to make as controller. A request reaching us is passed on and acknowledged as described at 7.3, and where an engagement is ending, the terms at 3.3 require the material to be returned or destroyed on the client's instruction.
24. Revisions to this chapter
This chapter describes the company as it stands on the effective date printed at the head of the page. It is rewritten when something it describes actually changes: a new supplier at section 9, a different transfer mechanism at section 10, an application published at section 11, or a purpose that did not exist before.
A revision that materially affects how personal data about you is handled — a new recipient, a new purpose, a longer period in the schedule at section 16 — is not left for a reader to discover. Where the company holds a way of reaching the people affected, they are told directly before the change takes effect. Where a change rests on consent, fresh consent is asked for rather than assumed from silence.
The effective date moves whenever the wording does, which makes it the reliable way to check whether you are reading the version you read last time.
The other chapters of the handbook are the terms of use and storage on your device. Anything unclear in any of the three goes to [email protected], and a question about the wording is treated as a defect in the drafting rather than a misreading by the reader.