01What this statement is for
Our Privacy Policy covers personal data we hold for our own purposes — the people who use the software we publish, enquiries, clients and suppliers. This statement covers the formal position behind it: which role we occupy for which data, and what we commit to when we handle personal data on behalf of a client while building or running something for them.
It is written for the people who have to assess us — procurement, security and data protection teams — and is intended to answer most of a supplier due-diligence questionnaire before you have to send one.
02Controller or processor?
Which role we occupy depends on whose purposes the data is being processed for:
- We are the controller
- Enquiries sent to us, our client and supplier relationships, our own accounts, our own staff. Governed by our Privacy Policy.
- We are the controller — our apps
- Personal data in the products we run ourselves, currently Partyyy at partyyy.party. Hosts still make their own decisions about who to invite and what to ask, and a host organising a private social event is often outside the GDPR's scope altogether under the domestic-purposes exemption. Partyyy's own GDPR statement works that split through in detail.
- We are the processor
- Personal data inside your systems, datasets or environments that we access, migrate, analyse or build against under your instructions. You remain the controller.
- We may be a joint controller
- Rarely, and only where we genuinely decide purposes together. If it arises, we agree the arrangement in writing under Article 26 first.
Getting this right matters, because it determines who owes what to the individuals concerned. If an engagement is ambiguous, we will raise it rather than assume.
03Our processor commitments
Before we process personal data on your behalf, we enter into a written data processing agreement meeting Article 28 of the UK GDPR. We are happy to sign yours, or to provide ours. Either way we commit to:
- process personal data only on your documented instructions, including on transfers, unless the law requires otherwise — in which case we will tell you first unless prohibited;
- make sure everyone authorised to process the data is under an appropriate duty of confidence;
- implement the technical and organisational measures in section 5;
- not engage a subprocessor without your authorisation, and to flow down equivalent obligations;
- assist you, so far as we can, with responding to data subject requests;
- assist you with security, breach notification, data protection impact assessments and prior consultation, taking account of what we know and can do;
- delete or return the personal data at the end of the engagement, as you choose;
- make available the information you need to demonstrate compliance, and allow for audits — see section 10;
- tell you promptly if we think an instruction infringes data protection law.
04Data minimisation in delivery
The most reliable way to protect personal data during a build is not to have it. We work that way by default:
- Synthetic or anonymised data first. Development and testing use generated or properly anonymised datasets wherever they will do the job.
- Pseudonymisation next. Where realistic data is genuinely needed, we prefer pseudonymised or masked extracts with identifiers stripped.
- Production data last, and only by agreement. Access to live personal data is scoped, time-limited, logged, and agreed in writing beforehand.
- Least data. We ask for the narrowest set of fields and records that supports the objective, not a convenient full export.
If an engagement is scoped in a way that needs more personal data than the purpose justifies, we will say so.
05Technical and organisational measures
Our measures are proportionate to the risk of the processing, and reviewed as it changes. In summary:
- Encryption
- TLS for data in transit; encryption at rest on managed storage and on all endpoint devices.
- Access control
- Least privilege, role-based access, individual named accounts, multi-factor authentication on business and cloud accounts, and prompt revocation when someone leaves an engagement.
- Secrets management
- Credentials and API keys held in a managed secret store, never in source control, rotated on a schedule and on personnel change.
- Separation
- Client environments, repositories and credentials are kept separate from each other and from our own systems. Client data is not commingled.
- Endpoint security
- Full-disk encryption, automatic screen lock, current OS and security patches, and remote wipe capability on devices used for client work.
- Logging and monitoring
- Access and change logging on systems we operate, with alerting on anomalous activity.
- Resilience
- Backups of systems we are responsible for, with restore testing. Backup of your own production systems remains yours unless we have agreed otherwise.
- Secure development
- Code review, dependency and vulnerability scanning, secrets scanning, and least-privilege service accounts for anything we deploy.
- People
- Confidentiality obligations in every contract, data protection awareness, and background checks where a client's risk assessment requires them.
- Supplier assurance
- Providers assessed before use and periodically thereafter, with written processing terms in place.
06Subprocessors
We keep the chain short. Where we do use a subprocessor — typically infrastructure, hosting, managed email, or a model provider forming part of the solution — we:
- seek your authorisation, either specifically or as a documented general authorisation in the DPA;
- put written terms in place imposing the same data protection obligations we owe you;
- remain fully liable to you for their performance;
- give you reasonable notice before adding or replacing one, with a fair opportunity to object.
A current subprocessor list for your engagement is available on request, and can be maintained as an annex to the DPA.
07International transfers
Where personal data moves outside the UK or EEA, we rely on one of the following, in this order of preference: adequacy regulations; the UK International Data Transfer Agreement or the EU Standard Contractual Clauses with the UK Addendum; or, exceptionally, an Article 49 derogation where one genuinely applies.
Where we rely on contractual safeguards, we carry out a transfer risk assessment covering the destination country's laws and the practical protections available, and apply supplementary measures — such as encryption with keys held in the UK, or keeping the data in-region — where the assessment calls for them.
Many providers offer UK or EU data residency. Where region matters to you, tell us at the start and we will design for it.
08Data subject requests
When we act as processor and someone contacts us directly to exercise their rights, we will:
- not respond substantively ourselves, unless you instruct us to;
- tell you without undue delay, and pass on what we received;
- help you locate, extract, correct, export or delete the relevant data within your response deadline;
- keep a record of what was asked and what we did.
We build systems so this is practical: knowing where personal data lives, and being able to find and remove it, is part of a sound design rather than an afterthought.
09Personal data breaches
If we become aware of a personal data breach affecting data we process for you, we will notify you without undue delay — in practice, as soon as we have confirmed something has happened and in any event within 24 hours of confirming it — so that you can meet your own 72-hour deadline to the ICO where one applies.
Our notification will describe, as far as we know at the time: what happened and when, the categories and approximate number of records and individuals affected, the likely consequences, the measures taken or proposed, and a contact point. We will follow up in phases as the picture becomes clearer rather than waiting for certainty.
We maintain an internal incident log, take containment steps immediately, preserve evidence, and carry out a post-incident review.
10Audits and assurance
We will provide the information reasonably needed to demonstrate compliance with Article 28, and will contribute to audits and inspections carried out by you or an auditor you appoint.
In practice, most questions are answered by a completed security questionnaire or a documentation review. On-site or hands-on audits are available on reasonable notice, no more than once a year unless a breach or a regulator requires otherwise, subject to confidentiality and to not compromising other clients' data. Each of us bears its own costs.
11Records, accountability and registration
We keep records of processing activities under Article 30 for the categories of processing we carry out on behalf of clients, and review them periodically.
Data protection responsibility sits with our management — given our size we are not required to appoint a statutory Data Protection Officer, and we have not. Contact for all data protection matters is hello ( at ) antcodelabs.ai.
Where the Data Protection (Charges and Information) Regulations 2018 require it, we pay the data protection fee and maintain our entry on the Information Commissioner's Office register. Our registration number is available on request.
12Impact assessments and AI
Where your use of a system is likely to result in a high risk to individuals — large-scale processing, systematic monitoring, or novel uses of technology, which includes many AI deployments — a Data Protection Impact Assessment is required before processing starts. We will support yours with technical detail on data flows, retention, access and safeguards, and will flag when we think one is needed.
For AI systems specifically, our AI Policy sets out how we handle training data, model providers, human oversight and automated decision-making. In short: client personal data is not used to train models, and we contract for the same from the providers we use.
Where a system produces decisions with legal or similarly significant effects on individuals, Article 22 restrictions apply. We design for meaningful human review rather than rubber-stamping, and will tell you when a proposed design would put you the wrong side of that line.
13Contact
Data protection questions, DPA requests, security questionnaires and audit enquiries can all go to hello ( at ) antcodelabs.ai with “Data protection” in the subject line.
You can also complain to the Information Commissioner's Office at ico.org.uk or on 0303 123 1113.