Data Protection Impact Assessment

SENScribe Encrypted Student Support File Service

Version: 1.3
Date: 1 July 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, Azure production configuration and public legal pages as of 1 July 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 Public wording alignment

SENScribe's public terms now state that, for Irish educational use, the school, ETB, or board of management is the controller for student personal data and the teacher acts as an authorised user under that organisation's authority. That role allocation should remain aligned across the site, contracts, order process, and customer communications before onboarding schools or ETBs.

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

1. A teacher enters student-support information into the browser.
2. The browser encrypts the record using client-side encryption.
3. The encryption key material is protected client-side using the teacher's data password.
4. The encrypted record is sent to SENScribe's server and stored in Azure Cosmos DB Table API.
5. Protected key material is stored server-side so the user can unlock the data from another authorised device.
6. On a new device, the teacher authenticates, enters the data password or recovery key, unlocks the key material client-side, and decrypts the stored records locally.

B. AI-assisted drafting

1. The teacher enters free text and plan information in the browser.
2. The browser redacts names and generalises diagnoses before transmission.
3. Only anonymised content is sent to SENScribe's backend and Azure OpenAI for generation.
4. 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 configured fallback email provider for transactional emails if Azure Communication Services fails

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 encryption key material used for encrypt and decrypt operations
• password-based key derivation from a separate data password
• protection of data encryption keys before server storage
• recovery-key flow where server-side material remains protected
• server storage of protected key material, not plaintext customer content keys

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 hosted in Azure Cosmos DB in an EU/EEA Azure region
• AI processing is documented as Azure OpenAI within the EU data zone
• email services are Azure Communication Services, with Resend as a configured fallback where Azure Communication Services fails

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.

The public privacy materials state that encrypted Student Support Files are retained until manually deleted, explicitly requested for deletion upon account closure, or automatically destroyed after 12 months of continuous account inactivity, whichever occurs first. The codebase supports deletion of server-side encrypted sync data. Before treating the 12-month inactivity rule as a formal operational commitment for ETB procurement, SENScribe should verify the scheduled deletion process, monitoring, and support runbook.

10.2 Account data

Public site materials refer to deletion after 12 months of inactivity for account and encrypted sync 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 customer database hosting in an EU/EEA Azure region and AI processing within the EU data zone.

However, email fallback, support workflows, analytics, or future telemetry integrations must be checked separately before being treated as transfer-free. Resend is configured as a fallback transactional email provider and is a US provider. Its use should be limited to email address and email-delivery metadata, not student-support record content. Transfers should rely on Resend's DPA, SCCs and applicable Data Privacy Framework commitments, and the live Resend account plan/configuration should be reviewed before ETB onboarding.

This DPIA assumes no international transfer of customer student-support record content outside the EEA as part of the standard encrypted-sync workflow. Transactional email metadata may be processed by Resend in the United States when fallback sending is used. This assumption must remain under review if providers, regions, or email-routing behaviour 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, protected key material, 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, standards-based key derivation, 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	Public terms now use school/ETB controller wording; privacy pages, DPA and DPIA are published	Reduced; wording must remain aligned across sales, terms, DPA and product screens
Incomplete deletion/retention governance	Data kept longer than necessary or deleted inconsistently	Sync deletion endpoint exists; public 12-month inactivity deletion rule is stated	Medium; verify scheduled deletion, monitoring and support runbook before relying on it as an ETB commitment
Sub-processor or region drift over time	Undocumented transfers or compliance mismatch	Current provider list in privacy documentation; Resend fallback identified separately from student-support content storage	Medium; maintain sub-processor register and change-notification process
Resend fallback email processing	Email address and transactional metadata processed by a US provider if Azure Communication Services fails	Fallback only; no student-support record content should be included in email bodies; appropriate transfer safeguards should apply	Reduced but not eliminated; provider settings and retention should remain under review

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:

• ongoing need to keep school-controller wording aligned across all public and contractual materials
• need to verify operational reality behind the public 12-month inactivity deletion commitment
• need to keep the school-facing DPA, sub-processor list and deletion terms current
• 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 controls are maintained and the retention/email-provider checks are completed before broad ETB 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

• keep public terms and privacy language aligned so controller and processor roles remain consistent
• issue the school-facing DPA under Article 28 as part of school/ETB onboarding
• verify and document retention/deletion operations for encrypted customer content, including the 12-month inactivity deletion commitment
• maintain a live sub-processor list and change-notification process
• verify operational reality behind all public claims on encryption, deletion, email provider routing 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