Data Processing Agreement

The SENDNest for Schools
Version: 5.1
Last updated: 9 September 2026

1. Status and parties

1.1 This Data Processing Agreement, referred to as the DPA, forms part of the licence agreement and any applicable order form for The SENDNest for Schools.

1.2 It is made between:

• the school, academy trust, local authority, proprietor or other legal entity identified as the customer in the order form, referred to as the Customer; and
• The SENDNest for Schools Ltd, a company registered in England and Wales under company number 17428150, whose registered office is at 61 Bridge Street, Kington, United Kingdom, HR5 3DJ, referred to as the Provider.

1.3 The DPA takes effect when the Customer accepts or enters into the relevant order form or licence agreement and continues for as long as the Provider processes Customer Personal Data.

1.4 The Customer is the controller and the Provider is the processor for the Customer Personal Data described in Annex A. If the Customer processes that data on behalf of another controller, the Customer is a processor and the Provider is its sub-processor, and the Customer confirms that it is authorised to appoint the Provider.

2. Definitions

2.1 In this DPA:

• Applicable Data Protection Law means the UK General Data Protection Regulation, the Data Protection Act 2018, the Privacy and Electronic Communications Regulations 2003, the Data (Use and Access) Act 2025, and any legislation that amends or replaces them, to the extent applicable to the processing;
• Customer Personal Data means personal data processed by the Provider on behalf of the Customer in connection with the service;
• Data Subject, Personal Data, Personal Data Breach, Processing, Processor and Sub-processor have the meanings given in Applicable Data Protection Law;
• Order Form means the ordering document, online order or other written record under which the Customer subscribes to the service; and
• Service means The SENDNest for Schools platform and the functions included in the Customer's subscription.

2.2 References to written or documented instructions include instructions recorded in the licence agreement, Order Form, this DPA, the Customer's authorised use of service controls, and other instructions capable of being stored, including email.

3. Scope and roles

3.1 The Provider processes Customer Personal Data only to:

• create and administer staff accounts;
• deliver training modules and assessments;
• record module progress, assessment performance and completion;
• issue certificates and organisation-level evidence and training-needs reports;
• operate the school-level SEND information report tool;
• provide authorised service communications and support;
• maintain service security, availability and auditability; and
• return or delete Customer Personal Data as instructed.

3.2 The details required by Article 28(3) of the UK GDPR, including the subject matter, duration, nature and purpose of processing, types of personal data and categories of data subject, are set out in Annex A.

3.3 The Provider is an independent controller for personal data it uses for its own corporate purposes, including sales enquiries, contract administration, billing, legal compliance and management of its own business contacts. That separate processing is governed by the Provider's privacy notice and is not Customer Personal Data under this DPA.

3.4 The Service is not a pupil-record system. The pupil-data boundary applying to the practitioner tools, local exports and working files is set out in Annex A.

4. Provider obligations

4.1 The Provider will process Customer Personal Data only on the Customer's documented instructions, including instructions concerning international transfers, unless processing is required by UK law.

4.2 Where UK law requires processing outside the Customer's instructions, the Provider will inform the Customer of that legal requirement before processing unless the law prohibits the Provider from doing so.

4.3 The Provider will immediately inform the Customer if, in its opinion, an instruction infringes Applicable Data Protection Law. The Provider may suspend the affected processing while the parties clarify or amend the instruction.

4.4 The Provider will ensure that each person it authorises to process Customer Personal Data:

• is subject to a binding duty of confidentiality;
• receives access only where needed for their role; and
• processes the data only as permitted by this DPA and the Customer's instructions.

4.5 The Provider will implement and maintain appropriate technical and organisational measures meeting Article 32 of the UK GDPR. The current measures are described in Annex C.

4.6 Taking into account the nature of the processing, the Provider will use appropriate technical and organisational measures to assist the Customer with requests by individuals exercising their data-protection rights.

4.7 Taking into account the nature of the processing and information available to it, the Provider will assist the Customer with its obligations concerning:

• security of processing;
• notification of Personal Data Breaches to the Information Commissioner's Office;
• communication of Personal Data Breaches to affected individuals;
• data protection impact assessments; and
• prior consultation with the Information Commissioner's Office where required.

4.8 The Provider will maintain the records concerning its processing activities that Applicable Data Protection Law requires and will cooperate with the Information Commissioner's Office where legally required.

5. Customer rights and obligations

5.1 The Customer retains control of Customer Personal Data and may:

• give lawful documented instructions;
• request reasonable assistance with individual-rights requests and regulatory obligations;
• obtain information reasonably necessary to assess the Provider's compliance;
• exercise the audit rights in clause 10;
• object to a proposed Sub-processor in accordance with clause 7;
• export Customer Personal Data using the available service functions; and
• require return or deletion in accordance with clause 11.

5.2 The Customer is responsible for:

• complying with its obligations as controller, including identifying a lawful basis and giving required privacy information to staff;
• ensuring that its instructions are lawful, fair and proportionate;
• deciding which staff may use the Service and promptly removing access when it is no longer required;
• maintaining the security of its user accounts, devices, locally exported documents and working files;
• ensuring that users comply with the non-identifying input restrictions in Annex A;
• not entering or uploading data that the Service is not designed or authorised to receive; and
• handling pupil information held in its own systems in accordance with its own legal duties, policies and retention schedule.

5.3 The Customer must not instruct the Provider to process pupil personal data or special-category personal data through the practitioner tools. If the Customer requires a materially different processing activity, the parties must complete a fresh data-protection review and agree any necessary changes before that processing begins.

6. Personal Data Breaches

6.1 The Provider will notify the Customer without undue delay after becoming aware of a Personal Data Breach affecting Customer Personal Data.

6.2 As information becomes available, the Provider's notification will describe:

• the nature of the breach;
• the categories and approximate number of affected individuals and records, where known;
• the likely consequences;
• the measures taken or proposed to address and mitigate the breach; and
• a contact from whom the Customer can obtain further information.

6.3 The Provider may provide information in stages where it is not possible to provide it all at the same time. The Provider will take reasonable steps to contain, investigate and remediate the incident and preserve relevant evidence.

6.4 The Provider's notification or cooperation does not constitute an admission of fault or liability.

7. Sub-processors

7.1 The Customer gives general written authorisation for the Provider to use the Sub-processors listed in Annex B for the purposes described there.

7.2 The Provider will give the Customer at least 14 days' prior written notice of an intended addition or replacement, except where an urgent change is reasonably required to protect service security or continuity. In an urgent case, notice will be given as soon as reasonably practicable.

7.3 The Customer may object within the notice period on reasonable data-protection grounds. The parties will work in good faith to resolve the objection, including by considering an available technical or commercial alternative. If the objection cannot reasonably be resolved, either party may terminate the affected part of the Service without penalty, but fees already due for services provided remain payable.

7.4 Before a Sub-processor processes Customer Personal Data, the Provider will enter into a written contract imposing data-protection obligations that provide an equivalent level of protection to this DPA, as required by Article 28(4) of the UK GDPR.

7.5 The Provider remains liable to the Customer for the performance of each Sub-processor's data-protection obligations to the extent required by Applicable Data Protection Law.

8. International transfers

8.1 The Customer authorises the transfers described in Annex B as part of its documented instructions.

8.2 The Provider will not make a restricted transfer of Customer Personal Data unless it uses a lawful transfer route. Depending on the recipient and transfer, this may include:

• UK adequacy regulations;
• the UK Extension to the EU-US Data Privacy Framework, but only while the relevant US recipient is currently certified for the UK Extension;
• the UK International Data Transfer Agreement;
• the UK Addendum to the European Commission's Standard Contractual Clauses; or
• another mechanism approved under Applicable Data Protection Law.

8.3 Where required, the Provider will carry out and document the applicable transfer-risk assessment and implement supplementary safeguards.

8.4 If a transfer mechanism becomes invalid or no longer applies, the Provider will take reasonable steps to replace it with a lawful mechanism or suspend the affected transfer.

8.5 On request, the Provider will make information about the relevant transfer mechanism available to the Customer, subject to necessary protection of confidential and security-sensitive information.

9. Individual-rights requests

9.1 If the Provider receives a request from an individual relating to Customer Personal Data, it will promptly refer the request to the Customer unless law requires the Provider to respond directly.

9.2 The Provider will not independently respond to the substance of the request without the Customer's documented instruction, except where required by law.

9.3 The Provider will provide reasonable assistance available through the Service or its support processes so the Customer can locate, export, correct, restrict or delete relevant Customer Personal Data.

10. Information, audits and inspections

10.1 The Provider will make available the information reasonably necessary to demonstrate compliance with Article 28 and this DPA.

10.2 The Provider will allow for and contribute to audits and inspections by the Customer or an independent auditor appointed by the Customer, subject to the following reasonable safeguards:

• the Customer will normally give at least 20 working days' notice;
• the parties will first use current documentation, test results and other assurance material where these can reasonably answer the Customer's questions;
• the audit will take place during normal business hours and minimise disruption;
• the auditor must be independent, suitably qualified and subject to confidentiality;
• the audit must not expose another customer's information, security credentials or information that would create a security risk; and
• the Customer will bear its reasonable audit costs unless the audit identifies a material breach by the Provider or a shorter-notice audit is required following a relevant Personal Data Breach or regulatory request.

10.3 The safeguards in clause 10.2 do not prevent the Customer from exercising its rights under Article 28(3)(h) or prevent a competent regulator from exercising its powers.

11. Return and deletion

11.1 During the subscription, the Customer may use the available functions to export its training and evidence records.

11.2 When the Service ends, the Customer will have a 30-day offboarding period in which to export available Customer Personal Data, unless the parties agree a different period in writing.

11.3 At the Customer's choice, the Provider will return Customer Personal Data and delete it, or delete it without return. If the Customer does not give a different lawful instruction during the offboarding period, the Provider will delete Customer Personal Data from live systems after that period.

11.4 The Provider will also delete existing copies unless UK law requires continued storage. Where immediate deletion from a protected backup is not technically practicable, the copy will be placed beyond ordinary use, protected under this DPA, and deleted during the Provider's normal secure backup-destruction cycle. It will not be restored except where necessary for disaster recovery or legal compliance. If restored, the relevant deletion instruction will be reapplied.

11.5 A legal requirement to retain particular information does not authorise continued use for another purpose. The Provider will inform the Customer of legally required retention unless prohibited by law.

12. Liability and precedence

12.1 This DPA is subject to the liability provisions in the licence agreement to the extent permitted by law.

12.2 Nothing in the licence agreement or this DPA limits either party's regulatory responsibilities, the Information Commissioner's Office's powers, or an individual's rights where those matters cannot lawfully be limited by contract.

12.3 If this DPA conflicts with the licence agreement on the protection or processing of Customer Personal Data, this DPA prevails.

12.4 The governing-law and jurisdiction provisions of the licence agreement apply to this DPA.

Annex A: Details of processing

A1. Subject matter

Provision, administration, security and support of The SENDNest for Schools platform for the Customer.

A2. Duration

For the subscription term and the 30-day offboarding period described in clause 11, followed by the limited period needed to complete secure deletion from protected backups or meet a legal retention requirement.

A3. Nature and purpose

The processing consists of collecting, recording, organising, storing, retrieving, displaying, calculating, transmitting, restricting, exporting and deleting Customer Personal Data for the following purposes:

• administering staff accounts and authentication;
• delivering training and recording progress;
• automatically marking assessments and recording scores and per-question correctness;
• producing certificates, evidence records and staff training-needs reports;
• operating and securing the Service;
• sending authorised transactional service emails;
• storing permitted school-level SEND information report inputs; and
• providing service support and complying with Customer instructions.

The Provider does not use training results to make employment, capability or disciplinary decisions. The Customer is responsible for any decisions it makes using those results and for ensuring appropriate human review.

A4. Categories of data subjects

• Customer staff and other authorised users with platform accounts;
• staff members whose professional contact details are included in the Customer's SEND information report inputs; and
• Customer administrators responsible for managing accounts and reviewing training records.

Pupils are not authorised data subjects within the Provider's processing under this DPA.

A5. Categories of Customer Personal Data

• name, work email address, professional role and Customer organisation;
• account identifiers, authentication records and account status;
• modules started and completed, assessment scores, per-question correctness and completion dates;
• certificate and evidence-record information;
• the SENCO's professional name and work contact details and permitted school-office contact details used in the SEND information report;
• IP address, device or browser information, request identifiers, timestamps, login events and security events where processed for authentication, delivery or security; and
• service-support information relating to a staff account, provided that it does not contain prohibited pupil information.

A6. Data not authorised for processing

No special-category personal data, criminal-offence data or pupil personal data is required or authorised within the Provider's processing scope.

The practitioner tools' own predefined options include broad categories of educational need (for example, needs associated with autism, with attention and concentration, or with speech, language and communication). Selecting one of these general professional categories is intended use of the Service: it describes a type of need, not a named pupil, and is not the entry of a medical record. The restrictions below concern identifying details and copied records.

Users must not enter, upload, paste or send through practitioner tools or support channels:

• pupil names, initials, dates of birth, addresses or pupil, health or national identifiers;
• a school, class, case number or local reference that could identify a pupil;
• medical records, diagnosis letters, EHC plan extracts or other professional reports;
• safeguarding information, detailed case histories or unique incident narratives; or
• names or identifying details of relatives, staff or other pupils.

Any practitioner-tool text field is restricted to a short, general description of a functional difficulty, educational need, desired outcome or support strategy. It must not be used as a case record, evidence log or pupil narrative.

The Customer must not use staff profiles, support requests or other service fields to submit health or disability details about staff, trade-union information, criminal-offence data or any other category of data that is excluded from the processing scope above.

A7. Practitioner tools and pupil identity

The practitioner tools work from predefined selections and permitted brief descriptions of general educational needs and support strategies. The Customer may know which pupil it is supporting using information held separately in its own systems. The Provider does not receive the separate identity information or the Customer's link between those general descriptors and a pupil.

The platform does not create pupil accounts or server-side pupil records. It does not provide fields for pupil names or direct identifiers during drafting.

Where a document requires a pupil name, the user adds it during export on the user's device. The export-only identity is not sent to the Provider's servers, stored in the Provider's database, included in an AI request, or placed in application analytics, content logs or error reports. The named document is created for and retained by the Customer under its own control.

The separation in this section is an agreed processing restriction. If the Provider proposes to change the Service so that it receives identifying pupil information, diagnoses, detailed pupil histories or identifiable documents, the Provider must complete a fresh data-protection review, amend this DPA and the privacy information, and obtain any required Customer authorisation before the change takes effect.

A8. Working files

Some tools may allow the Customer to download a working file containing general needs and support selections. The file has no field for the pupil's name or other direct identifier. It is saved by the Customer and opened locally in the user's browser. It is not uploaded to or stored on the Provider's servers.

If the Customer can connect a working file to a pupil using information it holds separately, the Customer must treat the file as pupil personal data. The Customer controls its access, accuracy, storage, retention, sharing and deletion.

If a connected tool offers AI drafting, only the permitted non-identifying fields required for that drafting action are submitted. The complete working file, the Customer's identity link, any export-only identity and the named export are not submitted.

At the date of this DPA, working files may be used by the EHC needs assessment request builder and, when released, the Pupil SEND Overview. The same restrictions apply to both tools.

A9. Other tool boundaries

• The costed provision map operates in the user's browser and does not store its contents on the Provider's servers.
• The SEND information report stores only permitted school-level structured inputs, public links, report dates and professional contact details. It is not designed to receive individual pupil information.
• Browser-only option pickers do not send their contents to the Provider unless the user expressly activates a permitted generation or save function described in the Service.

A10. Retention

• Per-question assessment detail: no longer than two years from the assessment date, unless earlier deletion is instructed or law requires otherwise.
• Completion records, scores, certificates and evidence records: for the subscription term and 30-day offboarding period, then returned or deleted under clause 11.
• Staff account data: until the account is deleted on Customer instruction or during service offboarding.
• SEND information report inputs: for the subscription term and offboarding period, then returned or deleted with the Customer's other data.
• Support and security records: only for the period reasonably required to resolve the issue, maintain security and an appropriate audit trail, or meet a legal obligation, in accordance with the Provider's retention schedule.
• Locally exported documents and working files: held by the Customer and not subject to the Provider's retention schedule.

Annex B: Authorised Sub-processors and transfers

The following suppliers are authorised to process Customer Personal Data. Provider terms, certifications and transfer arrangements may change. The Provider will review the applicable mechanism and give notice of relevant Sub-processor changes under clause 7.

AI drafting provider

The Provider uses Anthropic, PBC's commercial API to generate practitioner-tool drafts. Under the agreed service configuration, Anthropic is not authorised to receive Customer Personal Data. It receives only the non-identifying needs and strategy content permitted by Annex A. Staff account data, pupil identity, school-held identity links, working files and named exports are excluded from the prompt.

Anthropic is therefore identified here for transparency but is not appointed through this DPA to process Customer Personal Data. If the proposed use changes so that Anthropic would receive Customer Personal Data, the Provider must first complete a data-protection and transfer review, add Anthropic to the authorised Sub-processor table, update the privacy information and give the Customer the notice required by clause 7.

The Provider does not opt production API content into model training or submit it as feedback. Anthropic's current standard commercial terms state that API inputs and outputs are automatically deleted from its backend within 30 days, subject to stated legal, usage-policy and service exceptions.

Annex C: Technical and organisational measures

The Provider will maintain measures appropriate to the risk presented by the processing, including the following.

C1. Access and confidentiality

• Role-based and least-privilege access to Customer Personal Data.
• Tenant separation so that authorised users can access only data belonging to their Customer organisation.
• Database-level access policies protecting tenant data and regular testing of those policies.
• Multi-factor authentication for privileged administrative access where supported.
• Confidentiality obligations for anyone authorised to access Customer Personal Data.
• Prompt removal or adjustment of access when a role changes or access is no longer required.

C2. Encryption and communications

• Encryption in transit using current transport-layer security.
• Encryption at rest through the relevant database and infrastructure providers.
• Secure management of credentials, secrets and service keys.
• Assessment answer keys held server-side and not included in ordinary client code.

C3. Pupil-data minimisation

• No server-side pupil account or pupil-record database.
• Practitioner tools restricted to predefined selections and brief non-identifying needs and strategy descriptions.
• Export-only identity kept out of server requests, databases, AI prompts, analytics, content logs and error reports.
• Working files processed locally and not uploaded or placed in persistent browser storage by the Service.
• AI generation payloads restricted to the permitted fields needed for the selected drafting function.
• Product tests covering the controls that separate locally held pupil identity and working files from Provider-accessible processing.

C4. Logging and monitoring

• Application logging minimised to information required for security, reliability and fault diagnosis.
• No intentional logging of practitioner prompt content, generated content, export-only identity or working-file content.
• AI generation audit records limited to operational metadata such as model identifier, token counts, outcome, timing and duration, without prompt or output content.
• Monitoring for unauthorised access, abnormal activity and service failures, with access to security records restricted to authorised roles.

C5. Secure development and vulnerability management

• Change control and review appropriate to the significance of each production change.
• Automated testing of material access-control and data-boundary rules.
• Secret scanning and appropriate dependency or vulnerability checking during development and deployment.
• Timely assessment and remediation of security vulnerabilities according to their risk.
• Separation of production secrets from source code and public repositories.

C6. Availability, resilience and recovery

• Use of reputable infrastructure providers offering service resilience and protected backups appropriate to the Service.
• Documented incident-response and recovery procedures.
• Measures intended to restore availability and access following a physical or technical incident within a period appropriate to the risk.
• Periodic review or testing of recovery arrangements and corrective action where a weakness is identified.

C7. Deletion and disposal

• Restricted service permissions for scheduled deletion operations.
• Secure deletion or placement beyond ordinary use at the end of processing, in accordance with clause 11.
• Reapplication of deletion instructions if a protected backup is restored.

C8. Review

• Periodic assessment of the effectiveness of the measures in this Annex.
• Review of measures following a material change, relevant security incident or identified weakness.
• Appropriate due diligence and contractual protection for Sub-processors handling Customer Personal Data.