Data Protection Impact Assessment
Last updated: 24 August 2026
SENScribe Encrypted Student Support File Service
Version: 1.5
Date: 24 August 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 reflects the implementation described in the codebase, Azure production configuration and public legal pages as of 24 August 2026. It is not a substitute for legal advice.
This DPIA addresses:
- creation and storage of encrypted student-support records
- encrypted synchronisation of those records across teacher devices
- redacted and generalised 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 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. All public legal pages carry a last-updated date at the top of the page; whenever role-allocation wording changes, each affected page must be republished with an updated date so that statements like this one remain verifiable across the site, contracts, order process, and customer communications. That alignment should be in place 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 browser-redacted and generalised 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 client-side encryption.
- The encryption key material is protected client-side using the teacher's data password.
- The encrypted record is sent to SENScribe's server and stored in Azure Cosmos DB Table API.
- Protected key material is stored server-side so the user can unlock the data from another authorised device.
- 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
- The teacher enters free text and plan information in the browser.
- During drafting, the browser applies an automated check for likely names and common direct identifiers and generalises recognised diagnoses before any transmission; automated detection is not infallible.
- Immediately before the complete AI request is transmitted, a further automated identifier check is applied to the assembled request. The request fails closed: it is blocked rather than sent if that check cannot complete or still detects likely direct identifiers. Automated detection reduces risk but cannot guarantee that every identifier in free text will be recognised.
- The generated output is returned with placeholders and restored in the browser where appropriate.
3.3 Systems and providers involved
- SENScribe web application and APIs hosted on Azure Static Web Apps and Azure Functions
- Azure Cosmos DB Table API and Azure Blob Storage for encrypted entity and legacy-document storage
- Azure OpenAI for redacted and generalised AI drafting
- Azure Communication Services for transactional emails
- Resend as configured fallback email provider for ordinary transactional emails outside split-key invitation flows (split-key invitation flows are the secure invitation emails used for shared records, where the invitation link carries only one half of the split decryption key; neither the email service nor the application alone can decrypt the shared record. See the SENScribe Privacy Policy.)
- Azure Monitor and Log Analytics for security and operational diagnostics
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 redacted and generalised 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
- diagnostic data that may include user identifiers, error messages, stack traces and related technical context
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: browser-side redaction and generalisation checks are followed by a fail-closed check on the complete request immediately before transmission; automated detection is not infallible
- sync and storage flow: the system stores encrypted customer data server-side and therefore still processes personal data as processor, even though during normal operation SENScribe has no technical means to decrypt the content (decryption depends on teacher-held credentials; documented exceptions are described in the Privacy Whitepaper)
Client-side 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 and ETBs, the relevant anchors commonly relied on include section 9 of the Education Act 1998 (functions of schools in relation to the education of their students, including students with special educational needs), the assessment and related duties under the Education for Persons with Special Educational Needs Act 2004, and, where the body is a public authority acting in that capacity, Article 6(1)(e) GDPR. Where special-category data is processed, the controller must additionally identify an applicable Article 9(2) condition. These references are intended to assist controllers and procurement reviewers; 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 requests are browser-redacted and generalised to reduce identifiable student content
- stored records are encrypted before upload
- SENScribe cannot decrypt customer content during normal operation 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 is to 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
As of the date of this version, these consultations have not yet been formally completed and recorded. Until they are, this DPIA does not satisfy the seek-the-views expectation of Article 35(2) GDPR as described in WP248 rev.01; completion and recording of the consultation is a condition of the approval in Section 17 and is tracked as action R7 in Section 14.2.
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
- organisation-scoped sync mutations validate the caller against the canonical student assignment before changing shared caseload state
9.3 Data minimisation for AI
- during drafting, likely names and common direct identifiers are redacted in the browser and diagnoses are generalised before any AI transmission, with an explicit automated-detection limitation
- immediately before transmission of the complete request, a further automated identifier check is applied; the request is blocked rather than sent if the check cannot complete or still detects likely direct identifiers
- Azure OpenAI receives browser-redacted and generalised prompts intended not to contain directly identifying student names; automated detection cannot guarantee recognition of every identifier in free text
9.4 Hosting and data location
- encrypted storage is hosted in Azure Cosmos DB in an EU/EEA Azure region
- encrypted legacy documents are hosted in Azure Blob Storage 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 outside split-key invitation flows; split-key invitation emails are sent only through Azure Communication Services, and if that delivery fails the invitation is not routed to the US fallback
- security and operational diagnostics are retained in Azure Monitor / Log Analytics in West Europe for 30 days
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
9.6 Backups
- periodic backups of the customer database support service resilience, with an approximate four-hour recovery point objective as stated in the SLA
- backups are stored geo-redundantly by the cloud provider
- because student-support content is encrypted in the browser before upload, backups contain encrypted content and protected key material rather than plaintext customer content
- backup copies expire through the documented rolling thirty-day cycle, consistent with Clause 12 of the school-facing Data Processing Agreement
- deletion of active data and expiry of backup copies are therefore aligned: instructed deletions take effect in active systems within thirty days, and residual backup copies age out on the same thirty-day cycle
10. Retention
10.1 Customer content
The controller should determine retention periods for student-support records and instruct SENScribe accordingly.
Personal encrypted Student Support Files are retained until manually deleted, deletion is requested, or the eligible personal account is automatically deleted after 12 months of inactivity. Organisation-controlled school and student records are excluded from automatic account deletion and are retained or deleted through the controller's offboarding or deletion instructions.
10.2 Account data
Eligible personal accounts and their personal data are deleted after 12 months of inactivity. Organisation accounts and organisation-controlled records follow the controller's manual offboarding or deletion instructions.
10.3 Deletion and backups
Where deletion is instructed, active-system deletion takes place within thirty days and residual backup copies become inaccessible through the rolling thirty-day backup-expiry cycle described in Clause 12 of the Data Processing Agreement. Backup copies remain protected by that agreement until they expire.
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.
Website and application usage analytics, including Google Analytics 4, fall outside the scope of this DPIA: they are not part of the school-service workflow assessed here, they are consent-gated, and their safeguards are disclosed separately on the sub-processors page. This document makes no transfer-free claim for them. Any future integration that touches school-user account data, telemetry included, must be checked separately before being treated as transfer-free.
Plus Five Five, Inc. (Resend) is a US provider used for fallback transactional email outside the split-key invitation flows. It receives the recipient address, subject, HTML/plain-text message content, optional reply-to and delivery metadata; student-support record content is not intentionally included. The transfer is covered by Resend's DPA, EU Standard Contractual Clauses and EU-US Data Privacy Framework participation.
For secure review invitations, the email-link half of the split decryption key is transmitted within the invitation link. This half alone cannot decrypt the shared record: the other half is held within the application, so neither the email service nor the application alone can decrypt it. Split-key invitation emails are sent only through Azure Communication Services under the Microsoft sub-processing terms; if that delivery fails, the invitation is not routed to the US email fallback. Because the emailed half is what allows the recipient to open the link, protection depends on correct recipient addresses and on the split design itself; this exposure is assessed in the risk table.
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 content and 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; no technical means to decrypt stored content during normal operation (decryption depends on teacher-held credentials), 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 |
| Identifier redaction failure before AI request | Identifiable student data sent to AI provider | Client-side redaction and generalisation logic; additional automated check on the complete request blocks transmission if the check cannot complete or still detects likely identifiers | Reduced; layered detection helps, but coverage should be validated and monitored on an ongoing basis |
| School lacks clear lawful basis or internal authorisation | Unlawful controller processing | Teacher-facing notices and school-facing DPA | Medium to high unless school governance is explicit |
| Inaccurate public legal statements | Misleading customers and procurement risk | Public terms use school/ETB controller wording; privacy pages, DPA and DPIA are published | Reduced; wording must remain aligned across sales, terms, DPA and product screens, and affected pages must be republished with updated dates when wording changes |
| Incomplete deletion/retention governance | Data kept longer than necessary or deleted inconsistently | Personal-account inactivity deletion is scheduled; organisation-controlled records use controller instructions | Medium; retain run evidence and document each school offboarding or deletion request |
| 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 | Recipient address, message content and transactional metadata processed by a US provider if Azure Communication Services fails outside split-key invitation flows | Fallback only; student-support record content is not intentionally included; Resend DPA, SCCs and Data Privacy Framework participation documented | Reduced but not eliminated; provider settings and retention should remain under review |
| Compromise or over-retention of backup copies | Exposure of encrypted content or protected key material if backup copies are breached, restored insecurely, or kept beyond documented cycles | Content is encrypted before upload, so backups hold encrypted content and protected key material; backups are geo-redundant provider-managed periodic copies per the SLA; rolling thirty-day backup-expiry cycle documented in DPA Clause 12 | Reduced but not eliminated; retain evidence that expiry operates as documented, particularly around offboardings and deletion instructions |
| Exposure of the emailed key half in secure review invitations | Invitation email carries one half of the split decryption key; combined with the application-held half it opens the shared record | Split-key design means neither the email service nor the application alone can decrypt; invitation emails route through Azure Communication Services only, with no US fallback; recipients are authorised by the controller | Low to medium; depends on correct recipient addresses, recipient mailbox security, and provider-side message handling outside SENScribe control |
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 browser-redacted and generalised 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 retain evidence for personal-account deletion runs and school offboarding requests
- need to retain evidence that backup expiry operates as documented when deletion instructions are executed
- 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, Actions and Remediation Log
14.1 Decision
Proceed only subject to the actions below being completed and maintained.
14.2 Remediation log
Every action has an owner and a target date. Target dates are proposals for confirmation at sign-off; owners report progress against this log at each review point.
| Ref | Action | Owner | Target date | Status |
|---|---|---|---|---|
| R1 | Republish affected legal pages with updated last-updated dates whenever controller-role wording changes, starting with the Terms of Service | Founder or responsible manager | 30 September 2026 | Open |
| R2 | Issue the school-facing DPA under Article 28 in every school/ETB onboarding pack | Founder or responsible manager | Before first school/ETB go-live | Open |
| R3 | Verify and document personal-account deletion runs and organisation offboarding or deletion instructions | Engineering lead | 31 October 2026 | Open |
| R4 | Maintain a live sub-processor list and change-notification process | Founder or responsible manager | Ongoing; next review 30 November 2026 | Open |
| R5 | Verify operational reality behind all public claims on encryption, deletion, email provider routing and regional hosting, and record supporting evidence | Engineering lead | 31 October 2026 | Open |
| R6 | Validate the redaction controls, including the fail-closed pre-transmission check, on an ongoing basis and record results | Engineering lead | 31 October 2026, then quarterly | Open |
| R7 | Complete and record the Article 35(2) stakeholder consultation set out in Section 8 | Founder or responsible manager | 30 November 2026 | Open |
| R8 | Obtain external legal review and formal sign-off before representing this DPIA as final or regulator-ready | External data-protection counsel | Before broad ETB rollout with real student data | Open |
| R9 | Extend Annex A into a full Article 30 record of processing activities covering controller-side and processor-side operations | External data-protection counsel with founder or responsible manager | 31 December 2026 | Open |
| R10 | Confirm backup configuration evidence (periodic-backup cadence, geo-redundancy, thirty-day expiry) against provider configuration and retain it for audit | Engineering lead | 31 October 2026 | Open |
| R11 | Obtain an EU AI Act classification memorandum and monitor commencement of the Irish Regulation of AI Bill 2026 | External data-protection counsel | 31 December 2026 | Open |
15. EU AI Act Position
SENScribe uses AI only as an assistive drafting tool. The following is SENScribe's working position as of 24 August 2026; a formal classification memorandum is to be obtained from counsel (action R11). Nothing in this section is legal advice or a substitute for that memorandum.
- Intended purpose: AI-assisted drafting generates suggested text for educational documentation from browser-redacted and generalised inputs. A teacher reviews and edits the output before saving or signing. The service does not make automated decisions about students.
- Deployer posture: SENScribe integrates a third-party general-purpose AI service (Azure OpenAI) and does not train or develop its own model. On that basis, the current working position is that SENScribe acts as a deployer of a general-purpose AI system rather than a provider of a high-risk AI system under Annex III of Regulation (EU) 2024/1689. This position has not yet been confirmed by counsel and must not be treated as settled.
- Education-use boundary: the tool is not used for admission or admission decisions, assessment of learning outcomes, evaluation of learning levels, or monitoring or proctoring of students during tests. Those are among the Annex III education use cases the Regulation treats as high-risk; SENScribe's intended purpose excludes them, and product design must continue to respect that boundary.
- Transparency (Article 50): transparency obligations under the AI Act apply from 2 August 2026. Users are informed within the product when drafting assistance is used, and generated drafts are presented for human review before adoption, consistent with the obligation to keep people informed when AI-generated content is involved.
- Monitoring: SENScribe will track guidance and the commencement of the Irish Regulation of AI Bill 2026, and will revisit this position if the service's AI footprint changes.
16. 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
- EDPB Guidelines 05/2020 on consent under Regulation 2016/679 (WP259 rev.01)
- Irish ePrivacy Regulations 2011 (S.I. No. 336 of 2011)
17. Approval and Sign-off
Decision: this DPIA is approved for continued development and pilot use subject to the conditions below. It is not approved as final or regulator-ready until those conditions are discharged.
| Role | Name | Signature | Date |
|---|---|---|---|
| Founder / chief executive (accountable owner) | ____________________ | ____________________ | ____________ |
| External data-protection counsel or GDPR advisor | ____________________ | ____________________ | ____________ |
| Technical lead, encryption and sync implementation | ____________________ | ____________________ | ____________ |
Conditions of approval:
- completion of the remediation log in Section 14.2, or documented acceptance of any open items
- completion and recording of the Article 35(2) stakeholder consultation in Section 8
- confirmation by counsel of the EU AI Act position in Section 15 and of the Article 36 pre-consultation judgment in Section 8
- no material change to providers, regions, encryption design or email routing without triggering review of this DPIA
This DPIA is reviewed at minimum:
- annually as part of the DPIA review cycle
- on any change of sub-processor, hosting region or email-routing behaviour
- on any change to the encryption or key-management design
- on any material change in DPC guidance or applicable law
18. Version History
| Version | Date | Author | Status | Notes |
|---|---|---|---|---|
| 1.1 | 17 April 2026 | Engineering | Superseded | Initial published version; referenced in earlier companion documents |
| 1.4 | 24 August 2026 | Engineering and management | Superseded | Full internal reassessment of roles, data flows, transfers and risks |
| 1.5 | 24 August 2026 | Legal review (data-protection solicitor) | Current | Post-review revision: added approval block, version log, Article 30 annex (Annex A), backup and split-key analysis, EU AI Act position, and remediation log with owners and dates |
Changelog detail for versions between 1.1 and 1.4 was not retained in this log; earlier entries are recorded only where externally referenced.
Annex A: Article 30 Record of Processing, SENScribe-Controlled Operations
For school customer content, SENScribe acts as processor and maintains the corresponding records through the Data Processing Agreement (in particular Annexes 1 to 3). This annex records, in general terms, the processing operations for which SENScribe Limited determines purposes and means as a controller. It is a summary record pending the full record of processing activities (action R9).
| Operation | Categories of data subjects | Categories of personal data | Purpose | Lawful basis | Recipients | Retention (general) |
|---|---|---|---|---|---|---|
| Service account administration and authentication | Teachers, SETs and school staff | Name, work email, hashed credentials, session and authentication metadata, plan/subscription metadata, usage and audit metadata | Providing and securing access to the contracted service | Performance of contract (Art 6(1)(b)); legitimate interests (Art 6(1)(f)) for service security | Processors on the published sub-processors list (Microsoft) | Duration of the account relationship; eligible personal accounts deleted after 12 months of inactivity as described in Section 10 |
| Service security, diagnostics and support | Platform users | Diagnostic data including user identifiers, error messages, stack traces and technical context; support correspondence | Maintaining availability and security; resolving reported issues | Legitimate interests (Art 6(1)(f)) | Microsoft (Azure Monitor / Log Analytics, West Europe) | Covered diagnostics retained 30 days; support records kept as long as needed to handle the query and demonstrate compliance |
| Billing and payment management | Billing contacts for subscribing schools or personal subscribers | Billing contact details and payment details | Managing subscriptions, invoicing and payment collection | Performance of contract (Art 6(1)(b)); legal obligation (Art 6(1)(c)) for accounting and tax | Payment provider disclosed on the sub-processors page (Revolut) | Statutory accounting and tax retention periods, then deleted or anonymised |
| Prospective-school licence enquiries | Prospective customers and their staff | Contact name, school or work email, optional phone, role, school name and type, estimated staff, preferred licence, optional message; no pupil or student data requested | Responding to and managing licence enquiries | Consent (Art 6(1)(a)) or legitimate interests (Art 6(1)(f)) depending on the collection context | CRM provider disclosed on the sub-processors page (Zoho) | Duration needed to handle the enquiry and any follow-up, then deleted or minimised |
| Website and application usage analytics | Website visitors and app users | Pseudonymous browsing, URL, cookie and device data | Understanding usage and improving the site | Consent, collected through consent-gated analytics (Art 6(1)(a); ePrivacy Regulations 2011) | Analytics provider disclosed on the sub-processors page (Google Analytics 4) | As configured in the analytics tool and described in the privacy notice |
| Service communications to account holders and invitation recipients | Platform users and authorised recipients | Recipient address, subject and message content, reply-to, delivery metadata; for secure review invitations, the email-link half of the split decryption key | Delivering transactional and service emails, including secure sharing invitations | Performance of contract (Art 6(1)(b)) for service email; documented controller instructions for school-related email | Microsoft (Azure Communication Services); Plus Five Five, Inc. (Resend) solely as US fallback outside split-key invitation flows, with DPA, SCCs and Data Privacy Framework participation | Delivery metadata handled per provider retention settings; split-key invitation content exists only long enough to place the key half in the invitation link |
This annex is maintained at a general level on purpose: it contains no infrastructure detail beyond what is already published, and it is updated whenever a provider, purpose or retention rule changes.