← Back to Emeejay Assess

Data Processing Agreement

This Data Processing Agreement ("Agreement") is entered into between:

[School name], of [school address] ("the School", "the Controller"); and

Marc Jones, trading as Emeejay Assess (sole trader) (correspondence address: marc@emeejay.com) ("the Processor", "we"),

(each a "Party" and together the "Parties")

Background

1. The School uses the Processor's software-as-a-service product, Emeejay Assess, to record and analyse phonics and maths assessment data about its pupils.
2. In providing this service, the Processor processes personal data on behalf of the School.
3. This Agreement sets out the terms on which the Processor will process that personal data, in order to comply with Article 28 of the UK GDPR.

1. Definitions

"UK GDPR", "Data Protection Legislation", "Controller", "Processor", "Data Subject", "Personal Data", "Processing" and "Personal Data Breach" have the meanings given to them in the UK GDPR and the Data Protection Act 2018.

"Services" means the Emeejay Assess software-as-a-service product.

"Sub-processor" means any third party appointed by the Processor to process Personal Data on behalf of the School in connection with the Services.

2. Subject matter and duration

This Agreement applies for as long as the Processor processes Personal Data on behalf of the School under the Services, and terminates automatically when the School's use of the Services ends and all Personal Data has been returned or deleted in accordance with clause 8.

3. Nature, purpose, and details of processing

Full details of the nature and purpose of processing, the categories of Data Subjects, and the types of Personal Data processed under this Agreement are set out in Annex 1.

4. Processor obligations

The Processor shall:

• (a) only Process Personal Data on the School's documented instructions (including this Agreement), unless required to do otherwise by UK law, in which case the Processor shall inform the School before processing, unless prohibited from doing so by law;
• (b) ensure that all staff and contractors authorised to process Personal Data are subject to a duty of confidentiality;
• (c) implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, as set out in Annex 2;
• (d) not engage another processor (Sub-processor) without the School's prior general or specific written authorisation (see clause 5);
• (e) taking into account the nature of the processing, assist the School by appropriate technical and organisational measures, so far as reasonably possible, to respond to requests from Data Subjects exercising their rights under the Data Protection Legislation;
• (f) assist the School in ensuring compliance with its obligations under Articles 32 to 36 of the UK GDPR (security, breach notification, data protection impact assessments, and prior consultation), taking into account the nature of the processing and the information available to the Processor;
• (g) notify the School without undue delay, and in any event within 72 hours of becoming aware, of any Personal Data Breach affecting Personal Data processed under this Agreement;
• (h) at the School's choice, delete or return all Personal Data to the School at the end of the provision of the Services relating to processing, and delete existing copies unless UK law requires storage of the Personal Data;
• (i) make available to the School all information reasonably necessary to demonstrate compliance with this clause 4, and allow for and contribute to audits, including inspections, conducted by the School or an auditor mandated by the School, on reasonable notice.

5. Sub-processors

1. The School provides general written authorisation for the Processor to engage the Sub-processors listed in Annex 1, for the purposes described there.
2. The Processor shall inform the School of any intended changes concerning the addition or replacement of Sub-processors, giving the School the opportunity to object to such changes within 14 days.
3. The Processor shall impose data protection terms on any Sub-processor that are no less protective of Personal Data than those set out in this Agreement, and shall remain fully liable to the School for that Sub-processor's performance of its obligations.

6. International transfers

1. The Processor shall not transfer Personal Data outside the United Kingdom without an adequate safeguard in place (such as UK adequacy regulations, the International Data Transfer Addendum, or Standard Contractual Clauses).
2. Annex 1 identifies the current locations where Personal Data is processed and any transfers outside the UK, along with the safeguard relied on.

7. Liability and indemnity

Each Party shall indemnify the other against losses, damages, costs, and expenses arising from that Party's breach of this Agreement or of the Data Protection Legislation.

Subject to the paragraph below, the Processor's total liability to the School arising from or in connection with this Agreement, however caused, is capped at the total fees paid by the School to the Processor in the 12 months before the claim arose.

Nothing in this Agreement limits either Party's liability for death or personal injury caused by negligence, fraud, or anything else that cannot legally be excluded or limited, including liability for the Processor's failure to comply with its obligations under Article 28 UK GDPR.

This limitation matches the equivalent clause in the Terms of Service and reflects standard practice for a small processor of this kind. Larger multi-academy trusts with their own procurement terms and greater bargaining power are welcome to raise liability terms as part of onboarding a group-wide agreement.

8. Term and termination

1. This Agreement takes effect on the date the School begins using the Services and continues until the School's use of the Services ends.
2. On termination, clause 4(h) applies.

9. General

1. This Agreement is governed by the law of England and Wales, and the courts of England and Wales have non-exclusive jurisdiction over any dispute arising from it. This applies regardless of where in the UK the School is based, consistent with standard commercial practice for UK-wide processor agreements between businesses. A School based in Scotland or Northern Ireland that would prefer a different jurisdiction clause is welcome to raise this before signing.
2. In the event of any conflict between this Agreement and any other agreement between the Parties (such as terms of service), this Agreement takes precedence in relation to its subject matter.

Signatures

Annex 1 – Details of Processing

Subject matter: Provision of the Emeejay Assess phonics and maths assessment software-as-a-service.

Duration: For the term of the School's subscription to the Services, as set out in clause 2.

Nature and purpose of processing: Recording, storing, and analysing pupil phonics sound recognition, blending/reading check results, and times tables recall results, to help school staff track and report on pupils' phonics and maths progress.

Categories of Data Subjects

• Pupils at the School.
• School staff who hold an account (teachers, SENCOs, administrators).

Types of Personal Data

Pupil data: name, year group, gender, date of birth, additional needs flag (EAL/SEND), phonics sound assessment results, Blending Check results, Times Tables Check results, assessment dates.

Staff data: name, school email address, hashed password, role/display name.

Special category data: The additional needs (SEND) flag may constitute special category data (data concerning health) under Article 9 UK GDPR. Where this is recorded for safeguarding-related purposes, the applicable condition is typically the safeguarding of children and of individuals at risk condition at Schedule 1, Part 2, paragraph 18 of the Data Protection Act 2018, which requires the School, as Controller, to have an Appropriate Policy Document covering this processing. The School should confirm this reflects its own circumstances with its Data Protection Officer.

Sub-processors

Sub-processor	Purpose	Location of processing
Supabase	Database hosting and staff authentication	London, UK (AWS eu-west-2)
Stripe	Payment processing for school subscriptions	Global infrastructure (UK/EU/US) – Stripe's own Standard Contractual Clauses apply
Vercel Inc	Website hosting; billing-related serverless functions	United States (Virginia) for serverless functions; global CDN for static content

International transfers

Billing-related processing via Vercel's serverless functions and Stripe currently takes place in part outside the UK (United States). Both Vercel and Stripe incorporate the UK International Data Transfer Addendum to the EU Standard Contractual Clauses into their own data processing agreements – this is the safeguard recognised by the ICO for this type of transfer, and it's the mechanism the Processor relies on for these transfers.

Annex 2 – Technical and Organisational Security Measures

• Each school's data is isolated using database-level Row Level Security, so no school can access another school's data.
• All data in transit is encrypted using HTTPS/TLS.
• Passwords are hashed and salted; the Processor never has access to plain-text passwords.
• The Processor is currently a single-person operation (Marc Jones); access to the production database, hosting, and payment dashboards is restricted to the Processor personally, secured with unique logins and, where offered by the provider, multi-factor authentication. If the team grows, this Annex should be updated to describe access review cadence and staff confidentiality training.
• Card and full payment details are never stored by the Processor – these are handled entirely within Stripe's PCI-DSS compliant infrastructure.
• Regular backups are maintained by the database hosting provider (Supabase).
• In the event of a suspected Personal Data Breach, the Processor will assess and contain the incident as soon as reasonably possible, and notify the School in line with clause 4(g) of this Agreement, following the written process set out in Annex 3.

Annex 3 – Incident Response Process

This is the Processor's written process for handling a suspected or confirmed Personal Data Breach.

1. Detection. A suspected incident may come to light through an automated alert from Supabase or Vercel, a report from a school or member of staff, a security researcher's disclosure, or the Processor's own routine checks.
2. Immediate containment. As soon as the Processor becomes aware, they will act to stop ongoing harm – for example, revoking or rotating any compromised credentials or API keys, disabling affected accounts, or taking an affected feature offline until it can be fixed.
3. Assessment. The Processor will establish, as far as reasonably possible: what Personal Data was affected, which School(s) and data subjects, whether special category data (for example, the SEND flag) was involved, the likely cause, and the likely consequences for affected individuals.
4. Notification. The Processor will notify each affected School without undue delay and in any event within 72 hours of becoming aware, per clause 4(g), including: the nature of the incident and when it was discovered; the categories and approximate number of data subjects and records affected; the likely consequences; the measures taken or proposed to address it; and a contact point for further information (marc@emeejay.com). Schools remain responsible, as Controller, for deciding whether to notify the ICO or affected parents/guardians, and the Processor will support that decision with the information available.
5. Remediation. The Processor will fix the underlying cause and take reasonable steps to prevent the same type of incident recurring.
6. Record-keeping. Every suspected or confirmed incident – including ones assessed as low-risk and not requiring notification – is logged in a written incident record noting the date detected, a description, the data affected, actions taken, and any notification dates, kept as ongoing evidence of accountability under Article 5(2) UK GDPR.
7. Review. After any notifiable incident, the Processor will review what happened and whether the security measures in Annex 2 need updating as a result.

This process is proportionate to a single-person operation and will be reviewed and expanded as the team or the volume of schools using the Service grows.