Back to home

StudyMarket Privacy Policy

Version 1.0, effective 8 September 2026.

Replaces the Privacy Policy effective 1 May 2026. The English text is authoritative.

1. Who we are, and what we are responsible for

StudyMarket is operated by Rokket Digital Ltd, company number 12535365, Suite 301, 179 Whiteladies Road, Bristol, BS8 2AG, United Kingdom. We are registered with the Information Commissioner's Office under reference ZB289312.

Write to us about anything in this policy at privacy@rokket-digital.co.uk. It is a monitored address and it is the address our subject access tooling uses. We have not appointed a data protection officer; Article 37 does not require one on our processing, and that assessment is recorded and reviewed.

1.1 When we are a processor, and when we are a controller

Two different things happen on this platform and the law treats them differently.

  • A processor, acting for an agent or a provider: Everything about a student that an agent or a provider enters, and everything we do with it to serve that customer's own purpose: storing it, showing it to a connected user the customer chooses, the prospect summary, matching programmes, generating a proposal, transcribing a voice note, extracting from a document the customer uploads, and translating content. The agent or the provider decides why and how. We act on their instructions. If you want to know what is held about a student, ask the agent you dealt with. They are the controller and they hold the relationship with you. We will pass a request to them within three working days and help them answer it.
  • A controller, in our own right: Account and user data. Authentication, security, fraud and abuse prevention, rate limiting and audit. Engagement recorded against a proposal page. Platform analytics and our own growth reporting. Artificial intelligence cost and usage records. Billing. Our own marketing to users and prospective users. We decide why and how, and this policy describes it. Ask us directly about any of it.

The characterisation is a question of fact and is not settled by what a contract calls us. If a supervisory authority or a court decides we are a controller for something we have declared as processor, we will comply with the controller obligations for it, tell the customers affected, and change this policy. Clause 2.5 of the Data Processing Addendum commits us to that.

2. What we collect

2.1 As a controller

  • Account and identity: Name, business email address, telephone number, job title, and the organisation you act for. Authentication and session data is held by our identity provider.
  • Profile and business information: What you write about your organisation, the services you offer, and the content you choose to publish on the platform.
  • Platform activity: What you do on the platform: searches, connections, records created, messages sent, and the audit trail that records who did what.
  • Proposal page engagement: That a proposal page was opened and when, including reopens; which of the proposed programmes were engaged with and the relative attention given to each; and share events. Recorded against the proposal, never against a person. Section 6 sets out what we do not do.
  • Technical data: Ordinary web server access logs, kept briefly for security and diagnostics. A truncated, salted hash of a network address on unauthenticated public endpoints, held for rate limiting and abuse prevention only, expiring at 30 days.
  • Cookies and analytics: Only where you have consented. The Cookie Policy sets out what each one does.
  • Business contact details of agencies we have not yet dealt with: Where you are a contact at an education agency, we may hold your business contact details without having obtained them from you. We obtain them from publicly available and industry sources: subscription industry directories, accreditation and quality-assurance schemes, national and international trade association member registers, self-listing agency directories, and our own records of previous contact. We use them to introduce StudyMarket to agencies whose business is placing students. You can ask us at any time what we hold, where we got it, and to stop contacting you, and we will stop. Before we contact you, we may check that an email address is valid and deliverable using a third-party email verification service. This confirms whether the address works; it does not add to the information we hold about you.
  • If you upload contact details of people you work with, for example your existing agent list, you confirm you have the right to share them with us and a lawful basis for doing so, and that we may contact them for the purpose you have asked us to. We record that confirmation and the date you gave it. We may check those addresses are deliverable using a third-party verification service before anything is sent.

2.2 As a processor, on behalf of an agent or a provider

We hold what our customers enter. That includes information about students, some of whom are under 18: names and identifiers, school, nationality, what the family is looking for, budget and qualifications, notes, messages, uploaded documents, voice notes and the proposals produced from them. It includes medical, dietary and insurance information where an agent records it, which is special category data under Article 9.

We do not hold safeguarding records and we do not accept them. Clause 12.3 of the Terms prohibits placing one on the platform, in any field. The incident field on a student record holds a short reference from a fixed list that a concern was raised and recorded with the agency, with a date and a reference. It never holds the substance of the concern, and the field does not accept typed prose. If a safeguarding record reaches us anyway we restrict it, take it out of every search, index and model request, tell the customer, and delete it on their instruction or within 30 days of discovery. We do not screen uploads for them, and we do not claim to.

3. Why we use it, and on what basis

  • Create and run accounts, and operate the platform: To provide the service you signed up for. Article 6(1)(b), performance of a contract
  • Connect agents and providers, and record their agreements: It is what the platform is for. Article 6(1)(b)
  • Keep the platform secure: authentication, fraud and abuse prevention, rate limiting, audit: To protect a platform that holds information about children. Article 6(1)(f), legitimate interests
  • Record engagement against a proposal page: So the agent the family engaged can see that their proposal was read and which programmes interested the family, and follow up on it. The family asked the agent to help them choose. Article 6(1)(f), legitimate interests
  • Analytics, funnel reporting and our own growth reporting: To understand how the platform is used and where it fails. Article 6(1)(f), and consent where a cookie or a third-party analytics service is involved
  • Contact agencies about StudyMarket: Business development with businesses whose trade is placing students. Article 6(1)(f), with an opt-out in every message. A separate legitimate interests assessment covers it.
  • Meet our own legal obligations, and keep the records that demonstrate compliance: Because we have to. Article 6(1)(c), and Article 6(1)(f) for the defence of claims

Special category data

Where an agent records information about a student's health, medical needs or dietary requirements, the Article 9 condition is explicit consent under Article 9(2)(a), and it is the agent who obtains it from the family. The agent has the direct relationship, creates the record and decides which providers receive it. We have no relationship with the family and cannot obtain that consent. The platform will not save those fields without the agent's contemporaneous, versioned attestation that consent was obtained, and clause 17.2(g) of the Terms requires the agent to produce evidence of it on request. Article 9(2)(c), vital interests, is available in a genuine emergency and is not a substitute. If a family withdraws consent, the information is removed from the platform on the agent's instruction, ahead of any retention period.

4. Artificial intelligence, and what each feature sends

Some features send content to an artificial intelligence provider. We publish which ones, and what each one sends. There are ten entry points across two providers. Clause 13 of the Data Processing Addendum carries the full table, generated from our own code, and it is available to anyone who asks.

  • Four entry points send no student information at all: programme matching, programme comparison, classifying a provider's own marketing assets, and reading a provider's own brochure.
  • One sends student notes with the identifiers removed: the prospect summary. Removing a name does not remove what the note says. A note reading "severe asthma, carries an inhaler" survives with the name replaced and the health fact intact, and pseudonymised special category data is still special category data.
  • Five send identified student information, because the customer's own purpose requires the student to be named: extracting structured fields from a note the agent pasted, the proposal quick check, proposal generation and its shortened retry, and voice note transcription. In every case the output returns only to the customer who asked for it.

Voice audio is streamed from the browser directly to the transcription provider's European endpoint and never reaches our servers. Only the transcript is stored.

  • What we will never do with it: We do not use any student information to develop, train, fine tune, evaluate or benchmark any model, ours or anyone else's. We do not use it for product development, for research, or to produce insight across customers. Any market insight we build is built from agent-side data only, meaning data about an agency's or a provider's own business activity which contains no student information and nothing derived from a student record. We require each model provider, by contract, not to use content submitted through our account to train its models. And proposal page engagement is not an exception: it goes to the agent's screen, it does not go into a model, and it will never be used to rank or re-rank programme recommendations. The person browsing may be the student, and feeding their behaviour into a recommender would be profiling a child.

No decision producing a legal or similarly significant effect is made about anyone by automated means. A programme ranking is a suggestion to the agent, who decides.

5. Who we share with

5.1 Between users of the platform

An agent chooses whether to share a student's record with a provider, which provider receives it, when, and what is included. We give effect to that decision and record it; we do not make it. The agent and the provider each determine their own purposes for the record and each is a controller of it in their own right. Neither is a joint controller with us. Where two users jointly decide the purposes and means of processing between themselves, the arrangement Article 26 requires is theirs to make.

5.2 Companies that help us run the platform

Fourteen entries. Thirteen are processors and each has a data processing agreement in force; the fourteenth, Google Maps Platform, is an independent controller and no such agreement arises. The current list, what each touches, its region and the status of its data processing agreement, is published at studymarket.ai/subprocessors and at Annex 2 to the Data Processing Addendum. It is maintained in English so that it is always current, and a line in your own language on that page says so. We give at least 30 days notice before a new processor starts.

  • Clerk, authentication and account management
  • Resend, Email communications
  • DigitalOcean, database hosting
  • Airtable, CRM and lead enrichment data storage
  • Google Maps, address and location autocomplete
  • Google Analytics 4, site usage analytics (only with your cookie consent)
  • Deepgram, voice-to-text transcription for proposal notes
  • Sentry, error monitoring and diagnostics
  • Vercel, application hosting and file storage
  • Anthropic, AI-assisted features (e.g. proposal drafting)
  • Woodpecker, outbound email campaign delivery
  • Brevo, marketing email and contact management
  • MillionVerifier, Email address verification
  • DeepL, translation of dynamic content and proposal fields into other languages

5.3 Everyone else

  • A court, a regulator or a law enforcement body, where we are required to disclose.
  • A buyer of our business or assets, on the same terms as this policy.
  • A messaging platform, by link preview: When a proposal link is pasted into WhatsApp, Slack, iMessage or Telegram, that platform fetches the page to build a preview, and receives the proposal's title, description and cover image. That is a consequence of sharing a link rather than something we initiate, but it is a disclosure and we record it as one.
  • Google, as a controller in its own right, for address autocomplete: Typed address fragments go from your browser direct to Google Maps. That is not a processor relationship and Google's own terms govern it.
  • We do not sell personal data, and we do not serve advertising on the platform.

6. The proposal page

A proposal page is a private page an agent sends to a family about one student. It is reached only by an unguessable link, is not indexed and is not discoverable, and expires 30 days after it is created. It has its own short privacy notice, written to be understood by a fifteen-year-old, because we accept that the person opening it may be the student.

What is recorded. That the page was opened and when, including reopens; which of the proposed programmes were engaged with and roughly how much attention each got; and share events. All of it is recorded against the proposal and is visible to the agent who sent it.

What is not, and this is the part that matters. We set no cookie, no local storage identifier and no device fingerprint. Nothing is stored on, or read from, the visitor's device, which is why the page carries no consent banner. We make no attempt to work out which individual opened a link. The browser user agent is not written to the proposal record. The truncated hash of the network address exists for rate limiting on an unauthenticated endpoint, expires at 30 days, and is not shown to anyone.

The distinction we draw is not how much is captured but whether the person is identified. We do not need to identify the visitor to give the agent the engagement picture, because the link already identifies the family: every open of that link is that family by definition.

The page does not ask for free text. The reserve-confirm step accepts only the structured options it presents, so there is nowhere on the page for a family to type medical or personal information that nobody asked for.

We do not operate an age gate on the page. It would collect more information about a child than it protects, and it would not amount to highly effective age assurance in any event.

7. International transfers

We process in the United Kingdom, the European Economic Area and the United States. Annex 2 to the Data Processing Addendum states the region of each processor and the transfer instrument each relies on: the European Commission standard contractual clauses with the Addendum issued by the Information Commissioner, the International Data Transfer Agreement, or certification under the UK Extension to the EU–US Data Privacy Framework. We maintain a register of which applies to whom, including any case where the position is not yet settled, and we will give it to you on request.

Where a customer's own users access the platform from outside the United Kingdom, they are reading data their own organisation entered and instructed us to hold. We are making it available to the same controller that instructed the processing, not sending it to someone else, so it is not a restricted transfer made by us and no separate transfer instrument is provided for it. Counsel confirmed that position on 8 September 2026. Transfers we ourselves make to a processor outside the United Kingdom are a different thing and are covered in the paragraph above.

8. How long we keep things

What we keep, and how long we keep it:

  • Student identifiers, requirement notes and generated summaries: Anonymised 24 months after the last activity on the record
  • Medical, dietary and insurance information: Purged 90 days after the programme ends, with a 24-month backstop counted from the consent record. Removed immediately on the agent's instruction that the family has withdrawn consent, ahead of every period here. Longer only where medication was administered, where there was an incident, or where the information became part of a safeguarding matter, in which case the customer holds it in their own systems.
  • The incident reference on a student record: It is a business record that a referral was made, not a record of the concern. It follows ordinary student-record retention and does not attract safeguarding retention periods.
  • Messages and notes: Anonymised 24 months after the last message. Deleted rows purged at 30 days
  • Documents and attachments: They follow the record they belong to. Deleted files purged at 30 days
  • Proposals, and proposal page engagement: 24 months, following the student record. The rate-limiting hash expires at 30 days
  • Artificial intelligence usage records: Identifiers stripped at 13 months. No model request content and no model response content is stored at all
  • Events and audit trail: 24 months, then actor identity and free text stripped
  • Account data: Anonymised 12 months after the account closes
  • Booking records, returns, invoices and related correspondence: Six years from the end of the season they concern, for accounting purposes. Clause 16.7 of the Terms lists exactly which fields, so that it cannot extend to holding a student's data for six years. No student personal data is retained under it.
  • Analytics: 14 months
  • Outreach and marketing contacts: 24 months from the last engagement
  • Unsubscribe and suppression records: Indefinitely. Deleting one would remove a suppression and allow us to contact somebody who had asked us to stop

Every period is a default that a hold suspends: a live safeguarding investigation, a statutory inquiry instruction, a litigation hold, or a police investigation. A retention period is never an answer to a rights request. If you exercise a right, it is answered within the statutory period, by the customer where the customer is the controller and by us where we are, whatever period appears in this table.

9. Your rights

You have the right to be told what is held about you, to have it corrected, to have it erased in the circumstances the law provides, to restrict or object to processing, to portability, and to withdraw consent where consent is the basis. You can complain to the Information Commissioner's Office at ico.org.uk at any time, and we would rather you told us first so we can put it right.

Where to send a request. If it is about a student, meaning what is held, correcting it or removing it, the education agent you dealt with is the controller, and they can answer it fully and quickly. If a request reaches us instead we will pass it to them within three working days and help them answer it. If it is about something in section 1.1 where we are the controller, meaning your account, the security and audit records, proposal page engagement, analytics, or our marketing to you, send it to us at privacy@rokket-digital.co.uk and we will answer it ourselves.

One limit on requests about a student. Where a record is under a safeguarding hold, our tooling deliberately refuses to produce it, because the law restricts disclosure of child abuse data where release to a person with parental responsibility would not be in the child's interests. We have built to the wider test rather than the narrower one and we have asked counsel to tell us where the line properly falls. Until that is answered, a parent asking what is held about their child may not receive a complete answer, and we record that here rather than leave it to be found.

10. Security

Annex 3 to the Data Processing Addendum describes the measures in place and, separately and by name, every measure we have committed to and not yet delivered, with a date against each. It is published rather than given on request.

11. Children

The platform is for businesses. Users must be 18 or over and must act for an onboarded organisation, and a customer warrants that everyone it gives access to is 18 or over. Students and families do not hold accounts and cannot register.

Students are nevertheless the people this platform holds the most information about, and many of them are under 18. That is why the safeguarding line at section 2.2 exists, why the proposal page is built the way section 6 describes, and why we complete and keep under review a children's access assessment and an illegal content risk assessment. A proposal link is provided for the agent to send to the adult parent, guardian or authorised representative of the student, and clause 6.6 of the Terms requires exactly that.

12. Changes, and how you will know

We will publish a new version with its effective date and, for a material change, give at least 30 days notice by email and in the platform. We keep every published version, in every language, so that the policy as it stood on a given day can be produced rather than reconstructed.

This policy is published in twenty languages. The English version is authoritative. The processor list is maintained in English only and carries a line in your own language saying so, because a stale translation of that list would be misleading.

13. Contact