School Data Processing Agreement
The Article 28 processor terms offered to schools where the school is the controller and MyCodePad processes personal data on its instructions.
This document sets out the processor terms MyCodePad offers schools under Article 28 of UK GDPR, for the processing a school instructs when its pupils and staff use the platform.
It is written to be checked rather than skimmed: each mandatory Article 28(3) requirement has its own clause, the appendices are populated from an audit of the actual database and provider calls, and the places where MyCodePad cannot yet meet a clause are stated in the clause itself rather than left for a school to discover.
1.The parties, and how this fits the school's contract
This agreement is between the school, academy trust or college that subscribes to MyCodePad (the School) and To be confirmed: registered legal name of the MyCodePad operator, a Sole trader with company number Not applicable — MyCodePad is operated by a sole trader, who has no Companies House registration and address To be confirmed: registered or trading postal address (MyCodePad).
It supplements the School's subscription to MyCodePad and the Terms of Service, and forms part of that contract. Where this agreement and the Terms of Service conflict on a matter of personal data, this agreement prevails. Where the School has a separate signed agreement with MyCodePad, that agreement prevails over this page.
It takes effect when the School's subscription begins and continues for as long as MyCodePad processes personal data on the School's behalf.
2.Controller and processor roles are not the same for every feature
This agreement applies where the School determines the purposes and means of the processing and MyCodePad processes on its instructions. That is not every activity on the platform, and treating it as though it were would be inaccurate.
| Activity | Indicative role |
|---|---|
| Pupil accounts created to take part in the School's classes, class membership, work set and marked, teacher feedback, starter results | School as controller, MyCodePad as processor under this agreement. |
| School membership, invite codes, seat administration | School as controller, MyCodePad as processor. |
| Authenticating sign-ins, protecting accounts from unauthorised access, throttling join-code guessing, security logging | MyCodePad as controller for its own security obligations, in respect of the same data. |
| Billing the School, keeping tax and accounting records | MyCodePad as controller. |
| Operating, maintaining, securing and supporting the platform itself | MyCodePad as controller for its own legitimate interests, within the limits of clause 6. |
| An account a pupil or teacher created independently, outside any school | MyCodePad as controller. Not covered by this agreement. |
This allocation must be assessed, not assumed
Roles follow the facts of each processing activity. A school should satisfy itself that the allocation above matches its own assessment, particularly where an independently created pupil account is later joined to the school, because the basis on which that data was originally collected does not change simply by joining. This clause requires specialist review before the School relies on it.3.Subject matter and duration of the processing
Subject matter:the provision of an online coding platform to the School's pupils and staff, including browser-based development environments, saved work, classes, assignments, feedback, starter quizzes and school administration.
Duration:for the term of the School's subscription, and then only for as long as needed to complete the return and deletion obligations in clause 16. The deletion window is To be confirmed: period within which school data is returned or deleted at the end of a contract.
4.Nature and purpose of the processing
MyCodePad processes the School's personal data only to provide and support the platform. In practice this means:
- Creating and authenticating accounts for the School's pupils and staff.
- Storing, versioning and displaying the code, files and folders pupils create.
- Enrolling pupils in classes and recording school membership and roles.
- Distributing teacher-created tasks and library files to pupils, and recording submissions.
- Recording marking status, teacher comments, attributed teacher corrections and pupils' replies to feedback.
- Running starter quizzes and recording answers, scores and submission times.
- Providing AI-assisted error help and task generation, where the teacher has enabled it.
- Administering seats and invite codes for the School.
- Securing the service, including throttling attempts to guess class join codes.
- Providing support to the School's staff.
MyCodePad does not use the School's personal data for advertising, marketing, profiling or any form of behavioural analysis. No such technology exists anywhere in the platform.
5.Categories of data subject
- Pupils of the School, including children.
- Teaching staff and tutors at the School.
- School administrators who manage the School's membership, seats and plan.
MyCodePad does not collect data about parents, carers or other third parties, and the platform has no parent-facing account.
6.Types of personal data
The categories are set out in full in Appendix A, derived from the live database schema.
Special category data: MyCodePad does not request or require any special category data under Article 9, and the platform has no field for it. Because pupils write free text in their code, comments and quiz answers, the School should instruct pupils not to enter sensitive personal information into their work. MyCodePad cannot filter free text and does not inspect it.
Criminal offence data: none is requested or required.
7.Documented processing instructions
MyCodePad will process the School's personal data only on the School's documented instructions, including on transfers, except where required to do otherwise by law. Where the law requires it, MyCodePad will tell the School first unless the law prohibits that.
The School's documented instructions are:
- This agreement and the subscription it supplements.
- The School's and its teachers' use of the platform's own features — creating classes, issuing invite codes, setting and marking work, enabling or disabling AI help, adding and removing members.
- Any further written instruction the School gives to the privacy contact in clause 19.
MyCodePad will tell the School if, in its opinion, an instruction infringes UK data protection law. MyCodePad may implement a further written instruction that requires development work, or that materially changes the service, subject to agreement on feasibility and cost.
8.Confidentiality
MyCodePad ensures that every person authorised to process the School's personal data is bound by an appropriate duty of confidentiality, whether contractual or statutory, and that access is limited to those who need it to provide or support the service.
To be documented
The operator must be able to evidence this: confidentiality terms in staff and contractor agreements, a record of who holds production access, and the operational controls around support access to the live database. None of this can be read from the codebase, so it has to be documented separately before this clause can be relied upon.9.Technical and organisational security measures
MyCodePad implements appropriate technical and organisational measures under Article 32, taking into account the state of the art, the costs of implementation, the nature of the processing and the risk to data subjects — who in this case include children.
The measures currently implemented are listed in Appendix C. Each one is implemented in the product today and can be evidenced on request.
Certifications held: None held. MyCodePad does not hold Cyber Essentials, ISO 27001 or any other security certification, and does not claim to. MyCodePad does not claim any certification it does not hold, and the absence of a certification above means none is claimed.
10.Subprocessors
The School gives general authorisation for MyCodePad to appoint subprocessors. Those currently appointed are listed in Appendix B.
MyCodePad will:
- give the School To be confirmed: notice period before a new subprocessor is added notice before adding or replacing a subprocessor, so the School has a genuine opportunity to object;
- impose data protection obligations on each subprocessor that are no less protective than those in this agreement; and
- remain fully liable to the School for a subprocessor's performance of those obligations.
If the School reasonably objects to a new subprocessor on data protection grounds, the parties will discuss it in good faith. Where no resolution is reached, the School may terminate the affected part of the service.
Notice mechanism to be built
There is currently no mechanism for notifying schools of a subprocessor change. A notification route — at minimum, email to school administrators and a dated list on this page — is needed before this clause can be met in practice.11.Assistance with data subject rights requests
Taking into account the nature of the processing, MyCodePad will assist the School by appropriate technical and organisational measures, so far as possible, in responding to requests from pupils and staff exercising their rights under Chapter III.
Where a request reaches MyCodePad directly, MyCodePad will not respond to it itself unless the School instructs it to. It will tell the School without undue delay and pass the request on.
How an erasure request from a School-managed account is handled
This is implemented rather than merely promised. When a pupil or member of staff whose account belongs to the School asks to be erased, the platform records the request, gives it a reference, sets the response deadline at one month from receipt, and places it in the School's own queue on its school dashboard rather than acting on it. MyCodePad does not delete work produced for the School without the School's instruction.
From that queue, an administrator of the School — and only of that School — can record that the requester's identity has been verified, record separately that their authority to ask has been established, and mark the request completed or refused. A completion must say what was deleted, transferred or retained, and a refusal must state its grounds, because the School has to give those grounds to the requester. Every one of those steps is written to an audit trail with the administrator's name and the time.
The plan that governs what happens to each kind of record is published to the account holder before they ask, and distinguishes a teacher from a pupil from an administrator. A teacher leaving does not delete their classes: their identifiers are removed from the feedback they left, and the classes and pupil work transfer to the School. An administrator who created the School cannot be removed until School ownership has been transferred, because the database would otherwise delete the School with them.
What this assistance currently looks like
Schools should know exactly what they are relying on. Requests are now tracked to a decision with a visible deadline, but fulfilment is still manual: no code in MyCodePad deletes an account, and there is no single export covering an individual's account, classes, feedback and starter results. The queue also sends no notification, so the School should nominate someone to check it. The practical turnaround for a bulk request should be agreed with the School rather than assumed from this clause.The platform does let a teacher or administrator correct a pupil's name and remove a member from a school, and lets a pupil download their own files from inside either editor at any time.
12.Personal data breaches
MyCodePad will notify the School without undue delay after becoming aware of a personal data breach affecting the School's personal data, and in any event within To be confirmed: deadline for notifying a school of a personal data breach of becoming aware of it.
The notification will include, so far as it is known at the time:
- the nature of the breach, including the categories and approximate number of data subjects and records affected;
- the likely consequences;
- the measures taken or proposed to address it and to mitigate its effects; and
- a contact point for further information.
Where the full picture is not available at once, MyCodePad will provide information in phases rather than delay the initial notification. MyCodePad will assist the School with its own obligations to notify the ICO under Article 33 and affected individuals under Article 34, and will keep a record of breaches, their effects and the remedial action taken.
Set a deadline you can actually meet
The deadline above must be chosen deliberately. A school will often ask for 24 hours. Committing to a window the operator cannot meet — given on-call arrangements, monitoring and out-of-hours cover — creates a contractual breach on top of a data breach. Monitoring and alerting sufficient to detect a breach promptly should be in place before any figure is agreed.13.Data protection impact assessments and prior consultation
MyCodePad will provide reasonable assistance to the School with any data protection impact assessment under Article 35, and with any prior consultation of the ICO under Article 36, where these relate to the School's use of the platform.
That assistance takes account of the nature of the processing and the information available to MyCodePad: the descriptions in the appendices to this agreement, the security measures, the subprocessor list, and answers to specific questions about how a feature works.
MyCodePad's own DPIA status is To be confirmed: whether a DPIA has been carried out, by whom and when. No assessment has been completed at the time of writing, and MyCodePad does not claim that one has. A School whose own DPIA depends on the supplier having assessed its processing should ask for the current position before relying on this clause.
14.International transfers
MyCodePad will not transfer the School's personal data outside the United Kingdom except in accordance with this clause and with UK data protection law.
The hosting region is To be confirmed: Vercel deployment region(s) and the database region is To be confirmed: Neon database region. Where a transfer outside the UK takes place, the safeguard relied upon is To be confirmed: transfer mechanism relied on for any processing outside the UK.
Not yet established
The processing locations of the payment, email and AI providers in Appendix B have not been verified, and no transfer risk assessment has been carried out. A school that requires UK or EEA-only processing must not assume it from this page. These facts must be read from live configuration and confirmed with each provider before this clause can state anything definite.15.Audits and compliance information
MyCodePad will make available to the School the information necessary to demonstrate compliance with Article 28, and will allow for and contribute to audits, including inspections, conducted by the School or an auditor it mandates.
The practical arrangements for audits are To be confirmed: audit and inspection arrangements offered to schools. MyCodePad does not place restrictions on this right beyond those agreed in writing with the School, and no restriction should be read into the absence of detail here.
MyCodePad will respond to reasonable security and data protection questionnaires as part of the School's own supplier assurance process.
16.Return and deletion at the end of the contract
At the School's choice, MyCodePad will delete or return all the School's personal data at the end of the provision of the service, and delete existing copies, except to the extent the law requires it to be kept.
The School must make its choice within To be confirmed: period within which school data is returned or deleted at the end of a contract of the end of the subscription. Absent an instruction, MyCodePad will delete.
A deletion routine has to be written first
This is the clause the School should press hardest on. Most application tables reference users and classes by plain identifier columns with no database-level cascade, so deleting an account would leave that person's files, enrolments, comments, starter responses and share links behind. A deletion routine must be written and tested table by table before this clause can be honoured, and before any assurance is given to a school that deletion is complete. Backups are retained for To be confirmed: backup retention window and the point at which deletions reach backups, and deleted data persists in them until those expire.Removing a member from a school through the school dashboard marks their membership as removed. It is a membership change, not erasure, and it does not satisfy this clause.
17.Retention required by law
Where the law requires MyCodePad to retain personal data beyond the end of the contract, it will retain only what is required, for only as long as required, and will continue to protect it under this agreement.
The main example is billing and tax records, retained for To be confirmed: retention period for billing and tax records. MyCodePad will tell the School what has been retained and why, on request.
18.Responsibilities of the School and of MyCodePad
The School
- Determines the purposes and means of the processing it instructs, and is responsible for having a lawful basis for it.
- Provides its own privacy information to pupils, parents and staff. This page is not a substitute for the School's own privacy notice.
- Carries out any DPIA its own processing requires.
- Ensures instructions given through the platform are lawful, including decisions about who may see pupil work.
- Keeps its membership accurate, and removes staff and pupils who should no longer have access.
- Issues and controls invite codes responsibly; anyone holding a live code can join the School.
- Instructs pupils not to put sensitive personal information into free-text fields such as code, comments and quiz answers.
- Considers whether pupils should be permitted to publish work as public links, which the platform allows and which do not expire.
MyCodePad
- Processes only on the School's documented instructions.
- Maintains the security measures in Appendix C and does not reduce the overall level of security during the contract.
- Maintains a record of processing carried out on the School's behalf under Article 30(2).
- Assists with rights requests, breaches, DPIAs and prior consultation as set out above.
- Does not use the School's personal data for its own purposes beyond the limits in clause 2.
- Does not sell personal data, and operates no advertising, marketing or profiling technology.
19.Contact points
Notices under this agreement should be sent to the addresses below. The School should give MyCodePad a named data protection contact and keep it current.
Contacting MyCodePad about personal data
- Operator:
- To be confirmed: registered legal name of the MyCodePad operator
- Postal address:
- To be confirmed: registered or trading postal address
- Privacy enquiries:
- To be confirmed: privacy and data protection contact address
- Security and breaches:
- To be confirmed: security and breach notification contact address
- Data Protection Officer:
- To be confirmed: whether a Data Protection Officer has been appointed, and their contact details
20.Appendix A — Description of the processing
Populated from the audit of the live database schema. Where a value could not be established from the implementation, it is marked rather than filled in.
A.1 Categories of data subject
- Pupils of the School, including children.
- Teaching staff and tutors.
- School administrators.
A.2 Categories of personal data
| Category | Contents | Held in |
|---|---|---|
| Account identity | Name, email address, role (student or teacher), account type, chosen avatar key, first-login and onboarding flags, the last editor opened, and created/updated timestamps. | user table |
| Authentication credentials | A hashed password, managed by Better Auth. Password reset tokens with expiry times. MyCodePad never stores a password in a form it can read. | account.password, verification tables |
| Session records | A session token, its expiry, and the IP address and browser user-agent recorded when the session was created. | session table |
| Code and project work | The contents of every file a user writes, its name, language and folder, the pupil's version from immediately before any teacher correction, and marking status. | code_file, student_folder tables |
| Teacher feedback and corrections | Comments left on a pupil's file with the teacher's name, the pupil's reaction to each comment and when they gave it, and an attributed record of any line a teacher edited directly. | file_comment, code_file.teacherEditedBy* columns |
| Tasks and lesson material | Teacher-authored task instructions, topic, difficulty, year group and learning objective, plus worked solutions that are never served to a student. | file_task, library_file, library_folder tables |
| Starter quiz activity | A pupil's answers, score and total for each daily starter, the frozen record of their first attempt, when they opened it and when they submitted. | daily_starter_response, daily_starter_open tables |
| Class and school membership | Which classes a pupil is enrolled in, which teacher owns each class, school membership with its role and active/removed status, and which invite code a member redeemed. | enrollment, class, school_member, invite_code tables |
| AI help activity | A record of each request to unlock AI error help, tied to the pupil, the file and a signature of the error, with the time the hint becomes available. | ai_help_unlock table |
| Subscription and billing | Plan, status, billing interval, Stripe customer and subscription identifiers, the price identifier, the current period end and whether a cancellation is scheduled. Card details are handled by Stripe and never reach MyCodePad. | subscription, school_subscription, stripe_event tables; lib/checkout.ts |
| Security logs | Failed class join-code attempts, recorded against both the user and the raw IP address they came from, so a guessing attack can be throttled. | join_attempt table; app/actions/classes.ts |
| Public share links | Where a file has been published as a link, the random token, who owns the file and whether the link has been revoked. Anyone holding a live token can read that file without an account. | file_share table; app/s/[token] |
A.3 Special category and criminal offence data
None requested or required. The platform provides no field for it. Free-text fields cannot be filtered, hence the School instruction in clause 18.
A.4 Purposes of the processing
As set out in clause 4. In summary: providing accounts, storing and displaying pupil work, running classes and assignments, recording marking and feedback, running starter quizzes, providing teacher-controlled AI assistance, administering school seats and invite codes, securing the service and supporting the School.
A.5 Frequency and duration
Continuous for the duration of the subscription: processing happens whenever a pupil or member of staff uses the platform.
A.6 Retention and deletion
| Data | Arrangement | Status |
|---|---|---|
| Files deleted by a pupil or teacher | Removed from the database, along with any public share link attached to them. | Implemented |
| Classes deleted by a teacher | The class and its enrolments are removed. | Implemented |
| Sessions | Expire on their own, and are revoked in bulk on password change or reset. | Implemented |
| Password reset tokens | Expire one hour after issue. | Implemented |
| School membership after removal | Marked as removed; the account and its work remain. | Implemented — but not erasure |
| Erasure requests | Recorded with a reference, a one month deadline, verification checks and an audit trail, and routed to the School for decision. | Implemented — tracking only, not deletion |
| Account and work data after closure | To be confirmed: retention period for account and work data after an account is closed | Requestable and tracked; fulfilment is manual |
| The erasure request record itself | To be confirmed: retention period for the erasure request record itself | Holds the subject's name and email so the record survives the account |
| Backups | To be confirmed: backup retention window and the point at which deletions reach backups | To be confirmed with provider |
| Security logs, including failed join attempts with IP addresses | To be confirmed: retention period for security logs, including failed join-code attempts | Not implemented — table is not pruned |
| End of school contract | To be confirmed: period within which school data is returned or deleted at the end of a contract | Depends on a deletion routine that does not exist yet |
21.Appendix B — Subprocessors
Every provider that receives personal data, identified by reading the application code rather than taken from a vendor list.
| Subprocessor | Processing activity | Personal data received | Location |
|---|---|---|---|
| Vercel | Application hosting, serverless execution and privacy-friendly page analytics | Everything processed in a request, in transit. Analytics is enabled in production only and records page views without cookies. | To be confirmed: Vercel deployment region(s) |
| Neon | Managed PostgreSQL database | All stored personal data listed above. | To be confirmed: Neon database region |
| Stripe | Payment processing and subscription billing | The billing email address passed to Checkout, plus the payment details the customer enters directly with Stripe. MyCodePad stores only Stripe's identifiers in return. | To be confirmed with the provider |
| Resend | Transactional email delivery | Recipient email address, name where the template uses it, and message content for welcome and password reset emails. | To be confirmed with the provider |
| Vercel AI Gateway and OpenAI | AI error help, task generation and starter generation | For error help, the pupil's code (up to 8,000 characters) and the error message their program produced. For task and starter generation, the teacher's topic, year group and objective. No name, email or account identifier is included in the prompt. | To be confirmed with the provider |
| jsDelivr | Public CDN serving the Pyodide runtime that executes Python in the browser | The browser's IP address and request headers when it downloads the runtime. No account data is sent, and the code a pupil writes is executed locally in their own browser rather than uploaded. | To be confirmed with the provider |
Outstanding for this appendix
- The processing location of each provider must be confirmed, and the hosting and database regions read from live configuration.
- A signed data processing agreement with each provider must be obtained and kept on file.
- Whether the AI provider retains prompts, and whether it trains on them, must be confirmed in writing. Pupil code is sent to it.
- jsDelivr is a public CDN serving the Python runtime. Whether it is a subprocessor at all, or simply a third party the pupil's browser contacts directly, needs a legal view.
22.Appendix C — Technical and organisational security measures
Measures implemented in the product today. Nothing is listed here that cannot be pointed at in the code.
| Measure | Implementation |
|---|---|
| Password storage | Passwords are hashed by Better Auth and never stored in readable form. Changing a password requires the current one, and succeeds only by signing every other device out. |
| Session invalidation on password reset | Completing a password reset revokes every existing session for that account, on the assumption that the old password may be compromised. |
| Server-side authorisation on every read | Access to a class, a file or a task is resolved on the server from the session, not from anything the browser sends. Hiding a control in the interface is never the only barrier. |
| Role escalation blocked at the database layer | The role requested at sign-up is clamped to student or teacher before the user row is created, and the account endpoints strip role changes, so school administrator cannot be self-granted. |
| Teacher-only fields never selected for students | Student-facing queries list their columns explicitly rather than returning whole rows, which is what keeps worked solutions out of a pupil's response. |
| Durable throttling of class join codes | A join code is a bearer credential, so failed attempts are counted in the database against both the account and the IP address. The limit therefore survives cold starts and cannot be spread across serverless instances. |
| Webhook replay protection | Stripe events are recorded by identifier once processed, so a retried webhook cannot apply the same billing change twice. |
| Transport security and browser hardening | HSTS, X-Content-Type-Options, Referrer-Policy and cross-origin isolation headers are set for every route. Traffic to the database and to every provider is encrypted in transit. |
| Sandboxed code execution | Python runs in a web worker inside the pupil's own browser, and HTML previews render in a sandboxed frame that cannot reach the parent page, its cookies or the session that owns it. |
| Restrained logging | Email delivery failures are logged without the recipient address or message body outside development. |
Measures not yet in place
Listed so that a school's security review starts from an accurate picture rather than discovering them later:
- No Content-Security-Policy or Permissions-Policy response header.
- No multi-factor authentication for any role, including school administrators.
- No email address verification at registration.
- No account deletion routine, and no database-level cascade from a user to most of their data.
- No pruning of the security log that records IP addresses.
- No expiry, password protection or oversight on public share links.
- No documented record of who holds production database access, and no documented support-access procedure.
- No penetration test or independent security assessment.
23.Status of this draft
Do not sign this as it stands
This is version 0.1 — draft for legal review. It is a drafting basis, written to track Article 28(3) clause by clause and to be honest about what the platform does and does not do yet. It has not been reviewed by a qualified adviser, has no effective date, and is not a substitute for a signed agreement.
The clauses most in need of review before a school relies on this document are the role allocation in clause 2, the breach notification deadline in clause 12, the transfer position in clause 14, the audit arrangements in clause 15, and the return and deletion obligation in clause 16 — which cannot currently be honoured because the deletion routine it depends on does not exist.
Schools evaluating MyCodePad are welcome to send this page to their own data protection adviser and come back with requirements. Contact To be confirmed: privacy and data protection contact address.
Pre-publication checklist
Every item below is marked somewhere in these documents and must be resolved before any of them is published or relied upon. They are listed here as well so the list can be worked through in one pass.
- 01
Registered legal name of the MyCodePad operator
UK GDPR Article 13 requires the identity of the controller. Only the operator knows whether MyCodePad trades as a limited company, a sole trader or a partnership.
- 02
Registered or trading postal address
Article 13 requires contact details for the controller, and schools need a service address for a signed DPA.
- 03
Privacy and data protection contact address
Data subject rights requests need a route that is actually monitored.
- 04
Security and breach notification contact address
Article 33/34 breach handling and the DPA both depend on a reachable security contact.
- 05
General support contact address
Referenced by the Terms for service and billing queries.
- 06
Whether a Data Protection Officer has been appointed, and their contact details
Article 37 requires a DPO in some cases. Processing children's data at scale makes this a decision that must be taken deliberately and recorded, not assumed either way.
- 07
ICO data protection fee registration number
Most UK controllers must pay the data protection fee and register. The number must not be invented, and registration status must be confirmed before it is claimed.
- 08
UK or EU representative, if the operator is established outside the UK
Article 27 may require a representative. Depends on where the operator is established.
- 09
Governing law and jurisdiction for the Terms
A jurisdiction clause is a commercial and legal decision, and consumer protection rules limit what can be imposed on UK consumers.
- 10
Statutory cancellation / cooling-off position for individual subscriptions
The Consumer Contracts Regulations give a 14 day right to cancel distance contracts, with specific rules where a digital service starts immediately. How this is handled must be confirmed before it is described.
- 11
Refund policy beyond statutory rights
No refund logic exists in the billing code. Any discretionary refund promise is a commercial commitment.
- 12
VAT registration status and whether listed prices include VAT
Stripe is configured with plain GBP amounts and no tax behaviour, so the published prices cannot be described as VAT-inclusive or exclusive until this is confirmed.
- 13
Support response target, if any is offered
Several plans advertise "priority support". What that means in practice is a commitment that has to be set deliberately.
- 14
Internal complaints process and escalation route
Referenced by both the Terms and the Privacy Policy, and expected by schools procuring the service.
- 15
Retention period for account and work data after an account is closed
Erasure is now requested through the account area and carried out by hand against a recorded plan, so there is a process — but no decision has been taken on how long anything is kept before that plan runs, or whether a grace period applies in which a request can be reversed.
- 16
Retention period for the erasure request record itself
Each request stores the subject's name and email so the record still means something after the account is deleted, which is what lets MyCodePad show a regulator the request was handled. That record is itself personal data and cannot be kept forever without a stated period.
- 17
How a parent or guardian's authority to act for a child is established
The request form accepts a parent or guardian as the requester, and the product holds nothing that links a parent to a pupil. The check is therefore a documented human procedure, and acting on an unverified claim would disclose or destroy a child's data on a stranger's say-so.
- 18
Backup retention window and the point at which deletions reach backups
Set by the database provider's configured plan and by operator choice, and must be read from the live Neon project rather than assumed.
- 19
Retention period for billing and tax records
UK tax law sets minimum record-keeping periods, which interact with deletion requests. The applicable period depends on the operator's legal form.
- 20
Retention period for security logs, including failed join-code attempts
Failed join attempts record raw IP addresses and are not pruned by any code in this repository.
- 21
Whether dormant accounts are deleted, and after how long
Storage limitation requires data not to be kept indefinitely without reason. No dormancy policy is implemented.
- 22
Period within which school data is returned or deleted at the end of a contract
Article 28(3)(g) requires the processor to delete or return personal data at the end of the service. The window is a contractual term.
- 23
Vercel deployment region(s)
Determines where the application runs and whether a transfer outside the UK occurs. Must be read from the live Vercel project configuration.
- 24
Neon database region
Determines where personal data is stored at rest. Must be read from the live Neon project.
- 25
Transfer mechanism relied on for any processing outside the UK
The UK Addendum to the EU SCCs, the IDTA or adequacy may apply. Which one, for which provider, is a legal determination.
- 26
Deadline for notifying a school of a personal data breach
Article 33(2) requires notification "without undue delay". A specific number of hours is a contractual promise that the operator must be able to meet.
- 27
Audit and inspection arrangements offered to schools
Article 28(3)(h) requires audits to be permitted. The practical form — questionnaire, report, on-site — is negotiated.
- 28
Notice period before a new subprocessor is added
Article 28(2) requires the controller to have an opportunity to object to changes.
- 29
Whether a DPIA has been carried out, by whom and when
Processing children's personal data at scale is likely to require a DPIA under Article 35. No assessment is recorded in this repository.
lib/legal.ts. Filling in its value replaces the marker everywhere it appears and removes this row.