SpektraBot GDPR Controls — Comp AI Mapping

Pre-written control descriptions ready to input into the Comp AI GDPR compliance framework. Each control maps a GDPR article requirement to SpektraBot's concrete implementation with evidence references to the source code.

How to use: After setting up Comp AI, select the GDPR framework for your organization. For each control category below, create the corresponding control in Comp AI and paste the description and evidence references.

1.1 Lawfulness, Fairness, and Transparency (Art. 5(1)(a))

Status: Implemented

Description: SpektraBot processes personal data lawfully under explicit consent (GDPR Art. 6(1)(a)). All users must provide informed GDPR consent during registration before any data processing occurs. A consent middleware enforces this at the API level — requests from users without recorded consent are rejected with a 403 response.

The privacy policy is publicly accessible and linked during registration, explaining in plain language what data is collected, why, and how it is processed. SpektraBot is registered with the UK Information Commissioner's Office (ICO).

Evidence:

GDPR consent middleware: packages/api/src/middleware/gdpr.ts
User consent field in schema: packages/api/prisma/schema.prisma (User.gdprConsent)
Registration with consent checkbox: packages/web/src/app/register/page.tsx
Privacy policy: packages/web/src/app/policies/privacy/page.tsx
Terms of service: packages/web/src/app/policies/terms/page.tsx
ICO registration: [ICO registration number on file]

1.2 Purpose Limitation (Art. 5(1)(b))

Status: Implemented

Description: Personal data is collected and processed solely for providing SEND (Special Educational Needs and Disabilities) guidance to parents, carers, teachers, and SENCOs. Data is not used for secondary purposes such as advertising, profiling, or sale to third parties. Conversation data is used exclusively to provide contextual AI responses within the user's own session. Analytics are collected via privacy-focused Umami (self-hosted, no cookies, no PII tracking).

Evidence:

Chat service (sole data processor): packages/api/src/chat/service.ts
Privacy policy (purpose declaration): packages/web/src/app/policies/privacy/page.tsx
Umami analytics (no PII): Self-hosted on Civo K8s, no third-party data sharing

1.3 Data Minimisation (Art. 5(1)(c))

Status: Implemented

Description: SpektraBot collects only the minimum data necessary to provide the service:

Required: Name, email, role (parent/teacher/SENCO/admin), school affiliation
Optional: Children's year groups and SEND needs (for personalised guidance)
Not collected: Physical addresses, phone numbers, financial data, photographs

No unnecessary PII is requested. Children's information is limited to educational context (year group, SEND category) with no direct identifiers stored.

Evidence:

User model (minimal fields): packages/api/prisma/schema.prisma (User model)
Children model (no direct identifiers): packages/api/prisma/schema.prisma (Child model)
Registration form (minimal fields): packages/web/src/app/register/page.tsx

1.4 Accuracy (Art. 5(1)(d))

Status: Implemented

Description: Users can update their profile data (name, email, role, school) at any time through the application settings. Administrators can correct user records via the admin panel. School data is synchronised from the DfE GIAS (Get Information About Schools) database to ensure institutional data accuracy.

Evidence:

User profile editing: packages/web/src/app/settings/page.tsx
Admin user management: packages/web/src/app/admin/users/page.tsx
Admin update routes: packages/api/src/admin/routes.ts
GIAS sync service: packages/api/src/services/gias-sync.service.ts

1.5 Storage Limitation (Art. 5(1)(e))

Status: Implemented

Description: SpektraBot implements a tiered data retention policy aligned with ICO Children's Code Standard 8, which requires differentiation by service element:

Tier 1 — Chat conversations: Automatically deleted 90 days after last activity (updatedAt, not createdAt), enforced by a Kubernetes CronJob running daily. Messages cascade-delete via FK. ChildMemory sourceConversationId is set to NULL (not cascade-deleted), preserving extracted facts after conversation removal.
Tier 2 — Child support memories: Retained for account lifetime (closure or 12-month dormancy). Soft-deleted memories are hard-deleted after a 30-day grace period.
Tier 3 — User profiles and accounts: Retained until user requests deletion or 12 months of account dormancy. Dormancy triggers a 30-day warning email before deletion.
Tier 4 — Safeguarding records: Retained indefinitely (statutory requirement under Children Act 2004 s.11 and KCSIE 2024).

Database backups are retained for 30 days via S3 lifecycle policy. When data is deleted from the live database, it persists in backups until the containing backup expires.

Evidence:

Tiered retention policy: docs/compliance/data-retention.md
Retention CronJob: helm/spektrabot/templates/cronjob-data-retention.yaml
Retention configuration: packages/api/src/config/index.ts (DATA_RETENTION_DAYS)
Schema FK behaviour: packages/api/prisma/schema.prisma (ChildMemory onDelete: SetNull)
Batch deletion logic: packages/api/src/admin/service.ts

1.6 Integrity and Confidentiality (Art. 5(1)(f))

Status: Implemented

Description: All data in transit is encrypted via TLS 1.3, managed by cert-manager with Let's Encrypt certificates on the Kubernetes ingress. Data at rest is encrypted via Civo block storage encryption (AES-256). The PostgreSQL database runs within the Kubernetes cluster with no public network exposure. All infrastructure is hosted in Civo's LON1 (London) region, ensuring UK data residency.

Evidence:

TLS configuration: helm/spektrabot/values.yaml (ingress TLS settings)
cert-manager ClusterIssuer: Kubernetes resource for automated TLS certificates
Database internal service: helm/spektrabot/templates/ (no external ports)
Civo LON1 deployment: Cluster configuration (UK data residency)

2.1 Right of Access (Art. 15)

Status: Implemented

Description: Administrators can export a complete copy of any user's data in JSON format via the admin panel. The export includes profile information, conversation history, children's records, consent records, and audit logs. Users can request their data by contacting the data controller, who processes the request via the admin interface.

Evidence:

Admin data export route: packages/api/src/admin/routes.ts (GET /api/admin/users/:id)
Admin user detail view: packages/web/src/app/admin/users/page.tsx

2.2 Right to Rectification (Art. 16)

Status: Implemented

Description: Users can directly edit their profile information (name, email, role, school) through the application settings page. Administrators can update any user's records via the admin panel. Changes are reflected immediately and logged in the audit trail.

Evidence:

User settings page: packages/web/src/app/settings/page.tsx
Admin user editing: packages/api/src/admin/routes.ts (PATCH /api/admin/users/:id)
Auth service profile update: packages/api/src/auth/service.ts

2.3 Right to Erasure (Art. 17)

Status: Implemented

Description: User deletion is available through the admin panel. When a user is deleted, all associated data is cascade-deleted: conversations, messages, children records, consent records, binder items, reminders, and notifications. Audit log entries are preserved but anonymised (actor reference retained as ID only, personal data removed) to maintain system integrity records. Users can request deletion by contacting the data controller.

Evidence:

Delete user function: packages/api/src/admin/service.ts (deleteUser)
Delete user route: packages/api/src/admin/routes.ts (DELETE /api/admin/users/:id)
Cascade deletion: packages/api/prisma/schema.prisma (onDelete: Cascade relations)

2.4 Right to Restrict Processing (Art. 18)

Status: Partially Implemented

Description: Administrators can deactivate user accounts, which prevents login and all data processing for that user. While the account is deactivated, no new data is collected or processed. The user's existing data is preserved but not actively used. Full restriction granularity (e.g., restricting specific processing operations while allowing others) is not yet implemented.

Evidence:

User status management: packages/api/src/admin/service.ts
Auth service (login prevention): packages/api/src/auth/service.ts

2.5 Right to Data Portability (Art. 20)

Status: Implemented

Description: User data can be exported in JSON format, a structured, commonly used, and machine-readable format. The export includes all personal data and associated records. Administrators process portability requests via the admin panel.

Evidence:

Data export endpoint: packages/api/src/admin/routes.ts
JSON export format: Standard JSON with nested objects for related records

2.6 Right to Object (Art. 21)

Status: Implemented

Description: Users can object to analytics processing. SpektraBot uses Umami, a privacy-focused analytics platform that respects the Do Not Track (DNT) browser header. Users with DNT enabled are automatically excluded from analytics. No cookies are used for tracking. Users can also request account deletion to cease all processing.

Evidence:

Umami analytics integration: packages/web/src/app/layout.tsx (Umami script tag)
DNT respect: Umami built-in feature (automatic)
No cookie tracking: Umami configuration (cookieless mode)

3.1 Encryption

Status: Implemented

Control Description:

In transit: TLS 1.3 via cert-manager with Let's Encrypt certificates. All HTTP traffic is redirected to HTTPS at the ingress level.
At rest: Civo block storage provides AES-256 encryption for all persistent volumes including the PostgreSQL database.
Authentication tokens: JWT tokens stored in httpOnly, secure, SameSite=strict cookies. No tokens in localStorage or sessionStorage.

Evidence:

TLS/Ingress: helm/spektrabot/values.yaml (ingress.tls configuration)
Cookie security: packages/api/src/auth/service.ts (cookie options)

3.2 Access Control

Status: Implemented

Control Description: Role-based access control (RBAC) with four roles:

Admin: Full system access including user management, data export, deletion
Teacher: Access to own conversations, student-relevant features
Parent/Carer: Access to own conversations and children's records only
SENCO: Access to own conversations with specialist SEND features

Authentication uses JWT with httpOnly cookies. Admin routes are protected by role verification middleware. All API endpoints require authentication.

Evidence:

Role definitions: packages/api/prisma/schema.prisma (Role enum)
Auth middleware: packages/api/src/middleware/auth.ts
Admin route protection: packages/api/src/admin/routes.ts (requireAdmin middleware)
GDPR consent middleware: packages/api/src/middleware/gdpr.ts

3.3 Audit Logging

Status: Implemented

Control Description: All administrative actions are logged in an immutable audit trail. Each log entry records:

Actor (admin user ID)
Action performed (create, update, delete, export)
Target entity and ID
Timestamp (UTC)
Additional metadata (IP address where available)

Audit logs are preserved even when users are deleted (anonymised entries).

Evidence:

AuditLog model: packages/api/prisma/schema.prisma (AuditLog model)
Admin service logging: packages/api/src/admin/service.ts (audit log creation)
Audit log query routes: packages/api/src/admin/routes.ts

3.4 Data Residency

Status: Implemented

Control Description: All personal data is stored within the United Kingdom:

Compute: Civo Kubernetes cluster in LON1 (London) region
Database: PostgreSQL running on Civo LON1 block storage
Backups: Civo Object Storage in LON1 region (S3-compatible)

The AI engine (Azure OpenAI GPT-4.1) operates within the United Kingdom (UK South region), ensuring full UK data residency for all processing. Azure OpenAI does not retain user prompts or responses after processing.

Evidence:

Cluster configuration: Civo dashboard (LON1 region)
Backup storage: helm/spektrabot/ (S3 backup configuration pointing to Civo LON1)
Azure OpenAI DPA: On file (UK data processing, UK South region)

3.5 Incident Response and Business Continuity

Status: Implemented

Control Description:

Automated monitoring: Kubernetes health checks with automatic pod restart on failure
Backup schedule: PostgreSQL backups every 6 hours to Civo S3 Object Storage
Backup integrity: Automated verification (size check, pg_restore validation)
Recovery procedure: Documented restore process from backup
Alerting: Health endpoint with memory and connection status reporting

Evidence:

Health checks: helm/spektrabot/values.yaml (liveness/readiness probes)
Backup CronJob: Kubernetes CronJob manifest in helm/spektrabot/
Health endpoint: packages/api/src/admin/routes.ts (GET /api/health)

3.6 Privacy by Design and Default

Status: Implemented

Control Description: Privacy is embedded in the system architecture:

Analytics: Umami self-hosted analytics with no cookies, no PII, DNT respected
Minimal collection: Only data necessary for SEND guidance is collected
Consent-first: GDPR consent middleware blocks all data processing without consent
No third-party tracking: No Google Analytics, Facebook Pixel, or similar trackers
Secure defaults: All cookies httpOnly+secure, CORS restricted, CSP headers

Evidence:

Umami (no-cookie analytics): packages/web/src/app/layout.tsx
GDPR middleware (consent-first): packages/api/src/middleware/gdpr.ts
Security headers: packages/web/next.config.ts (CSP, CORS)

4.1 Controller Information

Field	Value
Controller	Spectrum Dynamics CIC
Purpose	SEND guidance for parents, carers, teachers, and SENCOs
Legal basis	Explicit consent (Art. 6(1)(a))
ICO Registration	[Registration number on file]

4.2 Data Processors and Sub-Processors

Processor	Role	Location	GDPR Status
Civo	Cloud infrastructure (Kubernetes, Object Storage)	UK (LON1)	UK GDPR compliant
Azure OpenAI	LLM inference for AI responses	UK (UK South)	UK GDPR compliant, no data retention
Umami	Privacy-focused analytics (self-hosted)	UK (LON1, self-hosted)	No PII processed
Resend	Transactional email delivery	US (EU data processing)	DPA available

4.3 Data Flows

User Input
    |
    v
SpektraBot API (UK, Civo LON1)
    |
    +--> PostgreSQL (UK, Civo LON1) -- stored 90 days, then auto-deleted
    |
    +--> Azure OpenAI GPT-4.1 (UK, UK South) -- prompt sent, response received, no storage
    |
    v
AI Response --> User

4.4 Data Categories and Retention

Data Category	Examples	Retention	Legal Basis
Account data	Name, email, role, school	Until deletion requested	Consent
Conversation data	Messages, AI responses	90 days (auto-deleted)	Consent
Children data	Year group, SEND category	Until parent account deleted	Consent
Consent records	Consent timestamps, versions	Permanent (legal requirement)	Legal obligation
Audit logs	Admin actions, timestamps	Permanent (anonymised on user deletion)	Legitimate interest
Analytics	Page views, session counts	Rolling 90 days	Legitimate interest (no PII)

5.1 Transfer Assessment

Primary storage: United Kingdom (Civo LON1) — no international transfer for stored data.

Processing transfers:

Azure OpenAI (UK): Azure OpenAI GPT-4.1 runs in UK South region. No international transfer required. Microsoft processes prompts in real-time and does not retain user data. Data processing agreement on file.
Resend (US): Standard Contractual Clauses (SCCs) for email delivery. Only transactional emails (password reset, notifications) — no conversation data.

No transfers to:

Countries without adequacy decisions (except Resend via SCCs)
Any third party for marketing, profiling, or data sale purposes

Evidence:

Azure OpenAI integration: packages/api/src/chat/langchain.ts (API calls to UK South endpoint)
Email service: packages/api/src/services/ (Resend integration for transactional email only)

6.1 Risk Assessment Summary

Risk	Likelihood	Impact	Mitigation
Unauthorised data access	Low	High	JWT auth, RBAC, encrypted transport
Data breach	Low	High	Encryption at rest, UK residency, backups every 6h
Excessive data collection	Low	Medium	Minimal schema, no unnecessary PII fields
Vendor data exposure	Low	Medium	Azure OpenAI no-retention policy, self-hosted analytics
Data retention beyond purpose	Low	Medium	90-day automated deletion, documented retention
Children's data sensitivity	Medium	High	No direct child identifiers, parent-controlled, cascade delete

6.2 Special Considerations for SEND Data

SpektraBot processes information related to children with Special Educational Needs and Disabilities. While the system does not directly identify children (no names, dates of birth, or unique identifiers are stored), the combination of SEND category, year group, and school could potentially be used to narrow identification. Mitigations:

Children records are accessible only by the parent who created them
No child data is shared between users or exposed in analytics
Cascade deletion ensures all children records are removed with the parent account
90-day conversation retention limits the window of data exposure

SpektraBot GDPR Controls — Comp AI Mapping ​

1. Data Protection Principles (GDPR Article 5) ​

1.1 Lawfulness, Fairness, and Transparency (Art. 5(1)(a)) ​

1.2 Purpose Limitation (Art. 5(1)(b)) ​

1.3 Data Minimisation (Art. 5(1)(c)) ​

1.4 Accuracy (Art. 5(1)(d)) ​

1.5 Storage Limitation (Art. 5(1)(e)) ​

1.6 Integrity and Confidentiality (Art. 5(1)(f)) ​

2. Data Subject Rights (GDPR Articles 12-23) ​

2.1 Right of Access (Art. 15) ​

2.2 Right to Rectification (Art. 16) ​

2.3 Right to Erasure (Art. 17) ​

2.4 Right to Restrict Processing (Art. 18) ​

2.5 Right to Data Portability (Art. 20) ​

2.6 Right to Object (Art. 21) ​

3. Technical and Organisational Measures (GDPR Article 32) ​

3.1 Encryption ​

3.2 Access Control ​

3.3 Audit Logging ​

3.4 Data Residency ​

3.5 Incident Response and Business Continuity ​

3.6 Privacy by Design and Default ​

4. Data Processing Records (GDPR Article 30) ​

4.1 Controller Information ​

4.2 Data Processors and Sub-Processors ​

4.3 Data Flows ​

4.4 Data Categories and Retention ​

5. International Data Transfers (GDPR Articles 44-49) ​

5.1 Transfer Assessment ​

6. Data Protection Impact Assessment (GDPR Article 35) ​

6.1 Risk Assessment Summary ​

6.2 Special Considerations for SEND Data ​

SpektraBot GDPR Controls — Comp AI Mapping

1. Data Protection Principles (GDPR Article 5)

1.1 Lawfulness, Fairness, and Transparency (Art. 5(1)(a))

1.2 Purpose Limitation (Art. 5(1)(b))

1.3 Data Minimisation (Art. 5(1)(c))

1.4 Accuracy (Art. 5(1)(d))

1.5 Storage Limitation (Art. 5(1)(e))

1.6 Integrity and Confidentiality (Art. 5(1)(f))

2. Data Subject Rights (GDPR Articles 12-23)

2.1 Right of Access (Art. 15)

2.2 Right to Rectification (Art. 16)

2.3 Right to Erasure (Art. 17)

2.4 Right to Restrict Processing (Art. 18)

2.5 Right to Data Portability (Art. 20)

2.6 Right to Object (Art. 21)

3. Technical and Organisational Measures (GDPR Article 32)

3.1 Encryption

3.2 Access Control

3.3 Audit Logging

3.4 Data Residency

3.5 Incident Response and Business Continuity

3.6 Privacy by Design and Default

4. Data Processing Records (GDPR Article 30)

4.1 Controller Information

4.2 Data Processors and Sub-Processors

4.3 Data Flows

4.4 Data Categories and Retention

5. International Data Transfers (GDPR Articles 44-49)

5.1 Transfer Assessment

6. Data Protection Impact Assessment (GDPR Article 35)

6.1 Risk Assessment Summary

6.2 Special Considerations for SEND Data