Sub-processor Register

1. Purpose

This register lists every sub-processor engaged by Fishing 4 Flowers Limited in the delivery of the Fishing 4 Flowers SEND platform, together with the personal data each may access, the region in which it processes that data, and the basis of any transfer outside the United Kingdom.

It is referenced by the Record of Processing Activities, the Data Protection by Design and by Default Statement and the Data Protection Risk Assessment, and supports each controller’s assessment of the processing chain under Articles 28(2) and 28(4) UK GDPR.

2. Roles

The subscribing school, academy trust or local authority is the controller. Fishing 4 Flowers Limited is the processor. The organisations listed at section 3 are sub-processors: they process personal data on behalf of Fishing 4 Flowers in order that the service can be delivered to the controller.

Sub-processors are engaged only where they provide sufficient guarantees of appropriate technical and organisational measures. Each is engaged under the provider’s data processing terms, which impose obligations no less protective than those owed to the controller. Fishing 4 Flowers is compiling the executed references for each — legal entity, contract date and data processing agreement reference — and will provide them to a controller on request; until that is complete the register states the position without citing them.

3. Sub-processor register

The table above lists the organisations engaged to deliver the platform. Most process pupil personal data on behalf of Fishing 4 Flowers; where an entry does not, its personal data column says so. Key custody is listed for that reason: a controller assessing the processing chain should know where the key protecting its pupils’ records is held, even though no record reaches it.

The identity providers at section 4 are recorded separately, with the reasoning for that treatment.

3.1 The model provider

Support plan generation is performed by Anthropic Claude Sonnet 4.6, served via Amazon Bedrock in UK — eu-west-2. The model is named here so that a controller can assess what handles its pupils’ data rather than infer it from the service description.

The model’s developer is not a sub-processor of Fishing 4 Flowers. Amazon Bedrock serves the model within its own infrastructure: the payload is sent to Amazon Bedrock and is processed there, and the developer neither receives it nor holds it. Amazon Bedrock is the sub-processor, and appears in the table above as one. There is no additional organisation in the processing chain and no international transfer arising from the choice of model.

No model retention applies to that processing, pupil data is not used to train models, and model invocation logging is disabled.

A change of model is a change trigger. Moving to a different model, or to a different way of reaching this one, is notified to every school in writing on the same 30 days’ notice that governs a change of sub-processor, and schools may object within that period under the data processing agreement.

4. Identity providers and federation

Microsoft Entra ID and Google Workspace are recorded separately because they do not process pupil personal data on behalf of Fishing 4 Flowers. Two distinct relationships exist, and they are set out separately below because they are easily conflated.

4.1 The authentication event

Staff authenticate using their school’s existing identity. Authentication takes place in the school’s own tenant, against the school’s own credentials, under the school’s own agreement with the provider — a relationship that exists independently of the school’s use of the platform. Personal data flows from the identity provider to Fishing 4 Flowers in the form of sign-in claims. No pupil data is sent to either provider.

Fishing 4 Flowers is a relying party in this exchange. No restricted transfer is made by Fishing 4 Flowers, and no International Data Transfer Agreement is required in respect of the sign-in flow.

4.2 The application registration

Separately, Fishing 4 Flowers holds its own registration with each provider so that schools are able to grant the application access:

The registration is configuration: a client identifier, redirect URIs, the permissions the application may request, and a client secret. It is not personal data, and it identifies the application rather than any individual.

Where the personal data sits. When a school grants access, the resulting consent record and service principal are created in the school’s own tenant, not in the Fishing 4 Flowers tenant. When a member of staff subsequently signs in, that sign-in event is likewise recorded in the school’s tenant. The publisher’s tenant is not where either lives.

The Fishing 4 Flowers Entra tenant was inspected in July 2026 and contained no sign-in records for the application.

What the provider itself records. At sign-in the platform performs a server-to-server token exchange using the registration credentials, so the provider’s own infrastructure records that the application requested a token for that user. The provider processes that record for the operation and security of its identity service, under its own terms, acting as controller of those records rather than as a processor engaged by Fishing 4 Flowers.

It is for those two reasons — the personal data resides in the controller’s own tenant, and what the provider itself holds it holds as controller — that neither provider appears in the sub-processor table at section 3.

Scopes and claims requested. Sign-in requests identity claims and, for Microsoft, the signed-in member of staff’s own profile. No permission to reach documents, mail or directory data is bundled into it.

4.3 Document storage in the school’s own tenant

SEND evidence documents — EHCPs, educational psychology reports, medical letters — are held exclusively in the school’s own SharePoint Online site or Google Shared Drive. Fishing 4 Flowers reads and writes them there through the provider’s API.

The platform provides no document storage of its own. A connected document store is a prerequisite for using the service, and the most sensitive material in the system therefore never resides in Fishing 4 Flowers infrastructure.

Because the documents remain in the school’s own tenant, under the school’s own agreement with the provider, that provider is processing them for the school — as it already does for every other document in that tenant — and is not a sub-processor of Fishing 4 Flowers in respect of them.

What Fishing 4 Flowers holds. A reference to the file in the school’s store, together with its filename, the date it was added, the pupil record it is associated with, and — where the document has been read for support plan generation — the text extracted from it, held encrypted under that pupil’s own key. That metadata is personal data in its own right. A filename may disclose a diagnosis, so it is treated as special category data and carries the same retention rule as the pupil record it belongs to.

Where content is read. Where a document grounds a support plan, its text is read once and stored as an extract, encrypted under the pupil’s own key, and that stored extract is what grounds generation from then on. Document content therefore leaves the school’s store and is held by the platform in extracted form, though the file itself is not. The extract may contain content from an EHCP, an educational psychology report or a medical letter, and is treated as special category data concerning a child accordingly.

Access is bounded by explicit grant, not by scope.

Sign-in and document access are deliberately separated. Staff sign-in requests identity claims and the signed-in member of staff’s own profile (openid, profile, email, User.Read); the permission to reach documents is granted by an administrator, for named locations, and is revocable by the school without affecting sign-in.

What a school administrator is asked to approve. The Microsoft consent screen reads: “Sign in and read user profile”, together with “Access selected site collections”. That is the whole of what the application requests, and an accurate description of what it can reach.

Tokens. No provider token is stored at rest, for either provider. SharePoint Online is reached using the application’s own credentials under the administrator’s Sites.Selected grant, and Google Drive by a service account holding membership of the school’s nominated Shared Drive. Neither route holds a credential belonging to a member of staff.

Control over document reads

The platform’s own access policy is the sole control over who may read a pupil’s document. Documents are retrieved using the application’s credentials under the administrator’s grant, so a school’s file permissions within a granted site do not further restrict which documents a request can reach. A controller assessing this should read the platform’s access policy as the whole of that control rather than as a layer above its own permissions.

A document read is recorded in two places, and they attribute it differently. The platform’s access log records which user read which pupil record. The school’s own SharePoint audit log shows the application. A school reconstructing an incident from its own tenant logs alone will therefore not see individual members of staff, and will need the platform’s log to attribute a read to a person.

That access policy has now been independently assessed. An independent penetration test was carried out in August 2026. The assessment phase is complete and the report is in the tester’s quality assurance process. One Medium-severity access control finding was identified and has been remediated; the remaining findings are Low or Informational and are addressed on receipt of the report. This entry is updated when the report is issued, and a summary will be made available to schools.

4.4 Authentication credentials

Single sign-on only in production, via the school’s own identity provider (Microsoft Entra ID or Google Workspace). Multi-factor authentication is enforced by the school’s identity provider, under the school’s own conditional access policies; Fishing 4 Flowers neither operates nor configures it.

Fishing 4 Flowers holds no passwords, MFA secrets or passkeys for production users, and does not authenticate users against a credential store of its own.

No provider token is stored at rest, for either provider. SharePoint Online is reached using the application’s own credentials under the administrator’s Sites.Selected grant, and Google Drive by a service account holding membership of the school’s nominated Shared Drive. Neither route holds a credential belonging to a member of staff. Fishing 4 Flowers holds its own application credentials — a client secret for each provider — but these identify the application rather than any individual, and cannot be used to impersonate a user. Section 4.3 describes the access model those credentials operate under, and what it gives up as well as what it removes.

Password and MFA credential fields exist in the application schema to support local development against test data. They are not populated in production, where single sign-on is the only authentication route. That position rests on architecture rather than on configuration: since 28 August 2026 the application refuses credential authentication in production, and the route fails closed, so it is off unless something explicitly enables it rather than on unless something disables it.

4.5 Corporate processing by Microsoft

Distinct again from both the sign-in flow and the application registration, Fishing 4 Flowers operates its own Microsoft 365 tenant for corporate purposes. Microsoft processes Fishing 4 Flowers corporate data in that tenant: staff mailboxes and files, and internal records. This is Fishing 4 Flowers company data. It is not pupil data, and it does not arise from the school’s use of the platform.

Pupil personal data is not to be sent to, or held in, Fishing 4 Flowers email or OneDrive. Documents relating to pupils belong in the school’s own document store, where the platform reads them; they are never sent to Fishing 4 Flowers directly. Where pupil data is received by email it is deleted and the school is asked to place it in its own document store instead.

Where Microsoft processes Fishing 4 Flowers corporate data outside the United Kingdom, it does so under the Microsoft Products and Services Data Protection Addendum, which incorporates the EU Standard Contractual Clauses and the UK Addendum. The EU Data Boundary does not include the United Kingdom, and UK residency is not claimed for Microsoft-processed corporate data.

5. Planned and possible changes

6. Changes to sub-processors

Controllers are given at least 30 days’ written notice before a sub-processor processing pupil personal data is added or replaced.

A controller may object on reasonable data protection grounds within that period. Where an objection cannot be resolved, the controller may terminate the service without penalty and receive a pro-rata refund of prepaid fees. This corresponds with clause 7.3 of the Data Processing Agreement.

7. Review

This register is reviewed at least annually, on any change of sub-processor, and before each new school is onboarded. The current version is the version published at the trust centre; superseded versions are retained.

Fishing 4 Flowers Limited · Company number 17024439 · ICO registration ZC147128 Data Protection Officer: Patrick Shone — pat@fishing4flowers.com