Data Protection Impact Assessment

DATA PROTECTION IMPACT ASSESSMENT

This DPIA has been prepared by Chalkie AI to support schools, groups, and Multi-Academy Trusts (MATs) in their procurement and data governance due diligence. It assesses the privacy risks associated with deploying Chalkie across schools and documents the technical and organisational measures in place to mitigate those risks.

1. Overview and Purpose of This DPIA

This Data Protection Impact Assessment (DPIA) has been prepared in accordance with Article 35 of the UK General Data Protection Regulation (UK GDPR) and the guidance published by the Information Commissioner's Office (ICO). It is intended to assist Multi-Academy Trusts (MATs) and their Data Protection Officers (DPOs) in evaluating the privacy implications of deploying Chalkie AI across their schools.

A DPIA is required where processing is likely to result in a high risk to individuals. Chalkie combines teacher content generation with Live Activities student participation. This DPIA documents data flows, the legal bases for processing, the risks identified, and the mitigations in place - enabling MATs to make an informed procurement decision and satisfy their own governance obligations.

1.1 Scope

This DPIA covers the processing of personal data that occurs when Chalkie AI is deployed within a Multi-Academy Trust, including:

• Registration and account management for teaching staff
• Use of the lesson-planning product, including AI content generation
• Live Activities follow-along, student answering, classroom visibility, and saved results
• Product analytics, error monitoring, and support communications
• Payment processing for subscriptions
• Data transfers to third-party sub-processors

1.2 What Chalkie AI Does

Chalkie AI is an AI-powered lesson planning tool designed for teachers. Teachers enter a topic, year group, and curriculum standard, and the product generates structured lesson content. Students can join Live Activities by code or link without an account, email address, password, or school login, and there is no student profile across lessons. When answering is enabled, Chalkie stores that lesson's display names, answers, and scores on our servers so the teacher can review results. Ending the session does not delete them, and there is no automatic deletion period. The teacher can delete that session's results in the app, or the school can ask us to delete them at hello@chalkie.ai. Hosting and the real-time connection provider process the technical data needed to run the lesson. Classroom visibility is described in section 4.4.

2. Controller and Processor Details

2.1 Data Controller

2.2 Data Processing Agreement (DPA)

The Data Processing Agreement at https://chalkie.ai/dpa forms part of the Terms where Chalkie processes personal data for a school, trust, or other educational organisation, including Live Activities. It formalises the controller–processor relationship for staff and student participation data. Schools in the UK and EEA use the UK and EU agreement. A separately signed agreement prevails where they conflict. Questions: hello@chalkie.ai

3. Description of Processing Activities

3.1 Categories of Data Subjects

3.2 Categories of Personal Data Processed

Important: Account information (names, email addresses) is never sent to AI model providers. Only the prompt content is transmitted, though prompts and uploaded files can contain anything the teacher types or includes; OpenAI editing-chat requests also carry a pseudonymous ID (a one-way hash of the account ID) used only to detect abuse.

3.3 Special Category Data

Chalkie does not request special category data (Article 9 UK GDPR). Teachers and students should avoid submitting real student names, sensitive information, or special category data in prompts, materials, responses, or display names. Generated nicknames reduce identification but do not make participation records anonymous; the teacher may know which student used a nickname.

3.4 Legal Bases for Processing

4. Data Flows and Sub-Processors

4.1 Infrastructure and Hosting

Primary data jurisdiction: European Union (Netherlands) for the live database. A worker server in London, United Kingdom, processes queued jobs; it stores no data and connects to the database in Amsterdam over TLS. Encrypted database backups are stored in London, United Kingdom, covered by the European Commission's adequacy decision for the United Kingdom.

4.2 Sub-Processor Register

Note: Where data is transferred outside the UK/EU (to US-based providers), transfers are governed by Standard Contractual Clauses (SCCs) under UK GDPR Schedule 21 / EU GDPR Chapter V, supplemented by transfer impact assessments where required.

Three further categories are not itemised above. Advertising conversion platforms (Google Ads, Microsoft Advertising, Meta and OpenAI Ads) receive no data at all for users belonging to a school or organisation account, which are excluded from conversion reporting entirely. Giphy (media search) receives only search queries and no personal data. Google Workspace and Google Maps receive data only when a teacher signs in with Google, chooses to export their own content to their own account, or uses address autocomplete (Google Maps) in the billing form. The complete sub-processor list, including these categories and each vendor’s data processing agreement, is maintained separately and available on request.

4.3 AI Processing and Data Minimisation

• Account identity data (name, email) is never included in prompts sent to AI providers.
• Student answers are scored against the activity answer key using fixed rules and are not sent to AI providers for assessment. Student data is not sold, used for advertising, or used to train models.
• Only the teacher-entered lesson prompt content is transmitted to AI services; OpenAI editing-chat requests also carry a pseudonymous ID (a one-way hash of the account ID) used only to detect abuse.
• Under the API terms of all AI providers used, data transmitted via API is not used for model training.
• Content moderation (via OpenAI API) screens all user input before it reaches generative AI models.

4.4 Live Activities Classroom Visibility

The teacher can view participants, responses, scores, and saved results during and after the session. Nicknames are shared within the room; enabling the leaderboard also shares nicknames and scores. Individual answers are submitted through the backend API. The device keeps a reconnection token and participant details in local storage for up to 12 hours, including after the tab is closed, so the same device can rejoin that lesson. Participant identities are not linked across lessons.

No analytics, advertising, session-replay, or support-tracking scripts run on chalkie.live. Essential storage and real-time connections remain necessary. Backend service events use teacher/session identity and operational counts without student names, answers, scores, or tokens.

5. Necessity and Proportionality Assessment

5.1 Is the Processing Necessary?

The processing activities described in Section 3 are each necessary to deliver the Chalkie AI service. Specifically:

• Teacher account data (name, email) is the minimum required for authentication, communication, and account management.
• Usage analytics use no event autocapture, EU-only processing and IP-based geolocation disabled for server-side events, and are necessary for product improvement and support. Session replay is on in the app: form-field input is masked and Live Activities student nicknames (student list and leaderboard) and score charts are blanked out; other on-screen text, including lesson and document content, is recorded unmasked.
• Prompt content is necessary to generate AI lesson content but is deliberately de-linked from account details before transmission to AI providers, though prompts and uploaded files can contain anything the teacher types or includes; OpenAI editing-chat requests also carry a pseudonymous ID (a one-way hash of the account ID) used only to detect abuse.
• Payment data is processed by Stripe solely for billing purposes and is not accessible to Chalkie AI in raw form.

5.2 Data Minimisation

Chalkie AI applies data minimisation principles throughout its architecture:

• Live Activities use session-specific generated nicknames and participant IDs without student accounts or a cross-lesson profile. Follow-along collects no student answers but processes connection information.
• PII detection warns teachers in real time if they appear to be entering personal information into the lesson planner.
• Analytics events are not autocaptured - only specific, intentional events are tracked. Session replay, which is on in the app, records screen activity separately: form-field input is masked and Live Activities student nicknames and score charts are blanked out, but other on-screen text, including lesson and document content, is not masked.
• IP-based geolocation is disabled for server-side analytics events.
• AI providers receive only the prompt content and any files the teacher attaches; no name or email from account details is sent, apart from a one-way hashed account ID sent to OpenAI for abuse detection, though prompts and uploaded files can contain anything the teacher types or includes.
• Analytics and advertising tags (Google Analytics, the Meta Pixel and the OpenAI Ads pixel) run only on the public marketing website. In every region they load and set cookies as soon as a page loads, before the visitor makes any cookie choice, unless the visitor has already opted out. Visitors can opt out through the cookie controls (see the Cookie Policy); after that the Meta and OpenAI Ads pixels no longer load and Google Analytics runs without cookies. The signed-in product contains no advertising trackers, and members of school or organisation accounts are excluded from advertising conversion reporting entirely.

5.3 Retention and Deletion

MATs can request full deletion of data associated with a former staff member by emailing hello@chalkie.ai. Organisation admins can also remove members from the trust organisation directly within the platform.

Schools can request access, correction, return, or deletion of student data through hello@chalkie.ai. The Information Security Lead (CTO) owns fulfilment; we complete requests manually. Fulfilment covers production records and copies we can instruct service providers to delete. Database backups remain recoverable for about 90 days (7 daily, 4 weekly, and 3 monthly copies). Deleted student records can remain in those backups until they expire. If a backup is restored, later deletions are re-applied so restored data does not revive deleted student records. Parents and eligible students should contact their school, with Chalkie assisting the school. Ending a session or closing a browser does not delete saved records.

6. Risk Identification and Assessment

The table below identifies the key privacy risks associated with deploying Chalkie AI and assesses their likelihood and impact before and after mitigations are applied.

Live introduces risks from identifying students through nicknames, classroom sharing, unauthorised access to saved results, and retaining records after the educational purpose ends. Schools should control access to join codes, use generated nicknames, decide whether to enable the leaderboard, and set retention instructions. Before student answering is released, complete the measured compliance assessment (GDPR, FERPA, Australian Privacy Act, and, for younger students, the COPPA school-authorization and direct-notice process, including remaining operator obligations). Confirm the school-request and termination deletion procedure, including provider copies, backups, and restore safeguards. The existing risk ratings above do not establish a completed assessment of these additional Live risks.

7. Technical and Organisational Security Measures

7.1 Encryption

• In transit: All traffic is served over HTTPS (TLS). Database connections use SSL.
• At rest: Database and file storage are encrypted at rest using industry-standard algorithms.

7.2 Authentication and Access Control

• Passwords are securely hashed using industry-standard algorithms aligned with OWASP recommendations.
• Sessions use HTTP-only cookies with CSRF protection on all endpoints.
• Login attempts are rate-limited with lockout after repeated failures.

7.3 Input Protection and Application Security

• All user input is validated and sanitised before processing.
• Database queries use parameterised statements to prevent SQL injection.
• Security headers are applied across the application: framing protection, content type enforcement, referrer policy, and permissions policy.
• AI generation and API requests are rate-limited.

7.4 Content Moderation and AI Safety

• Content moderation screens all user input in real time before it reaches any AI model.
• Stricter moderation thresholds apply to education-sensitive categories (e.g., sexual content, content involving minors).
• A designated AI Safety Lead (CTO) is responsible for risk assessment, safety guidelines, and AI system monitoring.
• AI Impact Assessments are conducted annually, covering content accuracy, inappropriate content, bias, data exposure, and prompt injection.
• Safety and jailbreak testing is performed prior to all major releases.

7.5 Security Testing

• Annual penetration testing is conducted by OneLeet, an independent third-party security firm. Most recent test: March 2026.
• Automated vulnerability scanning of infrastructure and dependencies runs continuously.
• Access control, rate limiting, and authorisation are reviewed annually.

7.6 Incident Response

In the event of an AI safety or security incident, Chalkie AI will:

• Investigate and contain the issue within 24 hours of identification.
• Notify affected users if their data or safety has been impacted.
• Document the incident, root cause, and preventive measures taken.
• Notify the ICO within 72 hours where required under UK GDPR Article 33.