Corrected against the deployed system on 7 September 2026; still awaiting legal review. This policy now describes how the platform actually works, including the parts that fall short of what an earlier draft claimed. Two things remain outstanding: it has not been reviewed by a data protection solicitor, and our ICO registration is not yet confirmed. Where a statement depends on a contract we have not seen executed, it says so rather than assuming.
1. Who we are
admitAI is a software platform operated by 24 IT Solutions Ltd, a company registered in England and Wales, with its registered office in London, United Kingdom. In this policy "we", "us" and "our" mean 24 IT Solutions Ltd.
We provide software to student recruitment agencies. Those agencies use our platform to manage their students' applications to universities. This distinction matters a great deal for how data protection law applies to us, so we set it out in full in the next section.
2. When we are a controller and when we are a processor
We act in two different capacities depending on whose data is involved.
We are the controller for:
- Data about the agencies who are our customers, and the individual staff at those agencies who hold accounts with us.
- Data about people who contact us, request a demo, or subscribe to anything we send.
- Data about visitors to this website.
For that data, we decide why and how it is processed, and this policy governs it directly.
We are a processor for:
- Student data. When an agency uses admitAI to manage a student's application, the agency is the controller and we are the processor acting on their documented instructions.
If you are a student whose data an agency holds in admitAI, the agency — not us — is responsible for how your data is used, and you should direct your requests to them in the first instance. We will assist them in responding to you. Our obligations to agencies in this role are set out in our Data Processing Addendum.
3. What we collect
Agency account data (we are controller)
- Name, work email address, telephone number, job role and the agency you work for.
- Authentication data, including password hashes and session tokens. We never store passwords in readable form.
- Billing details, including company name, billing address and VAT number. Card details are handled by our payment provider and never reach our systems.
- Usage and audit logs — which features you use, actions taken on student records, IP address, browser and device type, and timestamps.
- Support correspondence.
Student data (the agency is controller, we process it)
The categories below are typical of what agencies upload. The precise scope is determined by each agency, not by us.
- Identity and contact details: name, date of birth, nationality, passport details, address, email address, phone number.
- Academic history: qualifications, transcripts, grades, institutions attended, English language test results.
- Immigration information: visa status and history, previous refusals, CAS details, biometric appointment dates, sponsorship details.
- Financial evidence: bank statements and sponsor documentation supplied for visa maintenance requirements.
- Application data: universities applied to, offers, conditions, deposits, enrolment status.
- Communications between the student and their agency across the channels the agency has connected.
Some records may contain special category data, such as health information disclosed in a visa context. A prior immigration refusal is not, by itself, criminal offence data; separate offence information is treated as such only where it is actually present. Agencies are responsible for identifying the appropriate lawful basis and any additional processing condition, and we apply the safeguards described in section 10.
Website visitor data
- Pages visited, referring page, approximate location derived from IP address, browser and device type.
- Anything you type into a form on this site and choose to send us.
4. Why we use it
- To provide the platform — creating and maintaining accounts, delivering the features agencies subscribe to, and syncing data between the agency workspace and the Student Hub.
- To support you — responding to questions, investigating faults, and restoring service after an incident.
- To bill you — processing subscription payments and maintaining financial records we are legally required to keep.
- To secure the service — detecting unauthorised access, preventing fraud, and maintaining the audit trail agencies rely on for their own compliance obligations.
- To improve the product — understanding which features are used and where people get stuck, using aggregated and pseudonymised data wherever it will do the job.
- To communicate with you — service announcements, security notices, and, where you have agreed to it, occasional product news.
- To meet our legal obligations — including tax, accounting and responding to lawful requests from authorities.
5. Lawful bases
| Processing | Lawful basis |
|---|
| Providing the platform to an agency | Performance of a contract |
| Billing and financial records | Contract, and legal obligation for retention |
| Security monitoring and audit logging | Legitimate interests — protecting the service and our customers' data |
| Product analytics and improvement | Legitimate interests — improving a service you use |
| Service and security notices | Contract, and legitimate interests |
| Marketing email to prospective customers | Consent, or legitimate interests in a business context under PECR |
| Non-essential cookies | Consent |
| Student data processed for an agency | Determined by the agency as controller; we act on their instructions |
Where we rely on legitimate interests, we have assessed that our interest does not override your rights and freedoms. You can ask us for that assessment.
6. AI processing
Parts of the platform use large language models and optical character recognition to generate assessment reports, read uploaded documents, draft messages and score leads. Three commitments apply, and we consider all three to be non-negotiable.
- We do not use your data to train models, and we never will. What we cannot yet state as a contractual guarantee is the same for our AI provider: we call Google's Gemini API, and whether customer content is excluded from training turns on the commercial tier that account sits on. We are confirming it in writing and will say plainly here what it turns out to be. Until then, treat this as our intention rather than as a term you can rely on.
- A human reviews consequential output. Assessment reports, recommendations and shortlists are produced inside the agency workspace, where a counsellor reads them and decides what to send. That review is how the product is used, but we should be precise: there is no technical gate that stops an agency releasing an unread draft, and our automated outreach features send messages on a schedule without a per-message approval step. There is no fully automated decision-making that produces legal or similarly significant effects on a student within the meaning of Article 22 UK GDPR.
- Only what is needed is sent. We send the minimum data required for the task, and document processing happens without retaining copies at the AI provider beyond the duration of the request.
Our current AI sub-processor is listed on our sub-processors page, which we keep up to date.
7. Who we share data with
We do not sell personal data. We share it only in these circumstances:
- Sub-processors who provide infrastructure and services on our behalf, each under a written contract imposing equivalent obligations. The current list is on our sub-processors page.
- Services the agency chooses to connect — for example their WhatsApp Business account, email provider, calendar or CRM. This is done on the agency's instruction, and their relationship with those providers is their own.
- Universities and application portals, where an agency submits an application through the platform. This is the entire purpose of the service.
- Professional advisers — lawyers, accountants and auditors, bound by confidentiality.
- Authorities, where we are legally required to disclose. We will notify the affected customer unless legally prohibited from doing so.
- An acquirer, in the event of a merger or sale of the business, subject to this policy continuing to apply.
8. International transfers
Our application servers are in London, and documents uploaded to the platform are stored on them. Our database is not in the UK — it is hosted in the United States, so the structured student and agency records it holds are transferred outside the UK. An earlier version of this policy said all customer data was held in the UK and the EEA; that was wrong, and we would rather correct it here than leave it standing. We are deciding between migrating the database to a UK or EU region and documenting the transfer properly under the International Data Transfer Addendum with a transfer risk assessment. Our sub-processors page records the location and current transfer position for every provider, including which ones we have not yet confirmed in writing.
9. How long we keep data
| Data | Retention |
|---|
| Agency account data | Duration of the contract, then 12 months |
| Student data held for an agency | As instructed by the agency; deleted within 30 days of contract termination unless they ask for it sooner |
| Uploaded documents | As instructed by the agency; erasure is currently a manual request to us — see the note below |
| Billing and financial records | 7 years, as required by UK tax law |
| Security and audit logs | 12 months |
| Support correspondence | 3 years from last contact |
| Marketing contact data | Until you unsubscribe, then a suppression record only |
| Website analytics | None collected — we run no analytics product |
Backups are held encrypted by our database provider and cycle out on their retention schedule, so deleted data may persist in backup for a period after deletion. It is not restored into live systems during that period.
These periods are our policy, and they are not yet enforced automatically. The platform has no scheduled job that deletes data when a retention period expires, and deleting a student in the workspace moves the record to a trash view rather than erasing it. In practice that means data is retained until someone asks us to remove it, and we do it by hand. Erasure and retention requests are honoured — write to
privacy@admitai.co.uk and we will action them — but we are not going to describe an automated lifecycle we have not built. Building it is on our roadmap, and this note comes down when it ships.
10. How we protect it
- Encryption. TLS 1.2 or above in transit, with HTTP Strict Transport Security enforced. At rest, we rely on the encryption our database and server providers apply to their storage; we do not add a second layer of encryption of our own inside the application, and we would rather say that than let “AES-256” imply more than it does.
- Tenant isolation. Agency records are logically isolated and access is scoped by tenant controls. The deployed architecture and verification evidence should be confirmed during security review.
- Access control. Role-based permissions, with counsellors seeing only their assigned caseload. Our own staff access is least-privilege, logged, and granted only where needed to support you.
- Audit trail. Changes to a student's record are logged with who made them, when, and what moved from what to what — distinguishing an edit made by agency staff from one made by the student. Sensitive values such as passport numbers are recorded as having changed without copying the value into the log. Every view and download of a document is logged with the reader, the time and the address, and that log is kept deliberately independent of the document so it survives the record being erased.
- Authentication. Students set a password for the Student Hub, stored only as a bcrypt hash. They receive it through a single-use, time-limited link sent to an address we have verified, and password resets work the same way. An earlier version of this policy said there were no student passwords at all; that described a design we did not build.
- Breach response. We maintain an incident response procedure. Where a breach is likely to result in a risk to individuals, we notify the affected agency without undue delay and in any event within 72 hours of becoming aware, so they can meet their own notification obligations.
No system is perfectly secure, and we will not tell you otherwise. What we commit to is proportionate measures, honest disclosure when something goes wrong, and no quiet handling of incidents.
11. Your rights
Under UK GDPR you have the right to access your data, correct it, erase it, restrict or object to its processing, receive it in a portable format, and withdraw consent where consent is the basis we rely on. You also have the right not to be subject to solely automated decisions with legal or similarly significant effects — and as set out in section 6, we do not make them.
If you are an agency user, contact us directly at privacy@admitai.co.uk and we will respond within one month.
If you are a student, contact the agency handling your application — they control your data. If they cannot help, or you cannot reach them, write to us and we will do what we can within our role as processor.
We do not charge for responding, and we will not make you justify the request.
12. Cookies
This website uses only what is necessary to make it work. We do not run advertising trackers, and we do not share visitor data with ad networks.
| Type | Purpose | Consent needed |
|---|
| Essential | Session management, security, load balancing, and remembering your cookie choice | No |
| Analytics | Aggregate page views and navigation paths, so we can see which pages are useful | Yes |
| Advertising | Not used | — |
Within the platform itself, we use only essential cookies. You can clear or block cookies through your browser, though blocking essential ones will stop the platform working.
13. Students under 18
The platform is sold to businesses and is not intended for direct use by children. Agencies do sometimes handle applicants under 18. Where they do, the platform requires a guardian consent record to be on file before any application can be submitted, as part of our compliance monitoring. Responsibility for obtaining that consent rests with the agency as controller.
14. Changes to this policy
We will update this page when our processing changes. For material changes affecting customers, we give at least 30 days' notice by email before they take effect. The version number and effective date at the top of this page always reflect the current text.
For any privacy question or to exercise a right, write to privacy@admitai.co.uk, or by post to the Data Protection Lead, 24 IT Solutions Ltd, London, United Kingdom.
If you are unhappy with how we have handled your data, you can complain to the Information Commissioner's Office at ico.org.uk or on 0303 123 1113. We would rather you came to us first so we can put it right, but you are under no obligation to.