Data Protection Impact Assessment

SENScribe Encrypted Student Support File Service

Version: 1.1
Date: 17 April 2026
Assessed service provider: SENScribe Limited
Company number: 813862
Registered address: ARKINS & COMPANY LIMITED, BLOCK 15, Galway Technology Park, Parkmore, Galway, GALWAY, Ireland, H91 AY0Y
Contact: hello@senscribe.ie

Status and Scope

This DPIA covers SENScribe's encrypted server-sync service for Student Support Files and related student-support records used by Irish schools.

This document is drafted to be truthful to the implementation currently described in the codebase and public legal pages as of 9 April 2026. It is not a substitute for legal advice. It should be reviewed before production use with real student data.

This DPIA addresses:

creation and storage of encrypted student-support records
encrypted synchronisation of those records across teacher devices
anonymised AI drafting flows
account, authentication and support operations necessary to provide the service

This DPIA does not cover unrelated internal company processing such as HR, sales prospecting, or general website marketing analytics except where those functions touch school-user account data.

1. Need for a DPIA

This DPIA has been prepared because the processing is likely to result in a high risk to the rights and freedoms of natural persons unless carefully designed and controlled. Relevant factors include:

processing of student educational records that may contain special-category personal data, including health-related and special educational needs information
use of new technology, namely browser-side encryption, encrypted cloud sync, and AI-assisted drafting
ongoing systematic handling of student-support records across multiple schools and devices

This aligns with Article 35 GDPR and Irish Data Protection Commission guidance on DPIAs for high-risk processing.

2. Roles of the Parties

2.1 Intended role allocation

For school use, the intended role allocation is:

the school, ETB, board of management, or other educational body is the controller
teachers and SETs use the service under the authority of the school
SENScribe Limited is the processor for customer data stored or otherwise processed on behalf of the school
Microsoft acts as a sub-processor for relevant Azure infrastructure services used by SENScribe

2.2 Important legal caveat

SENScribe's public terms currently contain teacher-facing language stating that the teacher is the data controller for student data. That wording is not ideal for the school deployment model reflected in this DPIA. Before relying on this DPIA operationally, public contract language should be aligned so that school-controller wording is consistent across the site, contracts, and sales process.

3. Description of the Processing

3.1 Nature of the service

SENScribe is a web application used to create, update, store, review and export Student Support Files and related records for Irish primary and post-primary schools.

The current product model includes:

account creation and authentication for teachers
creation of student files, plans, reviews, log entries, checklists and drafts
browser-side encryption of stored student-support records
encrypted sync between devices using a client-held data password
AI-assisted drafting using anonymised inputs
PDF generation and export

3.2 Data flow summary

A. Student-support record storage and sync

A teacher enters student-support information into the browser.
The browser encrypts the record using a Data Encryption Key (DEK).
The DEK is wrapped client-side with a Key Encryption Key (KEK) derived from the teacher's data password.
The encrypted record is sent to SENScribe's server and stored in Azure Cosmos DB Table API.
The wrapped DEK is stored server-side so the user can unlock the data from another device.
On a new device, the teacher authenticates, enters the data password or recovery key, unwraps the DEK client-side, and decrypts the stored records locally.

B. AI-assisted drafting

The teacher enters free text and plan information in the browser.
The browser redacts names and generalises diagnoses before transmission.
Only anonymised content is sent to SENScribe's backend and Azure OpenAI for generation.
The generated output is returned with placeholders and restored in the browser where appropriate.

3.3 Systems and providers involved

SENScribe web application hosted on Azure Static Web Apps
Azure Cosmos DB Table API for encrypted entity storage and account-related records
Azure OpenAI for anonymised AI drafting
Azure Communication Services for transactional emails
Resend as fallback email provider where configured

4. Purposes of the Processing

The purposes are:

enabling authorised school staff to create and maintain Student Support Files and related records
enabling continuity across devices and reducing risk of local browser-data loss
helping staff generate draft educational documentation faster through anonymised AI assistance
enabling review cycles, export, and record continuity over time
maintaining user authentication, service security, and support operations

5. Categories of Data Subjects

students
parents or guardians where comments, contact-related notes, or sign-off information are included
teachers and SETs using the platform
school staff referenced in plan or review records

6. Categories of Personal Data

6.1 Teacher account data

name
email address
hashed password and authentication/session data
plan/subscription metadata
usage and audit metadata

6.2 Student-support data

Depending on use by the controller, encrypted records may contain:

student name
date of birth
year group and school level
support level
strengths, concerns, observations and interventions
targets, strategies and review periods
review outcomes and case-history information
log entries concerning assessments, meetings, interventions and consultations
student voice and parent comments
staff names or role references

6.3 Special-category data

The service may process special-category personal data, especially:

data concerning health
special educational needs data
psychological or assessment-related information if included by the controller

6.4 Data minimisation position

SENScribe applies data minimisation differently across two parts of the product:

AI generation flow: identifiable names and diagnoses are redacted or generalised before transmission
sync and storage flow: the system stores encrypted customer data server-side and therefore still processes personal data as processor, even though SENScribe cannot decrypt the content

Zero-knowledge encryption materially reduces risk but does not remove GDPR obligations.

7. Lawfulness, Necessity and Proportionality

7.1 Controller legal basis

The controller must determine and document its own lawful basis under Articles 6 and 9 GDPR for using SENScribe with student data. SENScribe cannot determine that basis for schools.

For Irish schools, likely bases will usually arise from the school's statutory and educational functions rather than consent. This DPIA does not attempt to fix the controller's legal basis definitively.

7.2 Processor necessity

From the processor perspective, the processing is necessary to provide:

encrypted record storage on behalf of the controller
multi-device access and business continuity
review-cycle functionality over time
document generation and export

7.3 Proportionality

The processing is designed to be proportionate because:

AI receives anonymised rather than identifiable student content
stored records are encrypted before upload
SENScribe cannot decrypt customer content without the user-held secret
only minimal cleartext metadata is used where needed for system operations
deletion capability exists for server-side sync data

The proportionality case depends on strong implementation discipline. Public claims should not overstate what encryption changes legally.

8. Consultation With Stakeholders

This DPIA should be reviewed with:

the SENScribe founder or responsible manager
technical lead responsible for encryption and sync implementation
a representative school data protection lead or DPO
external legal counsel or GDPR advisor before broad production rollout

If high residual risk remains after mitigations, consultation with the Irish DPC under Article 36 should be considered.

9. Technical and Organisational Measures

9.1 Encryption and key management

Current documented controls include:

AES-256-GCM encryption for student-support payloads
browser-side generation of an extractable DEK used only for encrypt and decrypt operations
KEK derivation from a separate data password using PBKDF2 with 600,000 iterations and SHA-256
AES-KW wrapping of the DEK before server storage
24-word recovery-key flow stored only in wrapped form server-side
server storage of wrapped DEK, not plaintext DEK

9.2 Access control and authentication

authenticated access required for account-level data and sync APIs
session-based authentication through Better Auth
customer content is separated per user in storage
sync APIs require an authenticated session

9.3 Data minimisation for AI

names are redacted in the browser before AI transmission
diagnoses are generalised before AI transmission
Azure OpenAI receives anonymised prompts rather than directly identifying student names

9.4 Hosting and data location

encrypted storage is documented as Azure Cosmos DB in North Europe (Ireland)
AI processing is documented as Azure OpenAI within the EU data zone
email services are Azure Communication Services, with Resend as fallback where configured

9.5 Integrity, availability and deletion

encrypted sync provides resilience against local device/browser loss
sync conflict handling exists in implementation
server-side sync deletion endpoint exists for full deletion of encrypted sync data for the authenticated user

10. Retention

10.1 Customer content

The controller should determine retention periods for student-support records and instruct SENScribe accordingly.

At present, the codebase supports deletion of sync data but this DPIA does not identify a fully documented and contractually fixed default retention schedule for encrypted student-support records across all customer scenarios. That is a compliance gap that should be closed in the DPA and customer-facing privacy materials.

10.2 Account data

Public site materials refer to deletion after 12 months of inactivity for some account data. That claim should be verified operationally and aligned across privacy, terms, and internal runbooks before being relied on as a formal retention commitment.

11. International Transfers

The intended architecture is to keep encrypted storage in North Europe (Ireland) and AI processing within the EU data zone.

However, any fallback provider, support workflow, or future telemetry integration must be checked separately before being treated as transfer-free.

This DPIA assumes no international transfer of customer student-support data outside the EEA as part of the standard encrypted-sync workflow. That assumption must remain under review if providers or regions change.

12. Risk Assessment

12.1 Risk methodology

Risks are assessed by considering:

severity of harm to students, parents, and staff
likelihood of occurrence
whether existing mitigations reduce the risk to an acceptable level

12.2 Key risks and mitigations

Risk	Potential impact	Existing mitigations	Residual position
Compromise of server-side encrypted records	Exposure of highly sensitive student data	Browser-side encryption, wrapped DEK, SENScribe cannot decrypt stored content, EU hosting	Reduced but not eliminated; depends on implementation correctness and key secrecy
Wrong-recipient access via shared credentials or unlocked device	Unauthorised access to student records	Account authentication, local key unlock requirement on new device	Medium; controller operational controls still matter
Weak or reused data password	Increased risk of successful brute force or compromise	Separate data password, PBKDF2, recovery flow	Medium; enforceable password policy should be reviewed
Browser-side redaction failure before AI request	Identifiable student data sent to AI provider	Client-side redaction and generalisation logic	Medium; should be validated and monitored because a client-side failure directly weakens privacy posture
School lacks clear lawful basis or internal authorisation	Unlawful controller processing	Teacher-facing notices and planned DPA	Medium to high unless school governance is explicit
Inaccurate public legal statements	Misleading customers and procurement risk	Existing privacy pages and whitepaper	Medium; current controller wording and "DPIA available" claim should be aligned
Incomplete deletion/retention governance	Data kept longer than necessary or deleted inconsistently	Sync deletion endpoint exists	Medium; contractual and operational retention schedule needs tightening
Sub-processor or region drift over time	Undocumented transfers or compliance mismatch	Current provider list in privacy documentation	Medium; sub-processor register and update process required

13. Residual Risk Evaluation

The architecture substantially reduces confidentiality risk compared with standard plaintext SaaS storage because:

customer records are encrypted before upload
SENScribe does not hold plaintext student-support content server-side
AI generation uses anonymised inputs

However, the residual risk is not negligible. The main remaining issues are governance and documentation rather than cryptography:

inconsistent controller wording in existing public terms
no fully settled customer-content retention schedule
need for a school-facing DPA with sub-processor and deletion terms
need to ensure that public claims about existing DPIA and DPA availability remain accurate

On the facts currently available, the residual risk appears manageable if those governance issues are closed before broad production rollout with real student data.

14. Decision and Actions

14.1 Decision

Proceed only subject to the actions below being completed and maintained.

14.2 Required actions before relying on this DPIA in production

align public terms and privacy language so controller and processor roles are consistent
finalise and issue a school-facing DPA under Article 28
define and document retention and deletion rules for encrypted customer content
maintain a live sub-processor list and change-notification process
verify operational reality behind all public claims on encryption, deletion and regional hosting
validate the client-side redaction controls on an ongoing basis
obtain legal review before representing the DPIA as final or regulator-ready

15. Sources Used

Official sources consulted while drafting:

Irish Data Protection Commission, Guide to Data Protection Impact Assessments
European Commission Implementing Decision (EU) 2021/915 on standard contractual clauses between controllers and processors under Article 28(7)
EDPB Guidelines WP248 rev.01 on DPIAs

Project sources consulted while drafting:

docs/todo/james_feedback_2026_04_01.md
docs/research/encrypted_sync_azure_analysis.md
frontend/src/app/privacy/page.tsx
frontend/src/app/privacy/whitepaper/page.tsx
frontend/src/app/terms/page.tsx
frontend/src/app/about/page.tsx
frontend/src/app/api/sync/setup/route.ts
frontend/src/app/api/sync/delete/route.ts
frontend/src/lib/sync.ts
frontend/src/lib/drafts/crypto.ts