StudyMarket Data Processing Addendum
Version 1.0, effective 1 October 2026.
This addendum forms part of the StudyMarket Terms of Service and is incorporated into them by clause 1.4 of those Terms. It is written so that it can be read on its own, and so that a Provider can give it to a host school, an accrediting body, an inspector or an insurer without also giving them commercial terms. Defined terms used but not defined here have the meaning given in the Terms of Service.
Read the Terms of Service, which this addendum forms part of
1. Definitions
| Customer Personal Data | Personal Data which we process on behalf of a Customer under this addendum. It is principally Student Personal Data entered by an Agent or a Provider, together with the contact details of the Customer's own contacts held within a record. |
| Controller, processor, personal data breach, data subject, processing, supervisory authority | as defined in the UK GDPR. |
| Restricted Transfer | a transfer of Customer Personal Data to a country outside the United Kingdom which requires a transfer mechanism under Chapter V of the UK GDPR. |
| Subprocessor | a processor engaged by us to process Customer Personal Data on a Customer's behalf. |
| Transfer Mechanism | the transfer mechanism identified in clause 12.3 for a transfer to a Subprocessor. |
2. Roles
2.1 For Customer Personal Data, the Customer is the controller and we are the processor. This addendum sets out the terms required by Article 28(3) of the UK GDPR.
2.2 For the categories listed at clause 2.3 we are a controller in our own right. This addendum does not apply to them, and the Privacy Policy describes what we do.
2.3 The split, stated by processing activity rather than by label:
| Processing activity | Our role |
|---|---|
| Storing Prospect Records, notes, messages, attachments and Proposals entered by a Customer | Processor |
| Sharing a Prospect Record or a Proposal with a connected User the Customer chooses | Processor |
| Producing a prospect summary for the Customer who created the record | Processor |
| Ranking Programmes against a Prospect Record and returning the ranking to that Customer | Processor |
| Generating Proposal text for the Customer who created the Proposal | Processor |
| Transcribing a voice note the Customer records, and returning the transcript to that Customer | Processor |
| Extracting information from a document the Customer uploads, and returning it to that Customer | Processor |
| Translating Customer content into the language a Proposal is rendered in | Processor |
| Account creation, authentication, session management and user administration | Controller |
| Platform security, fraud prevention, abuse prevention, rate limiting and audit logging | Controller |
| Visitor telemetry on a Proposal Page, including the salted hash of the visitor's IP address and the browser user agent | Controller |
| Proposal Page engagement recorded against the Proposal: opens and reopens with timestamps, which of the proposed Programmes were engaged with and the relative attention given to each, and share events. No visitor identifier of any kind. A truncated salted hash of the network address is held for rate limiting and abuse prevention only, expires at 30 days and is not surfaced in the Platform. The browser user agent is not written to the Proposal record. | Controller |
| Artificial intelligence cost and usage records | Controller |
| Billing, credit control and our own records of the commercial relationship | Controller |
| Our own marketing to Users and prospective Users | Controller |
2.4 The Customer is responsible for its own compliance as controller, including for having a lawful basis, for transparency to Students and families, for the accuracy of what it enters, and for responding to data subjects.
2.5 If the characterisation is wrong. The role a party occupies is a question of fact and is not settled by what a contract calls it. If a supervisory authority or a court determines that we are a controller for processing we have declared as processor, we will comply with the obligations of a controller in respect of it, we will tell affected Customers without undue delay, and we will update this clause. Nothing in this addendum is intended to displace that outcome.
2.6 An Agent and a Provider sharing the same Prospect Record each determine their own purposes for it and are each a separate controller of it. Neither is a joint controller with us: for the processing listed as processor in clause 2.3 we act on the Customer's instructions, and for the processing listed as controller we determine our own purposes. Where two Users jointly determine the purposes and means of any processing between themselves, the arrangement required by Article 26 is theirs to make and we are not a party to it. Clause 10.5 of the Terms applies.
3. Scope and duration
3.1 The subject matter, duration, nature and purpose of the processing, the categories of data subject and the types of personal data are set out in Annex 1.
3.2 The processing lasts for as long as the Customer holds an Account and for the retention periods in Annex 1 afterwards.
4. Our instructions
4.1 We will process Customer Personal Data only on the Customer's documented instructions, including in relation to a Restricted Transfer, unless we are required to process by law. The documented instructions are:
(a) this addendum and Annex 1;
(b) the Terms of Service, including the commitment at clause 8.11 of the Terms;
(c) the configuration choices the Customer makes in the Platform, including who a record is shared with and which features it uses; and
(d) any further written instruction given under clause 4.2.
4.2 How to give us a specific instruction. A Customer may give a specific written instruction by writing to privacy@rokket-digital.co.uk. We will acknowledge it within 5 working days and tell the Customer within 20 working days whether we can follow it, when we can follow it, and what it will cost if anything. We will follow an instruction which Applicable Data Protection Law requires us to follow, at no charge. Where an instruction is outside the scope of the service as configured, or requires development work, we may charge on a time and materials basis and we will say so before doing the work. We will not treat a Customer's use of a standard Platform feature as displacing this route.
This clause exists because a data processing addendum with no route for a controller to instruct its processor is not a real instruction relationship. The Information Commissioner criticised exactly that pattern in its June 2026 report on education technology providers.
4.3 Unlawful instructions. We will tell the Customer without undue delay if, in our opinion, an instruction breaches Applicable Data Protection Law. We may suspend the instruction while the point is discussed, and we are not obliged to follow an instruction we reasonably believe to be unlawful.
4.4 Processing required by law. Where the law requires us to process Customer Personal Data other than on the Customer's instructions, we will tell the Customer before processing unless the law prohibits it on important grounds of public interest.
5. Confidentiality of our people
5.1 We will ensure that everyone we authorise to process Customer Personal Data is under a written obligation of confidentiality or an appropriate statutory obligation, and that the obligation continues after they stop working for us.
5.2 Access is limited to those who need it for a defined purpose, and is granted on a least privilege basis.
5.3 Our people receive data protection training appropriate to their role before they are given access.
6. Security
6.1 We will implement and maintain appropriate technical and organisational measures to protect Customer Personal Data against accidental or unlawful destruction, loss, alteration, unauthorised disclosure or access, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of processing and the risks to individuals.
6.2 The measures in place are described in Annex 3. Annex 3 also records, separately and expressly, every measure we have committed to and what has happened to it, including any which are not yet implemented and the date by which they will be.
6.3 We may change the measures, provided the change does not materially reduce the protection given to Customer Personal Data.
6.4 The Customer is responsible for its own use of the Platform's security features, including who it grants access to, who it shares a record with, and who it sends a Proposal link to.
7. Subprocessors
7.1 The Customer gives general written authorisation for us to engage Subprocessors. The Subprocessors engaged at the date of this addendum are listed at Annex 2.
7.2 We will impose on each Subprocessor, by written contract, data protection obligations which are no less protective than those in this addendum, and we remain fully liable to the Customer for a Subprocessor's performance.
7.3 Changes. Before a new Subprocessor starts processing Customer Personal Data we will update Annex 2, publish the updated register at studymarket.ai/subprocessors, and give at least 30 days notice by email to the notification address on the Customer's Account. A Customer may subscribe to notifications of changes.
7.4 Objection. A Customer may object to a new Subprocessor on reasonable data protection grounds within 30 days of the notice. We will work with the Customer in good faith to offer an alternative or a change of configuration. If we cannot within a further 30 days, the Customer may terminate the affected part of the service without penalty, and we will refund any fees prepaid for the unused period.
7.5 Urgent replacement. Where a Subprocessor must be replaced urgently for reasons of security, legality or service continuity, we may do so and will give notice as soon as we reasonably can, after which clause 7.4 applies.
7.6 Annex 2 records, for each Subprocessor, its role, its region and whether a data processing agreement with it is in force. As at 7 September 2026 every Subprocessor which is a processor has an agreement in force. The one remaining entry, Google Maps Platform, is an independent controller rather than a processor, and no Article 28 agreement exists or is needed for it.
8. Data subject rights
8.1 We will not respond to a request from a data subject about Customer Personal Data ourselves, other than to tell the person to contact the Customer, unless the Customer instructs us to or the law requires it.
8.2 We will pass a request we receive to the Customer without undue delay and in any event within 3 working days, together with any information we hold which identifies which Customer it concerns.
8.3 Taking into account the nature of the processing, we will assist the Customer by appropriate technical and organisational measures, so far as is possible, to respond to requests to exercise rights under Chapter III of the UK GDPR. The tools available are described in Annex 1. Where the tools do not cover a request we will give reasonable assistance, and may charge our reasonable costs where the request is unusual in scale or complexity.
8.4 Where an Agent and a Provider are both controllers of the same record, we will tell the Customer who contacted us that another controller also holds the record, and we will not decide between them which should respond.
8.5 Erasure and holds. If a Customer instructs us to erase data and has told us that a legal hold, a live safeguarding investigation, a statutory inquiry instruction or a law enforcement instruction applies to it, we will not erase it, and we will record the refusal and its reason. It is the Customer, and not us, that decides whether an exemption or a hold applies.
9. Personal data breaches, and assistance with Articles 32 to 36
9.1 We will notify the Customer without undue delay and in any event within 48 hours after becoming aware of a personal data breach affecting Customer Personal Data.
9.2 The notification will describe, so far as we know it at the time: the nature of the breach and the categories and approximate number of data subjects and records concerned; the likely consequences; the measures we have taken or propose to take; and a contact point for more information. We will update the Customer as we learn more.
9.3 Where a breach affects a record shared between an Agent and a Provider, we will notify both, because each is a controller of it and each has its own obligation to assess and report.
9.4 We will not notify a supervisory authority or a data subject on the Customer's behalf, and we will not make a public statement which identifies a Customer without consulting that Customer first, unless the law requires us to.
9.5 We will provide reasonable assistance to the Customer with data protection impact assessments and prior consultation under Articles 35 and 36, taking into account the nature of the processing and the information available to us. Annex 1 and Annex 3 are intended to answer most of what an assessment needs.
9.6 We will assist the Customer in ensuring compliance with the obligations in Articles 32 to 36 more generally.
10. Return and deletion
10.1 On termination, the Customer may export Customer Personal Data under clause 16.5(b) of the Terms.
10.2 After the export period we will delete or anonymise Customer Personal Data in accordance with the retention periods in Annex 1, and in any event within 90 days of termination, unless the law requires us to keep it or a hold under clause 8.5 applies.
10.3 Copies held in routine backups are deleted in the ordinary backup cycle, and remain subject to this addendum until they are.
10.4 We will confirm deletion in writing on request.
10.5 Where we anonymise rather than delete, we will do so to a standard at which the data can no longer be attributed to an identified or identifiable person by us or by anyone else using means reasonably likely to be used. Truncation or hashing of an identifier is not by itself anonymisation.
11. Information and audit
11.1 We will make available to the Customer the information necessary to demonstrate compliance with Article 28, including Annex 2, Annex 3 and the parts of our record of processing which relate to that Customer.
11.2 The Customer may audit, or appoint an independent auditor to audit, our processing of its Customer Personal Data, once in any period of twelve months, on 30 days written notice, during business hours. An auditor must not be a competitor of ours and must sign a confidentiality undertaking. An audit must not disrupt our business unreasonably, must not access another customer's data, and is limited to the systems and records used to process that Customer's data.
11.3 A Customer may audit more often where a supervisory authority requires it, or following a personal data breach affecting that Customer.
11.4 Each party bears its own costs. We may charge our reasonable costs for an audit beyond the one permitted in each twelve month period, unless the audit finds a material breach by us.
11.5 We may satisfy an audit request by providing a current independent report, certification or completed security questionnaire where it answers the Customer's question.
12. International transfers
12.1 We process Customer Personal Data in the United Kingdom, the European Economic Area and the United States. Annex 2 states the region of each Subprocessor. Customer Personal Data is also accessible to the Customer’s own Users from wherever they are located, which the Customer directs and controls. Where those Users are in a country outside the United Kingdom which is not the subject of United Kingdom adequacy regulations, clause 12.3A explains why that access is not a Restricted Transfer made by us.
12.2 The Customer authorises the Restricted Transfers needed to provide the Platform, including transfers to the Subprocessors in Annex 2 which are located in the United States.
12.3 Each Restricted Transfer we make to a Subprocessor is made under the transfer mechanism in force between us and that Subprocessor, which is in each case the European Commission standard contractual clauses as supplemented by the Addendum issued by the Information Commissioner, the International Data Transfer Agreement, or the Subprocessor’s certification under the United Kingdom Extension to the EU-US Data Privacy Framework. We maintain a register recording which of those each Subprocessor relies on, and any case where the position is not yet settled, and we will provide it to the Customer on request. Annex 2 records the status of each Subprocessor’s processing agreement. Where we make that transfer as the Customer’s processor to a Subprocessor which is itself a processor, Module Three applies.
12.3A Where the Customer is established in, or accesses the Platform from, a country outside the United Kingdom which is not the subject of United Kingdom adequacy regulations, we make Customer Personal Data available to the Customer as a controller. That is not a Restricted Transfer made by us. We are not transferring Customer Personal Data to a separate recipient: we are making it available to the same controller which instructed us to process it, and we act only as that controller's processor in doing so. No Chapter V transfer mechanism is required for it and none is provided here. This clause does not apply to a transfer we initiate to a separate recipient, including a Subprocessor, which is governed by clause 12.3.
12.4 We will carry out and maintain a transfer risk assessment for each Restricted Transfer, and will make it available to the Customer on request. Where an assessment has not yet been completed, Annex 3 records that, in the same way as it records security measures which are committed rather than built.
12.5 If a Transfer Mechanism is invalidated or ceases to be available, we will implement an alternative lawful mechanism without undue delay or, if we cannot, stop the transfer and tell the Customer what that means for the service.
13. Artificial intelligence: what each feature sends
13.1 Some Platform features send Customer Personal Data to a model provider which is a Subprocessor. We declare below what each entry point sends. We publish this rather than leave it to be discovered. There are ten model entry points across two model clients. The table below is generated from the registry in our own code rather than maintained by hand, and a build gate fails if the two disagree, because a published table maintained by hand drifts and the first person to notice is a school's adviser reading the difference.
13.2 Every feature is assigned to one of three classes:
| Class | What it means |
|---|---|
| Class A | No Student Personal Data leaves our systems. The feature operates on catalogue or Provider content only. |
| Class B | Student Personal Data is sent with direct identifiers removed before it leaves our systems. Names, contact names, email addresses and telephone numbers are replaced with generic tokens, and email headers, quoted replies and signature blocks are stripped. Removing identifiers does not remove the content of what a note says. |
| Class C | Identified Student Personal Data is sent. This is permitted only where the Customer's own purpose requires it and the output returns only to that Customer. It is never used for any purpose of ours. |
13.3 The classification, entry point by entry point. This is a single table and not two lists. Each entry point appears once, with the client it uses, whether the call is de-identified or carries identified Student data, which side of the controller and processor line it falls, and the lawful basis and Article 9 condition applying to it. The same table is the source for our Article 30 record and for our Appropriate Policy Document, so that there are not three descriptions of the same processing to reconcile.
| Entry point, and which model client | Class | Our role, the basis, and the Article 9 condition |
|---|---|---|
| Programme matching (ai_matching) — model client 1 | A | Processor. The entry point receives the search text the Agent typed and the Programme catalogue. No Student record is sent. No Article 9 condition is engaged. |
| Programme comparison (programme_compare) — model client 1 | A | Processor. Programme records the Provider published. No Student record. No Article 9 condition is engaged. |
| Toolkit asset classification (toolkit_classify) — model client 1 | A | Processor. A Provider's own uploaded marketing assets. No Student record. No Article 9 condition is engaged. |
| Programme document extraction (programme_extraction) — model client 1 | A | Processor. A Provider's own brochure, page or document, read so its Programme details can be extracted. No Student record. No Article 9 condition is engaged. |
| Prospect summary (prospect_summary) — model client 1 | B — de-identified | Processor. The Agent's own notes about a Student, with names, contact names, email addresses and telephone numbers replaced before the request leaves our systems, and structured medical, dietary and insurance fields not sent at all. Article 6(1)(b) or 6(1)(f) in the Customer's hands; Article 9(2)(a) where the free text carries health content, obtained by the Agent under clause 6.1 of the Terms. ⚠️ De-identification removes identifiers, not content: a note reading "severe asthma, carries an inhaler" survives it with the name replaced and the health fact intact, and pseudonymised special category data remains special category data. |
| Note extraction (notes_extraction) — model client 1 | C — identified | Processor. Text or an image the Agent pasted, read so structured fields can be extracted from it. Whatever the Agent supplied travels, because extracting from it is the purpose. Permitted because the Customer's own purpose requires it and the output returns only to that Customer. Article 9(2)(a) where health content is present, obtained by the Agent. |
| Proposal quick check (proposal_quick_check) — model client 1 | C — identified | Processor. The Student's name and age and the notes written for the Proposal, so the draft can be checked against the Student it is for. Output returns only to that Customer. Article 9(2)(a) where health content is present, obtained by the Agent. |
| Proposal generation (proposal_generation) — model client 1 | C — identified | Processor. The Student's name and the notes written for the Proposal. A Proposal is written for a named Student and addressed to their family, which is what the Customer is asking the feature to produce. Article 9(2)(a) where health content is present, obtained by the Agent. |
| Proposal generation, shortened retry (proposal_generation_retry_shorten) — model client 1 | C — identified | Processor. The same content as proposal generation, retried shorter. Recorded as its own entry point because it is its own call site and a table which hides it is a table which is wrong. |
| Voice note transcription — model client 2 | C — identified | Processor. Audio is streamed from the Customer's browser directly to the transcription Subprocessor's European endpoint and never reaches our servers. Transcription happens in the EEA, so no Chapter V mechanism is engaged for it. Only the transcript is stored, with the Proposal. Article 9(2)(a) where health content is spoken, obtained by the Agent. |
13.4 Special category data.
(a) The structured medical, dietary and insurance fields are not sent to a model at all.
(b) Free text notes, messages and transcripts may contain information about a Student's health. Removing a name does not remove that information. Pseudonymised special category data remains special category data.
(c) By using a feature which processes free text, the Customer instructs us to transfer that content to the model Subprocessor for the sole purpose of producing the output for that Customer, and confirms that it has a condition under Article 9 of the UK GDPR which covers the processing.
(d) We will not use that content for any other purpose. Clause 14 applies.
13.5 No solely automated decisions producing legal or similarly significant effects are made by the Platform. A Programme ranking is a suggestion to the Customer, who decides.
13.6 The Customer is responsible for checking AI Output before relying on it or sending it to anyone, under clause 8.15 of the Terms.
13.7 We will give at least 30 days notice before adding a feature in Class C, or moving an existing feature into a higher class, and will update this clause when we do.
13.8 One boundary, enforced in code. Every request to a model passes through a single module which takes the declared data class as a required argument with no default, and an automated gate fails the build on any use of a model client from outside it. That work has a target date of 30 September 2026 and until it is complete the classification is enforced at each call site rather than at one boundary. We state the date because a published commitment with a date is worth more than one without, and because slipping it has a consequence we have written down elsewhere: our conclusion that prior consultation under Article 36 is not required rests on risk being in the course of mitigation, and a target date passing without closure would make that reasoning expire.
13.9 Proposal Page engagement data is not sent to any model, is not used to rank or re-rank Programme recommendations, and is not used to train, tune, evaluate or benchmark any model. Clause 8.11(f) of the Terms and clause 14 of this addendum apply to it.
14. What we will not do with Student data
14.1 This clause is a documented processing instruction and a binding commitment. It repeats clause 8.11 of the Terms so that it is enforceable in both places.
14.2 We will not use Customer Personal Data to develop, train, fine tune, evaluate or benchmark any model, whether ours or a third party's.
14.3 We will not use Customer Personal Data for product development, for research, or to produce insight across customers.
14.4 We require each model Subprocessor, by contract, not to use content submitted through our account to train or improve its models, and not to retain it beyond what is needed to return the output. Annex 2 records the position for each.
14.5 Any insight we produce across customers will be built from agent side data, meaning data about an Agent's or a Provider's own business activity — searches run, catalogue browsing, placement volumes, response times and similar operational behaviour — which contains no Customer Personal Data and no data derived from a Student record. Both limbs are necessary: an aggregate computed from Prospect Records describes agent behaviour in the aggregate and would otherwise slip through the first limb alone.
14.6 Our evaluation fixtures for artificial intelligence features are built from synthetic queries against our Programme catalogue and contain no Customer Personal Data.
14.7 We will not sell Customer Personal Data, and we will not disclose it to any person other than a Subprocessor listed in Annex 2, a User the Customer has chosen to share it with, or where the law requires.
14.8 Proposal Page engagement data goes to the Agent who sent the Proposal and nowhere else. It is not used to rank or re-rank Programme recommendations, to train, tune, evaluate or benchmark any model, or to build any insight product.
15. Safeguarding records
15.1 We are not the custodian of any Safeguarding Record and we do not accept custody of one. This clause states how that line is held in practice.
15.2 The Customer must not place a Safeguarding Record on the Platform, in any field. Clause 12.3 of the Terms sets out the prohibition and defines the term. The Platform is not a safeguarding record system and the Customer must not use it as one or rely on it as one.
15.3 If a Safeguarding Record reaches the Platform, whether deliberately or not, then on becoming aware of it:
(a) we will tell the Customer without undue delay;
(b) we will restrict access to it to the smallest number of our personnel needed to deal with it, and log that access;
(c) we will exclude it from every analytical process, every model request, every report and every export other than an export to the Customer;
(d) we will exclude it from search and from indexing, restrict it to a single named role, log the event, and the Customer must retrieve it into its own systems and instruct us to delete our copy;
(e) we will delete our copy on that instruction, and in any event 30 days after we discovered it if no instruction has been given, having given a reminder, unless the Customer has told us that a hold under clause 8.5 applies. This period was 60 days and is shortened to 30. The backstop is the point of the clause: without one, the quarantine store becomes exactly the archive of safeguarding records this architecture exists to prevent; and
(f) receiving, holding briefly or deleting a Safeguarding Record does not make us its custodian or its controller, and does not give us any of the obligations which attach to it in the Customer's hands.
15.4 We do not carry out any function of a designated safeguarding lead. We will not assess a concern, make a referral, or decide what a record means. If our personnel encounter something on the Platform which appears to indicate a risk to a child, we will tell the Customer and, where the law requires or permits, the relevant authority. That is a duty owed as any person owes it, and not a service we provide.
15.5 The retention periods which attach to a safeguarding record in the Customer's hands, including periods running to a child's twenty fifth or seventy fifth birthday, are the Customer's obligations. We do not assume them, we do not build to them, and nothing in this addendum should be read as us holding a record for that long.
15.6 Nothing in this clause requires or permits a Customer to destroy, withhold or fail to create a record it is obliged to keep.
15.7 The incident pointer. The incident field on a Prospect Record holds a short reference that a concern was raised and recorded with the Customer's own agency, together with a date and an agency reference, drawn from a fixed enumeration which does not accept typed prose. It is a business record that a referral was made and it is not a record of the concern. It follows the ordinary retention applying to a Prospect Record — the end of the Season in which termination takes effect plus six months, and otherwise the Prospect Record's own period — and does not attract the retention periods at clause 15.5. ⚠️ Our retention rules currently hold the incident pointer until the Student's twenty-fifth birthday. That is inconsistent with this clause and with the position we take, and it is being corrected.
15.8 We do not screen. We will not reliably detect a Safeguarding Record uploaded in breach of clause 15.2, and we do not represent that we will. Clause 12.3(h) of the Terms and clause 11.7 of the Terms say the same, and no assurance material we produce says otherwise.
16. Records
16.1 We maintain a record of the categories of processing we carry out on behalf of controllers under Article 30(2) of the UK GDPR.
16.2 We will make the parts of that record which relate to a Customer available to that Customer on request, and to a supervisory authority on request.
17. Liability and precedence
17.1 Liability under this addendum is subject to clause 18 of the Terms, except to the extent that Applicable Data Protection Law does not permit it to be limited.
17.2 This addendum prevails over the Terms to the extent of any conflict, under clause 1.6 of the Terms.
17.3 If a term of this addendum conflicts with a mandatory requirement of Applicable Data Protection Law, or with a Transfer Mechanism, that requirement or mechanism prevails.
18. Term, variation and governing law
18.1 This addendum applies for as long as we process Customer Personal Data for the Customer.
18.2 Variations are made under clause 21 of the Terms, and clause 21.5 of the Terms limits what we may change without the Customer's agreement.
18.3 This addendum is governed by the law of England and Wales, and clause 22 of the Terms applies to any dispute about it.
18.4 Contact for all matters under this addendum: privacy@rokket-digital.co.uk.
Annex 1. Particulars of processing
Required by Article 28(3) of the UK GDPR.
Subject matter and duration
| Subject matter | Provision of the StudyMarket platform to the Customer: recording students the Customer is seeking to place or to enrol, sharing those records with a connected User the Customer chooses, producing proposals and supporting materials, and the artificial intelligence features described at clause 13. |
| Duration | For as long as the Customer holds an Account, and thereafter for the retention periods below. |
| Nature of the processing | Collection, recording, organisation, structuring, storage, retrieval, consultation, use, transmission to a connected User chosen by the Customer, translation, transcription, summarisation, ranking, extraction, backup, restriction, erasure and anonymisation. |
| Purpose | To serve the Customer's own purpose of arranging or receiving a student placement. No other purpose. Clause 14 states what we will not do. |
| Frequency | Continuous, for as long as the Customer uses the Platform. |
Categories of data subject
Students described in a Prospect Record or a Proposal, some of whom are under 18.
Parents, guardians and other family members named in a record, or who open a Proposal Page.
The Customer's own personnel who use the Platform.
Personnel of a connected User with whom a record is shared.
Types of personal data, and how long we keep them
Retention below follows the StudyMarket retention schedule. Every period is a default which a hold under clause 8.5 suspends.
| Category | Fields and content | Retention |
|---|---|---|
| Student identity | First name, surname, family name, pronouns, age and, in the current schema, date of birth. School, nationality and destination preferences. | Anonymised 24 months after last activity on the record. |
| Health, dietary and insurance | Medical status and free text medical notes, dietary status and free text dietary notes, insurance status. Special category data under Article 9. | Purged 90 days after programme end, except where medication was administered, where there was an incident, accident or near miss, or where the information became part of a safeguarding matter, in which case the Customer must hold it in its own systems and clause 15 applies. |
| Requirement and qualification notes | What the Customer is looking for, budget and qualification fields, and generated summary text. | Anonymised 24 months after last activity. |
| Messages and notes | Free text between an Agent and a Provider, and internal notes. Unstructured and capable of containing anything a User types. | Anonymised 24 months after the last message. Soft deleted rows purged after 30 days. |
| Documents and attachments | Files uploaded against a Prospect Record, term sets and signed agreements. Held in private storage behind a gated download route. | Follow the parent record. Soft deleted files purged after 30 days. |
| Voice notes | Audio recorded by the Customer for transcription. Audio is streamed directly to the transcription Subprocessor's EU endpoint and is never received by us. Only the transcript is stored. | Transcript follows the Proposal. |
| Proposals and artificial intelligence records | Proposal content, generated text and match reasons. Records of a request to a model: token counts, cost, latency, and the identifiers of the user, organisation and record it related to. No model request content and no model response content is stored. | Proposals follow the Prospect Record at 24 months. The identifiers on artificial intelligence usage records are stripped at 13 months; token counts, cost and latency are retained in aggregate. |
| Events and audit | Record events, attachment events and the audit log, including actor identity. | 24 months, then actor identity and free text stripped. |
| Customer personnel data held within a record | Names, business email addresses and roles of the Customer's own people, where they appear inside a record we process for the Customer. | Follows the record. |
| Incident pointer | A fixed enumeration recording that a concern was raised and recorded with the Customer's own agency, with a date and an agency reference. No free text. Not a Safeguarding Record and not a record of the concern. | Follows the ordinary Prospect Record retention: anonymised 24 months after last activity, and on termination to the end of that Season plus six months. Clause 15.7 applies. ⚠️ The shipped rule presently runs to the Student's 25th birthday and is being corrected to match this row. |
| Medical and dietary information where consent is withdrawn | The structured medical and dietary fields and any Article 9 consent attestation attaching to them. | Removed on the Agent's instruction that the family has withdrawn consent, ahead of and independently of every period above. Clause 10.6(d) of the Terms applies. Any residual safety need is the Provider's to meet under its own condition. |
| Proposal Page engagement | Opens and reopens with timestamps, which Programmes were engaged with and the relative attention given to each, and share events, recorded against the Proposal. No visitor identifier. A truncated salted hash of the network address, held for rate limiting only. | Engagement follows the Proposal at 24 months, and on termination to the end of that Season plus six months. The rate-limiting hash expires at 30 days and is not surfaced in the Platform. |
Assistance available for data subject rights
| Right | What we can do today |
|---|---|
| Access | We can export the records relating to a named Student from the Customer's account. There is no self service export tool. Requests are handled by us on written request. |
| Rectification | The Customer can correct records directly in the Platform. |
| Erasure | On the Customer's written instruction. Automated erasure tooling is committed and not yet built. Clause 8.5 governs refusals. |
| Restriction | On the Customer's written instruction. |
| Portability | Export in a structured, commonly used, machine readable format on written request. |
| Objection | Referred to the Customer as controller. |
Annex 2. Subprocessors
Fourteen Subprocessors. Maintained in English only, and published at studymarket.ai/subprocessors. Changes are notified under clause 7.3.
The last column records whether a data processing agreement with the Subprocessor has been confirmed by us. It is stated accurately rather than assumed. That verification is complete. Thirteen of the fourteen entries are processors and every one of them has an agreement in force. The fourteenth is an independent controller, for which no such agreement arises.
| Subprocessor | Role and data | Region | Processing agreement |
|---|---|---|---|
| Clerk | Authentication. Account identity, email address and session data for every User. | United States | In force. Auto-incorporated by the Terms. |
| DigitalOcean | Primary database hosting. The whole personal data estate. | United States | In force. Auto-incorporated by the Terms. |
| Vercel | Application hosting and file storage, including prospect documents and signed agreement PDFs, held in private storage behind a gated download route. | United States | In force. Plan scope to be confirmed. |
| Anthropic | Artificial intelligence features. Content sent to the model under clause 13. | United States | In force. Incorporated by the Commercial Terms. See clause 14. |
| Deepgram | Voice transcription. Audio is streamed from the User's browser directly to Deepgram and is never received by us. | European Union (audio is streamed to the EU endpoint); vendor incorporated in the United States | In force. Executed 7 September 2026. Standard Contractual Clauses Module Two and the UK International Data Transfer Addendum are both incorporated by name. Audio is processed in the EEA, so no Chapter V transfer mechanism is engaged for it. |
| Resend | Transactional email. Recipient email addresses and message content. | United States | In force. Executed and filed 20 August 2026. |
| Sentry | Error monitoring. Error payloads, with personal data scrubbing applied in all three runtimes. | United States | In force. Accepted 20 August 2026. |
| Google Analytics 4 | Site analytics. Behavioural and IP derived data, gated on consent. | United States | In force. Google Ads Data Processing Terms, auto-incorporated. |
| Google Maps | Address autocomplete. Location queries from the browser. | United States | Not a processor. Google is an independent controller for this service. |
| Airtable | Operational and go to market storage. Agent contact records. Free text from a family comment is not mirrored to it. | United States | In force. Executed 20 August 2026. |
| Woodpecker | Outreach email sending. Business contact name and email address. Not used for Customer Personal Data. | European Union | In force. |
| MillionVerifier | Email address verification. Not used for Customer Personal Data. | Hungary (registered); processing location not disclosed | In force. Standard clauses referenced but not incorporated. |
| Brevo | Email and customer relationship platform. Marketing contact records. Not used for Customer Personal Data. | European Union | In force. |
| DeepL | Translation of dynamic content and proposal fields into nineteen languages. May include personal data embedded in user content. | European Union (Germany) | In force. Executed 4 September 2026. |
Transfers to Subprocessors located outside the United Kingdom are made under the Transfer Mechanism identified at clause 12.3.
Two parties are deliberately not on this list. studytravel.network, which is accessed through a subscription held by us and is not a contracted processor. An internal database controlled by Rokket Digital Ltd directly, which is not a third party. Neither touches Customer Personal Data.
Annex 3. Technical and organisational measures
Required by Article 28(3)(c) and Article 32 of the UK GDPR. This annex is written to be given to a Customer, a host school, an accrediting body or an insurer.
It is in two parts. Part A describes measures in place. Part B describes measures we have committed to and have not yet implemented. We have written it this way deliberately. An annex which overstates its controls is the one that fails a due diligence review, not the one which is candid about a gap and names a date.
Part A. Measures in place
| Area | Measure |
|---|---|
| Governance | A named owner for data protection. A maintained register of Subprocessors. A maintained record of processing. A retention schedule. An appropriate policy document covering special category processing. Periodic review of each. |
| Access control | Authentication through a managed identity provider. Access to production systems limited to named individuals on a least privilege basis. Additional authentication factors available and required for administrative access. Access removed when a person leaves or changes role. |
| Encryption | Transport encryption for all traffic to and from the Platform. Encryption at rest for the database and for file storage, provided by the hosting Subprocessors. |
| Application security | Uploaded documents and signed agreements held in private storage, reachable only through an access controlled download route. Proposal Pages protected by a link of 72 bits of entropy and an expiry period of 30 days. Rate limiting on public endpoints. Input sanitisation on unauthenticated submissions, and the reserve-confirm endpoint accepts only defined structured fields and no free text. The truncated salted hash is held for rate limiting and abuse prevention on an unauthenticated public endpoint, expires at 30 days, and is not surfaced in the Platform. No cookie, no local storage identifier and no device fingerprint is set on a Proposal Page, and an automated check prevents one being introduced. |
| Data minimisation in model requests | A dedicated module removes names, contact names, email addresses and telephone numbers, and strips email headers, quoted replies and signature blocks, before a Class B request leaves our systems. Structured medical, dietary and insurance fields are never included in a model request. Voice audio never reaches our servers, which is enforced by an automated architecture test that fails the build if audio handling appears in server code. |
| Logging and monitoring | Application error monitoring with personal data scrubbing applied in the client, server and edge runtimes. An audit log recording actor identity for record level events. |
| Special category field protection | Access to the medical, dietary and insurance fields is restricted separately from access to the rest of the prospect record, and every read of them is recorded against the identity of the reader. These fields are never included in a request to a model. Health content cannot be stored at all unless an explicit consent record or an emergency purpose record already exists for that individual, and that is enforced by the data layer rather than by procedure, so the restriction cannot be bypassed by a new feature. |
| Retention and erasure | Retention periods are applied by an automated sweep which runs nightly against 27 rules, each carrying a confirmed period, and which reports what has fallen due. A record may be placed under a hold, which every purge path is required to respect and which an automated build gate enforces. An incident may be recorded against a record, and recording one places a hold. Subject access export and erasure exist as tooling, with a refusal path for records under hold. |
| Backup and continuity | Managed database backups with point in time recovery provided by the database host. Deleted records purged from soft deleted state after 30 days. |
| Vendor management | A Subprocessor register recording what each vendor touches, its region and its processing agreement status. New vendors added to the register at integration rather than retrospectively. |
| People | Confidentiality obligations in every contract of employment and engagement. Role appropriate data protection training before access is granted. |
| Change control | Code review before merge. Automated tests, including tests which assert that personal data does not travel where it should not, for example that a family comment is not carried in an email notification. |
Part B. Measures committed, and their delivery
This part records every technical and organisational measure we committed to, and what has happened to each. It is published rather than given on request. Of the eight measures first recorded here on 4 August 2026, five have been delivered and are dated below, one has been removed because the premise it rested on was disproved, and two remain outstanding with a target date against each. This part is reviewed at every version of this addendum. One measure was removed on 21 August 2026: identifier removal extended to the Programme matcher. It rested on the matcher being class B. Checked against the code on 20 August 2026, every live entry point into the matcher takes a plain string the user types, no surface passes a student record to it, and nothing prefills the search box from a prospect record. The matcher is class A and receives no student data, so there is nothing to extend. Clause 13.3 records the same.
| Measure | Why it matters | Status, owner and date |
|---|---|---|
| Field level protection and access restriction on the medical, dietary and insurance fields | These are special category fields and access to them should be distinct from access to the rest of the record. | DELIVERED 6 August 2026. Access restriction distinct from the rest of the prospect record, with an access trail recording who read them. Column level encryption was considered and declined, and the reasoning is recorded. |
| Automated retention and erasure tooling, with a refusal path | Retention periods in Annex 1 were applied by hand, and an erasure tool built without a refusal path would destroy records subject to a hold. | DELIVERED. Erasure and subject access tooling live and rehearsed end to end on 6 August 2026, with a hold gated refusal path. The automated retention sweep runs nightly on production and was proven end to end by its scheduled run on 26 August 2026. It reported without deleting until 29 August 2026, when deletion was enabled on the trigger recorded in the previous version of this row: the first rule reporting records falling due. Updated 29 August 2026. |
| A hold flag at record level | Three retention rules in Annex 1 depend on it, and nothing recorded that a record must not be purged. | DELIVERED 6 August 2026. Holds exist as records, a hold evaluator governs every purge path, and an automated build gate fails any purge path that bypasses it. |
| An incident marker | Three retention rules are triggered by an incident having occurred, and nothing recorded that one did. | DELIVERED 6 August 2026. An incident can be recorded in the product. Recording it places the retention hold, releasing it requires a stated reason, and both events appear on the activity feed. |
| A single boundary for model requests with a declared data class | There are ten model entry points across two clients, and the identifier removal module is applied at one of them. A single boundary makes the data class an enforced property rather than a per feature decision. | COMMITTED. Target 30 September 2026. The design is written: one module through which every model request passes, taking a declared data class as a required argument with no default, an automated gate failing any use of the model provider's interface from outside it, and the classification table at clause 13.3 generated from the code rather than maintained by hand. |
| Family facing privacy notice on the Proposal Page, and the salted visitor hash | A family opening a Proposal Page should be told what is recorded, and a visitor identifier should be genuine pseudonymisation rather than a reversible hash. | DELIVERED 4 August 2026, deployed to production. Part A describes both as in place, and that description is now accurate rather than anticipatory. |
| Confirmed processing agreements with each Subprocessor | Annex 2 records the current position for each. | IN PROGRESS. Target 31 October 2026. Eleven of the fifteen are in force and one is not a processor. Of the remaining three, one is awaiting acceptance by us, and two publish no agreement and were asked for one in writing on 24 August 2026. Those two are not wholly within our control and Annex 2 states the position for each rather than implying otherwise. |
| Removal of the free-text field on the reserve-confirm endpoint, and of the browser user agent from the Proposal record | A 1,000 character free-text field on an unauthenticated page reachable by a child invites exactly the medical, personal and safeguarding content the rest of this document is built to keep out; and a user agent written into a named child's record is device data about a person we have chosen not to identify. | COMMITTED. Target: before the service becomes available to UK users for the free-text field, and within 30 days for the user agent. The user agent is written at five endpoints and all five are in scope. Ordinary web server access logs are unchanged: short retention, security and diagnostics only, not joined to the Proposal record and not surfaced. |
| Controlled vocabulary on the incident field, quarantine state and the 30-day deletion backstop | A prohibition in a contract does not prevent drift; a field which cannot accept prose does. Without the backstop, the quarantine store becomes the archive of safeguarding records the architecture exists to prevent. | COMMITTED. Target 30 days. Clauses 12.3(g) of the Terms and 15.3 and 15.7 of this addendum describe what is being built. |
| Blocking, versioned and immutable Article 9 attestation on the medical and dietary fields | The Article 9 condition for this data is explicit consent obtained by the Agent, and an attestation which is optional, undated or editable is not evidence of anything. | COMMITTED. Target 30 days. Per record and contemporaneous, blocking on save, storing the version of the wording shown, and not editable afterwards. Engineering finding H2 is re-scoped to this from consent capture. |