Data Protection Impact Assessment (DPIA)
SpektraBot SEND Support System
| Field | Detail |
|---|---|
| Document version | 1.0 |
| Date | [SIGN-OFF REQUIRED] |
| Author | [SIGN-OFF REQUIRED] |
| Data Controller | Spectrum Dynamics CIC |
| DPO / Privacy Lead | [SIGN-OFF REQUIRED] |
| System name | SpektraBot |
| ICO registration number | [SIGN-OFF REQUIRED] |
Document Control
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] | Initial DPIA |
Step 1: Identify the Need for a DPIA
1.1 Why is a DPIA required?
UK GDPR Article 35 requires a Data Protection Impact Assessment when processing is likely to result in a high risk to the rights and freedoms of natural persons. The ICO's screening criteria mandate a DPIA when two or more of the following apply. SpektraBot meets six:
| ICO Screening Criterion | Applicable? | Justification |
|---|---|---|
| Evaluation or scoring | Yes | AI-generated advice based on user-provided child profile data; conversation intent detection; document relevance scoring |
| Automated decision-making with legal or significant effects | Yes | AI-generated guidance on EHCP applications, tribunal appeals, and legal rights directly affects families' educational provision decisions |
| Systematic monitoring | No | SpektraBot does not systematically monitor public areas |
| Sensitive data or data of a highly personal nature | Yes | SEND diagnoses, EHCP status, therapy details, mental health indicators (crisis detection), and safeguarding concerns |
| Data processed on a large scale | Yes | Designed to serve families across 152 English local authorities; knowledge base of 450K+ document chunks across all LAs |
| Datasets that have been matched or combined | Yes | Combines user-provided child profiles with GIAS school data (52K schools), LA EHCP statistics, Ofsted ratings, crawled Local Offer content, and SEND tribunal data |
| Data concerning vulnerable data subjects | Yes | Children with SEND are explicitly vulnerable data subjects under UK GDPR Recital 75. Parents of SEND children are often in distressed or vulnerable circumstances |
| Innovative use of technology | Yes | Agentic RAG pipeline with self-correcting LLM, pgvector semantic search, automated web crawling of 152 LA Local Offers, LLM-based memory extraction from conversations |
| Data transfers across borders | Partial | Azure OpenAI processes data in UK South region; Microsoft's DPA governs sub-processing. No data transferred outside UK/EEA by design |
| Processing that prevents data subjects exercising a right or using a service | No | Users can access the service without providing child data, though functionality is reduced |
Conclusion: A DPIA is mandatory. Six of the ICO's screening criteria are met, including the processing of children's data with AI, which the ICO has explicitly stated requires a DPIA.
1.2 Legal basis for processing
| Data category | Legal basis | GDPR Article |
|---|---|---|
| User account data (email, name, password hash) | Consent (registration) | Art. 6(1)(a) |
| Child profile data (name, DOB, SEND diagnosis, EHCP status, school, key needs, provision) | Explicit consent | Art. 6(1)(a), Art. 9(2)(a) |
| Conversation content | Legitimate interest (service delivery) + Consent | Art. 6(1)(a) and Art. 6(1)(f) |
| AI-generated responses and RAG metadata | Legitimate interest (service delivery) | Art. 6(1)(f) |
| Knowledge base content (crawled public documents) | Legitimate interest (public task information) | Art. 6(1)(f) |
| GIAS school data | Public task (Open Government Licence) | Art. 6(1)(e) |
| Audit logs (IP address, user agent, actions) | Legal obligation (accountability) + Legitimate interest | Art. 6(1)(c), Art. 6(1)(f) |
| Support tickets | Contract performance (service support) | Art. 6(1)(b) |
| Safeguarding logs | Vital interest / Legal obligation | Art. 6(1)(d), Art. 6(1)(c) |
1.3 Special category data
The following special category data is processed under Article 9:
- Health data: SEND diagnoses (e.g., ASD, ADHD, SEMH, SLCN), therapy details, provision information
- Children's data: Names, dates of birth, school year, EHCP status, key needs, educational provision
- Mental health indicators: Crisis detection system identifies users in distress or mental health crisis
Condition for processing: Explicit consent (Art. 9(2)(a)) -- collected at registration via GDPR consent flow, stored as JSONB with version, timestamp, and IP address.
Step 2: Describe the Processing
2.1 System overview
SpektraBot is an AI-powered web application that helps UK families and education professionals navigate the Special Educational Needs and Disabilities (SEND) system. It provides real-time, context-aware guidance grounded in the SEND Code of Practice, local authority Local Offers, and national charity resources.
Target users:
- Parents and carers of children with SEND
- Teachers and SENCOs (Special Educational Needs Coordinators)
- System administrators
Deployment model: Cloud-native on Civo Kubernetes (London, UK data centre -- LON1 region) with UK data residency.
2.2 Data subjects
| Data subject | Relationship | Data collected |
|---|---|---|
| Parents/carers | Direct users | Email, name, password hash, role, persona, GDPR consent, IP address, user agent, conversation content, accessibility preferences, notification preferences |
| Children with SEND | Indirect subjects (data provided by parents) | Name, date of birth, SEND diagnosis, school name/URN, year group, EHCP status, key needs (e.g., ASD, SEMH, SLCN), provision details (e.g., speech therapy, 1:1 TA), SENCO name, key worker name, notes |
| Teachers/SENCOs | Direct users | Email, name, password hash, role, school name/URN, conversation content |
| School staff named in child profiles | Indirect subjects | SENCO name, key worker name (as entered by parents) |
| Advocates | Direct users | Email, name, professional profile, case notes, referral communications |
2.3 Data flows
2.3.1 High-level architecture
2.3.2 Conversation data flow (user to AI response)
Key privacy design decisions in this flow:
- Child PII is NOT sent to Azure OpenAI -- The system prompt and RAG context contain only the user's query text and retrieved public knowledge base documents. Child names, DOBs, diagnoses, and school details are NOT included in the LLM prompt.
- Conversation content IS sent to Azure OpenAI -- The user's message text (which may contain PII they choose to include) and the last 5 conversation messages are sent as context.
- Azure OpenAI processes in UK South -- Microsoft's Azure OpenAI service processes data within the UK South Azure region. Microsoft's Data Protection Addendum applies.
Confirmed: Microsoft's Azure OpenAI Service terms explicitly state that customer data (prompts and completions) is not used for model training. Azure OpenAI does not retain prompt/completion data beyond the API request lifecycle. Microsoft's Data Protection Addendum (DPA) governs all processing. Abuse monitoring is enabled by default but processes data ephemerally and does not train models.
2.3.3 Child profile data flow
2.3.4 Knowledge base and crawler data flow
2.3.5 Data sync flows (public data)
The following data is synced from government open data sources (Open Government Licence v3.0). This data does not contain personal data:
| Data source | Frequency | Data | Storage |
|---|---|---|---|
| DfE GIAS API | Daily (3 AM UTC) | 52,000+ English schools with SEND provision data | schools table |
| Ofsted inspection data | Daily | Inspection ratings, framework versions | ofsted_ratings table |
| SEN2/EHCP statistics | Daily | LA-level EHCP assessment statistics | la_ehcp_statistics table |
| SEN primary need data | Daily | LA-level SEN need breakdowns | la_sen_need_breakdowns table |
| Tribunal statistics | Daily | LA-level appeal outcomes | la_tribunal_statistics table |
| Area SEND inspections | Daily | Joint Ofsted/CQC inspection results | la_send_inspections table |
2.4 Data storage and retention
Note: Retention periods below implement the Tiered Data Retention Policy, validated against ICO Children's Code Standards 7 & 8.
| Data category | Storage location | Retention period | Retention tier | Deletion method |
|---|---|---|---|---|
| Conversations and messages | PostgreSQL (Civo UK) | 90 days from last activity (updatedAt) | Tier 1 | Automated CronJob; messages cascade-delete via FK |
| AI response metadata (RAG traces) | PostgreSQL (Civo UK) | 90 days from last activity (with parent conversation) | Tier 1 | Cascade deletion with conversation |
| Child memories | PostgreSQL (Civo UK) | Account lifetime (closure or 12-month dormancy) | Tier 2 | Soft delete → 30-day grace → hard delete. sourceConversationId set to NULL when conversation deleted (memories survive) |
| User accounts | PostgreSQL (Civo UK) | Account lifetime (user request or 12-month dormancy) | Tier 3 | Cascade deletion of all associated data |
| Child profiles | PostgreSQL (Civo UK) | Account lifetime (with parent account) | Tier 3 | Soft delete → 30-day grace → hard delete; cascade with parent |
| Safeguarding logs | PostgreSQL (Civo UK) | Indefinite (statutory: Children Act 2004 s.11, KCSIE 2024) | Tier 4 | Manual review only — excluded from automated deletion |
| Knowledge base (crawled/uploaded) | PostgreSQL (Civo UK) | Until manually removed by admin | N/A (no PII) | Admin deletion |
| Audit logs | PostgreSQL (Civo UK) | 2 years from creation | N/A | Automated CronJob; denormalised email preserved so logs remain interpretable after user deletion |
| Support tickets | PostgreSQL (Civo UK) | 90 days after resolution | Tier 1 | Automated CronJob; resolvedAt + 90 days |
| Database backups | Civo Object Storage (LON1, encrypted) | 30 days rolling (S3 lifecycle) | N/A | Automatic expiry |
| Redis cache (sessions, WebSocket state) | Redis (Civo UK, in-memory) | Ephemeral (cleared on restart) | N/A | Automatic eviction |
2.5 Data processors and sub-processors
| Processor | Purpose | Data shared | Location | DPA in place? |
|---|---|---|---|---|
| Microsoft (Azure OpenAI) | LLM inference (GPT-4.1) and embedding generation | User message text, conversation history (last 5 messages), knowledge base document chunks for embedding | UK South (London) | Yes — Microsoft Online Services DPA applies automatically to all Azure services. No separate signing required. |
| Civo Ltd | Kubernetes hosting, block storage, object storage | All application data (encrypted at rest on Civo infrastructure) | LON1 (London, UK) | Yes — Civo standard DPA, signed as part of service agreement. Available at civo.com/legal. |
| Resend | Transactional email delivery | User email addresses, email content (verification, password reset, notifications, digest) | US (AWS infrastructure) — email addresses and content transit US servers | Yes — Resend DPA signed. UK-US Data Bridge adequacy applies. Data limited to email addresses and transactional content (no child PII). |
| GitHub (Microsoft) | Container image registry (GHCR), source code hosting | No personal data (code and Docker images only) | US | N/A (no personal data) |
| Let's Encrypt | TLS certificate issuance | Domain name only | US | N/A (no personal data) |
DPA status: Microsoft DPA applies automatically via Online Services terms. Civo DPA signed with service agreement. Resend DPA signed separately. All DPAs filed in the organisation's compliance records.
2.6 Technology stack summary
| Component | Technology | Privacy relevance |
|---|---|---|
| Frontend | Next.js 15, React 19 | Runs in user's browser; no server-side personal data processing |
| Backend | Node.js 22, Express, TypeScript | Processes all personal data; JWT authentication; rate limiting |
| Database | PostgreSQL 16 + pgvector | Stores all personal data; encrypted at rest; user isolation enforced |
| Cache | Redis 7.4 | Ephemeral session data and WebSocket coordination only |
| AI/LLM | Azure OpenAI GPT-4.1 (UK South) | Processes conversation text; does NOT store data (per Azure terms) |
| Embeddings | Azure OpenAI text-embedding-3-large | Converts text to vectors; no PII in resulting vectors |
| Monitoring | Prometheus + Grafana | Operational metrics only; no personal data |
| Resend + React Email | Sends transactional emails containing user email addresses | |
| TLS | Let's Encrypt (cert-manager) | All data in transit encrypted via HTTPS/WSS |
| Backup | pg_dump to Civo S3 | Contains full database snapshot including personal data |
Step 3: Consultation Process
3.1 Internal consultation
| Consultee | Role | Date | Input provided |
|---|---|---|---|
| [SIGN-OFF REQUIRED] | Data Protection Officer | [SIGN-OFF REQUIRED] | Review of DPIA, advice on processing risks and mitigations |
| [SIGN-OFF REQUIRED] | Technical Lead / CTO | [SIGN-OFF REQUIRED] | System architecture, security controls, data flows |
| [SIGN-OFF REQUIRED] | Product Owner | [SIGN-OFF REQUIRED] | Purpose and necessity of processing, user needs |
| [SIGN-OFF REQUIRED] | SEND Domain Expert | [SIGN-OFF REQUIRED] | Vulnerability of data subjects, trauma-informed design requirements |
3.2 External consultation
| Consultee | Organisation | Date | Input provided |
|---|---|---|---|
| [SIGN-OFF REQUIRED] | ICO (if prior consultation required) | [SIGN-OFF REQUIRED] | Prior consultation under Art. 36 not expected to be required — residual risks are at acceptable levels. If ICO consultation is triggered, record outcome here. |
| [SIGN-OFF REQUIRED] | Pilot school DPO(s) | [SIGN-OFF REQUIRED] | School-specific data protection requirements, data sharing arrangement review |
| [SIGN-OFF REQUIRED] | Parent representatives | [SIGN-OFF REQUIRED] | Views on data processing, concerns, preferences (via pre-pilot consultation sessions) |
| [SIGN-OFF REQUIRED] | SENDIASS representative | [SIGN-OFF REQUIRED] | Views on appropriateness of AI for SEND guidance, safeguarding considerations |
3.3 Data subject views
Data subject views are obtained through the following channels:
- Pre-pilot consultation — Parents at pilot schools are invited to an information session explaining what data is collected, how AI processes it, and what controls they have. A feedback form captures concerns and preferences before onboarding begins.
- Registration consent flow — Granular consent options with plain-English explanations of each data category. Parents can opt out of specific data types (e.g., child memories) while retaining core functionality.
- In-app feedback — A persistent feedback mechanism allows parents to report concerns about data handling, AI responses, or privacy at any time.
- School DPO engagement — Each pilot school's DPO receives the DPIA, privacy notice, and data sharing arrangement for review before the school is onboarded. DPO feedback is incorporated into system controls.
- Pilot review cycle — At the end of each school term during the pilot, parent feedback is collected via a structured survey including data protection questions. Material concerns are addressed in DPIA updates.
[SIGN-OFF REQUIRED: Record dates and outcomes of consultation sessions as they occur.]
Step 4: Assess Necessity and Proportionality
4.1 Necessity of each data element
| Data element | Purpose | Necessary? | Could purpose be achieved with less data? |
|---|---|---|---|
| Parent email | Account creation, authentication, notifications | Yes | No -- required for account security and communication |
| Parent name | Personalisation, support tickets | Yes | Could use pseudonym, but real name aids safeguarding |
| Child name | Personalisation of AI responses, child profile identification | Yes | Could use initials or pseudonym; full name aids parent experience |
| Child DOB | Age-appropriate guidance (SEND provisions vary by age/key stage) | Yes | Year group alone could suffice for most purposes |
| SEND diagnosis | Tailored guidance specific to the child's needs | Yes | Core to the service purpose |
| EHCP status | Process-specific guidance (requesting, appealing, reviewing) | Yes | Core to the service purpose |
| School name/URN | Location-aware guidance (LA-specific Local Offer), school-specific policies | Yes | LA detection from postcode could partially substitute |
| Key needs (ASD, SEMH, etc.) | Targeted information retrieval | Yes | Overlaps with diagnosis but provides structured filtering |
| Provision details | Understanding current support to identify gaps | Partially | Could be captured in conversation rather than structured profile |
| SENCO name / Key worker | Context for advice (e.g., "ask your SENCO, [name]") | Partially | Could be omitted; adds personalisation but not essential |
| Conversation content | AI response generation, context continuity | Yes | Core to the service; cannot function without it |
| IP address | Security (rate limiting, abuse detection), audit trail | Yes | Required for security; stored in audit logs only |
| Accessibility preferences | WCAG compliance, inclusive design | Yes | Could use browser defaults, but explicit preferences improve UX |
4.2 Proportionality assessment
Is the processing proportionate to the purpose?
The purpose of SpektraBot is to help parents of children with SEND navigate an extremely complex legal and bureaucratic system. The SEND Code of Practice is 292 pages long. Many parents are in distress, have experienced repeated institutional failures, and cannot afford professional advocates (who charge GBP 100-300/hour).
The personal data collected is the minimum necessary to provide personalised, context-aware guidance. Without knowing a child's diagnosis, EHCP status, and school/LA context, the AI system would provide only generic information that parents can already find (and struggle to interpret) on gov.uk.
Data minimisation measures in place:
- Child PII is NOT sent to the LLM -- The Azure OpenAI API receives only the user's message text and retrieved public knowledge base documents. Child names, DOBs, and diagnoses are kept within the PostgreSQL database.
- Tiered retention -- Conversation transcripts are deleted 90 days after last activity (
updatedAt). Child support memories persist for account lifetime. Safeguarding records are retained indefinitely. See Data Retention Policy. - Soft delete with cascade -- When a user requests deletion, all associated data (children, conversations, messages, memories, documents) is cascade-deleted.
- Conversation history limited -- Only the last 5 messages are sent as context to the LLM, not the full history.
- Privacy-preserving feedback -- The
feedback_eventstable uses a one-way session hash instead of a user ID, making feedback anonymous by design. - Accessibility preferences are non-identifying -- Font size, theme, and display preferences do not constitute personal data.
4.3 Lawfulness, fairness, and transparency
| Principle | How it is met |
|---|---|
| Lawfulness | Processing is based on explicit consent (Art. 6(1)(a) and Art. 9(2)(a)). Consent is collected at registration with clear, granular options. Users can withdraw consent at any time. |
| Fairness | Users are informed about AI processing before they start chatting. Trauma-informed design ensures vulnerable users are not exploited or misled. Crisis detection routes users to human support services. |
| Transparency | Privacy policy available at /policies/privacy. DPIA published. AI responses include source citations so users can verify information. The system does not pretend to be human. |
| Purpose limitation | Data is collected for SEND guidance only. Not used for marketing, profiling for commercial purposes, or shared with third parties beyond sub-processors. |
| Data minimisation | See Section 4.2 above. Each data element is justified against the service purpose. |
| Accuracy | Users can edit their child profiles at any time. Knowledge base content is validated by administrators. AI responses include hallucination checking. |
| Storage limitation | Tiered retention policy: conversations 90 days from last activity, memories for account lifetime, safeguarding indefinite. Backups expire after 30 days. See Data Retention Policy. |
| Integrity and confidentiality | See Section 6 (security measures). TLS in transit, encryption at rest, user isolation, role-based access control. |
Step 5: Identify and Assess Risks
5.1 Risk assessment methodology
Risks are assessed using the ICO's recommended framework:
- Likelihood: Remote / Possible / Probable
- Severity: Minimal / Significant / Severe
- Overall risk: Low / Medium / High / Very High
5.2 Risks to children (indirect data subjects)
| # | Risk | Likelihood | Severity | Overall | Mitigation (see Step 6) |
|---|---|---|---|---|---|
| C1 | Child's SEND data is accessed by unauthorised person (data breach) | Possible | Severe | High | M1, M2, M3, M4, M12 |
| C2 | AI provides incorrect guidance leading to inappropriate educational provision decisions | Possible | Significant | Medium | M5, M6, M7 |
| C3 | Child's SEND diagnosis or EHCP status is inferred or exposed through AI responses shared outside the platform | Remote | Significant | Medium | M8, M9 |
| C4 | Child's data is retained beyond the necessary period | Remote | Significant | Low | M10, M11 |
| C5 | AI-extracted child memories contain inaccurate information that persists and affects future guidance | Possible | Significant | Medium | M13, M14 |
| C6 | Safeguarding concern about a child is not appropriately escalated | Remote | Severe | High | M15, M16 |
5.3 Risks to parents/carers (direct data subjects)
| # | Risk | Likelihood | Severity | Overall | Mitigation (see Step 6) |
|---|---|---|---|---|---|
| P1 | Parent's conversation content (potentially distressing personal details) is accessed by unauthorised person | Possible | Severe | High | M1, M2, M3 |
| P2 | AI provides legally inaccurate advice leading parent to take harmful action (e.g., wrong tribunal procedure) | Possible | Significant | Medium | M5, M6, M7, M17 |
| P3 | Parent in mental health crisis does not receive appropriate signposting to emergency services | Remote | Severe | High | M15, M16, M18 |
| P4 | Parent's data is used by Azure OpenAI for model training without consent | Remote | Significant | Medium | M19, M20 |
| P5 | Parent cannot effectively exercise right to erasure due to data existing across multiple systems (DB, backups, Redis) | Remote | Significant | Low | M10, M11, M21 |
| P6 | Parent is re-traumatised by insensitive AI responses | Possible | Significant | Medium | M22, M23 |
| P7 | Admin user accesses parent conversations without legitimate purpose | Possible | Significant | Medium | M24, M25 |
5.4 Risks to schools and education professionals
| # | Risk | Likelihood | Severity | Overall | Mitigation (see Step 6) |
|---|---|---|---|---|---|
| S1 | School staff member named in child profile has their data processed without their knowledge | Probable | Minimal | Low | M26 |
| S2 | Teacher/SENCO's conversation content about a pupil is accessed by a parent (cross-user data leak) | Remote | Significant | Medium | M1, M2, M3 |
| S3 | AI provides incorrect information about a school's SEND provision based on outdated crawled data | Possible | Minimal | Low | M27, M28 |
5.5 AI-specific risks
| # | Risk | Likelihood | Severity | Overall | Mitigation (see Step 6) |
|---|---|---|---|---|---|
| A1 | Prompt injection via crawled content causes AI to generate harmful or misleading responses | Possible | Significant | High | M29, M30 |
| A2 | AI hallucination produces fabricated legal references or procedures that parent acts upon | Possible | Significant | High | M5, M6, M7 |
| A3 | Bias in the AI model leads to systematically different quality of advice for certain SEND categories | Remote | Significant | Medium | M31, M32 |
| A4 | AI system develops over-reliance, discouraging parents from seeking professional human advice | Possible | Significant | Medium | M17, M33 |
| A5 | LLM-extracted child memories create an inferred profile beyond what the parent explicitly consented to | Possible | Significant | Medium | M13, M14, M34 |
5.6 Infrastructure and security risks
| # | Risk | Likelihood | Severity | Overall | Mitigation (see Step 6) |
|---|---|---|---|---|---|
| I1 | Database breach exposes all user and child data | Remote | Severe | High | M1, M2, M3, M4, M35 |
| I2 | Backup files containing personal data are accessed by unauthorised party | Remote | Severe | Medium | M36, M37 |
| I3 | Redis cache leaks session data or WebSocket state | Remote | Minimal | Low | M38 |
| I4 | Kubernetes cluster compromise provides access to all services and secrets | Remote | Severe | High | M39, M40, M41 |
| I5 | Sub-processor (Civo, Microsoft, Resend) data breach affects SpektraBot users | Remote | Severe | Medium | M42, M43 |
Step 6: Identify Measures to Mitigate Risk
6.1 Security measures (technical)
| ID | Measure | Risks addressed | Status |
|---|---|---|---|
| M1 | User data isolation -- Every database query includes userId filter; enforced at service layer. WebSocket connections join user-specific rooms. Conversation access verified before any read/write. | C1, P1, S2, I1 | Implemented |
| M2 | JWT authentication with role-based access control (parent, teacher_senco, admin). Token-based auth for all API and WebSocket connections. | C1, P1, S2 | Implemented |
| M3 | TLS encryption in transit -- All connections use HTTPS/WSS via Let's Encrypt certificates. SSL redirect enforced at ingress. | C1, P1, S2, I1 | Implemented |
| M4 | Encryption at rest -- PostgreSQL on Civo block storage (civo-volume) provides volume-level encryption. Backups encrypted in Civo Object Storage. | C1, I1 | Implemented |
| M12 | Security headers -- Helmet middleware applies security headers (CSP, HSTS, X-Frame-Options, etc.). CORS restricted to specific origins. | C1 | Implemented |
| M35 | Network security -- Kubernetes NetworkPolicy restricts pod-to-pod communication: ingress-nginx → web/api only; api → postgres/redis only; postgres ← backup CronJob only; deny all other intra-cluster traffic. Egress limited to Azure OpenAI, GIAS API, Resend, and DNS. Pods run as non-root (UID 1000) with dropped capabilities. No privilege escalation. | I1 | Implemented |
| M36 | Backup encryption -- Database backups stored in Civo Object Storage with S3-compatible encryption. Backup integrity verified (rejects files < 1MB, verified with pg_restore --list). | I2 | Implemented |
| M37 | Backup access control -- S3 credentials stored as Kubernetes secrets. Bucket access restricted to service account. | I2 | Implemented |
| M38 | Redis security -- Redis used for ephemeral cache only (session state, WebSocket pub/sub). No personal data persisted in Redis. Redis accessible only within cluster network. | I3 | Implemented |
| M39 | Kubernetes security context -- All pods run as non-root, all capabilities dropped, no privilege escalation allowed. | I4 | Implemented |
| M40 | Secrets management -- All credentials stored as Kubernetes secrets (not in Helm values or source code). External secrets management. | I4 | Implemented |
| M41 | Image security -- Private GHCR registry with imagePullSecrets. Commit-SHA image tags (mutable tags like 'latest' are blocked by Helm guard). | I4 | Implemented |
6.2 AI and data quality measures
| ID | Measure | Risks addressed | Status |
|---|---|---|---|
| M5 | Self-correcting RAG pipeline -- LangGraph state machine with hallucination checking and answer quality grading. Responses verified as grounded in retrieved documents. | C2, P2, A2 | Implemented |
| M6 | Source citations -- Every AI response includes citations to the specific knowledge base documents used, enabling users to verify information independently. | C2, P2, A2 | Implemented |
| M7 | Maximum retry limits -- Self-correction loop limited to 3 retries to prevent infinite loops and ensure response quality. | C2, P2, A2 | Implemented |
| M17 | Disclaimer and limitations -- AI responses include clear disclaimers that SpektraBot provides information, not legal advice. Users directed to SENDIASS, IPSEA, and professional advocates for legal matters. | P2, A4 | Implemented |
| M29 | Knowledge base validation workflow -- All crawled and uploaded content goes through admin validation (pending/approved/rejected/flagged) before being used in RAG retrieval. | A1 | Implemented |
| M30 | Prompt injection defence -- Multi-layer approach: (1) Crawler domain whitelisting restricts sources to known LA/charity sites. (2) Content sanitisation strips HTML, scripts, and suspicious patterns during crawl ingestion. (3) Admin validation gate — all crawled content requires admin approval before entering RAG retrieval. (4) System prompt security markers detect attempts to override instructions. (5) Retrieved KB chunks are presented as quoted context, not as system instructions. | A1 | Implemented |
| M31 | Evaluation test suite -- 74-case evaluation suite testing response quality across SEND categories, including trauma-informed grading. | A3 | Implemented |
| M32 | LA coverage monitoring -- Admin dashboard tracks knowledge base coverage across all 152 English LAs. Gaps identified and addressed through targeted crawling. | A3 | Implemented |
| M33 | Help system and onboarding -- Welcome wizard and help drawer include links to SENDIASS, IPSEA, and Spectrum Dynamics for human support. Explicit statement that SpektraBot is an AI tool, not a replacement for professional advice. | A4 | Implemented |
6.3 Children's data protection measures
| ID | Measure | Risks addressed | Status |
|---|---|---|---|
| M8 | Child PII not sent to LLM -- Azure OpenAI receives only user message text and public knowledge base documents. Structured child profile data (name, DOB, diagnosis) is NOT included in the LLM prompt. | C3 | Implemented |
| M9 | No child accounts -- Children do not have user accounts. All child data is managed by the parent/carer account holder. Children do not directly interact with the system. | C3 | Implemented |
| M13 | Memory confidence scoring -- LLM-extracted child memories include a confidence score (0.0-1.0). Low-confidence memories can be identified and reviewed. | C5, A5 | Implemented |
| M14 | Memory source tracking -- Each extracted memory links back to the source conversation and message, enabling audit and correction. | C5, A5 | Implemented |
| M34 | Memory deduplication -- SHA-256 content hashing prevents duplicate memories. Superseded memories are marked inactive rather than deleted (audit trail). | A5 | Implemented |
| M26 | Third-party names -- SENCO and key worker names entered by parents are stored in child profiles only. These names are processed under legitimate interest (Art. 6(1)(f)) — the purpose is to personalise AI guidance (e.g., "speak to your SENCO, Mrs Smith"). LIA conclusion: Processing is minimal (name only, no contact details), proportionate (aids parent communication), and low-risk (names are already known to the parent). No separate consent required. Names are deleted when the child profile is deleted (cascade). Staff members have no account, no direct processing, and no profiling. If a named individual requests erasure under Art. 17, their name is removed from the child profile field. | S1 | Addressed |
6.4 Data subject rights measures
| ID | Measure | Risks addressed | Status |
|---|---|---|---|
| M10 | Tiered automated retention -- Conversations deleted 90 days after last activity (updatedAt) via daily CronJob. Child memories persist for account lifetime (soft-deleted memories hard-deleted after 30-day grace). Safeguarding records retained indefinitely. Configurable via DATA_RETENTION_DAYS environment variable. See Data Retention Policy. | C4, P5 | Implemented |
| M11 | Right to erasure -- Users can request account deletion. Cascade deletion removes all associated data (children, conversations, messages, memories, documents, feedback). Soft delete with deletedAt timestamp. | C4, P5 | Implemented |
| M21 | Backup erasure procedure -- Database backups are stored in Civo Object Storage with a 30-day S3 lifecycle policy. When a user exercises their right to erasure, data is deleted immediately from the live database. Backup copies naturally expire within 30 days. The ICO accepts that granular erasure from encrypted backup archives is technically disproportionate where backups have a defined, short retention period and are not used for any purpose other than disaster recovery. If a backup is restored, the data retention CronJob will re-delete any data that was erased from the live database (since the erasure itself is recorded). Privacy notice informs users that backup copies may persist for up to 30 days. | P5 | Implemented |
| M24 | Audit logging -- 30+ action types tracked in audit logs including admin access to user data. All admin actions logged with user ID, action type, resource, IP address, and user agent. | P7 | Implemented |
| M25 | Role-based access control -- Admin routes gated by role middleware. Non-admin users cannot access other users' data. | P7 | Implemented |
6.5 Crisis and safeguarding measures
| ID | Measure | Risks addressed | Status |
|---|---|---|---|
| M15 | Crisis detection system -- Automated detection of crisis indicators in user messages. Crisis module overrides normal AI response with signposting to emergency services (Samaritans, Childline, 999). | C6, P3 | Implemented |
| M16 | Safeguarding logging -- Safeguarding concerns are logged in safeguarding_logs table with dedicated audit trail. | C6, P3 | Implemented |
| M18 | Distress detection -- Separate from crisis detection, the system detects emotional distress and adjusts AI responses to be more empathetic, slower-paced, and focused on immediate needs. | P3 | Implemented |
| M22 | Trauma-informed design -- All AI responses follow trauma-informed practice: validate emotions first, never blame or lecture, empower rather than prescribe, normalise the experience, respect autonomy. | P6 | Implemented |
| M23 | Banned language patterns -- System prompt enforces a strict set of prohibited phrases ("you should", "unfortunately", "obviously", "just do this") that could re-traumatise vulnerable users. Automated grading checks for compliance. | P6 | Implemented |
6.6 Sub-processor and transfer measures
| ID | Measure | Risks addressed | Status |
|---|---|---|---|
| M19 | Azure OpenAI data handling -- Microsoft's Azure OpenAI service does not use customer data for model training (per Azure OpenAI terms). Data processed in UK South region. | P4 | Implemented (by contract) |
| M20 | Data Processing Agreements -- DPAs in place with all sub-processors processing personal data. Microsoft: Online Services DPA (automatic). Civo: standard DPA (signed with service agreement). Resend: DPA signed separately. DPAs filed in compliance records and reviewed at each DPIA review. | P4, I5 | Implemented |
| M42 | Sub-processor monitoring -- Annual review of sub-processor compliance, aligned with DPIA review schedule (Appendix E). Review covers: DPA currency, security certifications (SOC 2, ISO 27001), data processing locations, breach history, and terms changes. Any material change triggers an interim DPIA review. | I5 | Implemented |
| M43 | Incident response and breach notification -- Breach notification procedure: (1) Contain and assess within 4 hours of detection. (2) Record breach in internal register regardless of severity. (3) If risk to data subjects: notify ICO within 72 hours via the ICO's online breach reporting tool. (4) If high risk to data subjects: notify affected individuals without undue delay, in plain English, explaining what data was affected, what we are doing, and what they should do. (5) For children's data breaches: also notify the parent/carer account holder and the relevant pilot school DPO. (6) Post-incident review within 14 days; update DPIA if systemic. PagerDuty alerts configured for automated breach detection (API/DB/backup failures). | I5 | Implemented |
6.7 Organisational measures
| ID | Measure | Risks addressed | Status |
|---|---|---|---|
| M27 | Knowledge base currency -- Automated crawler re-crawls LA Local Offers on admin-triggered schedule. Content hashing detects changes. Old content can be removed. | S3 | Implemented |
| M28 | Admin validation workflow -- All content must be approved by an administrator before being used in RAG retrieval. Rejected content is excluded. | S3, A1 | Implemented |
Step 7: Sign Off and Record Outcomes
7.1 Summary of residual risks
After applying the mitigations in Step 6, the following residual risks remain:
| Risk ID | Description | Residual risk level | Accepted? | Rationale |
|---|---|---|---|---|
| C1 | Child data breach | Medium (reduced from High) | Accepted | User isolation, encryption at rest, TLS in transit, JWT auth, RBAC, and audit logging reduce likelihood to Possible/Remote. Residual risk is proportionate to the service benefit. Reviewed annually. |
| C6 | Safeguarding concern not escalated | Medium (reduced from High) | Accepted with condition | Crisis detection is automated but not infallible. Condition: SpektraBot is not a substitute for school safeguarding procedures. Privacy notice and onboarding make clear that users should contact emergency services directly for immediate safety concerns. |
| P1 | Conversation data breach | Medium (reduced from High) | Accepted | Same security controls as C1. 90-day conversation retention limits the exposure window. |
| P3 | Crisis user not signposted | Low (reduced from High) | Accepted | Dual-layer detection (crisis + distress) with hardcoded signposting to Samaritans, Childline, 999. System is a supplement to, not replacement for, human crisis support. |
| A1 | Prompt injection via crawled content | Medium (remains High) | Accepted with condition | Admin validation of all crawled content before RAG inclusion. Domain whitelisting restricts crawl targets to known LA/charity sites. Condition: Content sanitisation (HTML stripping, script removal, chunk size limits) applied before embedding and before LLM context injection. |
| A2 | AI hallucination | Medium (reduced from High) | Accepted | Self-correcting RAG with hallucination grading, source citations for independent verification, clear disclaimers that output is informational not legal advice. Residual risk inherent in all LLM systems; mitigations reduce practical impact. |
| I1 | Database breach | Low (reduced from High) | Accepted | Encryption at rest, TLS in transit, Kubernetes network isolation, non-root pods, secrets management, audit logging. No public database endpoint. |
| I4 | Kubernetes cluster compromise | Low (reduced from High) | Accepted | Non-root containers, all capabilities dropped, no privilege escalation, GHCR private registry with imagePullSecrets, commit-SHA image tags, RBAC. Civo manages control plane security. |
7.2 Actions required before processing can commence
| # | Action | Owner | Deadline | Status |
|---|---|---|---|---|
| 1 | Sign DPA with Microsoft (Azure OpenAI) | Technical Lead | Before pilot launch | Complete — Microsoft Online Services DPA applies automatically to all Azure services |
| 2 | Sign DPA with Civo Ltd | Technical Lead | Before pilot launch | Complete — Civo standard DPA signed with service agreement |
| 3 | Sign DPA with Resend | Technical Lead | Before pilot launch | Complete — Resend DPA signed separately |
| 4 | Complete ICO registration | [SIGN-OFF REQUIRED] | Before pilot launch | [SIGN-OFF REQUIRED] |
| 5 | Define and implement audit log retention period | Technical Lead | Before pilot launch | Complete — 2-year retention, automated CronJob deletion. Denormalised email preserved in log entries so records remain interpretable after user account deletion. |
| 6 | Define safeguarding log retention period | Indefinite — statutory requirement (Children Act 2004 s.11, KCSIE 2024). Excluded from automated deletion. | Defined in Data Retention Policy | Complete |
| 7 | Document breach notification procedure (72-hour ICO notification) | Technical Lead | Before pilot launch | Complete — documented in M43. Procedure: contain (4h), register, notify ICO (72h), notify affected individuals (without undue delay), school DPO notification for children's data, 14-day post-incident review. |
| 8 | Implement content sanitisation for crawled KB content before LLM injection | Technical Lead | Before pilot launch | Implemented — crawler strips HTML tags, scripts, and style blocks during text extraction. Chunks are plain text only. Domain whitelisting restricts crawl targets to known LA/charity sites. Admin validation required before content enters RAG retrieval. |
| 9 | Enable Kubernetes NetworkPolicy | Technical Lead | Before pilot launch | Implemented — NetworkPolicy rules: ingress-nginx → web (3000) and api (3001); api → postgres (5432) and redis (6379); postgres ← backup CronJob; deny all other pod-to-pod traffic. Egress restricted to Azure OpenAI, GIAS API, Resend, and DNS. |
| 10 | Conduct legitimate interest assessment for named school staff in child profiles | Technical Lead | Before pilot launch | Complete — LIA conclusion in M26: processing is minimal (name only), proportionate (aids parent-school communication), and low-risk. No separate consent required. Erasure available on request (Art. 17). |
| 11 | Obtain and document data subject views (parent consultation) | Product Owner | Before pilot launch | Process defined in Section 3.3. Pre-pilot information sessions, registration consent flow, in-app feedback, termly surveys. [SIGN-OFF REQUIRED: Record consultation dates and outcomes.] |
| 12 | Consult pilot school DPOs | Product Owner | Before each school onboarding | Process defined — each school DPO receives DPIA, privacy notice, and data sharing arrangement for review before onboarding. [SIGN-OFF REQUIRED: Record consultation dates and DPO responses.] |
| 13 | Publish privacy notice referencing this DPIA | Technical Lead | Before pilot launch | Complete — privacy notice published at /policies/privacy. References tiered retention policy and DPIA. Updated to describe all data categories, retention tiers, and data subject rights. |
| 14 | Document backup erasure procedure | Technical Lead | Before pilot launch | Complete — documented in M21. 30-day S3 lifecycle policy provides natural expiry. If backup is restored, data retention CronJob re-deletes previously erased data. Privacy notice informs users of up to 30-day backup persistence. |
| 15 | Establish sub-processor review schedule | Technical Lead | Before pilot launch | Complete — annual review aligned with DPIA review schedule (Appendix E). Covers DPA currency, security certifications, data processing locations, breach history, and terms changes. |
7.3 Decision
Recommendation: Processing should proceed with conditions. All technical and organisational mitigations identified in Step 6 are implemented or in progress. Residual risks are at acceptable levels (Low–Medium) and proportionate to the significant benefit the service provides to vulnerable families navigating the SEND system.
| Decision | Proceed with conditions |
| Conditions | (1) ICO registration completed before pilot launch. (2) Pilot school DPO consultations completed before each school is onboarded. (3) Parent consultation sessions held before onboarding families. (4) DPIA reviewed annually and after any material change to processing. |
| Date | [SIGN-OFF REQUIRED] |
| Decision maker | [SIGN-OFF REQUIRED] |
| Role | [SIGN-OFF REQUIRED] |
7.4 DPO advice
The DPO should review this completed DPIA and provide formal advice on whether processing should proceed.
| DPO name | [SIGN-OFF REQUIRED] |
| DPO advice | [SIGN-OFF REQUIRED] |
| Date | [SIGN-OFF REQUIRED] |
7.5 Sign-off
| Role | Name | Signature | Date |
|---|---|---|---|
| Data Controller representative | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] |
| Data Protection Officer | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] |
| Technical Lead | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] |
| Product Owner | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] |
Appendix A: Automated Decision-Making Assessment
Does SpektraBot make automated decisions with legal or significant effects?
UK GDPR Article 22 restricts solely automated decision-making that produces legal effects or similarly significantly affects individuals.
Assessment:
SpektraBot's AI generates informational guidance, not decisions. The system:
- Does NOT determine a child's EHCP eligibility
- Does NOT approve or reject educational provision
- Does NOT make referrals to local authority services on behalf of users
- Does NOT replace professional legal or educational advice
However, the guidance provided may significantly influence parents' decisions about:
- Whether to request an EHCP assessment
- Whether to appeal a decision to the SEND Tribunal
- What provision to request in an EHCP annual review
- Whether to make a formal complaint about a school
Conclusion: SpektraBot does not fall within Article 22's scope as it does not make automated decisions with legal effects. However, given the potential influence of its guidance on consequential decisions, the following safeguards are maintained:
- Clear disclaimers that outputs are informational, not legal advice
- Source citations enabling independent verification
- Signposting to SENDIASS, IPSEA, and professional advocates
- Human-in-the-loop for all consequential actions (parent must act on guidance independently)
- Self-correcting RAG pipeline with hallucination checking
Appendix B: International Data Transfer Assessment
Transfer Impact Assessment (TIA)
| # | Question | Answer |
|---|---|---|
| 1 | Is personal data transferred outside the UK? | No, by design. All primary data storage is on Civo Kubernetes in London (LON1). |
| 2 | Is personal data processed outside the UK? | Partially. Azure OpenAI is configured to use UK South (London) region. Conversation text is processed by Microsoft's UK South infrastructure. Microsoft's Azure OpenAI service documentation confirms that data is processed in the selected region and is not moved to other regions for inference. Microsoft may sub-process for abuse monitoring, but this is governed by the DPA and does not involve data storage outside the processing region. Resend (email delivery) processes email addresses via US-based infrastructure, covered by the UK-US Data Bridge adequacy framework. |
| 3 | What personal data is transferred? | User message text and conversation history (last 5 messages) are sent to Azure OpenAI for LLM inference. Knowledge base document text is sent for embedding generation. |
| 4 | Is there an adequacy decision? | N/A -- processing is within the UK. If Microsoft sub-processes to EEA, the UK Extension to the EU-US Data Privacy Framework may apply. |
| 5 | What transfer mechanism is used? | Standard Contractual Clauses (SCCs) are included in Microsoft's DPA as a fallback mechanism. |
| 6 | Are supplementary measures needed? | Not for UK South processing. If any sub-processing occurs outside the UK, supplementary measures should be assessed. |
Azure OpenAI data handling
| Aspect | Detail |
|---|---|
| Processing location | UK South (London) -- spektrabot-openai.cognitiveservices.azure.com |
| Model training | Microsoft states customer data is NOT used for training Azure OpenAI models |
| Data retention by Microsoft | Azure OpenAI does not store prompt/completion data beyond the API request lifecycle (per Azure OpenAI terms) |
| Abuse monitoring | Microsoft may process data for abuse monitoring; can be opted out for approved use cases |
| Encryption | Data encrypted in transit (TLS 1.2+) and at rest within Azure |
Abuse monitoring: Azure OpenAI abuse monitoring is enabled by default. Microsoft processes prompts and completions ephemerally for abuse detection but does not store them beyond the request lifecycle. For approved Azure OpenAI customers, abuse monitoring can be disabled via a request form — this is not currently applied as the default monitoring terms are acceptable (no storage, no training). Microsoft's DPA (Online Services Data Protection Addendum) governs all processing, including abuse monitoring. The DPA includes Standard Contractual Clauses as a fallback transfer mechanism.
Appendix C: Children's Data - Additional Considerations
ICO Children's Code (Age Appropriate Design Code) Compliance
Although SpektraBot is designed for parents and education professionals (not direct use by children), the following considerations apply because the system processes children's data:
| Standard | Applicability | How met |
|---|---|---|
| Best interests of the child | Yes -- all processing should be in the child's best interest | System purpose is to help parents secure appropriate SEND provision for their child |
| Data protection impact assessment | Yes | This document |
| Age-appropriate application | Partial -- children do not use the system directly, but their data is processed | System designed for adult users only; no child accounts; no gamification or attention-capture design |
| Transparency | Yes -- parents should understand what happens to their child's data | Privacy notice explains child data processing; GDPR consent collected at registration |
| Detrimental use of data | Yes -- child data must not be used in ways detrimental to the child | Data used solely to provide SEND guidance beneficial to the child |
| Data minimisation | Yes | Only data necessary for personalised SEND guidance is collected (see Step 4) |
| Data sharing | Yes -- limits on sharing child data | Child data not shared with third parties. Child PII not sent to LLM. |
| Geolocation | N/A | No geolocation data collected |
| Parental controls | Yes -- parents control their child's data | Parents create, edit, and delete child profiles. No autonomous child data collection. |
| Profiling | Yes -- limits on profiling children | Child memories extracted by AI constitute a form of profiling. Mitigated by source tracking, confidence scoring, and parent ability to view/delete memories. |
| Nudge techniques | N/A | System does not use nudge techniques on children |
| Connected toys and devices | N/A | Not applicable |
| Online tools | Yes | Accessibility features (WCAG 2.2, configurable font/contrast/motion) support parents with disabilities accessing their child's data |
Parental responsibility
SpektraBot processes children's data based on the parent/carer's consent. The system assumes:
- The registering adult has parental responsibility for the child(ren) whose data they enter
- Where there are multiple adults with parental responsibility, the registering adult has authority to consent on behalf of the child
Parental responsibility declaration: The registration flow includes a checkbox confirming: "I have parental responsibility for the child(ren) whose data I will enter, or I have the consent of all persons with parental responsibility to do so." This is stored as part of the GDPR consent record (JSONB with version, timestamp, IP address).
Dispute scenarios: If a dispute arises (e.g., separated parents with shared custody), the policy is:
- Either parent with parental responsibility may create a profile for their child.
- If one parent requests deletion of a child profile created by another parent, the request is referred to the Data Controller for manual review — automated deletion is not appropriate where parental responsibility is shared.
- The system does not arbitrate custody disputes. If both parents create separate accounts, each account's data is isolated and neither parent can see the other's conversations or memories.
Appendix D: Glossary
| Term | Definition |
|---|---|
| SEND | Special Educational Needs and Disabilities |
| EHCP | Education, Health and Care Plan -- a legal document describing a child's special educational needs and the provision to meet them |
| SENCO | Special Educational Needs Coordinator -- the teacher responsible for SEND in a school |
| SENDIASS | Special Educational Needs and Disabilities Information, Advice and Support Service -- free, impartial advice service for parents |
| IPSEA | Independent Provider of Special Education Advice -- charity providing free legal advice on SEND |
| LA | Local Authority -- the council responsible for education in an area |
| GIAS | Get Information About Schools -- DfE database of all schools in England |
| RAG | Retrieval-Augmented Generation -- AI technique that retrieves relevant documents before generating a response |
| LLM | Large Language Model -- the AI model (GPT-4.1) that generates responses |
| pgvector | PostgreSQL extension for vector similarity search |
| ICO | Information Commissioner's Office -- UK data protection regulator |
| DPA | Data Processing Agreement -- contract between data controller and processor |
| DPO | Data Protection Officer |
| TLS | Transport Layer Security -- encryption protocol for data in transit |
| JWT | JSON Web Token -- authentication mechanism |
| RBAC | Role-Based Access Control |
Appendix E: Review Schedule
This DPIA must be reviewed:
- At least annually from the date of sign-off
- When there is a significant change to the processing, including:
- New data categories collected
- New sub-processors engaged
- Changes to the AI model or RAG pipeline
- Expansion to new user groups or geographies
- Security incidents
- Changes to UK GDPR or ICO guidance
- Before each new school onboarding (abbreviated review confirming no material changes)
| Review # | Date | Reviewer | Changes made | Next review due |
|---|---|---|---|---|
| 1 | [SIGN-OFF REQUIRED] | [SIGN-OFF REQUIRED] | Initial DPIA | [SIGN-OFF REQUIRED: +12 months from sign-off date] |
This DPIA follows the structure recommended by the ICO in its DPIA guidance (https://ico.org.uk/for-organisations/guide-to-data-protection/guide-to-the-general-data-protection-regulation-gdpr/data-protection-impact-assessments-dpias/). It should be read in conjunction with SpektraBot's Privacy Policy, Terms of Service, and Data Processing Agreements.