Privacy policy

Discia's worksheets are free, need no account, and ask nothing about you. There are also accounts for tutors, and for the students and parents those tutors work with. A tutor can make one for themselves; a student or parent can make one only with their tutor's join code or an invitation from us. This page explains what is recorded on each side, why, and for how long.

Who we are

Discia is operated by Mashdup Limited, a company registered in England & Wales (company number 17020411), registered office 124–128 City Road, London, England, EC1V 2NX (“we”, “our”). We are the data controller for the personal data described here.

We are registered with the UK Information Commissioner's Office (ICO), registration reference ZC197200. We have not appointed a Data Protection Officer, as we are not required to.

For any privacy question, or to exercise your rights, contact privacy@discia.org.

This policy is written under the UK GDPR and the Data Protection Act 2018.

The two halves of this site

Almost everything on Discia is the first of these, and it is the part you are reading now.

• The worksheets — open to everyone, anonymous. Every worksheet page, the on-screen “generate another”, the answers and printing from your browser are free, need no account, and ask you for nothing: you give us nothing at all by reading one. The downloadable PDF of a sheet is free and needs no account today as well, and it is the one part of this half of the site that could change — see the download allowance below, which says what is built, what is switched off, and what we will publish before any of it runs.
• Accounts — for tutors, and for the families they teach. A tutor can create an account for themselves: we email a link to the address they give, and the account is made only when they open it. A student or a parent can create one only with a tutor's join code, or from a single-use invitation we issue by hand. Without one of those there is no sign-up for a student or a parent.

The short version

• The worksheet pages set no cookies of their own.
• Tutors can sign up; students and parents only with a tutor's join code, or from an invitation we have issued to a named person.
• There is no analytics service, no tag manager and no tracking pixel. The worksheet pages do keep anonymous daily totals of how each worksheet is used (viewed, printed, and so on), with nothing in them about who you are; see How we count worksheet use.
• The pages make no third-party requests at all — no content delivery network, no web font, no embedded widget. Your browser talks to this site and to nothing else.
• We ask you for no personal data, and you give us none by reading a worksheet.
• We send eight kinds of email and no others: a link to confirm an email address on an account; a password-reset link to somebody who has asked for one; a warning before we delete a student account nobody has used for a year; a link to finish signing up, to somebody who asked for an account; and four to a parent, each about something they, their child or their child's tutor did: asking them to confirm a child they added, a receipt when they do, a note when their teenager's tutor accepts them, and a note that a tutor has sent a progress report. No newsletter, no marketing, no announcements. Reading a worksheet never puts you on any list, because we never learn your address. See Email we send.
• We do not count what you download. A monthly allowance on worksheet PDF downloads is written into this site and is switched off, so no account carries a tally of sheets taken and we keep no list of them. Asking for a PDF does write an ordinary line in the server log, like asking for any other page or file — see what we actually record and the download allowance.

Because the worksheet pages start no cookies and contact no third party, there is no consent banner on this site. There is nothing to consent to in order to read a worksheet.

What we actually record when you read a worksheet

Our web server keeps a request log. (Until version 2.5 there were two: the application behind the web server kept a second copy of the same lines. We switched it off, and it is no longer written.) The log records your IP address, the date and time, the page or file requested, the response status and size, the referring page if your browser sent one, and your browser's user-agent string. A worksheet PDF is a file like any other, so asking for one writes a log line like any other, and that line names the sheet you asked for. An IP address can be personal data under the UK GDPR, so we treat the log as personal data.

Purpose: keeping the site running, diagnosing faults, protecting it from attack and abuse, and counting, in total, how many requests the site receives and how many come from automated programs. Lawful basis: our legitimate interests (Article 6(1)(f)) in operating and securing the service. We consider this proportionate because the data is minimal, is not used to build a profile of you, is never used for advertising, and is deleted quickly.

Retention: 14 days. The log is rotated and deleted automatically after that, and it is not included in our off-site backups, so this data never leaves the server it was written on.

We do not sell, rent or share this data. We do not use automated decision-making or profiling.

How we count worksheet and game use

We want to know whether the worksheets are any use to anyone, and the request log cannot tell us: much of what reaches this site is automated programs, not people. So each worksheet page runs a short script that tells our own server when certain things happen on it: the page was viewed, it was printed, an answer was revealed, or one of its buttons was used (a different sheet, another question like this one). The server also counts each worksheet PDF it sends. The practise online page counts three things the same way: that it was opened, that an answer was revealed, and that somebody marked themselves right. What you type into its answer box, and how you marked yourself on any particular question, never leave your browser. The fluency game pages count two things: that a game page was opened, and that a round was started, with the round's level and whether it had a clock. When a round ends, the page also sends the round's code and the answers given, so that our server works out the score itself rather than trusting the page. The answers are read and thrown away. The score is added to a total, which is how a player can be told that they beat, say, 70% of rounds played in the last 30 days. So that the same round is not counted twice, we keep a scrambled copy of the round's code for one hour; it identifies nobody.

What we keep is a total per worksheet or game, per event, per day, for example “Surds, printed, 30 September: 4” or “Times tables, level 2 round started, 30 September: 7”, and for the games a total per score, such as “Times tables, level 2, 60 seconds, a score of 23, 30 September: 3”. That is all of it. The count stores no IP address, no browser or device details, no time more exact than the day, and no identifier of any kind, and it puts nothing on your device: no cookie, no local storage. The message the script sends carries only the worksheet's or game's name, the event's name and, for a round, its level and kind, or its code and answers when it ends, and receiving one does not write a line in the request log. Nothing in the totals can be traced back to you, so they are not personal data, and we keep them for as long as they are useful for seeing how the worksheets are used over time.

If your browser blocks scripts, nothing is counted and every worksheet works exactly the same.

Accounts

If someone creates an account — as a tutor, with a tutor's join code, or from an invitation — we hold more than a log line, and this section sets all of it out in three lists. The first is the account record itself, held against every account. The second exists only on an account we have put on a plan ourselves — there is no way to do that from the site, so most accounts carry no such record at all. The third is everything the site writes against an account as it is used. Between those three and the server log above, that is everything we hold about a person.

On every account:

• A username, which the account holder chooses.
• A first and last name, if given — both are optional.
• An email address. Required for a parent or teacher account, because they are the adult we need to be able to reach. Required too for a student of 13 or over who makes their own account with a tutor's join code, because that is where we send the link that makes it. Optional otherwise: a child whose parent made their account has no address of their own and we have no use for one.
• A date of birth. Used to decide whose consent counts for the account (a parent's under 13, the student's own from 13) and who adds a tutor for a student, and, when an account is made by sign-up, that a parent or tutor account belongs to someone 18 or over (see “Children” below). An account made by sign-up keeps the date typed on the form; one typed again later is not read. We do not verify it and we do not use it for anything else.
• A password, stored only as a one-way hash. We never hold the password itself and cannot recover or read it.
• A role — student, parent or teacher. A tutor chooses it on the sign-up form, and a student or parent on a tutor's join page; otherwise the invitation we issued sets it.
• Which GCSE tier a student sits — Foundation or Higher — where we have recorded it. It is set by us, not by the student, and it is used for two things: leaving the topics that are not on their paper off their progress pages, and choosing practice questions that are on their paper. Most accounts have nothing recorded here.
• Links to other accounts: to a parent or a tutor, made by an invitation, by a parent adding their child, or by a family typing a tutor's join code (see Children).
• Three dates the account keeps about itself: when it was created, when it was last signed in to, and — where the account has an email address — when that address was confirmed by following the link we sent. Nobody types these; the site writes all three.
• Whether the account is switched on, so that we can close an account without deleting it if somebody asks us to, and whether it is one of the administrator accounts the operator uses to run the site. If consent has been withdrawn, the account also records when it was closed and the date it will be deleted; see Children. If a student account has gone unused for 12 months, it records when we sent the warning that it is about to be deleted; see How long we keep things.

Only where we have put an account on a plan, by hand:

• The plan the account is on, the status of the record (active, cancelled and so on), and an end date where the plan has one.
• Who granted it. A link to the administrator account that created the record, and a separate copy of that person's username, kept so that the answer survives their own account being deleted.
• A note saying why. Free text we write ourselves — an invoice reference, a school's purchase order, or simply that it was given free. Whatever we put there is personal data about the account holder, so we keep it short and factual, and you can ask to see it like anything else on this page.
• A payment-provider reference, which is empty on every record there is: no payment provider is connected to this site.
• The dates the record was created and last changed.

Nothing here takes payment and there is no way to buy a plan. A plan is an administrative record rather than a receipt: it exists so that we can say a named account was given something, by whom, and why. If it ever becomes part of a paid arrangement, this policy will say so before that happens rather than afterwards.

Lawful basis. For a student's account and everything their practice generates, we rely on consent (Article 6(1)(a)): for a child under 13, the consent of the holder of parental responsibility (Article 8); from 13, the student's own. We record each consent, and it can be withdrawn at any time; see Children. For a parent's or teacher's own account, the basis is Article 6(1)(b) — performing the agreement to provide the account holder with the service they asked for — which is also the basis for the plan, its status and its dates where a plan record exists. For the two fields recording who granted a plan, and for the note, we rely on our legitimate interests (Article 6(1)(f)) in being able to answer afterwards who gave an account something and why — nothing else on this site records it.

The download allowance: built, and switched off

One thing on this site is written and not running, and we would rather disclose it than have you find it. The code that would cap how many worksheet PDF files a signed-in account may download in a calendar month exists, and it is switched off. Nothing counts your downloads today: no account carries a tally, we keep no list of which sheets anybody has taken, and the worksheet pages, the answers and printing from your browser are not part of it at all.

What a download does leave is exactly what every other request leaves — a line in the server logs described under what we actually record, naming the file that was asked for, kept 14 days and then deleted. That is the record of a request arriving, not a tally kept against anybody, and it is the same whether you are signed in or not.

If we switch it on, an account would from that moment carry two things it does not carry now: a count of how many worksheet PDFs it has taken in the current calendar month, and a list of which sheets those were, kept so that fetching the same sheet again does not normally count against it a second time. Neither exists today, which is why neither is in the lists above. We will publish a new version of this policy describing them before it is switched on, not afterwards — the same commitment version 2.0 made about email, and kept.

What else is written against an account as it is used

The two lists above are the account record. Using the site writes more than that, and rather than let an “and so on” do the work, here is the whole of it. Most of these only ever exist for one kind of account, and the last one exists only on the administrator accounts the operator uses to run the site.

• Being signed in. Signing in issues your browser a renewable sign-in token and opens a matching session on our side. We keep a copy of each token against the account, with the time it was issued, the time it stops working, and whether it has been withdrawn — which is what makes signing out, or changing a password, genuinely end a session rather than merely forget it. These are security records: they say when somebody signed in, and nothing whatever about what they did afterwards. The token stops working after 14 days, and the record of it is deleted within a day or so of that.
• Practice — the sessions, answers, marks and estimates set out under what we record as a student practises below, together with which account marked a piece of work where a teacher marked it.
• Fluency games — the fluency game rounds a student plays while signed in. For each round: the game, the level and the kind of round, the score, how many questions were answered, how long a round with no clock took, the date, up to twenty of the questions got wrong, with their answers, and, where a tutor set the game as homework, which homework the round counted towards. What the student typed is not kept. The student, their linked tutors and their linked parents can see these rounds. They never change the topic estimates described under what we record as a student practises. They are kept as long as the account and deleted with it. Each round's score is also added, with no link to the account, to the anonymous totals described under how we count worksheet and game use. A tutor can also run rounds for their student in a lesson, on the tutor's account; those are kept with the student's rounds in the same way, marked as played in a lesson, and do not count towards homework.
• A difficulty rating a student has given a question, where they have used that control: the score out of ten, and how they did on that question at the time.
• Links between people. Parent to child, carrying the parental-consent stamp described under “Children”: when we asked for the parent's consent, when they confirmed it from our email, when it took effect, which version of this policy and of the declaration they were shown, and, where we review it ourselves, when we approved it. Teacher to student, and where a family used the tutor's join code, who typed it, the name they gave the tutor, when, and when the tutor accepted; membership of a teacher's class group; and the work a teacher has set to a group or to one student, with an optional due date.
• A student's consent decisions. Each time a student agrees to us using their practice data, acknowledges their parent's consent, says yes or no to a parent seeing their work, is told what a tutor can see, or agrees to a tutor added with the tutor's join code, we keep a record of it: what it was about, the decision, the name of the parent or tutor it concerned, who made it, the student's age at the time, the version of this policy in force, and the date. If consent is later withdrawn, or a tutor link ends, the record says when, and a second record says who ended it: the student, their parent, the tutor, or us. These records are kept with the account and deleted with it.
• Invitations, and how an account was made. An invitation records who issued it and, once it has been used, which account it created. When an account is made by sign-up (a tutor signing up, a family with a tutor's join code, or a parent adding a child), the site makes the invitation instead of us, and it also records which of those it was, the email address, the date of birth and the account type that were given. For a tutor, it also records which version of the tutor terms they ticked. It counts wrong codes typed against it, to stop guessing.
• A tutor's join code, on a tutor's account, which the tutor can change at any time. It is meant to be given to the families they teach.
• On a tutor's account, for the free plan's limit: the date each student they had accepted stopped being their student, kept for 30 days because until then that student still counts towards the limit; and, if the tutor has more students than their plan allows, the date we first saw it. Neither names a student.
• On a tutor's account, the tutor terms they accepted: which version of our tutor terms, and when. A tutor who signs up ticks a box accepting them, and we record it when their account is made. Kept as long as the account.
• Progress reports sent about a student, as described in Progress reports below.
• A saved whiteboard, if the account holder has used the drawing canvas: its title, the drawing itself, any question placed on it, the dates it was made and last changed, and — on a tutor's board — which student it is for. A tutor opens a student's boards from that student's page and uses them in lessons: on screen beside the student, or, in an online lesson, by sharing their screen through the video-call service the tutor and family already use (that service is not part of Discia, and its own privacy terms apply). New boards are titled with the date, not the student's name. Only the account that made a board can open it — the student it is for, their parent and other tutors cannot. A board is deleted with the account that made it, and a board made for a student is also deleted with that student's account.
• Lesson notes, on a tutor's account. After a lesson a tutor may write one note about it for the student: the date of the lesson and what the tutor writes about it. To save the tutor time, the note starts as a draft that our own server fills in from that lesson's records on Discia — the practice sessions, the marks, how our estimate of each topic changed, and any work set. The draft is built by fixed rules, not by an AI, and no other service is used to write or read it. A note has two parts. The main part is private: only the tutor who wrote it and the site's operator can read it — not the student, not their parent, and not any other tutor — except that a copy is included if the child, or their parent, asks us for their data. The second part, written for parents, is optional, and is stored but not shown to anyone yet; if we ever show it to parents, we will say so here first. While a lesson is running, notes are hidden on the tutor's screen unless the tutor chooses to show them. If a tutor stops being linked to the student, their notes stay but only the operator can read them. The operator may delete a note, for example when a family asks, but never rewrites one. Notes are deleted with the student's account, and with the account of the tutor who wrote them.
• Saved themes, on a teacher account: a name the teacher chose and the list of topics saved under it, used to set the same group of topics again. It holds nothing about any student. Only the teacher who saved a theme can see it, and deleting the theme or the account deletes it.
• On administrator accounts only: a log of every change made through our administration tools — which account made it, to what, and when. A few records the operator creates while running the site carry the same author stamp: where new questions are being prepared from past papers, which drafts that account reviewed, the topics it chose and any parser fault it reported; and, in the curriculum, which account added a link between two topics. These exist so that an operational change has an author. An ordinary student, parent or teacher account never has any of them.

What we record as a student practises

A signed-in student's practice generates records tied to their account: the practice sessions they start, the questions they were served, the answers they typed or drew, whether each was marked right or wrong, the marks scored, and the dates and times. About half of each topic's questions in a session are drawn from that topic's core skills, the methods its exam questions ask most often, and the session records which questions were drawn that way. That choice is made the same way for every student and uses nothing about them. An answer that is drawn on a grid is saved as it is drawn, so a drawing a student started and never submitted is kept as well. From those answers we calculate a running estimate of how confident the student looks on each topic, and a score history per topic.

Behind those estimates sits a statistical model, and it keeps records of its own. We hold the individual answer records that the statistical side of the estimate reads, a record of each calculation we run and which student it was run for, the ability estimate it produces for a student on a topic, and — where a session is choosing questions adaptively — the estimate a session keeps while it is choosing the next question. A practice session also keeps a record of each question it would suggest next, and whether it suggests stopping, alongside any response from the tutor running the session; we use it to check whether those suggestions are any good. All of it is worked out from the answers already described; none of it is a new kind of information about the student, and none of it comes from anywhere other than their own practice on this site.

Those estimates are used to choose which questions to show next and to draw the progress charts the student, their parent and their teacher see. They are not used to make any decision with a legal or similarly significant effect, they are not shared with anyone outside the accounts described below, and they are never used for advertising.

Progress reports

A tutor can send a report about one of their students for a calendar month. It lists the topics where our estimate rose or fell by 10 percentage points or more, the topics practised, topics not practised for a while, work still to do, and how many sessions and questions were done. It is built only from the estimates described above. It never shows a tutor's marks, a session score, or a grade a tutor typed in, and it shows no number for a topic with too little work behind it, or for an estimate made only from related topics. The tutor may add a message of up to 2,000 characters.

We keep each report exactly as it was sent: its contents, the tutor's message, who sent it and when, and how many parents were emailed (not their addresses). A report can be read by the student, by a linked parent while they are linked, and by the tutor who sent it while they still teach the student. It is deleted with the student's account, and is included if the student or their parent asks us for their data.

Cookies

The public pages of this site — the worksheets, the home page, the page for tutors, this page and the terms — start no cookies of any kind. Arrive with an empty browser, read as much as you like, and you leave with an empty browser. That is the promise, and it is the one tested on every build.

There is exactly one way you can be reading a worksheet while holding a cookie from us, and it is worth spelling out rather than burying. If you have followed a password-reset link we emailed you and have not finished setting the new password, the short-lived session cookie described below is already in your browser, and every page you visit afterwards — worksheets included — will go on refreshing it until the reset finishes or it expires, which is within an hour. No worksheet page can create that cookie; it only ever arrives from a link you asked us to send you.

A few pages away from that surface do set a cookie, and every one of them is a strictly necessary cookie, which does not require consent under the Privacy and Electronic Communications Regulations:

• The sign-up pages — the tutor sign-up form, a tutor's join page (/join/…) and /register/ — set a csrftoken cookie. It is what stops another website submitting those forms on your behalf, so a form that creates an account cannot safely be served without it. It carries no identifier for you, it is set only on those pages, and it is never set while you are reading a worksheet.
• The password-reset and address-confirmation pages (/account/…) set the same csrftoken on the pages that carry a form, for the same reason. The page you land on from a reset link additionally sets a short-lived session cookie: it is how the single-use code from your email is taken out of the web address and held on our side while you type a new password, so that the code does not sit in your browser history, get passed on to the next site you visit, or ride in the address of every page you look at afterwards. It is deleted as soon as the reset finishes, and if you never finish it expires on its own within an hour — it is not allowed to outlive the code it is holding.
• The signed-in area sets a session cookie, and the same csrftoken, to keep an account holder signed in securely.

None of these cookies is an analytics, advertising or tracking cookie. We set none of those anywhere.

Children

This is a GCSE mathematics site, so we expect it to be used by under-18s, and we have designed it with the ICO's Age Appropriate Design Code in mind.

On the worksheet side, the strongest protection we can offer is still not to collect anything, and we do not: no sign-up, no profiling, no behavioural tracking, no advertising, no streaks or other techniques designed to extend use, and no third party receives any information about a visit because the pages contact no third party.

On the account side, children's accounts exist, and these are the rules they run under:

• A child under 13 cannot set up their own account. A tutor's join page asks for a date of birth, and if it puts a student under 13 it asks for a parent instead and keeps nothing they typed. A parent creates the child's account from their own, declares that they hold parental responsibility, and confirms from an email we send them, or uses an invitation from us. We record when they did each, and which wording they were shown. Until they confirm, the child can sign in but sees only a page saying they are waiting for their parent, nothing is recorded about them, and nobody else can see the account; if the parent never confirms, it is deleted after 7 days. This is the age the Data Protection Act 2018 sets for a child's own consent to an online service.
• Under 13, a parent consents, and we record it. When a parent sets up a child's account, we store — against the link between those two accounts — the date and time they did it and the version number of this policy that was in force at that moment. That is what a parental-consent record is here: the act of setting the account up is the consent, and it is timestamped and version-stamped. Where the parent added the child from their own account, we also record when we asked, when they confirmed from our email, and which version of the declaration they were shown, and their consent counts only once they have confirmed. On their first sign-in the child is told, in plain words, what that means and who can see their work.
• From 13, the student consents for themselves. We process a 13+ student's practice data only with their consent. A student who practises in lessons with their tutor, on the tutor's account, can give it in person, and we keep a record of who agreed, when and how. Every student aged 13 or over is also asked in the app, before anything else, the first time they sign in themselves, and their answer there is recorded with the rest. A child whose parent consented for them is asked again for themselves the first time they sign in after turning 13. A parent does not need to be involved.
• A parent sees a 13+ student's work only if the student says yes. The student is shown what the parent would see and asked. If they say no, the link is removed, the parent sees nothing, and we are told so that we can talk to the family.
• Every student is shown what a tutor can see: before they add one with the tutor's join code, or on their first sign-in after their parent or we add one.
• Age is self-declared. We ask for a date of birth, and a student's school year, and check that they agree; we do not store the school year. We confirm an email address, not anybody's identity, and we use no age-estimation technology. When a parent adds a child, the parent states the child's date of birth. For a family who arrives with a tutor's code, the controls are these checks and the tutor's acceptance; we do not know those families ourselves. A student account made before we asked for a date of birth is asked for one on its next sign-in, before anything else.
• Consent can be withdrawn at any time. A student aged 13 or over can do it themselves on the Your choices page in the app. For a child under 13, the parent can do it on their home page in the app, or email privacy@discia.org. Either way the account is closed at once: it cannot be signed in to, no parent or teacher can see it, and nothing more is processed. If the family changes its mind within 30 days, we can reopen it, and the student is asked for consent again. After 30 days the account and all of its practice data are deleted, and our encrypted backups of it are gone within a further 14 days.
• A student of 13 or over can stop a parent seeing their work at any time, on the Your choices page. It takes effect at once and we keep a record that they did it. A child under 13, or anyone on their behalf, can ask us at privacy@discia.org.
• From a student's 18th birthday a parent can no longer see their work. The link between the two accounts is removed automatically, and recorded. The student's account and their work are not affected.
• Discia does not check tutors. We do not check a tutor's identity or ask for a DBS certificate; each tutor confirms in our terms that they are not barred from working with children. Discia is a tool a tutor uses with families who have already chosen them; it does not introduce tutors to anybody and has no messaging. Ask to see your tutor's DBS certificate.
• When a student of 13 or over adds a tutor, a linked parent is told by email and on their home page, once the tutor accepts. The parent cannot stop it: from 13 it is the student's choice. A child whose parent added a tutor is asked again for themselves after turning 13.

We have also written this policy for young people, in plain words, with a short version for under-13s. Every student page shows, by name, who can see that student's work.

What a linked parent can see about their child

A parent account can see the children it is linked to — and, for a student aged 13 or over, only once the student has said yes — and for each of them: their name, their grades and score history, the confidence estimates described above, the list of practice sessions they have done, and the detail of each session down to the individual questions and the answers the child gave, and the progress reports their child's tutors have sent. A parent cannot see any other child, and cannot change a child's answers or marks.

What a teacher account can see

A teacher account can see students' practice data — grades, sessions and the answers within them — can set work, and can mark and correct the marks on their own students' work. Teacher accounts cannot author or publish questions. A teacher can read the lesson notes they wrote themselves, but never another tutor's notes, even about a student they share. A teacher can send a monthly progress report about their own student and read the reports they sent, but not another tutor's.

A teacher account is restricted to their own students. A teacher is given a student in one of two ways. The family types the tutor's join code into their own account — the student, if they are 13 or over, or the parent of a younger child — after being shown what the tutor will be able to see, and the tutor then accepts. Until the tutor accepts they see only the name the family gave them. Or the site's operator links them, as before: when the invitation is issued, by adding that student to the teacher's group, or by recording the link directly in our administration tools. A student can have more than one tutor; each is added and accepted separately. A teacher cannot give themselves a student: they cannot add one to their own list, search for one, or reach the record of a student who is not theirs. Parent accounts are restricted to their own children, and student accounts to themselves.

A student of 13 or over can remove a tutor at any time on their Your choices page, and a parent can for a younger child on their home page. A tutor can stop teaching a student, and the operator can end any link. The tutor's access goes at once. The student keeps all their work. Lesson notes the tutor wrote stay, readable only by the operator.

Two limits worth stating plainly rather than implying a stronger control than we have. A teacher who has been given a student can see all of that student's practice on this site, including work the student did on their own or for another teacher. And the site's operator holds an administrator account that can see every account and every record, which is what running the service requires.

If you contact us

If you email us — to exercise a right, to report a mistake in a worksheet, or for any other reason — we keep that correspondence, and whatever you choose to put in it, for as long as we need to deal with your query and for a short period afterwards. We use it only to answer you. We do not add you to a mailing list, because we do not have one.

Lawful basis: our legitimate interests (Article 6(1)(f)) in responding to people who contact us, or compliance with a legal obligation (Article 6(1)(c)) where you are exercising a data protection right and we are required to respond.

Our email is provided by Zoho acting as our processor. Zoho keeps it on servers in the European Union, and its staff in India and the United States can reach it for support, under the same contract terms as our outgoing mail (see Email we send).

Where your data is processed

The site runs on a server in Nuremberg, Germany, provided by Hetzner Online GmbH acting as our processor. The UK Government has determined that the EEA provides an adequate level of protection for personal data, so no additional transfer safeguards are required.

We keep off-site backups with Backblaze acting as our processor, in its European Union region. These are backups of the site's database and its images, so — unlike under version 1.0, when there were no accounts — they include account records and practice data. Every database backup is encrypted on our server before it is sent, with a key that is not kept on the server or with Backblaze. Server logs are still not backed up, so the request log described above never leaves the server it was written on.

How long we keep things

• Server access logs: 14 days, then deleted automatically.
• A student account and its practice data: while the account is in use, and for 12 months after it was last used. "Used" means the student signed in, practised or had work marked, or their tutor recorded a session, a grade or a lesson note for them. After 12 months with none of those, we email the parent on the account, and the student if we have their address, to say the account will be deleted in 30 days. Signing in during those 30 days keeps it. Otherwise the account and all of its practice data are deleted. If we have no confirmed email address for anyone in the family we do not delete automatically; we get in touch another way first.
• The record of each question a session would suggest next: 12 months, then deleted, whether or not the account is still in use.
• A parent's or teacher's own account: until it is closed. We close and delete one on request.
• When consent is withdrawn, or on request, we delete. The account closes at once and is deleted with its practice data 30 days later; see Children. A student of 13 or over can do this in the app. Anyone can email privacy@discia.org, and a parent may ask for their child's.
• Sign-in records: about 14 days. A sign-in stops working after 14 days and its record is deleted soon after.
• Invitations: 90 days after they are used, expire or are withdrawn. An unused invitation from us is only a role, an expiry date and a note about who the code was for. One made by sign-up also holds the email address and date of birth that were typed; if its link is never opened, it is deleted within three days of being asked for.
• A request to join a tutor that the tutor has not answered: 30 days, unless they accept or decline it, or the family removes it, first. Then it is deleted and the family's agreement to it is marked withdrawn; they can type the code again. A child a parent added and never confirmed is deleted after 7 days.
• A tutor's record of a student who left: 30 days, then deleted.
• Backups. Anything deleted may persist in an encrypted off-site backup until that backup is aged out, which is within 14 days. We do not restore deleted accounts from backup.

Email we send

Version 2.0 of this policy said the site sent no email at all, and promised that if that changed we would update this page at the same time as the feature rather than afterwards. This is that update. We now send eight kinds of message:

• Confirming an email address. When an account is created with an address on it, we send one message to that address containing a link. Opening it records that the address really reaches the account holder. It expires after a week, and you can ask for another. An account made from a sign-up link needs no second message: opening the link confirms the address.
• Resetting a password. Only in reply to somebody asking, and only to an address that has been confirmed. The link expires after an hour and stops working once it has been used.
• Before deleting an unused account. When a student account has not been used for 12 months, we email the parent on it, and the student, to say it will be deleted in 30 days unless it is used (see How long we keep things). Only to addresses that have been confirmed.
• Finishing a sign-up. When somebody asks for an account on the tutor sign-up form or a tutor's join page, we email the address they typed a link to finish it, which works once and for 48 hours. If that address already has an account, we send a note saying so instead, with links to sign in or reset the password. Never more than three a day to one address, whoever asks.
• Asking a parent to confirm a child. When a parent adds a child from their own account, we email them the declaration they made, with a link to confirm it while signed in.
• A receipt for a parent's consent. When they confirm, we email them a record of what they agreed to, the version of this policy, their child's username, and how to withdraw.
• A teenager's tutor accepted. When a student of 13 or over adds a tutor with the tutor's join code and the tutor accepts, we email each linked parent whose address is confirmed, naming the student and the tutor. We send nothing when the student only asks, or when the tutor declines.
• A progress report is ready. When a tutor sends a report about a student, we email each linked parent whose address is confirmed, to say it is there. The email names the student, the tutor and the month, and holds a link. The report itself is not in the email; it can only be read by signing in, so if a student stops a parent seeing their work, the parent loses the reports too.

That is the whole list. There is no newsletter, no marketing and no announcement email. Our messages are plain text: no images, no tracking pixel, no click-tracked links, nothing loaded from anywhere else when you open them.

Most children's accounts have no email address on them at all, because we do not ask a child for one. Those accounts receive nothing from us and cannot use the password-reset link — a parent, or whoever set the account up, changes the password instead. An address that has never been confirmed is in the same position: we will not send a reset link to it, and when somebody asks us to, the page they see says the same thing whether or not an account exists, so that nobody can use it to find out who has signed up here.

Outgoing mail is handed to Zoho ZeptoMail, a service of Zoho acting as our processor, which delivers it for us and, in doing so, processes the recipient's address and the contents of the message. Zoho keeps that data in its data centre in the European Union. Zoho's own staff in India and the United States can reach it for support and maintenance, under contract terms the UK recognises for transfers outside the UK (the EU standard contractual clauses with the UK addendum). In that sense an email address leaving an account here is transferred outside the UK. We use no other mail provider for outgoing messages, and we use it for nothing except the messages listed above. This transfer is one of the things the outstanding professional review noted at the top of this page is expected to look at.

Your rights

Under the UK GDPR you have the right to access your personal data, to have it corrected or erased, to restrict or object to its processing, and to data portability. To exercise any of these, email privacy@discia.org. We will respond within one month.

A parent or guardian may exercise these rights on behalf of a child under 13, and may withdraw their consent to us holding the child's data at any time. A student aged 13 or over can exercise them for themselves, and can withdraw their own consent in the app.

A tutor's private lesson notes about a student are that student's personal data too, even though the student and their parent cannot read them in the app. If a child or their parent asks us for a copy of the child's data, the notes are included.

If you have never created an account and have not emailed us, there is very little for us to act on: the only data we hold about a visitor is the server log lines described above, keyed to an IP address and deleted within 14 days. If you ask us to find it, please tell us the approximate date and time of your visit and the IP address you used, or we will not be able to identify it.

Complaints

If you are unhappy with how we have handled your personal data, please contact us first so we can try to put it right. You also have the right to complain to the Information Commissioner's Office, the UK supervisory authority: ico.org.uk/make-a-complaint, or 0303 123 1113.

Changes to this policy

If we change this policy we will update the version and date below, and summarise material changes at the top of this page. The version number is not decoration: it is recorded against every consent record, a parent's or a student's, so anyone can tell which version of this policy they agreed to.

When we change this policy in a way that affects what we collect, who sees it or how long we keep it, we show what changed the next time you sign in and ask you to confirm you have seen it. That is asked of a student aged 13 or over, and of the parent who gave consent for a child under 13. We keep a record of it.

Version 2.14 Published 19 October 2026